IQY files and Paradise Ransomware

Posted by James Haughom MAR 10, 2020 ON

IQY files, perhaps one of the less known of the weaponizable Microsoft Office file formats, provide attackers with a simple way to infiltrate a network. We have intercepted a campaign that leverages this file type to deliver a new variant of the Paradise ransomware.

IQY, or Internet Query files, are simple text files read by Excel that download data from the Internet. This file type can be leveraged to download an Excel formula (command) that could abuse a system process, such as PowerShell, cmd, mshta, or any other LoLBins (Living-off-the-Land Binaries). As this is a legitimate Excel file type, many organizations will not block or filter it. For organizations that do have security appliances that analyze attachments, these files may not flag as malware, as there is no payload. These appliances would typically rely on the reputation of these URLs, with the more robust solutions having the ability to actually analyze the contents that the URL returns.

Figure 1: Malicious IQY attachment containing the location of a remote Excel formula.

The Spam Campaign

This campaign attempts to entice users into opening an IQY attachment (Figure 1), which reaches out and retrieves a malicious Excel formula from the attacker’s C2 server. This formula, in turn, contains a command to run a PowerShell command that will download and invoke an executable (see Figure 2).

Figure 2: Malicious Excel Formula.

While IQY attachments are known to have been distributed by the Necurs botnet [1] to deliver FlawedAmmy RAT [1], this executable is instead tied to the Paradise Ransomware family, which has been around since at least 2017.

As displayed in Figure 3, we observed that this activity spanned just under two days, targeting an organization in Asia.

Figure 3: SMTP traffic delivering IQY.

Paradise Ransomware

This new version of the ransomware contains several interesting static properties (see Figure 4) including:

Anomalous section names For example: .py

Lack of imports (indicator of packed code) 5 DLLs 14 APIs APIs associated with dynamically loading code



Figure 4: Sections and Imports of Paradise ransomware.

Unpacking Routine

The unpacking routine is quite interesting in that it leverages a self-injection technique. This involves copying itself to a new location in memory, transferring control flow to the copy of itself, and then replacing the original executable in memory with the unpacked ransomware.

First, a new block of memory is allocated with the WinAPI VirtualAlloc function.

Figure 5: Allocated Memory

The malware then copies itself to this newly allocated block of memory – rep movsb.

Figure 6: Copying Itself

Control flow is then transferred to this copy – jmp eax. This allows the copy to manipulate the original executable (in memory).

Figure 7: Control Flow Transfer

The copy then allocates an additional block of memory to begin the unpacking process.

Figure 8: Memory Allocation

The copy overwrites the original executable (in memory) with NULL bytes – rep stosb, essentially removing the original executable from memory. This is the last step of the unpacking stub, prior to injecting the unpacked executable into this region of memory.

Figure 9: Wiping the Original Executable From Memory

The copy writes the unpacked executable in place of the original executable (in memory) –movsb.

Figure 10: Unpacked Executable Injected in Memory

Here is a before/after the unpacking stub of the sample. Notice that the anomalous section names are different, as are many other properties of both the PE and Optional Headers.

Figure 11: Side by Side of Packed and Unpacked PE

The unpacking stub then transfers control flow to the beginning of the unpacked ransomware code.

Figure 12: Control Flow Passed to Ransomware

Dynamic Code Resolution

At the start of the ransomware, WinAPIs of interest are dynamically resolved via manual PEB traversal, just before a language check is performed. The function dubbed find_API (Figure 13) accepts a unique checksum of the WinAPI function to resolve, and a pointer to the DLL to search. This instance of the function returns a pointer to LoadLibraryW.

Figure 13: PEB Traversal / API Resolution

LoadLibraryW is located by iterating through kernel32’s exports, performing a hashing function on each export name. This hash is then compared against the hardcoded hash of LoadLibraryW – 0x0DCA3722E. Figure 14 shows a snippet of the hashing function, which includes XORing the first four characters of the export name with the key 0xDEADCODE.

Figure 14: DLL Export Name Hashing Function

Language Check

The function shown in Figure 15 checks to see if the victim’s language ID is that of Russian, Kazakh, Belarusian, Ukranian, or Tatar. If the victim’s language ID matches one of these whitelisted values, the malware exits before performing any malicious activity.

Figure 15: Checking for specific languages

If the language check is passed, the main payload is executed. This function begins with an attempt to disable Windows Defender through setting the registry value for DisableAntiSpyware to 1.

