Perpetual IT

According to reports, Minnesota-based business travel company CWT is the latest victim of the latest trend in ransomware.

In fact, we’re probably at the point where we need to stop calling them just “ransomware” attacks, because it’s increasingly common that there’s a lot more to these attacks than just keeping you out of your files, which is how we usually think of ransomware.

When ransomware first became big news thanks to malware such as CryptoLocker, back in the early 2010s, the crooks behind the crime deliberately chose to use in-place encryption to tie up your computer.

They didn’t need to do it that way – they could have stolen all your files first and then deleted the copies off your computer, and then sold you back your files.

They could have proved they had the files by inviting you to name a couple and then sending them back for free – given that they wouldn’t know which names you’d pick, this would probably convince you that they had all the others, too.

But that approach would have been slow, and troublesome, especially when the crooks were targeting as many victims as possible and aiming to make $300 a time out of hundreds of thousands of people.

Back then, the average home user or small business on an ADSL connection just didn’t have enough upload bandwidth to make this sort of attack practicable – and getting the files back to victims who paid up would have been unreliable, too, which would have discouraged people from paying up on technical grounds as well as moral ones.

So the crooks encrypted the files in place, and all they needed up upload to themselves (and hide from you) was the decryption key – data that you could fit into a single network packet.

The encryption happened at disk speed, not network speed, so it was harder to spot and finished quickly.

Also, the early ransomware attackers went out of their way to provide the decryption keys to those who paid up as quickly as they could – paradoxically building up a reputation for ransomware gangs as “crooks who could be trusted”.

Well, the ransomware crooks are still scrambling your files in place, because that doesn’t just derail your business operations but also rubs the attack right in everyone’s face.

Your files are all there – you can see them, with the right names in the right directories – and in some ransomware attacks the crooks cynically don’t encrypt the first few thousand bytes of each file, so you can reach out and almost touch the contents if you want – or so it seems.

So near, but yet so far!

The good news is that, by now, many companies have adapted to the ransomware threat in two ways:

• Organisations are less inclined to pay up if they can possibly help it, because it feels all wrong, and law enforcement understandably urges victims not pay up and feed the criminals.
• Organisations have got better at backup and disaster recovery, so they are increasingly likely to be able to recover on their own.

A recent survey conducted by Sophos suggests that self-recovery after a ransomware attack typically costs much less than paying the crooks, for the simple reason that even after the crooks send you the decryption program, you still need to run it across all your systems, which requires much the same sort of time and effort as restoring backups. Ransomware decryptors aren’t magic bullets that instantly recover you data as soon as they hit your email inbox.

The bad news is that the crooks have adapted, too.

Some ransomware gangs not only scramble your files, but also steal the unencrypted copies first.

Given that ransomware gangs now mainly target businesses, where outbound network bandwidth is typically much better than on home networks, the crooks really can upload large tranches of data before encrypting files in place.

And given the low cost and easily availability of cloud storage, they don’t have to worry about running of of disk space.

In fact, they don’t need to steal all your files – just a sufficient quantity of juicy ones that they can use to prove their point.

You can’t be sure how much they did steal, but if they can wave even just a few potentially damaging samples in your face, you have to assume that they stole everything that matters.

Their ransomware demands are therefore no longer just sort-of blackmail, they absolutely are blackmail: “Pay the money or we’ll spill your trophy data to your customers, to the data protection regulators, to the SEC, to your competitors, heck, to anyone who wants to see it; and no amount of backup will save you from the fallout from that.”

So the ransom demand now has a double bite – you don’t have access to your data, but everyone else in the world soon will!

In CWT’s case, reports suggest that the criminals claim to have scrambled files on 30,000 computers and to have uploaded 2 terabytes of company data.

Although those high numbers sound doubtful, the double pressure was sufficient to put CWT between a rock and a hard place.

