Perpetual IT

You’ve probably heard of Zlib, but even if you haven’t, you’ve almost certainly used it.

Zlib’s unashamedly 1990s-style website describes the product as A Massively Spiffy Yet Delicately Unobtrusive Compression Library (Also Free, Not to Mention Unencumbered by Patents).

Data compression software (and, of course, the matching code to decompress it later) has always been handy to have around, as anyone who has ever used software such as PKZIP, WinRAR, 7-Zip and any of a great number of archiving tools will attest.

As you can imagine, the primary purpose of data compression is to save space, such as reducing the storage capacity needed for backups or cutting down on the bandwidth used for data transfer.

Often, however, despite the computational overhead added for squashing and expanding the data before and after storing or sending it, compression saves time as well as space, simply by reducing the amount of data that needs to be shuffled back and forth between a fast storage location such as RAM (memory) and a slow one such as disk, tape or network.

An internet standard

Zlib’s compression algorithm is known simply as DEFLATE.

Although the algorithm was originally part of a patent for use in the commercial compression software PKZIP, it was adopted as an internet standard in RFC 1951 DEFLATE Compressed Data Format Specification version 1.3, published in 1996.

RFC 1951 notes that, despite the patent on PKZIP’s version of the process, “[t]he format can be implemented readily in a manner not covered by patents.”

Ironically, perhaps, Zlib and its companion tool gzip (which compresses individual files using the Zlib algorithm) are probably best-known to users of Unix/Linux, because they were introduced as a replacement for the once-ubiquitous Unix tool compress, which performed a similar function with a similar sort of algorithm.

But fears over compress getting caught up in patent arguments meant that the Unix community sought an unencumbered equivalent that wouldn’t suddenly vanish from use due to legal arguments over its provenance.

Zlib and gzip, based on the known-and-already-trusted DEFLATE algorithm, were the answer to this dilemma, and given that Zlib compressed better and faster, as well as being legally unencumbered, meant that it quickly took over the role of compress.

Zlib still very widely used

Interestingly, numerous modern compression schemes provide significantly better compression, primarily by using lots more memory to keep track of repeated text (e.g. 7z for arbitrary data), or by equipping each end with a substantial dictionary of oft-repeated text strings (e.g. Brotli for compressing web pages).

But Zlib’s DEFLATE is nevertheless still the most likely compression scheme you’ll find, because it’s been so widely used for so long, and is therefore “built in” to numerous widespread file formats.

For example, Office documents such as DOCX and XLSX files are stored in ZIP format, using the DEFLATE algorithm to save space; so are Java JAR files and Android APK files; and PNG graphics files use Zlib compression internally.

Likewise, a huge number of web pages – probably the majority of pages you’ll visit – are compressed for transmission using Zlib, even though Google’s Brotli algorithm, which usually compresses better, is now widely supported by web servers and browsers alike.

What this means is that many apps you use regularly will include code not only to decompress Zlib data when reading it in, but also to compress to Zlib format when saving or sending data, because DEFLATE is a sort of lingua franca for compressed data.

And any of these apps – perhaps even most of them, if you’re on Linux or Unix – will use the Zlib implementation of DEFLATE, often in the form of a shared library (a DLL on Windows) called libz.so or LIBZ.DLL.

In a quick test on our Linux laptop, we found that the following apps all loaded the libz.so shared code into memory, ready for use if needed: the browsers Firefox, Edge, Chromium and Tor; the PDF reader Xpdf; the popular media player VLC; the Word-and-Excel compatible software LibreOffice; the image editor GIMP; and even our favourite HP desktop calculator emulator, Free42.

Surely no bugs left?

With a legacy that long, and with an algorithm that was locked down as an internet standard back in 1996, you’d no doubt assume that Zlib had very few bugs left, and that any serious ones, such as those leading to the sort of memory corruption that could be exploitable for remote code execution (RCE), would have been found by now.

After all, memory corruption errors, when triggered by mistake by randomly weird input, typically give themselves away by causing the app concerned to crash, which in turn typically leaves behind a telltale error trace saying which part of the program provoked the crashworthy behaviour.

And with all sorts of data getting compressed and decompressed all the time, often without you realising it (e.g. between a web server and your browser, where Zlib typically squashes and unsquashes the data invisibly for transfer)…

…you’d expect that even the most esoteric memory mismanagement bugs would be outed in the end, if only by chance.

