Log4Shell Lives!
It has been about a year since the security hole at the heart of the open source Java logging library Apache Log4j was revealed. The resulting zero-day vulnerability, CVE-2021-44228, aka Log4Shell, is still with us today. That’s crazy! But it’s true.
Recently, the Cybersecurity and Infrastructure Security Agency (CISA) revealed not only are hackers still using Log4Shell successfully, but Iranian government agents are also using it to pry open Federal government agency VMware systems.
Oh, come on! Patch it already!
The Exploit
Specifically, threat actors exploited Log4Shell to get access to the organization’s unpatched VMware Horizon server. Once in, they opened a connection to a known malicious IP address. Over that link, they ran a Windows PowerShell command to add an exclusion rule to Windows Defender that white-listed the c:\drive. This enabled them to put executable files to the c:\drive without a virus scan.
What did they put on? Well, so long as you’re screwing around with a government server, you might as well get money out of the hack, too, so they placed XMRig cryptocurrency mining malware on the machines.
That done, the attacker moved on to more fun and games. They shifted over to the VMware VDI-KMS host. From there, they uploaded.
- PsExec – a Microsoft signed tool for system administrators.
- Mimikatz – a credential theft tool.
- Ngrok – a reverse proxy tool for proxying an internal service out onto a Ngrok domain, which the user can then access at a randomly generated subdomain at *.ngrok[.]io. CISA has observed this tool in use by some commercial products for benign purposes; however, this attack was anything but benign and bypassed typical firewall controls,
With these tools, the attacker harvested credentials and created a rogue domain administrator account. Using the newly created admin account, they infected other hosts using Microsoft’s Remote Desktop Protocol (RDP). Upon logging into each host, the attackers manually disabled Windows Defender and implanted Ngrok executables and configuration files. That way, Ngrok persisted even if it was removed from one machine or they lost access to an infected machine during a routine reboot.
They finished up the attack by trying to take over the domain controller. While they were at it, they used Active Directory to get a list of all domain-attached machines and tried to — surprise! — change the passwords of local administrator accounts and try to dump Identity and Access Management (IAM) data from the Local Security Authority Subsystem Service (LSASS). At this point, the agency figured out something was going badly wrong.
Patch It
All of this story, an all too typical tale of an automated Windows attack, started with Log4Shell. Patch Log4Shell, and none of this would have happened.
Mind you, many other problems were revealed in this attack. For example, what was PowerShell doing being available to non-administrative users? And, what in the world were the local administrator accounts doing without Two-Factor Authentication (2FA)?
So, I can’t blame all this on a failure to patch VMware. There’s lots of security blame to spread around on this system. But, still, if you aren’t absolutely sure you’ve got every instance of Log4J patched, it’s way past time to do it.
Oh, and if you missed one, start tearing apart that machine and every networked system to find the malware now hiding in them. By this time, it’s a lead-pipe cinch that all your machines have been compromised.