Apparently, the company finally settled with the crooks (we’re not sure “settled” is the right word, but that’s how the criminals treat these matters, as though they’re legitimate businesspeople) on paying $4,500,000 – in Bitcoin, of course – instead of the $10m that the crooks wanted at the start.

In return, they received the cryptographic material to decrypt the scrambled files, and a “promise” from the criminals that the stolen data is now gone for good.

(Assuming, of course, both that the crooks are telling the truth, and that the crooks themselves didn’t get hacked and have the data stolen from them in the interim via whichever cloud system they were holding it in.)

What to do?

• Use anti-ransomware tools to block file scramblers as early as you can. Even if no data gets stolen and you have comprehensive backups, recovering scrambled files costs time and money.
• Protect your login portals to stop outsiders getting access in the first place. Ransomware attacks often start through forgotten, insecure or unpatched systems, notably RDP servers (remote desktop protocol) that are there to let your own IT staff in. Don’t let crooks sneak in via the same route.
• Watch your logs. Most ransomware attacks are preceded by telltale signs, if you know what to look for and take the time to look. Existing malware can create backdoors for ransomware crooks; the creation of new but unexplained accounts usually indicates crooks spreading their wings; and the presence of sysdmin tools where you wouldn’t expect them is a sign of crooks preparing to pounce.
• Never give up on user awareness. Use tools such as Sophos Phish Threat to train your users to recognise scammy emails – phished passwords are also a common way for ransomware criminals to get in and form their beachhead. Set up an internal email or telephone reporting line where users can report nascent attacks and get the whole company to be eyes and ears for the security team.

Another month, another BWAIN!

That’s our tongue-in-cheek name for a cybersecurity vulnerability that not only gets assigned an identifier like CVE-2020-10713, but also acquires an impressive name plus a jaunty logo (and even, in one intriguing case, a theme tune).

This month’s bug with an impressive name (see what we did there?) is called BootHole, and its logo rather cheekily shows a boot with a worm sticking out of a hole in the toecap.

The bad news is that this bug affects the integrity of bootup process itself, meaning that it provides a way for attackers to insert code that will run next time you restart your device, but during the insecure period after you turn on the power but before the operating system starts up.

The good news for most of us is that it relies on a bug in a bootloader program known as GRUB, short for Grand Unified Boot Loader, which is rarely found on Windows or Mac computers.

The bad news for the sysadmins among us, however, is that GRUB (more precisely, GRUB2, but it’s often just referred to as GRUB) is the default bootloader used by several popular Linux distros these days.

In other words, if you have a rack of Linux servers somewhere, whether that’s a physical rack in your own server room or a virtual rack in a cloud service, you may have lots of important computers that are – in theory at least – at risk.

By the way, the logo that we referred to above as “cheeky” – because it features a worm – might be taken to imply that this is an wormable security hole.

A wormable hole would mean that a crook who could infect one of your servers with malware exploiting this bug might be able to kick off a self-spreading feature that automatically dissemimated the malware to other servers in the same rack, or perhaps even further afield.

We don’t want to say that’s impossible, because we can envisage server setups where you might just about be able to pull off that sort of caper in a pre-boot environment, but we think it’s unlikely.

Generally speaking, an attacker will almost certainly need to have superuser (root) access to your computer up front in order to exploit this vulnerability.

If you need to be logged in as root to start with, there’s no unauthenticated remote code execution (RCE) hole, which we assume is why Linux vendor Red Hat has given this bug a severity impact of Medium rather than High or Critical, even though it affects the boot process and could give attackers a way to implant malware that manipulates the operating system itself.

The bootup process

In the early days of PCs, the bootup process was almost totally unprotected.

When the power was turned on, the CPU ran a small program called the BIOS, short for Basic Input Output System, out of ROM, short for read-only memory. (This part was pretty secure, because the ROM firmware could only be changed by opening up the case and swapping out a special chip on the motherboard.)

