Anybody fighting Zero Access rootliy

[stevenamills]

It's beating me up! MB sees nothing - ditto eset. Combo sees it, but is ineffective. Not surprisingly, the Webroot specialized tool doesn't get a smell.

Any advice would be appreciated,

 

[PaulRome]

May want to give this a read.

http://www.malwarecity.com/blog/how...refef-from-your-pc-as-easy-as-1-2-3-1160.html


Best of luck

 

[othersteve]

Yup, just got finished with two machines over the past 24 hours and was actually thinking about posting about it.

The first one I partially killed from offline using my normal methods but finished off using the Webroot tool. The second I actually ended up killing offline entirely just for additional practice and gratification. It actually wasn't all that difficult once I knew what to look for:

• Kill the randomly-named numeric file in %WinDir% with the alternate data stream (e.g. %WinDir%\3439254774:153289011.exe)
• Remove the NTFS reparse point created within %WinDir% (e.g. $NtUninstallKBxxxxx$) using a tool such as junction by Sysinternals, then delete the actual folder containing the rootkit files.
• Run an integrity check on the system drivers.
• Scan the installed services registry keys to ensure they don't relate to the malware.
• Clear all Temp folders.
• Reboot into Windows and check with GMER to ensure no suspicious drivers exist, then scan with TDSSKiller/antizeroaccess just for good measure.
• Repair ACLs or reinstall any security software which attempted to access the rootkit and was killed by its tripwire.

Remember, these steps have to be performed from a PE/offline boot environment.

The last couple of steps aren't even really necessary, but it's best to be safe. If antizeroaccess can't nail it on its own, this process will kill it for sure.

 

[FoolishTech]

It's beating me up! MB sees nothing - ditto eset. Combo sees it, but is ineffective. Not surprisingly, the Webroot specialized tool doesn't get a smell.

Any advice would be appreciated,

Probably ineffective because the malware EXE hiding in alternate data stream is preventing the driver from being cleaned. *shrug*

I have cleaned this up recently on live systems by first creating an Image File Execution Option to replace this executable with a dummy file. Naturally, I use D7 to accomplish this.

Fire up D7, click the D7 menu > IFEO Modifier. In the drop down list of running processes, find/select the file looking like a bunch of random numbers, a colon, and more numbers followed by .exe (e.g. 1235985734:4473265567.exe) then hit the CREATE button.

From here, that process cannot execute, instead a dummy file will fire. So you can kill the process or simply reboot the machine and not worry about it executing again. But for now, no need to delete the actual file/ads (it may be recreated anyway) until you've finished cleaning the virus.

Next you can pretty much do what othersteve posted, except you don't have to do it *offline* and can work on the live system.

I've found that TDSSKiller finds the infected driver in system32\drivers, however it's good to know that there are several specific removal tools for this virus I wasn't aware of. I'll look into those for the future...

As for repairing ACLs which the removal tool doesn't do, you can use the new "Repair Permissions" function (in D7 v4.5.9 or above) on the malware tab. Vs. the old way of using secedit, the function now uses subinacl.exe and actually resets default ACLs on the entire partition AND registry - the benefit is you don't have to know where the messed up ACLs are, the downside is it will take FOREVER. But it works great.

Granted if you know where the ACLs you need to fix are in the file system, (e.g. the antivirus installation directory obviously), you go there, right click on the entire directory, and use the Take Control option... but I just use Repair Permissions though because it's complete. I've had several Windows Installer 2203 errors when installing / removing software after this particular virus that a full Repair Permissions action will fix.

 

[iladelf]

I just saw it for the first time recently (around two weeks ago). Combofix indeed dropped the hammer on it; found the rootkit and deleted a lot of random files from the computer. Other scans after that (TDSSKiller, SAS, MBAM) found nothing. There were a few permission issues I had to fix (namely regarding Windows Update if I remember right).

It's a tough one, for sure! I'd say that with this infection the first tool I'd run would be Combofix.

And of course, I'd run those from the D7 tool! (thanks, FoolishTech!)

 

[othersteve]

That's a great idea with the IFEO, FoolishTech. I'll definitely try to give that a shot on the next one

 

[ZenTree]

Fixed one on site today, took about 2 hours including a couple of scans after to make sure hadn't missed anything. infected tcp stack redirecting all search results etc. Combofix recognised it as a zerostack rootkit if I remember correctly and took out some chunks of it. TDSSKiller and gmer were both knocked out before (gmer when trying to restore code).

Thanks Foolish for the info, sounds v interesting and i'll have to give it a go on the next one I find.

edit: system was bsod in normal mode, figures comes through java since found 3 virus laden jar files in the temp directories with matching time stamps.

 

[MobileTechie]

Can I ask some dumb questions here:

