Andrew Brandt, the principal researcher from global security company Sophos, said in a blog post that this resulted in taking all the organisation's VMs offline.
The ransom note was embedded in the script itself, he noted. The target was running VMware ESXi server.
The Python script embeds the text of the ransom note.
ESXi runs on bare metal unlike other VMware products and includes its own kernel. Initially, it included a Linux kernel, at which point it was known as ESX, but development was stopped at version 4.1, according to Wikipedia.
Were ransomware to infect any VMs on an ESXi system, it could spread to Windows machines on the same network, as ESXi is often connected to Active Directory.
Brandt said the attackers had gained entry by logging into a TeamViewer account, which did not have MFA set up, on a PC where the user had Domain Admin credentials on the target network.
The script embeds the file suffix it appends to encrypted files (ext), and email addresses (mail, mail2) to be used to contact the attacker for payment of the ransom as variables.
The login took place at half an hour after midnight and a tool called Advanced IP Scanner was downloaded 10 minutes later to identify other targets on the network.
By 2am, an SSH client called Bitvise was downloaded and used to log in to the VMware ESXi server. ESXi has a built-in SSH server called the ESXi Shell; this is disabled by default but in this case it had been enabled and not turned off.
The script used was just 6kb in size, and Brandt was impressed with what it could pack into that small space.
"Only 6kb long, the small size of the script belies its abilities," he wrote. "The script contains variables that the attacker can configure with multiple encryption keys, email addresses, and where they can customise the file suffix that gets appended to encrypted files."
Encryption keys are generated on the fly. "One thing that we noticed while walking through the code was the presence of multiple, hardcoded encryption keys, as well as a routine for generating even more encryption key pairs," Brandt noted.
ESXi management tools can enable or disable the ESXi Shell either from within the tool, or locally on the console connected to the server. The shell defaults to “Stopped.”
"Normally, an attacker would only need to embed the 'public key' that the attacker generated on their own machine and which would be used to encrypt files on the targeted computer(s). But this ransomware appears to create a unique key every time it is run."
In the case of this attack, there were three datastores, so three unique key pairs were generated.
Brandt pointed out that while malware that ran on a system like ESXi was rare, it was even more uncommon for detection tools to be installed on such endpoints.
"Hypervisors, in general, are often quite attractive targets for this kind of attack, since the VMs they host may run business-critical services or functions," he said.
Use of the ESXi Shell could be toggled on or off from either a physical console or through the normal management tools provided by VMware, Brandt said.
"Administrators should only allow the Shell to be active during use by staff, and should disable it as soon as maintenance (such as the installation of patches) is complete," he added.
Screenshots courtesy Sophos