The BIOS then blindly read 512 bytes from the first physical sector of the hard disk into a known location in RAM – memory addresses 0x07C00 to 0x07DFF, if you are interested – to act as the bootloader program.

If the last two bytes of that 512-byte sector were 0x55AA (chosen because it’s 01010101 10101010 in binary), known as the boot signature, it was assumed to be a legitimate bootloader and the BIOS then jumped directly to address 0x07C00 (0000:7C00 in 16-bit segment notation), and the bootup sequence commenced.

And that was that – the master bootloader code was supposed to locate the bootable partition, load a secondary boot sector from there, perform some basic verification of its own and hand over control in turn, whereupon the secondary boot sector would find the operating system kernel and load it, and so the process would continue.

This process is known as bootstrapping to this day, from the idea of “pulling yourself up by your bootstraps” – an impossibility in real life, thanks to Newton’s Laws of Motion, but nevertheless a metaphor in the English language for working yourself up into an influential position from humble beginnings.

Of course, in the old days, the boot sector could contain anything, and frequently did.

Corruption caused by writing to sector zero by mistake would typically leave your PC unbootable, while deliberate infection of the boot sector by viruses led to years’ worth of trouble caused by boot sector viruses with redolent names such as Stoned, Angelina and Michelangelo.

Notably, because the boot sector runs before your operating system – indeed, the operating system relies on the boot sector to load in the first place – it runs before any operating system protections are in place.

There’s no memory protection, no idea of privileged processes, no concept of user and superuser (also known as the root or administrator account), no access control lists on files or directories, nothing.

So crooks often used the boot sector to hide away hacking tools such as rootkits, malware programs that are specifically devised to disguise or conceal other malware by interfering with the operating system “from underneath”.

Adding in security

To protect the bootup process, most modern computers – whether they’re laptops, servers, NUCs or whatever – have a feature called Secure Boot, and on most devices it’s turned on by default.

The BIOS is replaced by a system called UEFI, short for universal extensible firmware interface, which isn’t blindly trusting like the BIOS process was. (Actually the BIOS still is there: you can turn most computers back into BIOS mode, also called legacy mode, if you want, but you typically need physical access to the computer to make the switch.)

In Secure Boot mode, the various stages of the bootstrap process are verified using digital signatures, based on cryptographic keys stored on the motherboard before the device is shipped. (On most computers you can replace these keys with your own to take control of the signing process, but once again you need physical access to do so.)

When you boot with GRUB, the process usually involves a chain of loading and digital signature checking that works a bit like this:

• Verify the UEFI firmware.
• Use the firmware to load the main bootloader.
• Verify the main bootloader, which on Linux systems is probably an intermediate bootloader called shim or PreLoader that is signed by Microsoft, whose signing key your computer hardware probably already trusts.
• Use the shim or PreLoader bootloader to load the GRUB bootloader, which is typically signed by the creator of your Linux distro.
• Verify the GRUB bootloader.
• Read in a text-based configuration file and present a bootloader menu.

The digital signatures make it hard for crooks to replace any of the bootloader programs, which helps to keep boot sector viruses and rootkits out of your system – it’s difficult for the crooks to insert low-level code that runs before the operating system and might therefore be able to subvert it right from the start.

You can guess where this is going, can’t you?

Text files can be harmful

That text-based configuration file we mentioned above isn’t digitally signed – at least, it isn’t checked by GRUB itself, and in most Linux distros there is apparently no additional process for validating the file before the operating system loads.

And the BootHole vulnerability is a parsing error in the GRUB bootloader that leads to a buffer overflow while the configuration file is being read in.

Oh no!

Text files are supposed to be pure data, but by feeding the GRUB bootloader a line that’s far too long, it seems that you can not only crash the bootloader code, but also wrangle control back from it, causing code execution to continue inside the data that just got read in from the text file.

Eclypsium, the company that found this vulnerability, reports that it’s the sort of bug that you might call a “comedy of errors”.

