Keeping your guard up: Python-based ransomware attacks
Earlier this year, researchers at Sophos identified a new variety of ransomware that was written in the Python programming language. The attack targeted VMware ESXi-hosted Virtual Machines (VM), encrypting the virtual disks and taking them all offline.
Interestingly, the ransomware discovered is unusually fast-acting and has the potential to encrypt user data in just a matter of hours. In fact, in the case discovered by the Sophos researchers, the attack took just three hours.
In a report on the discovery, a principal researcher at Sophos noted that Python is a coding language not commonly used for ransomware. According to a recent report from BlackBerry’s Research & Intelligence division, malware is more commonly created using languages like Go, DLang, Nim and Rust. That said, it is often largely dependent on the platform an attacker is targeting.
The Python programming language
Firstly, it’s important to contextualize the significance of the use of Python in ransomware. Python is an open-source, full-featured, robust scripting language. In terms of its uses as a system administrator, it is able to utilize modules to help with tasks that are performed repeatedly.
As noted by the researchers at BlackBerry, attackers usually favor languages that are young in their existence and relatively unknown and unanalyzed. Python on the other hand is one of the most popular programming languages used today and was founded 30 years ago in 1991. Its popularity is due to its value as a tool for any system administrator. Among other things, Python can be of great help with managing servers, logging and testing Web applications.
How was this attack possible?
Ultimately, human error was the cause of this attack. It started when attackers managed to break into a TeamViewer account belonging to the victim organization. The user had admin access and didn’t have multi-factor authentication (MFA) enabled.
Thereafter, the attack involved an exploitation of an administrative VMware Hypervisor interface. ESXi servers have a built-in SSH service called the ESXi Shell that administrators can enable and disable as and when necessary. This attack occurred because the ESXi shell service was enabled and then left running.
In the report, the researchers claim that attacking the system exposed a running shell service which should have been disabled after use. Essentially, the gates to each of the victim’s operating systems were left open.
The victim organization’s IT staff regularly used the ESXi Shell to manage the server and had enabled and disabled the shell multiple times in the months prior to the attack. However, the last time they enabled the shell, they failed to disable it afterwards. The criminals took advantage of this and were able to access and consequently encrypt all the victim’s virtual disks.
Had the VMware system security recommendations been adhered to, the system would have been secure or at the very least it would have been more difficult for attackers to break in and eventually encrypt the entire system.
Why was Python used?
Python is becoming increasingly popular, not only as a general-purpose programming language but for IT systems administration as well. Python was used during this attack because it was convenient.
As Python is pre-installed on many Linux-based operating systems such as ESXi, the use of Python in this instance makes perfect sense.
Essentially, attackers used the tools that already exist within the makeup of the target of the attack. Attackers used the same scripting that the victim was already using for its day-to-day administrative tasks.
The fact that Python was utilized as a system-wide tool explains how the malware was deployed in just ten minutes. This also explains why it was labeled by researchers as ‘unusually fast’, all the necessary tools were waiting for the attackers on site.
Targeting ESXi servers and virtual machines
ESXi servers are an attractive target for ransomware criminals because they can attack multiple virtual machines at once and each of the virtual machines could be running several business-critical applications or services.
For an attack to be successful, threat actors need to access the business’s critical data. In this case, the target organization had already grouped it all under one umbrella prior to the attackers’ arrival. The potential return of investment from the attack is therefore maximized and ESXi servers make for the perfect target.
Learning valuable lessons
VMware does not recommend leaving the ESXi shell running without it being monitored and also makes recommendations around system privilege that weren’t adhered to in this case. Enforcing simple security procedures could halt attacks like these or at least make them more difficult.
As a general security rule in IT systems administration: the less the system exposes, the less there is to be secured. The initial system setup and default configuration is not sufficient for production system security.
If the ESXi Shell had been disabled after administrators had finished their work, it wouldn’t have happened so easily. Administrators were accustomed to using the ESXi Shell as a legitimate gateway to manage clients’ virtual machines and consequently acted in a careless manner, failing to shut the gate on their way out.
Another aspect of this case to consider from an administrative perspective, is the global file systems visibility. All the victim’s data partitions were accessible within their internal filesystem. We know the encrypting was done file by file. The criminals attached the encryption key to each file and overwrote the original file content. A more cautious system administrator could split the data domain from the tools and divide it between their data storage and the rest of the system.
Adding Multi-Factor Authorisation for accounts with a high level of privilege would also stop potential attackers, but MFA is often unwelcomed by administrators for frequent, daily use.
It can’t be underestimated that having the right procedures in place will help to deter future attacks. Overall, this has more to do with system security and administration than it does with Python. In this case, Python was merely the most convenient tool to use, and it gave attackers access to all virtual machines system wide.
Piotr Landowski, Service Delivery Manager, STX Next
Comments are closed.