A Tweet posted recently by AVG researcher, Jakub Kroustek, suggested that a new ransomware, written entirely in Python, had been found in the wild, joining the emerging trend for Pysomwares such as the latest HolyCrypt, Fs0ciety Locker and others.
This Python executable comprises two main files. One is called boot_common.py and the other encryptor.py . The first is responsible for error-logging on Windows platforms, while the second, the encryptor, is the actual locker. Within the encryptor are a number of functions including two calls to the C&C server. The C&C is hidden behind a compromised web server located in Israel. The Israeli server was compromised using a known vulnerability in a content management system called Magento, which allowed the threat actors to upload a PHP shell script as well as additional files that assist them in streaming data from the ransomware to the C&C and back.
A notable point to mention is that the server was also used for phishing attacks, and contained Paypal phishing pages. There are strong indications that a Hebrew-speaking threat actor was behind these phishing attacks. The stolen Paypal credentials were forwarded to another remote server located in Mexico and which contains the same arbitrary file upload technique, only with a different content management.
It is a known practice for attackers to look for low-hanging fruit into which they can inject their code in order to hide their C&C server. One such example was the CTB-Locker for web servers reported last March.
To reverse the executable one should first conduct a number of checks using a convenient debugger. The universal steps for unpacking an unknown packer start with trying to set a memory breakpoint on popular functions that packers use, such as VirtualAlloc.
If the breakpoint hits, the next step involves switching to user mode and setting a hardware breakpoint (on access). That will assist in inspecting where exactly the program initializes the memory block. In most cases, an executable magic header (MZ) should appear in the memory block. However, in this case the following screenshot shows the readable data that was allocated to that memory block:
After the data was allocated to the memory block, it appeared to be using VM code (python vm) to execute the code. For those who are not familiar with the term, VM code is the process of creating new instruction sets based on the author’s request. The CPU uses those instruction sets to understand the instructions.
py2exesimply converts the code to x86 assembly, the architecture used on the CPU for communication, and, by loading a python DLLs, loads all the modules into the memory.
We found that the executable file was generated using py2exe . The first indicator was a stack PUSH instruction to add the string – PY2EXE_VERBOSE : a module that compiles Python scripts to Microsoft Windows executables.
PY2EXE module string disclosure
A module that reverse the operation of the py2exe can be found in Github and is called unpy2exe . This module will revert the executable back to its origin Python compiled code (i.e. .pyc file). From that format, another step will be required to fully revert to the original code. We randomly chose to use EasyPythonDecompiler .