Over the weekend, several researchers identified the EiTest RIG campaign delivering a new ransomware strain. EiTest actors seem to switch their ransomware strains fairly regularly, having delivered Cerber, Revenge, Spora, and CryptoShield between the beginning of February and the end of March.
The latest choice is a bit of an odd one: a five megabyte NSIS installer comprised of a Python-built loader and a second executable for displaying the user interface. The main function behind the malware is simple. The NSIS-installer first writes hardcoded values to three different text files:
The NSIS installer then executes a Python script, pushing these values into the main function:
The malware runs the get_btc subroutine, sending collected system information to the server via POST request and receiving a json containing a bitcoin address (for payment), a public key (for encryption), and a decryption price in BTC and USD.
The encrypt_all function call several subroutines, including:
- Make_filelist (walks through the drive, minus excluded folders, and appends to list)
- Send_status (uses the BTC address as a check-in point with C2 during various subroutines)
- Encrypt_documents (runs encrypt_file subroutine on each file in the filelist, encrypting each file using AES)
The Python script then calls a second executable (ui.exe) using the bitcoin address, bitcoin and USD decryption prices, and server as arguments, periodically checking in to the server for a private decryption key. We expect that the server checks a website like Bockchain.info and returns a key to the user once the ransom has been paid.
Overall, there are a few unusual characteristics with this code. While the use of an NSIS installers in ransomware is an increasing trend, more sophisticated samples use these installers to decrypt obfuscated payloads and components. In this instance, the script is merely used to do two things: provide hardcoded values to the Python script and execute the Python script.
The NSIS installer providing values to be used in the Python script is also odd. At a high-level, the NSIS installer must create a new file, write a value to it, and execute a Python script. The Python script must then open those files, read the lines of those files, and put the contents of those lines into a variable. It would make more sense to simply place those values within variables in the Python code.
It’s possible that this was intended to be an anti-analysis technique, but the process for extracting information from an NSIS installer (unzipping the installer with an old version of 7zip) is significantly faster than installing the dependencies required to decompile a Python-based Windows executable. We suspect the authors of this malware simply aren’t experienced programmers.
MD5: 0b71016ac598c45e8a2a219eba903ec8
Article Link: https://blog.cyber4sight.com/2017/03/a-python-oddity-eitest-switches-from-cerber-to-test-python-based-ransomware/