Well, Google bug-hunter Tavis Ormandy, who has uncovered some truly funky bugs in his storied bug-hunting career, just found a curious and possibly, just possibly, exploitable bug in the Zlib code…

…only to discover, when he came to report it, that it had been reported and patched before, back in 2018, when it was wryly noted as being 13 years old:

This bug was reported by Danilo Ramos of Eideticom, Inc. It has lain in wait 13 years before being found! [2018-04-20]

Somehow, though, the patch committed back on 20 April 2018 never made it into an update to Zlib, for the simple reason that until 2022-03-27, the previous release of the library was published on 2017-01-15, more than five years ago.

As Ormandy noted in his bug report:

Greetings list, I was recently trying to track down a reproducible crash in a compressor. Believe it or not, it really was a bug in zlib-1.2.11 when compressing (not decompressing!) certain inputs.

I reported it upstream, but it turns out the issue has been public since 2018, but the patch never made it into a release. As far as I know, nobody ever assigned it a CVE.

Ormandy’s surprise above is not just that the bug inadvertently went unfixed for all that time, but also that he’d discovered a potentially exploitable buffer overflow in the compression part of the code, rather than the decompressor.

Memory mismanagement can happen anywhere that a programmer is careless with which data gets written where, but in compression software it’s much more common to find this sort of bug in code that expands data from its compressed format, most notably because you can’t reliably determine how much memory space you’ll need to decompress everything safely until you actually try decompressing it.

(Many compression formats include a header that tells you how much space you’ll need to extract the data, but you can’t rely on that information because it could have been understated deliberately by an attacker to confuse your code and crash your decompressor on purpose.)

Astonishingly, if not actually amusingly, the fact that the bug was first investigated in 2018 means that the official bug number for this vulnerability is CVE-2018-25032, even though it was only assigned this week.

What to do?

• If you’re a user or a sysadmin, update to Zlib 1.2.12. Most Unix and Linux distros should provide this update for you. Although this bug is difficult to trigger, there are many places, notably on servers, where untrusted data that was supplied by an outsider gets compressed automatically and then archived, logged or transmitted by the system.
• If you’re a programmer, never assume that the “last bug” must have been found by now. Pay special attention to esoteric or unusual paths through your code that rarely get activated in real life – you may find bugs that time alone was not enough to expose by chance. If your code supports options that are not only rarely used but also not strictly needed, consider removing those parts altogether. You can’t trigger a bug in code that isn’t there.
• If you’re a product manager, never assume, just because a patch was produced, that it must have made it into the shipping code. Make sure that your software doesn’t have bugs that have been patched yet never actually fixed!

The price of freedom from bugs, as Mr Jefferson might have said, is eternal vigilance.

---

Last time we reported on a Chrome zero-day flaw was back in February 2022.

Back then, Google noted that the Chrome browser – and, by implication, all other browsers based on the Chromium-project code and its underlying Blink rendering engine – had been patched against a range of memory mismanagement bugs that were potentially exploitable for remote code execution (RCE).

In the browser world, RCE vulnerabilities, if successfully abused, often mean that merely viewing a web page containing booby-trapped content could leave you with uninvited, unapproved program code implanted onto your computer – an active malware infection, to put it bluntly.

(Note that we used the word could above, not will, given that browser exploits are often fickle flaws that are unreliable even when used deliberately in anger, perhaps leaving you with a crashed browser but an otherwise unharmed computer.)

Anyway, back in February 2022, none of the bugs listed by Goole got a truly dangerous rating of “Critical” (they maxxed out at the level “High”), but one of them, dubbed CVE-2022-0609, was nevertheless accompanied by the admittedly rather vague words: “Google is aware of reports that an exploit for CVE-2022-0609 exists in the wild.”

Saying that someone’s told you that a working exploit exists is not the same as admitting that you’ve actually seen the exploit yourself, of course, and that, in turn, means that you can only assume that the patch you’ve just created really does prevent any alleged “in-the-wild” attacks.

Indeed, in the case of CVE-2022-0609, Google’s Threat Analysis Group needed until late in March 2022 to follow up with a detailed report.

In that report, Google’s researchers claimed they’d tracked the first use of this exploit right back to the start of January 2022, and suggested that it had been abused by two different North Korean hacking groups.

Once more unto the breach…

Well, March 2022 has brought us another Chrome exploit listed with the dreaded words, “Google is aware of reports that an exploit for CVE-2022-1096 exists in the wild.”

