Anatomy of a ransomware attack
Ever wondered how all this high-tech financial half-inching and data scrambling works? Wonder no more.
Unfortunately, if you fall victim to a ransomware attack and don’t have any backups, it’s probably too late to do anything about it. The usual asking price to unlock is around $500, though many variants will threaten to increase this amount after a couple of days, and may even threaten to make decryption impossible after longer. These threats just provoke anxiety in the victim, who’s then more likely to pay up before considering the merits of doing so.
What is important to remember is that while there’s a possibility that whoever’s in control of this malware is reasonable enough to provide a decryption key, there’s also the possibility that they won’t. Their business model, after all, is to collect payments, so why should they bother with the extra admin of sending an email after that is achieved? It’s not like people who receive a key will recommend that particular strain of malware to their friends.
Be that as it may, whether or not you have access to it a decryption key probably does exist somewhere. There is of course malware that just deletes everything – this class of malware is known as a wiper and would fall into the Chaotic Evil category in D&D – but this doesn’t offer criminals much in the way of revenue generation. Since crypto is hard, the people peddling ransomware often get it wrong and it is possible to recover a decryption key without becoming a victim of extortion. To understand how this is possible, it’s necessary to understand how all this key generation malarkey works.
Traditional symmetric encryption relies on two people being able to agree on a secret key by a secure channel. That channel might be a meeting in the woods, or sealed message delivered by a trusted intermediary. Today’s numerous, distant electronic transactions do not allow us this luxury. We can’t go whisper to our buddy at Paypal every time we want to pay for something online; every transaction requires a new key to be negotiated.
Fortunately we now have public key (asymmetric) encryption which
““Ransomware that phones home to some central server could use symmetric encryption to perform its sordid garbling. ”
enables us to negotiate a shared secret with a remote other party, be it a person or a machine, even if we’ve never met them. This is what underlies the key-exchange part of SSL/TLS (used in HTTPS), SSH and PGP communications. Public key crypto is also intrinsic to the workings of all cryptocurrencies. It’s a fascinating subject, and also a strange concept to get your head around, but we’ll leave you to ponder it at your leisure. All you need to know is that it requires parties to hold not one but two keys – a keypair; that only one of them needs to be kept secret; and that random numbers are involved.
Ransomware that phones home to some central server could use symmetric encryption to perform its sordid garbling. A random key and a unique identifier could be generated on the target machine and both of these numbers sent and then stored on that command and control (CC) server. All traces of the key would be removed from the victim’s machine once files had been duly scrambled, and the unsuspecting victim would then send the requested ransom, together with their unique identifier to the extortionist.
Said extortionist, if they had any shred of decency, would then provide the decryption key and life would go on. This all relies on some degree of centralisation: somewhere out there a list of keys and tokens needs to be stored. For large-scale attacks this isn’t ideal – often, multiple command and control servers are used for redundancy – and it makes more sense to somehow store those keys locally. Without public-key encryption this turns into a Catch-22 cascade of futility. You can encrypt the key and store it locally, but then where do you store the key used to encrypt that key?
Instead, an attacker can use a hybrid scheme whereby the symmetric key (or keys) used to scramble all the files is stored on the victim’s machine, but encrypted asymmetrically. The simplest implementation of this type of scheme would require our attacker to only look after a single private key, while the public key could be stored locally – inside the decryption program, for example.
So in order to recover their files, the victim needs to pay the ransom, which releases the attacker’s private key, which is combined with the public key and these two keys used to decrypt the locally stored symmetric key. Simple, right? Whoever said these people don’t work for their money…
SCUM, VILE SCUM
Actually, they don’t. Ransomware and command and control servers can be readily bought/rented via the darker recesses of the dark web and all this key management business can be taken care of with just a few clicks in a friendly interface. Having a single private key governing all victims is also not a terribly smart idea. It’s straightforward enough to protect it as it’s sent down the wire from the C2 server to the victim machine over HTTPS or SSH, but a suitably meticulous researcher would, given enough time and a retainer, be able to extract it from memory during the decryption phase. In this way, paying the ransom once (or maybe a few times) could provide decryption capability for everyone. Which is not really what malware authors want and why more advanced key distribution is generally used.
There have been a number of high-profile cases where ransom has been paid and data has been liberated. For example, in 2016 a hospital in Los Angeles coughed up 40 Bitcoins ($17,000 at the time) after being infected with the Locky ransomware. In life or death situations like this, it’s easy to see why paying the ransom is a reasonable option. The sum of money involved may well be less than the daily cost of working around a crippled network.
Even if the crooks don’t provide a decryption key, the ransom payment may be dwarfed by these costs, so from an accounting (but not awfully principled) point of view the victims aren’t that much worse off. Hospitals, and indeed all reputable organisations, ought to have a watertight backup regimen in place, but restoring a whole network under considerable pressure is a complicated business. Consider how long it would take you to restore your machine’s software stack, configuration and data after it was wiped, then multiply this number by at least several hundred. Locky evolved over 2016 to become one of the (then) most-detected pieces of malware in the wild, eventually being localised in 30 different languages and no longer requiring C2 infrastructure – which, if it’s located in a friendly jurisdiction, is easy enough for authorities to shut down once an outbreak becomes prevalent enough.
Some malware is selective about what it encrypts; it may just encrypt documents (based on file extensions) and leave the rest of the OS intact. Doing this means it only requires user permissions to run. If you’re lucky this means it’s easy to clean up, at least once the source of the infection is tracked down and so long as backups were taken. Of course, people have come up with ingenious ways of hiding scripts and getting these infections to resurrect themselves. There’s nothing more frustrating than thinking you’ve recovered everything to the preoutbreak state only to have it all come undone.
‘Fileless malware’ is becoming the new norm. This often travels by poisoned documents (PDFs in particular) which contain some script or code to fetch hostile code from the internet and inject it directly into memory. This makes it terribly tricky to detect.