How hackers manually escalated from a malicious email to a devastating, company-wide ransomware takeover in under 5 hours.
(This article aims to contextualise an excellent incident report by Thedfirreport.com. I’ve used my own experience to fill in the gaps to demonstrate how these attacks affect real people in real companies.)
The Attack Started Like Many Others
A phishing email landed in the victims inbox at around 5 pm UTC and was promptly opened and read. There was nothing particularly suspicious about it. It was a well-written email with a reasonable call to action. There were no urgent demands. It wasn’t claiming to be from the company CEO. It looked identical to many of other emails received that same day.
The company email servers scanned it and allowed it straight through to the victim’s inbox. It was sent through a legitimate and well-known email delivery service with a good reputation. There were no attachments to be scanned for malware. All it contained was a politely written request and a link to a web page.
The web page didn’t ask them to log in. It wasn’t trying to steal their password by masquerading as a trusted login page. All the victim saw was a message saying: ‘Oops! The document preview isn’t available. Click here to download’, or words to that effect. This is the sort of error message that we’ve all seen many times over the years. Most of us wouldn’t think twice about clicking that link, myself included.
Malware In Disguise
The browser downloaded a file named something like PreviewReport.DOC.exe. A warning message came up at the bottom of their browser asking if the user wanted to keep or discard the file as it could be harmful.
Regrettably, our unfortunate user downloads all sorts of documents all day every day and many of them give the exact same warning. They’ve learned that this warning message is just a regular part of online life. One more thing they must click on in order to get work done. Out of habit, they clicked on ‘keep’, then opened the file.
The executable was signed with a trusted certificate from a well-known vendor. It was malicious, and yet it was signed. The thing is, anyone can buy legitimate and trusted software signing certificates on the internet these days if you know where to look. The user’s PC had AppLocker configured to block unsigned executables but it made no difference. The trusted, signed malware executed without a problem.
Their local antivirus software had the latest virus signatures downloaded and available. As the malware was unique to this victim, the signature didn’t match anything on record. Nothing was blocked.
As far as the user was concerned, the file did nothing. Perhaps it was corrupted. Nevermind…
Sadly, it wasn’t corrupted. It sent a message out to a command and control server on the internet to say, ‘Hello, I’m here, And I’m waiting’, then opened a backdoor into the heart of the company network. It checked-in using standard, encrypted, HTTPS traffic, and notified the ransomware gang that it was active and waiting for instructions. From the outside, it looked exactly the same as the device’s owner viewing any other secure web page on the internet.
The Malware Takes Hold
The executable opened by the user didn’t really do much, to begin with. It was a malware loader, wrapped in layers of masking techniques to hide its true purpose. After reporting in, it did nothing. It waited.
Two and a half hours later at 7:34 pm UTC, the attacker took to their keyboard and began to issue instructions to the malware. The first thing they did was download a larger piece of malware from the internet and load it into memory.
Rather than spawning a new process, which is really easy to detect, it injected the malware straight into an existing process owned by the Operating System. Then, it created a Windows scheduled task, set to trigger every time a user logged into the system. Should the device be restarted, the scheduled task would load it back into memory again in the same way.
These two techniques ensure stealth and persistence are maintained. As a cybercriminal, being discovered or losing your hard-earned access to a system before you make your money are two of the biggest mistakes you want to avoid.
The larger piece of malware the loader downloaded was actually a piece of commercial software called Cobalt Strike. From their website, the developers state that “Cobalt Strike gives you a post-exploitation agent and covert channels to emulate a quiet long-term embedded actor in your customer’s network.” Originally created to simulate what criminals do after gaining a foothold into your network, it is now being used by criminals after gaining a foothold into your network. How’s that for a product recommendation?
In this instance they used the trial version of Cobalt Strike, saving themselves a license fee of $3,500 dollars and keeping their name and credit card number away from interested eyes.
The Ransomware Attack Begins
As the malware loader was executed by our unsuspecting victim, the malware ran with their user account and privileges. In this instance, they only had a standard Domain User level account with no elevated permissions. This limited what the malware could do, at least for a few minutes.
Using built-in Windows applications, the hacker started poking around the company network, identifying other computers and servers as it went. All of this was done manually by the attacker sitting safely and anonymously at a keyboard, hundreds of miles away, running commands and looking at the results as if they were right there in front of the keyboard.
Fourteen minutes after they started issuing commands, the hacker discovered that the company’s primary domain controller had not been patched against the CVE-2020-1472 Zerologon vulnerability. A patch for this was released two months prior to the attack but had not been applied. They then exploited the vulnerability on this server, changing the password of the primary domain controllers’ machine account (not a user account) to all zeros. This is where the vulnerability get’s the name, Zerologon.
Fifteen minutes later, the compromised machine account was used to push the Cobalt Strike files to a secondary domain controller and then execute them remotely. While not a domain admin, the account at least had enough privileges to do this. Cobalt strike was then used to elevate privileges to the local administrator which itself has domain administrator privileges. This means it has access to pretty much everything on the company network. Game over.
Deploying Ryuk Ransomware and Encrypting Everything, Including The Company’s Backups
Thirty-nine minutes later, the attacker was back on the primary domain controller as a local (and also domain) administrator, mapping out the company network and executing the final attack. In order to almost guarantee payment, they encrypted the company’s backup servers first to destroy any online backups and make any offline backups difficult to use. Next, they encrypted all of the companies servers and then workstations, pushing out and executing the ransomware via RDP as the domain administrator account.
Twenty-one minutes later, the final host, the primary domain controller, encrypted itself with Ryuk ransomware bringing the whole thing to an end.
Total hands-on time, 1 hour and 29 minutes.
Total elapsed time since the user was phished, 4 hours and 2 minutes.
Devastating.
Lessons Learned
Patch Management
From this incident, it’s clear how important it is to deploy critical patches as quickly as possible. Even if a server isn’t externally facing, it can still be exploited through lateral movement once an attacker gains a foothold into your company network. If Zerologon had been patched it may have taken significantly longer for the attacker elevate their access level enough to carry out the full attack. Maybe they wouldn’t have managed it at all, or maybe they would. We’ll never know now.
Sometimes time is on our side. It gives us longer to detect and react to the threat as it appears. But it also gives attackers more time to think, investigate, and discover new possibilities for exploitation. Given the choice, I’d take more time to react and respond any day.
User Devices As A Way In
It’s understandable to prioritise hardening your externally facing servers and firewalls above everything else as they are literally your first line of defence against bad actors on the internet. The trouble here is that beyond the automated scanners and exploitation bots, nobody is really targeting you in this way. It’s your people and their devices who pose the biggest risk.
Users spend all day browsing the internet, downloading and opening files, following instructions in emails, and generally making things happen. They’re prime targets for ransomware gangs as they’re the easiest to fool and they’ve got access to everything a criminal needs.
As we’ve seen in this incident, the initial foothold came from an unsuspecting user downloading and executing a file from the internet. None of their existing layers of protection detected and blocked the file. So what could have been done differently?
An SSL decrypting web proxy could have made a difference if configured correctly. A policy to block standard users from downloading executable .exe files would have stopped the malware loader in its tracks before it ever reached the user’s device. If configured to block new, unknown, and bad websites it may also have blocked the command and control traffic, provided direct access to the internet was also blocked from their device. This doesn’t always work as attackers are not afraid to use legitimate services such as Github.com for communications, but it’s definitely an improvement.
Next-Generation Intrusion Prevention
This isn’t an advert so I won’t name names, but there are vendors who’s entire sales pitch is about host-based or network-based intrusion prevention systems that can detect weird network activity and kill it automatically. They do this by flooding the network with noise to cancel out communications from the malicious hosts once a problem is detected. Think noise-cancelling headphones, but for computer networks.
By stopping a device from communicating and raising an alert with a real person, these tools buy you time to investigate and remediate before a problem spreads to your backups, servers, and workstations. If an attacker can destroy your company in less than 5 hours, any time you can buy back with a tool like this is time worth having.
Question says
Curious about this….doesn’t quite right?
there are vendors who’s entire sales pitch is about host-based or network-based intrusion prevention systems that can detect weird network activity and kill it automatically. They do this by flooding the network with noise to cancel out communications from the
Craig Hays says
Yep, it’s right. Drop me an email and I’ll show you examples [email protected]