The malware then attempts to kill any processes containing specific strings (see Figure 16). Ransomware will typically force target applications to close to ensure that handles to files of interest are released. This allows the malware to then obtain handles to these important files during the encryption process.

Figure 16: Strings contained in programs targeted for termination.

Killing target processes/services:

Figure 17: Killing Processes

Crypto Routine

The crypto routine involves traversing the file system (and file systems of network shares), while avoiding certain directories to avoid damaging the system. Those whitelisted directories are:

Windows

Recycle.bin

System Volume Information

Program Files

Program Files (x86)

Perhaps the most interesting technique involved in the crypto routine is the algorithm used. The malware leverages Salsa20 to encrypt the victim’s files. The benefit of using this algorithm is that malware authors can implement it into their source code (see Figure 18 and Figure 19 for Salsa20 constants found within the malware code), rather than calling functions from a crypto library. This makes detecting the encryption routine more difficult, and also makes determining the type of encryption being used a bit more challenging for malware analysts. This approach allows the malware to fly under the radar, as AV/EDRs may hook crypto-related WinAPIs (such as CryptEncrypt) to detect such behavior.

Figure 18: Salsa20 Constants

Figure 19: Salsa20 Constants

This algorithm is applied against a buffer that gets populated with ReadFile. Once the contents of this buffer are encrypted (in memory), the cipher text is written to disk, overwriting the original file.

Figure 20: File Encryption Steps

Here is a before/after of an application being encrypted during the crypto routine.

Figure 21: Before/After of an Executable being encrypted.

The file extension is then modified for each encrypted file with MoveFile,using the following syntax: <filename>_decryptor_{unique_id}.tor. As you can see below, the file dirwatch_ui.exe is being renamed to dirwatch_ui.exe_decryptor_{HphFZC}.tor, through the MoveFile function.

Figure 22: Changing encrypted file’s extension.

The ransom note, titled “—==%$$$OPEN_ME_UP$$$==—.txt” is dropped to disk, and automatically opened upon completion of the encryption routine. This ransom note (Figure 23) instructs the victim to visit an online chat to receive instructions on how to decrypt the files.

Figure 23: Ransom Note

The last task the malware completes is a short connection to a URL (iplogger.com) stored in the malware’s resource section.

Figure 24: Extract URL from embedded resource.

Figure 25: URL in resource.

This appears to just be a simple check-in/notification of infection C2, as no data is sent to C2 in this request. A NULL value is passed as lpOptional parameter to HttpSendRequest.

Interaction with Ransomware Support

To further understand the attack, we made an attempt to interact with the ransomware’s support team. The URL from the ransom note points to the chat’s login page, as shown in Figure 26.

Figure 26: Ransomware Support chat login.

Upon logging in, you are greeted with an automated message, as well as a set of rules for the chat room.

Figure 27: Ransomware Support chat.

Unfortunately, we never received a reply. What is interesting is that the time date format matches what is used in many European Countries.

Figure 28: Ransomware Support lack of correspondence.

Revisiting the static properties of the malware, it has a Compilation Timestamp of 2019-12-08 18:42:38 (UTC), which would fall at around 7:42pm in Europe. The malware was first submitted to VT from an IP with a geolocation of Great Britain, at 2019-12-10 16:08:25 (UTC).

Conclusion

In summary, this campaign exhibited how weaponized IQYs can be an effective technique for an attacker to infiltrate a network. Since these IQYs contain no payload (just a URL), they can be challenging for organizations to detect. Organizations may have to rely on a 3rd party URL reputation service if they do not have appliances in place to analyze and interrogate these URLs.

Although it has been around since at least 2017, public knowledge of the Paradise ransomware is not wide-spread. This ransomware does contain a few evasion techniques that prove to be interesting and effective, such as implementing its encryption algorithm manually/at the source level, to avoid API calls. The algorithm used (Salsa20) is not very commonly employed by ransomware, although it has been observed being leveraged by certain versions of Sodinokobi, and Anatova. Lastly, it is always interesting whenever malware hard-codes a whitelist/blacklist of countries.

References

[1] https://exchange.xforce.ibmcloud.com/collection/Necurs-spreads-FlawedAmmyy-RAT-using-Excel-Internet-Query-attachments-c34ee7d56e1c32ab3592e47bae9f9f53

IOCs