In fact, CVE-2022-1096 is the only security fix listed in the 2022-03-25 Chrome update advisory, which announces the release of Chrome version 99.0.4844.84.

Unfortunately, as you’ll see if you read Google’s report on the CVE-2022-0609 zero-day mentioned above, details such as who’s using a known exploit, where they’re using it, what they’re using it for, and how reliably the exploit works in real life, can be hard to figure out, especially if the attackers guard the exploit carefully.

Indeed, if you’ve ever experienced what’s known in the jargon as malvertising (booby-trapped web content that’s delivered semi-randomly via a hacked ad network, causing intermittent and unpredictable malware warnings to pop up, perhaps even on mainstream sites), you’ll know just how elusive web threats can be:

Even if your chosen anti-virus software detects and blocks an attack against your browser, so you know to report it, there’s no guarantee that the threat researchers who investigate will be able to coax the same misbehaviour that you did out of the compromised servers.

And even if you are able to find left-over remnants of the attack, such as temporary JavaScript code left behind in a cache file on disk, it won’t be much use if it depended on a random run-time decryption key that was only ever stored in memory…

…especially if the exploit succeeded only because your browser crashed and took the memory-based decryption key with it.

What to do?

Until Google is able to acquire, and decides to share, specific details about this CVE-2022-1096 zero-day attack, there aren’t any definitive indicators of compromise (IoCs) that you can rely upon to see whether it’s been used against you.

Your best bet, as always, is: Patch Early, Patch Often.

If you’re a Chrome (or Chromium) user, you can type the the special URL chrome://version into the address bar to show you the precise details of the version you’re currently running.

(Google’s security advisory notes that the update applies to Windows, Mac and Linux; there’s no mention of what version number to look for on Android, or even if Chrome on Android is affected.)

If Chrome hasn’t already fetched the latest version for you automatically, go to DotDotDot (the More menu) in the top right, then use Help and About to access the update dialog: you want 99.0.4844.84 or later.

---

You’ve almost certainly heard of the LAPSUS$ hacking crew.

That’s lapsus, which is as good a Latin word as any for “data breach”, followed by a dollar sign, like a text variable in BASIC.

Microsoft refers to this cybergang by the more pedestrian moniker of “the DEV-5037 actor”, and noted, in a blog post earlier this week, that the group has been involved in:

[A] large-scale social engineering and extortion campaign against multiple organizations, with some seeing evidence of destructive elements.

According to Microsoft, the scale of the LAPSUS$ infiltrations has been huge:

Early observed attacks by DEV-0537 targeted cryptocurrency accounts resulting in compromise and theft of wallets and funds. As they expanded their attacks, the actors began targeting telecommunication, higher education, and government organizations in South America. More recent campaigns have expanded to include organizations globally spanning a variety of sectors. Based on observed activity, this group understands the interconnected nature of identities and trust relationships in modern technology ecosystems and targets telecommunications, technology, IT services and support companies – to leverage their access from one organization to access the partner or supplier organizations. They have also been observed targeting government entities, manufacturing, higher education, energy, retailers, and healthcare.

Source code grab

Indeed, as the article goes on to admit, Microsoft itself was one of the companies that LAPSUS$ managed to compromise, allegedly making off with gigabytes of Microsoft source code.

Fascinatingly, Microsoft notes that the LAPSUS$ crew went public even while that data theft was in progress (the group seems to like bragging openly on Telegram about hacks it’s busy with and businesses that it’s determined to embarrass).

The Microsoft security team wryly noted that “[t]his public disclosure escalated our action allowing our team to intervene and interrupt the actor mid-operation, limiting broader impact.”

Other cybercrimes attibuted to LAPSUS$ include a January break-in at 2FA (two-factor authentication) service provider Okta, which ultimately only came to light this week…

…and an unusual extortion attempt against graphics card company Nvidia, which we discussed two weeks back on the Naked Security Podcast:

Most ransomware extortions, whether they’re old-school ransom notes offering decryption keys to unlock scrambled files, or whether they follow the more recent cybercrime path of blackmailing companies in return for not leaking, selling or dumping stolen data…

…demand money, often huge amounts of money, to be paid in cryptocurrency.

But in the Nvidia standover, the LAPSUS$ gang variously demanded Nvidia to open-source its graphics drivers, or to remove the limitations imposed on recent Nvidia graphics cards to restrict their use in cryptomining:

Seven suspects busted

Tonight, the news wires are buzzing with stories stating that seven suspected hackers have been arrested in the UK, with many headlines insisting that this is a “LAPSUS$ bust”.

