Opachki, from (and to) Russia with love

Published: 2009-11-03
Last Updated: 2009-11-03 15:36:36 UTC
by Bojan Zdrnja (Version: 1)
13 comment(s)

Opachki is a pretty interesting link hijacking trojan that has been spreading quite a bit in last couple of weeks. I started analyzing it couple of days ago and noticed that in the mean time Joe Stewart of SecureWorks posted his analysis as well (available here).

There are some very interesting things about Opachki so let me start at the beginning. The Trojan is distributed with a dropper which, when infecting the system, drops a DLL file. Both the dropper and the DLL file are packed with a packer called "Mystic Compressor". Besides this, the trojan never actually decrypts all strings in memory but calls a function to decrypt only what it needs and immediately deletes the data after it is not needed. Finally, the packer destroys PE header data from memory to make dumping more difficult.

Besides dropping the DLL, the dropper also does one vary nasty action: it completely deletes the SafeBoot registry key by calling reg.exe, as shown below:

Opachki registry delete

This prevents the system from booting in Safe Mode – the attackers did this to make it more difficult to remove the trojan. This goes well with what I've been always saying – do not try to clean an infected machine, always reimage it.

As Opachki's main goal is to hijack links, it hooks the send and recv API calls in the following programs: FIREFOX.EXE, IEXPLORE.EXE, OPERA.EXE and QIP.EXE. While the first three are well known, I had to investigate the last one. It turned out that QIP.EXE is an ICQ client that is very popular in Russia, so the trojan has a component that directly attacks Russian users.

The trojan will monitor web traffic (requests and responses) that above mentioned applications make and will inject a malicious script tag into every response. The injected script tag can be actually seen in the browser (by selecting the view source option) and can be seen in the image below:

Opachki script insertion

This will cause the browser to go to the shown site (google-analystisks.us), which is still live at the time of writing this diary. The site serves back a JavaScript file which modifies all links in the currently shown web page so they are redirected to a third site (http://thefeedwater.com/?do=rphp&sub=241&b= when I posted the diary). The PHP script at the google-analystisk.us web site is interesting as well – if you try to retrieve it directly you'll get an error back so you have to supply a referrer field. It also checks if you came from a search engine (i.e. Google) and returns back a different JavaScript file so it steals search queries as well.

Finally, Opachki performs another interesting action: it tries to see if the system is already infected with ZEUS and will remove ZEUS' files (rename them to C:ntldrs). It will check for all four ZEUS versions by verifying presence of the following files: C:WINDOWSsystem32ntos.exe, C:WINDOWSsystem32oembios.exe, C:WINDOWSsystem32twext.exe and C:WINDOWSsystem32sdra64.exe. I don't know why they do this, it could be that they are hijacking ZEUS or simply competing for same machines or using same attack vectors as the ZEUS crew.

The whole story about Opachki shows how that the bad guys are prepared to invest a lot of effort into building malware. Removing such a trojan is not simple and I would recommend reimaging the machine as the trojan puts a lot of effort into making removing difficult. As the Trojan is specifically attacking Russian users (among the others), it is probably safe to assume that it originates from Russia as well.

Finally, this shows that the bad guys are (probably) making good money by just hijacking links/clicking.




13 comment(s)


It is all well and good to tell people to re-image their systems, but as soon as you do that then they want to bring back the pictures, emails, documents and whatever from the old machine which probably contain infected garbage. And for that matter, you end up needing a half dozen CDs with drivers for things like cameras, scanners, and whatnot - stuff which lots of end users either throw away or can't find. Then there are the gobs of applications that they have installed - some of which require configuration of some sort.

Now maybe if you are doing this for someone you don't know very well, you can get away with just telling them they are out of luck. But when it is a friend or family member (the last one I had to do was my sister-in-law's computer) it gets harder to just say no.

When I clean up these sorts of machines, BartPE is your friend. I can boot directly from the CD, and then run various AV tools from a clean and safe environment where the malware is not in control. It is also possible to mount the registry of the infected machine and examine/clean it as required from this environment (one of the AV tools on my BartPE disk actually uses this to scan for malware in the registry). My experience is that any one AV tool by itself is insufficient, so I run several of them. In a sense it is time consuming in that the scans take a long time, but it isn't time that I am required to be sitting there and monitoring the thing.
So how might one dump an unencrypted version of such a binary? Perhaps by doing an in-memory patch on the malwares delete function, and then dumping the memory pool? Dumping each function as it decrypts seems like it would make reconstruction harder, plus how would you know that you've got all the functions unless you knew you could walk every code path? And to Jack Russell, I would advise against trying to "clean" a trojan infection, it's a recipe for trouble. I've seen far too many "cleaned" boxes show up infected again shortly thereafter (probably never got "clean" to begin with). Antimalware apps should be a warning sign and the lack of alerts does not mean that a system is clean. I've seen this at the .edu way too many times to trust any "cleaning" tool.
@Curt If the decryption routine is part of the binary (and not the packer) you don't - you can write an external program which will decrypt stuff for you but if you debug it live you'll have to go through decryption routines. Once you figure them out it's not a big deal though.