What does the IFEO modifier actually do and why?
How does one know what the NTFS parse point is and what is happening with it?

I'm also interested to know how you guys knew what to do here. I've got rid of this virus a few weeks ago but mostly by just getting rid of that 123451234:12431234.exe file and offline scanning and combofix. You seem to have worked out a much more effective and specific attack on it but I don't know how you've worked it out.

 

[FoolishTech]

Can I ask some dumb questions here:

What does the IFEO modifier actually do and why?

Best read about IFEO Modifier here.

"IFEO" stands for Image File Execution Option, a registry location that is typically for debugging apps. It can be used BY malware to hijack other EXEs, or it can be used BY YOU to combat malware!

Basically it works like this. Ex: You put in a value for executable A, attach a debugger value to it with a different executable (B), and any time you try to run executable A in Windows, executable B runs instead!

So malware can use this to say run itself instead of a legitimate app (e.g. notepad.exe, iexplore.exe, etc.)

But you can fight back by creating an IFEO for the malware executable, attaching a perfectly harmless dummy executable as the debugger value... which basically means the malware can't execute no matter what.

I use this method a lot especially with new malware I'm not yet familiar with. It lets you get in there and work at finding the non-executable malware (e.g. infected drivers, etc.) without being bothered by the malware's pesky attempts to kill off your processes or otherwise re-write itself...

How does one know what the NTFS parse point is and what is happening with it?

A quick explanation (and tool) here. A longer one here.

Rather than go into it, a junction point is sort of like an IFEO, but for the file system. Basically a junction created at directory A pointing to directory B means that anytime you (or apps) try to go to directory A, they actually go to directory B.

I have seen this with malware much that I recall. Until now.

I mostly use junctions on servers to move directories from a crowded C: drive that might be running out of free space, to a secondary partition or drive, without the OS/Apps on the server knowing any different. You know how like Dell servers and such come with that tiny C: partition that runs out of space sooner or later and there's nothing you can do about it but bring the server down and repartition... well when you can't do that, you physically move directories to another drive to fee up space, then use junctions to create a junction point in the location of the original directory, pointing to the new drive:\directory.

 

[ZenTree]

Can I ask some dumb questions here:

What does the IFEO modifier actually do and why?
How does one know what the NTFS parse point is and what is happening with it?

I'm also interested to know how you guys knew what to do here. I've got rid of this virus a few weeks ago but mostly by just getting rid of that 123451234:12431234.exe file and offline scanning and combofix. You seem to have worked out a much more effective and specific attack on it but I don't know how you've worked it out.

IFEO modifier is just a debug tool that tells windows what program to open a certain file with. Note it's a particular file (e.g bob.exe) as opposed to any generic .exe . So in foolish's instructions you tell it to open it with a dummy exe that actually does nothing, instead of running the program.

The NTFS parse point is just a junction point as far as I know. Junction points i'm less familiar with but from what I know of them they basically allow you to link two locations to be the same logical location as far as windows is concerned. I learn/t about these a while back when I wanted to move steam files to diff hard drive from the default C drive. You can't move them but you can use junction points to fool windows into thinking files are in C:\X when they are instead in Z:\Y
Tried explaining in more detail but failed, you'd be better checking the sysinternals tool for this as i'm far from an expert. As to what the virus was leveraging from this, i'm not sure, just obscurity or something more? Sure someone more knowledgable/ less tired can explain it.

edit: yeah I should have refreshed. His explanation is way better

 

[MobileTechie]

Thanks guys.

So I've infected a VM with this virus and tried D7's IFEO Modifier tool to load the dummy exe and this has enabled other tools to work unhindered. Plus the take ownership tools was a very nice quick way of getting blocked scanners working again too. You're frikking genius by the way Foolishtech - D7 really is one amazing piece of work. One donation coming your way.

TDSSKiller found the infected driver (as did sigverif as it happens) and fixed it.

However the system is still infected. MBAM or whatever will find infected files in the temp areas, reboot but they are still there. So the rootkit is still active. I just appear to have neutered the tripwire exe.

I used junction and it says it cannot open c:\windows\$NTUninstallKB7903$. I assume this is actually a junction point but protected somehow. Certainly I cannot open, delete or take ownership of this directory. Junction.exe won't let me create a new parsepoint for it which I thought was a bright idea but sadly not.

I dare say some scanner or other will finish this off or I can go offline but I'd be interested to hear how you finished it off online at this point. Like ZenTree, I'd also like to know how the virus is using the parsepoint to its advantage here.

 

[MobileTechie]

I found out that Nirsoft do a tool called NTFSLinksView which is a nice GUI based tool to see these parse-points and the folder they link to.

In this case the c:\windows\$NTUninstallKB7903$ file links to \systemroot\system32\config