So far, however [2022-03-25T00:01Z], we haven’t actually seen anything that explicitly connects these arrests with the DEV-0537 a.k.a. LAPSUS$ group.

The closest we’ve seen is a report on popular technology site TechCrunch quoting a City of London Police officer as saying:

[We have] been conducting an investigation with its partners into members of a hacking group. Seven people between the ages of 16 and 21 have been arrested in connection with this investigation and have all been released under investigation. Our enquiries remain ongoing.

You may also have seen reports earlier this week about a doxxing incident dating back to January 2022 in which a youngster allegedly from the Cherwell District in Oxfordshire, England, was “identified” as a kingpin in LAPSUS$.

Doxxing is where a cybercriminal publicly dumps what they claim is detailed personal information about another criminal they’ve fallen out with, or about a victim whose life they want to throw into disarray. “Dox” is short for “documents” in the same way that “tix” is short for tickets, so the verb “doxxing” means dumping official, or at least official-sounding, details about someone’s life, possibly also including information about their family.

Cybersecurity journalist Brian Krebs, for example, recently published an investigative writeup about LAPSUS$ and this alleged ringleader, who apparently uses a variety of handles including white and breachbase.

Intriguingly, the doxxed data claims that the youngster is 17 years old (he would have been 16 back in January, when the data was dumped), which would indeed put him within the 16-to-21 age bracket of the seven suspects arrested today, albeit that he would not be the youngest.

The unknown unknowns

As far as we are aware, however, neither the Thames Valley Police, who look after law enforcement in the Oxfordshire area (and who are, ironically, themselves headquarted in the Cherwell District), nor the City of London Police, whom we quoted above, have yet gone public with any specific information about these busts.

So we don’t officially know whether the alleged kingpin of LAPSUS$ is amongst the seven who’ve been busted, or even if the arrests are related to LAPSUS$ at all. (If breachbase were amongst those arrested, of course, the police would not identify him anyway if his age were 17.)

Watch this space – this is almost certain to get interesting!

---

LISTEN NOW

With Doug Aamoth and Paul Ducklin.

Intro and outro music by Edith Mudge.

You can listen to us on Soundcloud, Apple Podcasts, Google Podcasts, Spotify, Stitcher and anywhere that good podcasts are found. Or just drop the URL of our RSS feed into your favourite podcatcher.

---

In January 2021, reports surfaced of a backup-busting ransomware strain called Deadbolt, apparently aimed at small businesses, hobbyists and serious home users.

As far as we can see, Deadbolt deliberately chose a deadly niche in which to operate: users who needed backups and were well-informed enough to make them, but who didn’t have the time or funds to give their backup routine the attention it really deserved.

Many ransomware attacks unfold with cybercriminals breaking into your network, mapping out all your computers, scrambling all the files on all of them in unison, and then changing everyone’s wallpaper to show a blackmail demand along the lines of, “Pay us $BIGVAL and we’ll send you a decryption key to unlock everything.”

For large networks, this attack technique has, sadly, helped numerous audacious criminals to extort hundreds of millions of dollars out of organisations that simply didn’t have any other way to get their business back on track.

Deadbolt, however, ignores the desktops and laptops on your network, instead finding and attacking vulnerable network-attached storage (NAS) devices directly over the internet.

To be clear, the decryption tools delivered by today’s cybercriminals – even when the amount involved is hundreds of thousands or millions of dollars – routinely do a mediocre job. In our State of Ransomware 2021 survey, for example, half of our respondents who paid up nevertheless lost at least a third of their data. In fact, a third of them lost more than half of the data they paid to recover, and a disastrously disappointed 4% paid full price but got nothing back at all.

No lateral movement required

By exploiting a security vulnerability in QNAP products, the Deadbolt malware didn’t need to get a foothold on your laptop first, and then to spread sideways through your home or business network.

A remote code execution (RCE) hole identified in QNAP’s security advisory QSA-21-57 could be exploited to inject malicious code directly onto the storage device itself. (Like many internet-connected hardware devices, the affected products run a customised Linux distribution.)

So, if you’d inadvertently set up your backup device so that its web portal was accessible from the “internet side” of your network connection – the port that’s probably labelled WAN on your router, short for wide-area network – then anyone who knew how to abuse the security hole patched in QSA-21-57 could attack your backup files with malware.