GRUB correctly detects that the line is too long for the buffer, catches the error, faithfully reports it where you might just about notice it pop up on the console if you were looking at the screen at exactly the right instant…

…and then ignores the error and carries on anyway.

Simply put: anyone who has root-level access to your computer, and can write text into the GRUB.CFG file, can sneak in bootloader code – what’s known as shellcode in the jargon – via that text file.

But because the text file is considered “mostly harmless”, in the words of the HHGttG, it is not subjected to the same digital signature controls as the other files that are part of the secure bootstrap process.

In other words, crooks can implant arbitrary bootloader code that will run next time you restart your computer, before the operating system starts up, without bothering about digital signatures.

Unfortunately, buffer overflows of this sort in bootloader code are almost always exploitable by attackers, because the comparative simplicity of the UEFI environment means that a lot of the exploit prevention mechanisms that modern operating system provide simply don’t exist.

During the bootstrap process, there are no protections such as Data Execution Prevention (which helps to stop data in an overflowed buffer from being executed at all) and Address Space Layout Randomisation (which makes it hard to grab control successfully even if you can reliably provoke a program crash).

If you’re a programmer then, in the world of bootloaders, it’s like 1984 all over again.

What to do?

Apparently, Eclypsium’s bug report prompted not just a bug fix in GRUB but a code review looking for other smilar coding errors, given the extra severity of buffer overflows in the bootloader world.

So the GRUB team has removed not only this bug (CVE-2020-10713) but also seven more, denoted CVE-2020-14308, CVE-2020-14309, CVE-2020-14310, CVE-2020-14311 CVE-2020-15705,CVE-2020-15706 and CVE-2020-15707.

With this in mind:

• Check your Linux distro for an update to GRUB if you use it. If you don’t need the size and complexity of GRUB, you might consider switching to a different bootloader.
• Consider monitoring your GRUB.CFG files for unauthorised modifications. If you don’t already have tools for doing this sort of thing, check out the command inotifywait. But remember that a criminal with root access to overwrite the GRUB configuration file in the first place might be able to turn off or bypass your change monitoring anyway.
• Review who has root-level access to your servers. You should do this anyway, and regularly, as much to prevent accidents as to keep crimimals out.
• Use 2FA whenever you can. This makes it easier to make sysadmins individually accountable, which protects them as much as it protects you, and it stops crooks using simple phishing or keylogging tricks alone to recover passwords.

Note that if you aren’t using Secure Boot, then your bootloader code isn’t protected by digital signature checking anyway, but it’s still worth considering all these tips, because it’s probably easier for crooks to mess with your bootloader via GRUB.CFG than by using low-level techniques to write to the bootloader files and disk sectors directly.

We suspect that there won’t be many computers out there that are pure-play Windows or Mac devices – ones that don’t have a Linux partition at all – running GRUB, but even if you aren’t affected directly by this bug…

…take heed of tips 3 and 4 anyway, because they’re good advice for everyone!

---

The Beatles famously sang about The Taxman back in 1966, when Britain had much higher taxes on the rich than it does now:

 Let me tell you how it will be There's one for you, nineteen for me 'Cause I'm the taxman, yeah, I'm the taxman Should five per cent appear too small Be thankful I don't take it all 'Cause I'm the taxman, yeah, I'm the taxman If you drive a car, I'll tax the street If you try to sit, I'll tax your seat If you get too cold, I'll tax the heat If you take a walk, I'll tax your feet 'Cause I'm the taxman, yeah, I'm the taxman

It was the era, if you like, where income tax boiled down to “you versus the Revenue”, the earner versus the government, the individual versus society.

How times have changed!

These days, there’s a very clear third player in the income tax game: cybercriminals.

Personal taxation now incudes a new sort of battleground, with taxpayers and the IRS as unexpected allies on one side of the fight, and cybercrooks on the other.

That’s because of what are known very descriptively as tax refund scams.

We’ve written about tax refund scams many times before on Naked Security, and the way they work is easily told.