Turns out dir /aL /s C:\ will show you which junctions you have but not where they go to.

 

[FoolishTech]

Thanks guys.

So I've infected a VM with this virus and tried D7's IFEO Modifier tool to load the dummy exe and this has enabled other tools to work unhindered. Plus the take ownership tools was a very nice quick way of getting blocked scanners working again too. You're frikking genius by the way Foolishtech - D7 really is one amazing piece of work. One donation coming your way.

TDSSKiller found the infected driver (as did sigverif as it happens) and fixed it.

However the system is still infected. MBAM or whatever will find infected files in the temp areas, reboot but they are still there. So the rootkit is still active. I just appear to have neutered the tripwire exe.

I used junction and it says it cannot open c:\windows\$NTUninstallKB7903$. I assume this is actually a junction point but protected somehow. Certainly I cannot open, delete or take ownership of this directory. Junction.exe won't let me create a new parsepoint for it which I thought was a bright idea but sadly not.

I dare say some scanner or other will finish this off or I can go offline but I'd be interested to hear how you finished it off online at this point. Like ZenTree, I'd also like to know how the virus is using the parsepoint to its advantage here.

Sweet, thanks!

What shows up in GMER, and you have checked for rogue services? If you can't find what is keeping them active but MBAM keeps finding the same files, you can block them by renaming them, and creating a dummy directory in place of it named the same name as the file was (also a right click feature of D7). Then reboot.

You should be able to delete the junction with -d

I'm not sure that that's about, but it appears to be the same behavior across infections. I noted the same directory on my removal as I recall. Good thing you couldn't delete it though, as it redirected to the registry directory lol.

I found out that Nirsoft do a tool called NTFSLinksView which is a nice GUI based tool to see these parse-points and the folder they link to.

In this case the c:\windows\$NTUninstallKB7903$ file links to \systemroot\system32\config

Turns out dir /aL /s C:\ will show you which junctions you have but not where they go to.

Nice find! I love Nirsoft tools!

 

[ZenTree]

So the only benefit for the junction point is that if we're tracking through registry keys and see something pointing to $uninstall we might be unaware where the file actually is?

If that's the case then i'm not so worried now

@MobileTechie - thanks for the information. I'll have to try and source the infection to have a run through as well.

 

[FoolishTech]

If you guys are running tests in a VM, I recommend using RegShot to take a snapshot of the registry, \windows and \Docs and settings or \Users and \ProgramData on vista/7.

Basically use it once to snapshot the before, and again to snapshot after the infection. When compared, it will give you a good idea of changed files/reg entries.

 

[MobileTechie]

So the only benefit for the junction point is that if we're tracking through registry keys and see something pointing to $uninstall we might be unaware where the file actually is?

If that's the case then i'm not so worried now

@MobileTechie - thanks for the information. I'll have to try and source the infection to have a run through as well.

If you need a copy just let me know and I'll put one on a share somewhere.

Reading up on bleeping computer forums etc it seems Junction.exe worked for a while but then seems to have stopped working at breaking the parse points. So maybe the developers have updated the kit now.

 

[ZenTree]

Thanks MobileTechie, I managed to source one from malwaredomainlist. Different varient from the one I had worked on before, was cdrom.sys that was infected instead of all the network related files which made life easier.

Using some of foolish's recommendations and usual procedures was able to remove all with just D7 and gmer on the live system, the only thing I cannot remove is the junction point, despite having actually deleted everything else. Get an access denied error, maybe like you said they've altered things a bit. Scans all show clean so must be a permission somewhere.

Differences to the other one i'd worked on bar the diff .sys files was just a shell hijack as well.

Quite enjoyed removing it though, may look for another varient to hone my manual removal tricks a bit more.

 

[FoolishTech]

If you need a copy just let me know and I'll put one on a share somewhere.

Reading up on bleeping computer forums etc it seems Junction.exe worked for a while but then seems to have stopped working at breaking the parse points. So maybe the developers have updated the kit now.

Interesting... Can I get a copy of your sample?

 

[MobileTechie]

Interesting... Can I get a copy of your sample?

I've emailed you a copy at foolishit.com - it's zipped and altered to get to you hopefully.

 

[FoolishTech]

If you need a copy just let me know and I'll put one on a share somewhere.

Reading up on bleeping computer forums etc it seems Junction.exe worked for a while but then seems to have stopped working at breaking the parse points. So maybe the developers have updated the kit now.

I've emailed you a copy at foolishit.com - it's zipped and altered to get to you hopefully.

Got it sweet thanks!

EDIT: HMM... doesn't seem to be the full payload, or for some reason I can't seem to get it to spread the full infection... it doesn't drop the ADS file nor does it seem to infect any system drivers...