We’ve seen a couple of cases of this trojan
hitting client computers lately; unfortunately, the security bulletin by the CYCO doesn’t have much yet in terms of information on IP addresses, domain names, or what else the trojan might be doing in the background, so I dusted off the old forensics toolkit and did a bit of digging.
Look at this bad boy! Innit unreal? Brilliant 🙂 I knew this kind of stuff was around but I must admit it’s the first time I encounter ransomware this targeted…
My colleague confirmed that this was only happening on the user’s account – not the local admin account present on the computer. So the first thing we did was run Sysinternals’ Process Monitor to identify what was causing the screen to appear. Note that we use Deep Freeze on users’ computers and the machine was frozen at the time of the infection, so it was likely that what was running was persisted on the user’s drive. I really wish that we could freeze everything but the user’s Desktop, My Docs, and Favorites – however, that seems to royally piss off our users. Would have prevented this from happening though. Anyway, moving on. If you know that the only location where this executable could possibly exist is the user’s drive, it’s easy to identify the culprit:
No big surprise there — it’s running in the user’s Temp folder. Unsurprisingly as well, the user’s SoftwareWindows NTCurrentVersionWinlogon file has been modified to point the shell to that upd executable – that’s easily sussed out by using regripper or regdump. With regripper, we even get a timestamp of when this was done which will be useful for cross-referencing information later.
OK great, so now we know where this thing is – how did it get there?
It was a bit harder to figure out how the hell the trojan got on the user’s computer, I’ll admit. I used Web Historian at first to identify any suspicious sites. I don’t know about the rest of you out there, but my experience is that when malware shows up on users’ computers, it’s typically because they’ve been downloading something illegal or, er, carnal. However, when looking at the user’s web history no alarm bells were going off. All good, clean, unremarkable sites. I went as far as to investigate the user’s mail store to see if the machine could have gotten infected by email – nothing suspicious there either. USB keys would have left a trace in the registry but since the machine was frozen, I wouldn’t be able to figure out if a key was inserted at the time of the infection. I therefore switched tactics and ran a timeline analysis of the user drive using sleuthkit. That’s when I found this:
The same minute the executable was written, something was written to the Java cache. Coincidence? Yeah right. I took a look at the index file, guess what I found?
If you decompile the JAR using jad, you get something like this:
If you check out the domain and IP address written in the index file, you’ll see that the domain is registered to a Russian registrant; the IP address traces back to the domain, but is hosted in the Netherlands.
That’s all the JAR file seems to do. I haven’t messed around with the upd.exe file yet, will probably do so sometime soon. In the meantime, I hope that you found this entertaining 😀 Should I be looking at anything else? Let me know.