Simply put, crooks figure out enough about you that they are in a position to submit a realistic looking tax return on your behalf…

…and then they do just that, except that they understate your income convincingly enough that the IRS pays out a refund, into a bank account provided by the crooks…

…who promptly run off with the money.

That means the crooks have stolen that money not just from you, not just from the government, but essentially from all of us – the refunded money gets drained out of the system and will never be seen again.

You end up with a fraudulent tax return filed against your name; the government ends up with a huge dent in its tax revenues; and the mess can take ages to sort out.

An unfair advantage

Annoyingly, the crooks have an unfair advantage here, just because of the way most of us – perfectly reasonably, and lawfully, and understandably – approach our tax returns.

Many countries give a fairly generous amount of time to submit tax returns, preferring slow but correct answers to hasty submissions that need constant revision, and many taxpayers (you know if you are one of them!) take a fairly generous amount of the available time to complete the paperwork.

As a result, tax refund scammers don’t have much trouble getting their fake returns in before real taxpayers submit their real ones.

Also, many if not most countries prefer you to file online these days, to reduce the cost of collecting taxes in the first place.

And many if not most taxpayers prefer to do just that, because it’s easier and less stressful than handling pages and pages of written forms as in the past.

As a result, tax refund scammers can scam in bulk and from afar- they don’t need to take the risk of visiting a tax office in person for each taxpayer they want to impersonate.

For example, the scammers will claim that they – which really means you, of course – were unable to work for a significant part of the year, for example due to injury or illness, and therefore that taxes witheld so far were greatly overpaid.

If the crooks can provide fake but believable documentation, tax offices in many countries will typically issue a refund automatically and fairly quickly.

After all, the tax office knows where you live, so they can and will prosecute you and claw the money back if you provide fake information, so an efficient refund system can be considered both fair and fairly safe.

Unless the money refunded is drained out of the system altogether, of course.

Plugging the leaks

Well, the IRS is determined to plug the leaks, especially during the coronavirus outbreak, where remote filing of everything has become the norm.

The IRS is currently in the middle of a five-step series called Working Virtually: Protecting Tax Data at Home and at Work, with help from government departments at state and federal level, taxation professionals and financial institutions.

Part 2 of the five-part series just came out and we can report that its primary advice is really simple:

Use multi-factor authentication to protect accounts.

Indeed, from 2021, the IRS will demand that all tax software vendors must offer multi-factor authentication, and expects all tax professionals preparing returns to make use of this feature:

Starting in 2021, all tax software providers will be required to offer multi-factor authentication options on their products that meet higher standards. Many already do so. A multi-factor or two-factor authentication offers an extra layer of protection for the username and password used by the tax professional. It often involves a security code sent via text.

Using multi-factor authentication is the second in a five-part series called Working Virtually: Protecting Tax Data at Home and at Work. The public awareness initiative by the IRS, state tax agencies and the private-sector tax industry – working together as the Security Summit – spotlights basic security steps for all practitioners, but especially those working remotely or social distancing in response to COVID-19.

[…]

Of the numerous data thefts reported to the IRS from tax professional offices this year, most could have been avoided had the practitioner used multi-factor authentication to protect tax software accounts.

What to do?

We know it’s an old drum, but we’re not tired of beating it yet: 2FA won’t sort out the problems of phishing and fraud, but it slows down cybercriminals significantly.

We know it’s an inconvenience: 2FA does add a bit of extra hassle to your online experience, but in return, you make things a lot harder for the crooks.

And we know there are plenty of excuses not to do it: your phone could get stolen; your SIM card could get swapped so that the crooks get your text messages instead; or you might lock yourself if you leave your phone at home.

But in most cases, your phone won’t get stolen (or if it does it will be passcode protected and inaccessible anyway); your SIM card won’t get swapped (and even if it does the crooks still need your password too); and you won’t lock yourself out (or at least not after the first time it happens).

Why it’s worth it