@Jack I hear you -- I'm aware that in some cases you can't reimage the machine and have to try to clean it. And your approach in such cases sounds good, however, I try to minimize them as much as possible because you really can't be sure that you've cleaned everything, even if you ran multiple AV programs etc...
AV removal quality has been comparatively tested recently. Not encouraging in my mind.

A request: when you do these analyses and discover domains hosting malware, _please_ let malwaredomains.com know about them so they can be added to their list promptly.

Swa - thanks for the link. What they describe seems to matche my experience.

My experience with cleaning is that it takes time. Lots of time. Not always your own time, but running a scan can take many hours, and when you are done you are going to want to run some different tool. It helps a lot if you can just take the machine (or at least the disk) with you so you can launch a scan and then go about your business so you can come back later to figure out what you want to do next. By doing it this way you minimize the amount of your own time and effort that is required to get the job done.

If an AV tool leaves behind registry traces of malware, you can argue that the machine is technically no longer infected as the registry traces by themselves can do you no harm. My experience has been that AV vendors tweak their databases all the time. Thus you might run a update/scan and it finds and removes everything it finds. But you update the AV database and re-run the scan (even as little as a day after the previous scan), and all of a sudden it is finding new stuff - mainly the registry traces that weren't caught the 1st time. A novice at cleaning machines might see this and presume that there is some other infection still present that they haven't caught, but it could just be that the tool is finding the crumbs from before.

I do of course worry that the tools will miss something along the way. That's especially true if the infection is something relatively new that the AV vendors haven't completely analyzed yet. If you have the machine for some amount of time, then you can just turn it off and wait a week or so and then check it again after the vendors have updated their databases.

As noted, a lot of the malware out there will actively attempt to block you from installing any sort of AV tools. They will either block web access to the sites, prevent installation or prevent the tool from working properly. Trying to disinfect an infected machine in such a state can be an exercise in futility. That's why I went the BartPE route - the tools I have on that boot-CD let me remove the active bits of the infections, and once that's done, then you are able to boot the machine again (first in safe mode) and run other tools to clean up the crumbs.

One other word of wisdom for cleaning infected machines. Clean out browser temporary files. On systems these days, the caches are allowed to grow to several Gb per user, and scanning those things takes forever. Most people would never know the difference if you cleaned out that garbage, and odds are that some of the files in there are the infection that was first downloaded.
BartPE is for sure a decent part of anyone's kit. But it's somewhat clear that Jack's world revolves more around family machines, whereas Bojan is talking about production environments. What Jack doesn't catch is that the hours wasted on (maybe) cleaning such a machine will cost more than the machine is worth, and we'll be stuck with an outstanding risk factor.

In the end, you can split the difference. If you're in an environment where a preplan is feasable (you DO intend to mitigate a compromise on each machine you've got, right?) you make and maintain images, and use them. If preplans aren't part of the plan, then you blow an entire day playing roulette. Or in cases that are a mix of both - use a tool like BartPE to simply rip the known-good files off the suspect drive, and then fry it.
Interesting points. I would probably approach it differently at the office myself. But in my experience we very rarely get infections of machines at work - I don't know how well this matches other people's experiences however.

This does raise interesting questions. Has anyone tried to estimate the sizes of the populations of infected machines and tried to break it down in terms of home, work, school, etc? And for that matter, how often are machines with functioning AV software ever infected?
This may explain why I seem to recieve more ICQ spam than expected. I have noticed an increase of IM's from users I do not know. The messages are always in Russian and contain a URL.
This is a great discussion regarding the frustrations of cleaning infected computers. The key is prevention and of course defense in depth. I struggle with my clients trying to get them to understand that AV alone won't protect their systems. You must patch in a timely manner and restrict local users from being admins. The few clients that take all of my advice have almost zero infections. Those that take some advice have many issues.

With regard to reinstalling the OS or reimaging, I have to agree that this is the best route vs. attempting cleaning. This is especially true when you have novice level 1 type IT folks trying to clean a machine. Even an experienced IT staff member would be challenged by the current threats. If you don't practice patching, restrict local admin and install decent AV, you will have a lot to clean up.

Diary Archives