In fact, if you were in the habit of looking at your device only when you needed to recover or review files you didn’t have space to keep “live” on your laptop, you might not have realised that your files had been scrambled until you next went to the web interface of your NAS.

When you got there, however, you’d be in no doubt at all what had happened to your data, because the Deadbolt attackers deliberately modified the portal page of the NAS itself to confront you with the grim news:

Intriguingly, the criminals behind this attack don’t supply you with an email address or a website by which to get in touch.

The crooks instruct you to contact them simply by sending the blackmail money to a specific Bitcoin address (in current attacks, they’re demanding BTC 0.03, presently about $1250 [2022-03-23T15:00Z]).

Reply by blockchain

They promise to send you the 16-byte decryption key you need via a return transaction, encoding the data as a transaction message on the public Bitcoin blockchain:

The business of using cryptocurrency blockchains for exchanging messages with cybercriminals is common these days. In the infamous Poly Networks hack, where a crook stole cryptocoins collectively worth about $600,000,000, the company notoriously negotiated with the attacker via messages on the Ethereum blockchain. After sending a rather bizarrely worded series of justifications for the cryptocrime, the attacker suddenly messaged 52454144 5920544f 20524554 55524e20 54484520 46554e44 21, which comes out as READY TO RETURN THE FUND! Poly Networks began referring to him as Mr White Hat; agreed he could keep $500,000 as a curious sort of bug bounty; and ultimately, if amazingly, got the lion’s share of the missing cryptocoins back.

The all-you-can-eat buffer

Also, perhaps taking a leaf out of the playbook tried by the Kaseya ransomware criminals, the Deadbolt crew have included what you might call a “meta-blackmail” demands aimed at QNAP, the makers of the device itself.

For BTC 5 (just over $200,000 today), the crooks claim that they’ll reveal the vulnerability to QNAP, although that offer seems redundant in March 2022 given that QNAP’s QSA-21-57 bulletin states that it identified and patched the hole itself jack in January this year.

And for BTC 50 (more than $2 million today), the crooks promise to provide a magic “all-you-can-eat buffet” ticket that will decrypt any device infected with the current strain of Deadbolt malware:

The Kaseya gang notoriously demanded $70,000,000 for their “ultimate decryptor”. (Whether that was in the hope that victims might rally together and actually pay up, or simply to thumb their noses at the world, we couldn’t tell at the time.)

Interestingly, with one of the alleged perpetrators of the Kaseya attack now awaiting trial in Texas, we may yet find out more about that $70m blackmail note:

Good news and bad news

The good news in the Deadbolt story is that QNAP not only published a patch for the QSA-21-57 vulnerability back in January 2021, but also apparently went on to take the unusual step of automatically pushing out that update even to devices with automatic updating turned off.

The bad news is that the online internet security scanning service Censys is reporting that Deadbolt infections have suddenly leapt back onto its radar, with more than 1000 affected devices showing up in the past few days.

As it happens, spotting devices affected by this malware is fairly easy.

If a publicly accessible IP number has a listening HTTP server, then the first few lines of HTML sent back in web server’s main page will give away whether that the server has already been scrambled by Deadbolt (or, alternatively, that it’s deliberately pretending to have been attacked).

As you can see in the screenshots above, the Deadbolt extortion page has a dramatic, all-caps title that is easy to detect using a simple text search at the top the HTML page, which starts like this:

<!DOCTYPE html>
<html lang="en"> <head> <meta charset="UTF-8"> [. . .] <title>ALL YOUR FILES HAVE BEEN LOCKED BY DEADBOLT.</title> [. . .]

What we can’t tell you is why these infections have returned.

Admittedly, 1000 visibly affected devices is a tiny number against the size of the global internet and the huge number of devices QNAP has sold, so it’s perfectly possible that these numbers have arisen entirely from devices that failed to update back in January and February, despite QNAP’s efforts to update everyone regardless of their auto-update settings.

It’s also possible that the crooks behind Deadbolt have come up with a brand new exploit, or a variation on the exploit they used before, though you might expect a bigger surge in new Deadbolt infections if the crooks really had come up with a fresh attack.

And it’s even possible that some unpatched devices that were theoretically at risk before, but weren’t exposed to the internet, have recently been opened up to attack by by users hurriedly “reviewing” and revising their network configurations – and perhaps promising themselves to “make more backups more often” – in the light of current cybersecurity anxieties provoked by the war in Ukraine.

We suspect, however, that the Deadbolt crooks, or someone associated with them, simply decided to have another try, on the grounds that what worked before might very well work again.