We’ve found 2FA to be a bit like seatbelts and bicycle helmets.

At first, they’re all kind of annoying to use, and you feel as bit as though they’re a vote of no confidence that assumes you will fail rather than backing you to succeed.

After a while, though, they don’t just feel acceptable but highly desirable – because the effort involved in using them is close to zero, and you start to feel naked without them.

Tax refund fraud isn’t just an injury to you, it’s an insult to everyone, so…

…please don’t delay, adopt 2FA today!

---

You’ve probably heard of a Blue Moon, which is the second full moon in any calendar month.

The last one was back in 2018; the next one is coming up in October 2020.

Well, 28 July 2020 is a Blue Firefox Update event – the second major security fix of the month, given that Mozilla now uses an every-four-weeks-on-Tuesday rhythm, and Firefox 78.0 came out on the first day of the month.

Interestingly, you don’t get double-scheduled-update months from many other sources, because Mozilla’s algorithm differs slightly from – and, in strict terms, is more regular than – other well-known schedules.

Microsoft and Adobe follow a process of “once each month on the second Tuesday”; Oracle has a system than delivers “four times a year on the Tuesday closest to the 17th day of the first month of each calendar quarter” (don’t ask us, we don’t know why!), and Apple favours the “when security fixes are ready they arrive, and we deliberately don’t say exactly when for security reasons” approach.

In other words, if Firefox tells you today that it’s got an upgrade ready, numbered 79.0 and giving you both feature updates and security fixes, it’s not a mistake even though you already had an upgrade at the start of July 2020.

The good news is that there are no “red-coded” critical security fixes this time, as you will see from Mozilla security bulletin MFSA2020-30.

Nevertheless, three bugs, denoted CVE-2020-15652, CVE-2020-6514 and CVE-2020-15655, are rated high, and it’s definitely worth patching to fix the middle one of these alone.

The CVE-2020-6514 bug was found by well-known Google bug-hunter Natalie Silvanovich, and is described as “WebRTC data channel leaks internal address to peer”.

In plain English, what this means is that a crook could, in theory, entice you to some sort of audio or video related URL – a chat session or similar – and trick your browser into revealing information about what’s stored where in memory.

Memory layout considered confidential

As we’ve explained before, most remote code execution (RCE) attacks – where crooks trick your browser into treating data as code and running it, bypassing any security checks or pop-up warnings – depend on the attacker being able to guess where to “land” in RAM on your computer.

Otherwise, the exploit will typically crash the browser completely rather than toppling it in the controlled way needed to take over the execution flow.

This sort of “soft landing” is deliberately made difficult by most operating systems through the fairly simple expedient of randomising the memory locations used each time a program runs for the first time after a reboot – a technique known by the self-explanatory name of ASLR, short for address space layout randomisation.

Crooks who figure out an exploit that works perfectly on their own system are unlikely to have it work correctly on anyone else’s computer…

…unless they can get hold of second vulnerability that leaks information about the browser’s currently-chosen position RAM.

Unfortunately, it sounds as though Firefox’s WebRTC system – used for real-time audio and video chat via browsers – used memory addresses as one-off tmeporary identifiers for WebRTC sessions, rather than just picking random numbers instead.

After all, two different blocks of RAM allocated for sessions that happen at the same time can’t be at the same address, so memory addresses often do make handy unique identifiers – but that’s a bit like using your social security number when a website asks to to pick a username that cold be anything at all.

So memory address leakage bugs often aren’t considered critical vulnerabilities on their own, but in a cunningly-deployed combination exploit, they might be just what a crook needs to turn some other theoretical RCE hole into a working attack.

One more thing…

Another bug that caught our attention, even though it only gets a grey-coded low rating, was CVE-2020-15658, described as “Overriding file type when saving to disk.”

By offering a download with weird characters in the filename, an attacker could trick you into approving a download that looks like one sort of file, and gets shown to you that way, but actually gets saved to disk as something very different.

