Fallout Exploit Kit Used in Malvertising Campaign to Deliver GandCrab RansomwareTowards 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 href="https://www.nao-sec.org/2018/09/hello-fallout-exploit-kit.html">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, href="https://www.fireeye.com/blog/threat-research/2017/03/still_getting_served.html">cushion
domains, and then to the exploit kit landing page is shown in
Figure 1.
Figure 1: Malvertisement redirection to
Fallout Exploit Kit landing page
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).
Figure 2: Content in the first ad page
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, 4 and 5
Figure 3: 302 redirect to exploit kit
controlled cushion servers
Figure 4: Another redirection before
exploit kit landing page
Figure 5: Last redirect before user
reaches exploit kit landing page
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.
Figure 6: Fake AV prompt for Mac users
Figure 7: Fake Flash download prompt
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 ( href="https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8174">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 8: Snippet of landing page
Figure 9 shows the JScript function that decodes the malicious
VBScript code.
Figure 9: Base64 decode function
Flash embedding code is inside the ‘noscript’ tag and loads only
when scripts are disabled (Figure 10).
Figure 10: Flash embedding code
The decoded VBScript code exploits the href="https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8174">CVE-2018-8174
vulnerability and executes shellcode (Figure 11).
Figure 11: Decoded VBScript
The shellcode downloads a XOR’d payload at %temp% location,
decrypts it, and executes it (Figure 12).
Figure 12: XOR binary transfer that
decrypts to 4072690b935cdbfd5c457f26f028a49c
Payload Analysis (4072690b935cdbfd5c457f26f028a49c)
The malware contains PE loader code that is used for initial loading
and final payload execution (Figure 13).
Figure 13: Imports resolver from the PE loader
The unpacked DLL 83439fb10d4f9e18ea7d1ebb4009bdf7 starts by
initializing a structure of function pointers to the malware's core
functionality (Figure 14).
Figure 14: Core structure populated with
function pointers
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.
CRC32 Checksum
|
Process Name
|
99DD4432h | width="312" valign="top">vmwareuser.exe
2D859DB4h | width="312" valign="top">vmwareservice.exe
64340DCEh | width="312" valign="top">vboxservice.exe
63C54474h | width="312" valign="top">vboxtray.exe
349C9C8Bh | width="312" valign="top">Sandboxiedcomlaunch.exe
5BA9B1FEh | width="312" valign="top">procmon.exe
3CE2BEF3h | width="312" valign="top">regmon.exe
3D46F02Bh | width="312" valign="top">filemon.exe
77AE10F7h | width="312" valign="top">wireshark.exe
0F344E95Dh | width="312" valign="top">netmon.exe
278CDF58h | width="312" valign="top">vmtoolsd.exe
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).
Figure 15: Blacklisted CRC32 check
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.
Dump Path
|
Dump Name
|
%APPDATA%\Microsoft | width="312" valign="top">{random alphabets}.exe
%APPDATA%\Microsoft\Windows\Start
Menu\Programs\Startup | | valign="top">{random alphabets}.pif
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).
Figure 16: Downloader code execution
after image path checks
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).
Figure 17: Encoded URL being copied
A 32-byte multi-XOR key is set up with the algorithm shown in Figure 18.
Figure 18: XOR key generation
XOR Key (83439fb10d4f9e18ea7d1ebb4009bdf7)
|
{ 0x25, 0x24, 0x60, 0x67, 0x00,
0x20, 0x23, 0x65, 0x6c, 0x00, 0x2f, 0x2e, 0x6e, 0x69, 0x00,
0x2a, 0x35, 0x73, 0x76, 0x00, 0x31, 0x30, 0x74, 0x73, 0x00,
0x3c, 0x3f, 0x79, 0x78, 0x00, 0x3b, 0x3a } |
Finally, the actual decoding is done using PXOR with XMM registers
(Figure 19).
Figure 19: Payload URL XOR decoding
This leads the way for the downloader switch loop to execute (Figure 20).
Figure 20: Response/Download handler
Table 3 shows a breakdown of HTTP requests, their expected responses
(where body = HTTP response body), and corresponding actions.
Request #
|
Request URL
|
(Expected Response) body+0x0
|
body+0x4
|
body+0x7
|
Action
|
1 | | valign="top">hxxp://91[.]210.104.247/update.bin
width="104" valign="top">0x666555
| valign="top">0x0
url
for request #2 | | valign="top">Download payload via request #2, verify MZ and
PE header, execute via CreateProcessW
1 | | valign="top">hxxp://91[.]210.104.247/update.bin
width="104" valign="top">0x666555
| valign="top">0x1
| valign="top">N/A
| valign="top">Supposed to be executing already downloaded
payload via CreateProcess. However, the functionality has been
shortcircuited; instead, it does nothing and continues loop
after sleep
1 | | valign="top">hxxp://91[.]210.104.247/update.bin
width="104" valign="top">0x666555
| valign="top">0x2
url
for request #2 | | valign="top">Download payload via request #2, verify MZ and
PE header, load it manually in native process space using its
PE loader module
1 | | valign="top">hxxp://91[.]210.104.247/update.bin
width="104" valign="top">0x666555
| valign="top">0x3
| valign="top">N/A
| valign="top">Supposed to be executing already downloaded
payload via its PE loader. However, the functionality has been
shortcircuited; instead, it does nothing and continues loop
after sleep
1 | | valign="top">hxxp://91[.]210.104.247/update.bin
width="104" valign="top">0x666555
| valign="top">0x4
url
for request #3 | | valign="top">Perform request #3
1 | | valign="top">hxxp://91[.]210.104.247/update.bin
width="104" valign="top">N/A
| valign="top">N/A
| valign="top">N/A
| valign="top">Sleep for 10 minutes and continue from request
#1
2 | | valign="top">from response #1
| valign="top">PE payload
| valign="top">N/A
| valign="top">N/A
| valign="top">Execute via CreateProcessW or internal PE
loader, depending on previous response
3 | | valign="top">from response #1
| valign="top">N/A
| valign="top">N/A
| valign="top">N/A
No
action taken. Sleep for 10 minutes and start with request
#1 |
Table 3: HTTP requests, responses, and actions
The request sequence leads to href="https://www.fireeye.com/blog/threat-research/2018/04/cryptocurrencies-cyber-crime-blockchain-infrastructure-use.html">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).
Figure 21: Request #1 fetching initial
command sequence from payload URL
Figure 22: Request #2 downloads GandCrab
ransomware that gets manually loaded into memory
Conclusion
In recent years, arrests and distruptions 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 href="https://www.fireeye.com/solutions/nx-network-security-products.html">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
Domain / IP / Address / Filename
| width="312" valign="top">
MD5 Hash Or Description
finalcountdown.gq,
naosecgomosec.gq, ladcbteihg.gq, dontneedcoffee.gq
| Exploit kit domains
|
78.46.142.44, 185.243.112.198
| Exploit kit IPs |
47B5.tmp | width="312" valign="top">4072690b935cdbfd5c457f26f028a49c
| valign="top">hxxp://46.101.205.251/wt/ww.php
hxxp://107.170.215.53/workt/trkmix.php?device=desktop&country=AT&connection.type=BROADBAND&clickid=58736927880257537&countryname=
Austria&browser=ie&browserversion=11&carrier=%3F&cost=0.0004922&isp=BAXALTA+INCORPORATED+ASN&os=windows&osversion=6.1&useragent=
Mozilla%2F5.0+%28Windows+NT+6.1%3B+WOW64%3B+Trident%2F7.0%3B+rv%3A11.0%29+like+Gecko&campaignid=1326906&language=de&zoneid=1628971
Redirect URL
examples used between malvertisement and exploit kit
controlled domains |
91.210.104[.]247/update.bin
| | valign="top">Second stage payload download URL
91.210.104[.]247/not_a_virus.dll
| width="312" valign="top">8dbaf2fda5d19bab0d7c1866e0664035
Second stage payload (GandCrab ransomware)
Acknowledgements
We would like to thank Hassan Faizan for his contributions to this
blog post.
Source:
Fallout Exploit Kit Used in Malvertising Campaign to Deliver GandCrab Ransomware
