Towards the end of August 2018, FireEye identified a new exploit kit (EK) that was being served up as part of a malvertising campaign affecting users in Japan, Korea, the Middle East, Southern Europe, and other countries in the Asia Pacific region.

The first instance of the campaign was observed on Aug. 24, 2018, on the domain finalcountdown[.]gq. Tokyo-based researchers “nao_sec” identified an instance of this campaign on Aug. 29, and in their own blog post they refer to the exploit kit as Fallout Exploit Kit. As part of our research, we observed additional domains, regions, and payloads associated with the campaign. Other than SmokeLoader being distributed in Japan, which is mentioned in the nao_sec blog post, we observed GandCrab ransomware being distributed in the Middle East, which we will be focusing on in this blog post.

Fallout EK fingerprints the user browser profile and delivers malicious content if the user profile matches a target of interest. If successfully matched, the user is redirected from a genuine advertiser page, via multiple 302 redirects, to the exploit kit landing page URL. The complete chain from legit domain, cushion domains, and then to the exploit kit landing page is shown in Figure 1.

The main ad page prefetches cushion domain links while loading the ad and uses the <noscript> tag to load separate links in cases where JavaScript is disabled in a browser (Figure 2).

In regions not mentioned earlier in this blog post, the ‘link rel="dns-prefetch" href”’ tag has a different value and the ad does not lead to the exploit kit. The complete chain of redirection via 302 hops is shown in Figure 3, Figure 4 and Figure 5.

URIs for the landing page keep changing and are too generic for a pattern, making it harder for IDS solutions that rely on detections based on particular patterns.

Depending on browser/OS profiles and the location of the user, the malvertisement either delivers the exploit kit or tries to reroute the user to other social engineering campaigns. For example, in the U.S. on a fully patched macOS system, malvertising redirects users to social engineering attempts similar to those shown in Figure 6 and Figure 7.

The strategy is consistent with the rise of social engineering attempts FireEye has been observing for some time, where bad actors use them to target users that are on fully patched systems or any OS/software profile that is not ideal for any exploit attempts due to software vulnerability. The malvertisement redirect involved in the campaign has been abused heavily in many social engineering campaigns in North America as well.

FireEye Dynamic Threat Intelligence (DTI) shows that this campaign has triggered alerts from customers in the government, telecom and healthcare sectors.

Landing Page

Initially, the landing page only contained code for a VBScript vulnerability (CVE-2018-8174). However, Flash embedding code was later added for more reliable execution of the payload.

The landing page keeps the VBScript code as Base64 encoded text in the ‘<span>’ tag. It loads a JScript function when the page loads, which decodes the next stage VBScript code and executes it using the VBScript ExecuteGlobal function (Figure 8).

Figure 9 shows the JScript function that decodes the malicious VBScript code.

Flash embedding code is inside the ‘noscript’ tag and loads only when scripts are disabled (Figure 10).

The decoded VBScript code exploits the CVE-2018-8174 vulnerability and executes shellcode (Figure 11).

The shellcode downloads a XOR’d payload at %temp% location, decrypts it, and executes it (Figure 12).

Payload Analysis (4072690b935cdbfd5c457f26f028a49c)

The malware contains PE loader code that is used for initial loading and final payload execution (Figure 13).

The unpacked DLL 83439fb10d4f9e18ea7d1ebb4009bdf7 starts by initializing a structure of function pointers to the malware's core functionality (Figure 14).

It then enumerates all running processes, creates their crc32 checksums, and tries to match them against a list of blacklisted checksums. The list of checksums and their corresponding process names are listed in Table 1.

Table 1: Blacklisted checksums

If any process checksums match, the malware goes into an infinite loop, effectively becoming benign from this point onward (Figure 15).

If this check passes, a new thread is started in which the malware first acquires "SeShutdownPrivilege" and checks its own image path, OS version, and architecture (x86/x64). For OS version 6.3 (Windows 8.1/Windows Server 2012), the following steps are taken:

• Acquire "SeTakeOwnershipPrivilege", and take ownership of "C:\Windows\System32\ctfmon.exe"
• If running under WoW64, disable WoW64 redirection via Wow64DisableWow64FsRedirection to be able to replace 64-bit binary
• Replace "C:\Windows\System32\ctfmon.exe" with a copy of itself
• Check whether "ctfmon.exe" is already running. If not, add itself to startup through the registry key "\Registry\Machine\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"
• Call ExitWindowsEx to reboot the system

In other OS versions, the following steps are taken:

• Acquire "SeTakeOwnershipPrivilege", and take ownership of "C:\Windows\System32\rundll32.exe"
• If running under WoW64, disable WoW64 redirection via Wow64DisableWow64FsRedirection to be able to replace 64-bit binary
• Replace "C:\Windows\System32\rundll32.exe" with a copy of itself
• Add itself to startup through the registry key "\Registry\Machine\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"
• Call ExitWindowsEx to reboot the system

In either case, if the malware fails to replace system files successfully, it will copy itself at the locations listed in Table 2, and executes via ShellExecuteW.

Table 2: Alternate dump paths

On execution the malware checks if it is running as ctfmon.exe/rundll32 or as an executable in Table 2. If this check passes, the downloader branch starts executing (Figure 16).

A mutex "Alphabeam ldr" is created to prevent multiple executions. Here payload URL decoding happens. Encoded data is copied to a blob via mov operations (Figure 17).

A 32-byte multi-XOR key is set up with the algorithm shown in Figure 18.

Finally, the actual decoding is done using PXOR with XMM registers (Figure 19).

This leads the way for the downloader switch loop to execute (Figure 20).

Table 3 shows a breakdown of HTTP requests, their expected responses (where body = HTTP response body), and corresponding actions.

Table 3: HTTP requests, responses, and actions

The request sequence leads to GandCrab ransomware being fetched and manually loaded into memory by the malware. Figure 21 and Figure 22 show sample request #1 and request #2 respectively, leading to the download and execution of GandCrab (8dbaf2fda5d19bab0d7c1866e0664035).

Conclusion

In recent years, arrests and disruptions of underground operations have led to exploit kit activity declining heavily. Still, exploit kits pose a significant threat to users who are not running fully patched systems. Nowadays we see more exploit kit activity in the Asia Pacific region, where users tend to have more vulnerable software. Meanwhile, in North America, the focus tends to be on more straightforward social engineering campaigns.

FireEye Network Security detects all exploits, social engineering campaigns, malware, and command and control communication mentioned in this post. MVX technology used in multiple FireEye products detects the first stage and second stage malware described in this post.

Indicators of Compromise

Acknowledgements

We would like to thank Hassan Faizan for his contributions to this blog post.