Details are scant about the nature of this particular bug, but you can imagine how crooks could exploit a bug that offered you an image file with a safe-sounding download name such as KNOWN.EXE[WEIRD STUFF]NICE-PIC.JPG, only to end up sending you KNOWN.EXE instead – a file you’d never have approved otherwise.

What to do?

As usual, go to the Hamburger (three lines) icon at the top right of the Firefox window, then use Help > About Firefox to check for the 79.0 version and download it if needed.

If you’re using the Extended Support Release (ESR), your update should take you to 78.1.0esr (most recent ESR version) or 68.11.0esr (one-before-last) instead.

Remember that the leftmost two numbers in the ESR release added together (78+1 or 68+11 in this case) should come out the sameas the leftmost number in the regular release (79 here).

---

SophosLabs has just published a new report on a ransomware strain known as ProLock, which is interesting not so much for its implementation as for its evolution.

Let’s start at the very top of the ransomware dilemma.

Should you ever pay blackmail money to ransomware crooks?

As you can imagine, law enforcement and government bodies around the world reguarly say, “No! Please don’t, because it’s the regular payments that make the whole ransomware ecosystem work in the first place.”

Sure, in the 1990s, before anyone figured out how to make any real money out of malware, there were plenty of deeply destructive computer viruses that circulated widely and did huge amounts of damage.

It was often hard to figure out why anyone would write and deliberately disseminate malware back then, because those who were caught very often ended up serving prison sentences.

There were lots of possible reasons, of course: because virus writers had some sort of axe to grind with the world; because they wanted to make some sort of social or political statement; or simply because they could, and wanted to show off to their buddies in the cyberunderground.

Money didn’t really come into it at all back then, not least because there wasn’t a reliable way to extort money online and remain anonymous.

But malware in general, and ransomware in particular, doesn’t much follow that “anger at the world” path any more.

All about money

It’s almost all about money now – and as you are no doubt aware in the case of ransomware, the money demanded can be several million dollars per network attack.

So, if no one ever paid up, contemporary theory says that crooks would be much less inclined to bother attacking networks with ransomware in the first place.

That’s because most attacks require quite a lot of time and effort on the part of the crooks – this isn’t an after-hours hobby where hackers compare notes with underground chums, but a competitive cybercrime arena.

Ransomware gangs may take days or weeks to get their attack ready, for example by:

• Hacking, phishing or buying access to the network to get a beachhead for their attack.
• Acquiring domain administrator privileges so they have the same power as your own IT team.
• Mapping out the network in detail to figure out what and where to attack.
• Finding and eliminating online backups that could help in recovery.
• Testing and tweaking various ransomware samples to find one that is most likely to work.
• Reconfiguring network-wide security tools and settings to open up more of the network to attack.
• Identifying system services to shut down to maximise the number of files that can be overwritten.
• Stealing confidential company data from the network to increase their blackmail leverage.

Our own threat response team has even dealt with a ransomware victim where the criminals appear to have dug around in the IT department’s own email to find out what cyberinsurance arrangements the company had in place, and to gauge how high to pitch their ransom demand.

These crooks also downloaded personal contact data for key members in the IT team, and then placed a voice call (using a voice changer) to the IT manager to threaten him directly, reading out some of his personally identifiable information (PII) as proof that they had already exfiltrated corporate data.

We’ve also seen ransomware attacks where the criminals have emailed staff across the company to warn them that their own PII would be exposed to the world if the company didn’t pay up, urging the staff to contact their IT team to demand that payment be made – basically, turning the organisation against itself.

As you can see, the reaction of the crooks to the ever-louder advice, “Don’t pay!” has been to adjust their approach to make their demands more compelling, even against companies that feel sure they’d never pay up.

As a result, we’ve always taken a conciliatory approach that says, “We urge you to avoid paying up if there is any way you can. But if it’s legal to pay in your country, and you end up doing so, we’re not going to judge you for it, because it’s not the future of our business that’s looking into the barrel of a ransomware criminal’s gun.”

