Sometimes people naively open .onion links in their browsers, so every few days I’ll check out what pops up in Investigate to dig in a little deeper. Today I came across gsxrmcgsygcxfkbb.onion and poof! down the rabbit hole I tumbled.
Kelihos Aids Distribution
We first started seeing WildFire ransomware hitting our resolvers on June 21, 2016, and there has been an increase in activity over the last few days. This is most likely due to a bump in distribution by the Kelihos Botnet.
Before the ransomware takes hold, systems infected with WildFire will aggressively attempt to communicate
exithub-xuq.su. If we look at the number of requests for those domains, we see a nice influx:
Most infection reports are coming in from the Netherlands. If we check out who is requesting these domains, we see that most requests originate from the same place: 95% Netherlands.
Word Macro via Email
The journey starts with an all-too-common initial infection vector: a user receives an email with a macro-embedded Word document attached. In this case, it was titled BT-32084.doc (8f8741e18aa6b7b8282402f0aea5e0c9).
The Word document displays a message to the reader instructing them to enable macros to view the content. Those with an eye for detail might notice that the document is 205 pages long! This is because it’s using an oldie-but-goodie trick by embedding its payload in the document text, rather than within a document stream. At first glance, you might miss it since all of the pages appear to be blank. An easy way to view this hidden “treat” is to select all text in the document with CTRL+A, then change the color to something other than white, like red. Here’s what you’ll see:
The prevalence of 0x33 bytes suggests that the payload could be XOR’ed with 0x33. Rather than take this avenue for analysis, let’s use another technique to take the express train to the binary.
oledump will allow you to dump the various streams of the document, or if you’re in a tight analysis environment and speed is more important than thoroughness, you could just ‘ride-or-die’ and execute the macro. I have always thought DMX and Fetty were onto something, so let’s go for ‘ride-or-die’.
Searching for calls to the Shell() function within the macro will fast-track you to what is being executed. If we set a breakpoint on the call and inspect its parameters at runtime, we can see that the macro is calling
C:\ProgramData\Memsys\ms.exe (f157038d7b105cee1b8bb8c957f1ec39), which means it likely wrote ms.exe to the file system earlier in macro.
ms.exe resting nice and comfortably on your file system, you might be so inclined to open it up in IDA to let the real work begin.
That is, until a few strings indicating this is a self-extracting archive bring you right back to “ride-or-die”.
%TEMP%\RarSFX or extracting with 7zip will yield three files:
Imvenagxehdoj.xml (9f543d1ca1fe9a2ea69984f2a3804fe1), and
Dot Net Obfuscation!
WildFire’s second-stage executable (
Jnmsiyyks.exe ) is just really a wrapper around the supplemental files that were extracted in the same directory. The obfuscated code creates a big nasty AppContext with the contents of
Bigrmkwhrr.png as a variable, decodes it, and then launches it as a form in a thread.
Dot Net Ransomware
Luckily, this thread’s assembly is not obfuscated, so with some quick XOR’ing, we have access to the full source of the source. Here’s a quick script to handle the XOR’ing:
As mentioned above, the malware aggressively attempts to contact its servers —
exithub1.su, exithub2.su, exithub-pql.su and exithub-xuq.su. Once it is successful, it will POST base64-encoded data to the server. I changed the output slightly to anonymize it:
If the registration is successful, the server will return a password:
and the client will update the server with its status in increments:
Then, upon success, the server will return:
Notification and Payment
Once WildFire encrypts all of the files on the system, the ransomware lets the user know by the now-ominous ransomware notification page. One interesting thing here is that the payment page is hosted on both the internet and on Tor. Usually bad actors only leverage Tor to remain anonymous, but here the attacker is either confident in the privacy of the system hosting the landing page, or doesn’t care to remain anonymous.