Whatever the reason, you’ll be happy to know that no one seems to have paid up, because the Bitcoin address redacted in the screenshots above (we saw just one address, for victims and QNAP alike, in all the recent samples we looked at) currently shows a balance of zero, and an empty transaction history.

A grand cracking challenge

Fascinatingly, the Deadbolt crooks have left a tempting but as-good-as-impossible clue to that 50-bitcoin master decryption key, right in the blackmail page they install on each infected device.

If you enter a decryption key, the web page itself checks to see if it’s valid before activating the decryptor, presumably to prevent you from “decrypting” the data with the wrong key, which we’re guessing would leave you with doubly-encrypted, garbled data rather than stripping off the encryption originally applied.

To prevent you simply reading the decryption key out of the JavaScript source, the web page checks that the decryption key you enter has the SHA-256 hash it expects, rather than directly comparing your input with a text string stored in the code.

And although you can easily go forwards from the correct key to the matching hash, SHA-256 is specifically designed so you can’t go the other way, thus allowing the right password to be verified if you know it already, but not to be recovered if you don’t:

function check_key() { sha256_hex_bytes($('keyinput').value).then(r => { if (r === "xxxx[REDACTED]xxxx") { // <--this one is unique to each attack $('key_info').innerHTML = 'correct key detected...'; $('keysubmit').style.display = 'inline'; $('keysubmit').disabled = false; } else if (r == "93f21756aeeb5a9547cc62dea8d58581b0da4f23286f14d10559e6f89b078052") { $('key_info').innerHTML = 'correct master key detected...'; $('keysubmit').style.display = 'inline'; $('keysubmit').disabled = false; } else { $('key_info').innerHTML = 'invalid decryption key entered.'; $('keysubmit').style.display = 'none'; $('keysubmit').disabled = true; } })
}

As you can see, there’s a test for the one-off key unique to your infected device, but there’s also a test that claims to check whether you’ve put in the multi-million dollar master key offered for sale to QNAP.

So, if you can figure out the input data that would produce a SHA-256 hash of 93f21756 aeeb5a95 47cc62de a8d58581 b0da4f23 286f14d1 0559e6f8 9b078052 …

…you’ve just cracked this particular ransomware for everyone.

What to do?

Here’s our advice for protecting specifically against this malware, as well as protecting generally against network attacks of this sort:

• Don’t open your network servers up to the internet unless you really mean to. QNAP has advice on how to prevent your NAS device from receiving connections from the public internet by mistake, thus preventing your device from being accessed or even discovered in the first place. Perform a similar check for all the devices on your network, just in case you have private devices that can inadvertently be “tickled” from the internet.
• Don’t rely on automatic patching working every time. Whether it’s a NAS device, your mobile phone, a smart TV or a laptop, don’t simply “set and forget” automatic updates. Regularly verify that any updates you do receive, whether they’re forced on you, automatically fetched or manually requested, have gone through correctly.
• Don’t use Universal Plug-and-Play (UPnP). The UPnP “feature” sounds very useful, because it’s designed to allow routers to reconfigure themselves automatically to make network setup of new devices easier. But it comes with enormous risks, namely that your router might inadvertently make some new devices visible through the router, thus opening them up to untrusted users on the internet. QNAP’s advisory shows you how to prevent your NAS device from usin UPnP, but we also recommend that you turn off uPnP in your router itself. If you have a router than supports UPnP but won’t let you turn it off, get a new router.
• Don’t rely entirely on online backups. Along with any online backups such those made to connected NAS units, you should also maintain an offline backup that can’t be wiped out automatically in a cyberattack.

When it comes to backups, you might find the “3-2-1 rule” handy.

The 3-2-1 principle suggests having at least three copies of your data, including the master copy); using two different types of backup (so that if one fails, it’s less likely the other will be similarly affected), and keeping one of them offline, and preferably offsite, so you can get at it even if you’re locked out of your home or office.

Remember to encrypt your backups so that stolen backup devices can’t be accessed by the thieves.

---

---

If you don’t have the experience or the time to maintain ongoing threat reponse by yourself, consider partnering with a service like Sophos Managed Threat Response. We help you take care of the activities you’re struggling to keep up with because of all all the other daily demands that IT dumps on your plate.

Not enough time or staff? Learn more about Sophos Managed Threat Response:
Sophos MTR – Expert Led Response  ▶
24/7 threat hunting, detection, and response  ▶

---