Critical Infrastructure Security , Cybercrime , Cybercrime as-a-service

How Ransomware Attackers Hit Virtual Machine Hypervisors

BlackMatter, HelloKitty and REvil Among Groups Targeting VMware's ESXi Hypervisor
How Ransomware Attackers Hit Virtual Machine Hypervisors
Ransom note text embedded in a Python script used to target VMware ESXi environments (Source: Sophos)

How quickly can ransomware attackers strike? In one case, three hours is all it took for one or more ransomware-wielding attackers to gain initial access to a target, escalate their attack and deploy crypto-locking malware.

See Also: Finding New Ways to Disrupt Ransomware Operations

So says security firm Sophos, in a new report detailing a ransomware outbreak that hit the victim's installation of VMware ESXi, which is an enterprise-class hypervisor designed to partition servers into multiple virtual machines.

"This is one of the fastest ransomware attacks Sophos has ever investigated and it appeared to precision-target the ESXi platform," says Andrew Brandt, who's a principal researcher at Sophos.

The attack is notable not just for its speed, but also for a list of defensive mistakes made by the victim - who might otherwise have repelled the attack - including leaving unnecessary functionality active and failing to use multifactor authentication to lock down remote-access tools, especially for users with admin-level access to core systems.

Hitting a hypervisor gives attackers the ability to forcibly encrypt many different systems at once. If the hypervisor should be hosting a multi-tenant environment, furthermore, attackers might have the opportunity to crypto-lock systems used by multiple organizations, thus giving them more victims to extort.

"ESXi servers represent an attractive target for ransomware threat actors because they can attack multiple virtual machines at once, where each of the virtual machines could be running business-critical applications or services," Brandt says. "Attacks on hypervisors can be both fast and highly disruptive. Ransomware operators including DarkSide and REvil have targeted ESXi servers in attacks."

ESXi-Targeting Groups

Sophos has not attributed the attack it investigated to any particular ransomware group.

But as it notes, multiple groups have been seen targeting ESXi. They include REvil, which is also known as Sodinokibi, which was the dominant strain of ransomware seen in Q2, before going quiet over the summer. But the ransomware group recently resumed operations.

After also disappearing over the summer, DarkSide appears to have been reborn as BlackMatter. In August, the MalwareHunterTeam security research group, warned that BlackMatter was continuing to use a Linux version of DarkSide's malware developed to target ESXi environments, which includes the ability to run ESXi shell commands, and thus to forcibly shut down virtual machines so that they can be encrypted and held to ransom.

In July, meanwhile, Doel Santos and Ruchna Nigam of Palo Alto's Unit 42 threat research group warned that they'd spotted "a Linux variant of HelloKitty targeting VMware's ESXi hypervisor, which is widely used in cloud and on-premises data centers" (see: 7 Emerging Ransomware Groups Practicing Double Extortion).

Attackers Wield Python

In its report, Sophos says this incident involved attackers successfully sneaking a Python script onto a server running ESXi, which has Python installed by default.

Sophos says that for each different ESXi datastore - to which paths are grayed out - attackers targeted, their Python script generated a unique encryption key, which they then encrypted using a secret key.

What isn't clear is how many other organizations attackers tried to target before successfully hitting this one.

Sophos didn't immediately respond to a request for more information about the victim, such as the industry and geography in which it operates.

But many aspects of attackers' MO are nothing new, including their hitting the victim on a weekend, when IT teams would be less likely to spot or be able to quickly stop the intrusion.

Luckily for attackers, Sophos says they appear to have found an active shell for accessing ESXi, which administrators use for routine maintenance, including updates, but which they would typically have deactivated afterwards, for security reasons.

Early Sunday Morning Strike

Here's a timeline of the attack as detailed by Sophos, in the victim's local time, early one Sunday morning:

  • 12:30 a.m.: Attackers access TeamViewer remote access and control software running on a computer assigned to a user who also has Active Directory domain administrator access credentials. The TeamViewer software was not protected with multifactor authentication, meaning attackers likely brute-forced their way in.
  • 12:40am: Attackers use the free Advanced IP Scanner tool to identify an ESXi server and then find that administrators left a shell active. Attackers use the shell to remotely log in, via a remote-access tool called Bitvise. Attackers then upload a Python script.
  • 03:40 a.m.: Attackers run the Python script, which creates a directory map and inventories every hypervisor, and then shuts them all down and encrypts every virtual drive hosted on the ESXi server, leaving a ransom note.

Security Essentials

The takeaway for any organization that runs a hypervisor is that attackers have a history of attempting to exploit them, meaning they should pursue appropriate defenses.

"This includes using unique, difficult to brute-force passwords and enforcing the use of multifactor authentication wherever possible," says Brandt, and especially for remote-access accounts, including remote desktop protocol and TeamViewer.

To help organizations that use ESXi, VMware has published a guide to securing the hypervisor.

Beyond minimizing access, not least for administrators - including regularly auditing Active Directory access levels - Sophos also recommends using virtual local area networks, or VLANs, to segment critical servers, including ESXi platforms, to make them more difficult to attack.

Disabling shell access in an ESXi environment (Source: Sophos)

"The ESXi shell can and should be disabled whenever it is not being used by staff for routine maintenance, for instance, during the installation of patches," Brandt says. "The IT team can do this by either using controls on the server console or through the software management tools provided by the vendor."


About the Author

Mathew J. Schwartz

Mathew J. Schwartz

Executive Editor, DataBreachToday & Europe, ISMG

Schwartz is an award-winning journalist with two decades of experience in magazines, newspapers and electronic media. He has covered the information security and privacy sector throughout his career. Before joining Information Security Media Group in 2014, where he now serves as the executive editor, DataBreachToday and for European news coverage, Schwartz was the information security beat reporter for InformationWeek and a frequent contributor to DarkReading, among other publications. He lives in Scotland.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing bankinfosecurity.in, you agree to our use of cookies.