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 exithub1.su, exithub2.su, exithub-pql.su and 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.
Payload Extraction
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.
Self-Extracting Archive
With 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”.
Executing ms.exe, checking %TEMP%\RarSFX or extracting with 7zip will yield three files: Bigrmkwhrr.png (645e7f63886d74c5edd149caac1b41cd), Imvenagxehdoj.xml (9f543d1ca1fe9a2ea69984f2a3804fe1), and Jnmsiyyks.exe (a86f56fee647446d33d555b25d871bf8).
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:
Network Activity
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:
{"action":"connect","uid":"abcdef0123","rid":"email_spread_XXX","username":"user","computername":"LAPTOP","ip":"123.45.67.89","country":"UE"}
If the registration is successful, the server will return a password:
{“status”:”success”,”password”:”sAKFSdgVKVdFLfvjwWkvdjjXXlotynss”}
and the client will update the server with its status in increments:
{"action":"update","uid":"abcdef0123","filecount":"8320"}
Then, upon success, the server will return:
{"status":"success","null":"null"}
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.
Attribution
I’m half-joking about the heading of this section, we all know attribution is hard. But if we wanted to comment slightly on the topic, we could imply from directory listings shown in the image to the right that this system may have been set up/compromised on June 20th. And, due to some friendly comments in the HTML source of the page shown below the directory listing, we see that the author needs to fix the timer javascript. You read Russian too, right?
