The attack started in mid March with a phishing email sent to a company employee. Eleven hours later, the employee opened a malicious Office file attached to the email. Opening the file triggered malware installation, providing the attackers with initial network foothold. Within eight days, the attackers managed to gain control of the company’s network and encrypt files on over 200 endpoints and 30 servers belonging to the organization. The activation of the ransomware occurred on a Thursday night after 1AM, when no one was available to notice the extremely irregular network behavior.

The Attack Timeline

At this point, our partner Ideal Integrations was called in to assist the victim company. Ideal helped the victim make two decisions. The first was to rebuild their entire infrastructure from scratch over the weekend. The second was to pay the ransom in order to allow the company to continue operation.

After working throughout the weekend reconstructing their network, Ideal called Guardicore Labs to assist with the incident response investigation. Our initial task was to build a timeline of the attack and analysing the decryptor provided by the attackers. As part of the analysis, we wrote our own safe-decryptor tool to bypass the attackers’ executable.

The malicious email appeared to be a reply to a message initially sent by the employee. It contained a protected ZIP file and the password to open it. The email was signed by a person allegedly working for a company located in the same state as the victim company. The employee opened the attachment, which included a macro enabled Word document. Once executed, the macro downloaded additional malware. In any modern version of Office software, the user would have to explicitly confirm running the macro, but as experience shows, this is not a good way to block execution.

Investigating the malicious document, we discovered the following orphaned strings hidden inside the file. However, we should be careful in reaching any conclusions based on the strings.

The document contains many orphaned strings. Their source is unknown

An antivirus software installed in the organization’s network detected malicious activity and alerted on malicious files originating from the employee’s machine, the antivirus software identified the files as belonging to Dridex. However, this alert was not followed up and the attackers continue to work their way into the rest of the network. Once inside the network, the attackers started reconnaissance and lateral movement actions.

With control over the network, they initiated the last phase of their attack – encrypting every file they could find OS system files were left out of encryption scope. This allowed the machines to run while the access to users’ data was blocked. A combination of proper encryption methods, along with control over most of the network, including the backup servers, meant that the attackers shut down operations in the network.

IEncrypt Ransom Note

Based on publications and a recent report on a ransomware attack against Arizona Beverages, Guardicore Labs team believes the attacking ransomware was an IEncrypt sample. Evidence to support this assumption includes:

• The ransom note format (“Your network was hacked and encrypted”) – this is the exact same wording used for the ransom note displayed on Arizona Beverages’ computers.
• The encrypted files’ extension contained the company’s name – a known characteristic of the IEncrypt ransomware.

With the majority of their data encrypted, the customer had no other choice but to pay the ransom. After some BitCoins exchanged hands the decryptor was provided by the attackers.

We decided to reverse engineer the decryptor in the hope of better understanding its capabilities. Our goal was to make sure the executable performed decryption, and decryption only.

A basic observation of the decryptor disassembly did not prove to be helpful; there were few strings and only one imported Windows API function – MessageBox.

The immediate conclusion was that like many other malware samples in the wild, the malware author implemented their own functions for:

• Loading DLL files (equivalent to Windows APIs LoadLibrary); and
• Fetching the required processes’ addresses (equivalent to Windows APIs GetProcAddress).

In such implementations, the names of libraries and functions are not hard-coded in plaintext. Instead, each string is represented by a hashed value.
For the sake of simplicity, we will refer to these implementations as MyLoadLibrary and MyGetProcAddress.

To short-circuit a long process, we want to know which DLLs and functions were being used. To do that, we could have figured out the hashing algorithm, run it on a large number of system functions and search for hashes residing in the decryptor binary. However, we chose a quick-and-dirty way this time. We used windbg to put two breakpoints: one on the entry point of MyLoadLibrary function and the other on the following call to the address returned by MyLoadLibrary. This allowed us to monitor module-loading and Windows API calls in runtime.

windbg commands to print out the names of imported functions

At this point we had a list of the functions imported by the decryptor module. The attacker relied exclusively on Windows API calls for the decryption process – mainly from crypt32.dll and advapi32.dll – which made it fairly easy to collect all relevant information without even reading the code. For example, to extract the attackers private key, we observed calls to CryptStringToBinaryA and the subsequent call to CryptImportKey.

windbg output providing us the decryption key

Like most ransomware today, IEncrypt uses a combination of both symmetric and asymmetric encryption. The IEncrypt process works as follows for each file:

1. Each file is encrypted using an AES symmetric key. This key is generated by the ransomware per file.
2. This key is then encrypted using an RSA public key which is baked into the malware.
3. The encrypted key is stored in an adjacent file, named:  [._readme]

The end result of the ransomware process on specific files

According to our analysis, the RSA private key used for decryption cannot be obtained without the attacker’s decryptor, leaving the victim with only one option to recover their files. However, even after paying the ransom and receiving the decryptor program, the victim was still wary.
How can the victim make sure the decryptor program doesn’t have additional functionality, such as leaving backdoors or adding malicious payloads to the decrypted files?

For these reasons, we chose to create our own safe IEncrypt decryptor program and provide it to the targeted company. In addition, we decided to publish this tool, named pasta, since we believe it will be of value to others. You can download it here, free of charge. Our tool is written in plain Win32 C and recreates the attackers decryptor routine.

To run the tool, you must provide the decryption key and the file extension appended to the encrypted file as command line arguments. At time of writing, to recover the decryption key, some manual reverse engineering is required.

pasta -e <.extext> -k  [-f] 
    -e  encrypted file extension (starting with '.' character
    -k  path to private key to use for decryption
    -f  force overwrite of existing decrypted file
    -h  show this help

To prevent the initial breach, employees should be trained to not click on links or download attachments in emails that look suspicious in any way. Alternatively, companies can use cloud mail providers with such protection integrated.

However, breaches are inevitable and mistakes will most likely exist somewhere in the network. Consider applying micro-segmentation policies anywhere your applications run. This will reduce the attack surface and prevent lateral movement.

In addition, apply multiple backup layers, both online and offline. Online backups were not enough in this case, the attackers reached the backup servers as well. In addition, practice recovering backup files in different disaster scenarios.

Finally, do not assume the attack is over once the ransom is paid and files are decrypted. Run a thorough investigation to understand the attack vector and scope and the consequences that enabled it. Before running a binary file sent by the same people who just created mayhem for your organization, make sure the code is safe to run.