After all, if you genuinely have been caught out with inadequate backup, if every single computer in your company is essentially frozen and useless, if your business is almost certain to go down the tubes if you don’t pay up, and if paying up is likely to save the company…

…then it would be rather self-indulgent for anyone to insist, “You still shouldn’t pay up, even if it means that everyone loses their job.”

What if paying up won’t work

But what if paying up won’t work, no matter how stuck you are, and might even make your position worse?

That’s a problem that faced the ProLock ransomware gang earlier this year.

Last year, as far as we can tell, these crooks were behind ransomware called PwndLocker that – fortunately for the rest of us – could sometimes be decrypted without paying.

The crooks had apparently made a cryptographic blunder that sometimes allowed victims to recover the decryption key even after the encryption was finished.

Next came the ProLock ransomware strain, which ended up provoking a more-urgent-than-ever warning from the FBI that said:

The decryption key or “decryptor” provided by the attackers upon paying the ransom has not routinely executed correctly. The decryptor can potentially corrupt files that are larger than 64MB and may result in file integrity loss of approximately 1 byte per 1KB over 100MB. Added coding may be necessary for the decryptor to function.

Encryption with a difference

Interestingly, ProLock doesn’t actually scramble every byte of every file it attacks.

In the ProLock sample analysed by SophosLabs, the first 8KB (8192 bytes, or 0x2000 in hex) of every file are left untouched.

As a result, files of 8KB or below are unmodified, while files bigger than 8192 bytes are encrypted but with the first 8KB intact.

ProLock isn’t the first ransomware to use this trick – leaving the start of files alone – and there are three likely reasons why ransomware crooks do it:

• To bypass encryption detection tools that only keep tabs on the start of the file. Most ransomware scrambles the whole file, so monitoring access to the start of each file is an efficient way of spotting some, but not all, unauthorised changes.
• To fool common file-type identification tools. Some directory browsing tools show icons or list a text string that tells you what type each file probably is, e.g. “that’s an image”, “this one’s a PDF” and “that’s an application”. Many file types can be guessed with good accuracy from the first few bytes, so many type-guessing tools only read in than a few KB at most in order to run much faster.
• To give you a false sense of security. At first glance, you might think you’ve got away with the ransomware attack, given that some files are intact and some part of every file can be recovered.

We checked our own home directory and found that about two-thirds of our files were smaller than 8KB, which led us to think that a ProLock attack might not be that bad after all…

…except that the one-third of files that would get scrambled included almost everything of real importance, including all audio and podcast files and every video file, as well as most images, PDFs, documents, databases and presentations.

Only in the case of our Naked Security article archive would we have been “lucky” enough to retain just over half of our files, for the simple reason that we save the originals as plain text files, half of which are just under 8KB. (If saved as DOC or DOCX files, they would all come out well over 8192 bytes.)

ProLock also has some other interesting tricks to learn about, including obscuring the ransomware executable itself by hiding it inside a BMP (bitmap image) file that displays as an almost-uniform and apparently uninteresting black rectangle if you open it for inspection.

In a real-life ProLock attack, however, a PowerShell script that does not itself contain any ransomware code is used to unravel the EXE from the innocent-looking BMP file in order to launch it.

ProLock also contains a list of more than 150 different software products that it tries to spot in memory and kill off automatically, including enterprise applications (which typically keep files such as databases locked open, with the result that ransomware can’t get write access to those files), security software and backup tools.

What to do?

For the full and fascinating details of the ProLock ransomware, please visit the SophosLabs report.

You will learn:

1. What the ransomware does: how it gets in, avoids attention, and activates.
2. How Sophos products can detect and block ProLock at many different stages of its attack.
3. A full list of Indicators of Compromise (IoCs) that you can use to learn more about what it does, and to search for evidence of the malware on your own systems.

---