Anybody fighting Zero Access rootliy

[ZenTree]

I couldn't find another version online so if you're able to post to a share online that'd be appreciated MobileTechie, company email too protected for me to be able to receive via that.

 

[MobileTechie]

It's here: http://www.mediafire.com/?507w4j5t580txyg

password is password

 

[ZenTree]

Thanks, i'll have a run through this tomorrow

 

[DCGPX]

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.

@foolishtech - I might be missing the obvious but where exactly is the IFEO modifier exactly in D7?

I was going to try this on a sample zeroaccess but can't find it in the program!

Probably staring at me but I can't see it!

Thanks


www.tornadopc.com

 

[MobileTechie]

Click the D7 logo in the top left and a menu comes up.

 

[DCGPX]

Thanks MT - knew it would be staring at me!!!


www.tornadopc.com

 

[ZenTree]

MobileTechie's sample is pretty much identical to the one from malwaredomainlist bar it infected ipsec.sys this time.

I'm still unable to remove the junction. Sysinternals tools comes up with an access denied error on the $ntupdate folder in question when scanning, so although you get shown it, it says no parse points found. Trying to delete it gets the same error.

If someone does manage to remove the junction i'd be interested in how to do it for future ref. The nirsoft tool will only show links, not remove them.

All in all though quite a "nice" virus to remove in terms of the different things going on.

 

[MobileTechie]

If you run Gmer it can see the files in the junction directory. I've found no way of finding these files anywhere else. I seem to remember reading that the virus mounted a fake volume. Maybe the junction leads ultimate to that volume and is the only way in which those files are accessible by the OS?

I think going offline is the only way to remove the junction

 

[othersteve]

Hey guys,

With regard to the junction issue, if you just want to get at the files...

See if this works:

robocopy /mir /xj %WinDir%\$RootkitJunctionDir$ C:\zeroaccess

(You will need robocopy from the 2003 Resource Kit or later).

Or perhaps to try and delete it:

fsutil reparsepoint delete %WinDir%\$RootkitJunctionDir$

NOTE: Try this on a VIRTUAL MACHINE first!

Just some random thoughts that may work. Any luck?

 

[ZenTree]

If you run Gmer it can see the files in the junction directory. I've found no way of finding these files anywhere else. I seem to remember reading that the virus mounted a fake volume. Maybe the junction leads ultimate to that volume and is the only way in which those files are accessible by the OS?

I think going offline is the only way to remove the junction

The files are hidden (as in system protected files hidden not just normally hidden) and each time have been in the same place (local settings, app data, gibberish folder name) - I think that's right, yet to have my coffee. I have succesfully removed the files both times on the live system once you take care of the service, ADS, infected sys file and the usual run items.

@othersteve - thanks for that! If I get chance i'll reinfect the virtual machine and give those a go

 

[FoolishTech]

Or perhaps to try and delete it:

fsutil reparsepoint delete %WinDir%\$RootkitJunctionDir$

NOTE: Try this on a VIRTUAL MACHINE first!

Just some random thoughts that may work. Any luck?

YES! Thanks othersteve! fsutil succeeds where junction.exe fails. We CAN get rid of these extras on a LIVE system:

Step 1: With D7 open, navigate to %WinDir%\$RootkitJunctionDir$

Step 2: Right click - Take Control. Assign current user ownership and permissions.

Step 3: fsutil reparsepoint delete %WinDir%\$RootkitJunctionDir$ (should succeed after Take Control)

Step 4: Open the dir and look inside, or just delete it!

I plan to automate this as a 1-click fix within the next release of D7................

FYI on the systems I have all seen:

* the directory has had the SAME NAME. %windir%\$NtUninstallKB32069$ - I'm sure you can all confirm this?

* the reparse point redirects this dir to %windir%\system32\config for no particular reason that I can determine, but that is beside the point. The reparse point is laid down on TOP of the existing directory with the malware files inside, (I wasn't aware you could do that!) as an attempt to prevent you from actually accessing the files inside that directory.

Hope this helps!

 

[ZenTree]

Thanks Foolish

As a side point, I wonder how the malware uses/refers to those files, you would think the junction would isolate it and make it tricky to say the least for anything else in the virus to relate to it.

 

[FoolishTech]

Ok, I attempted to script the steps to get rid of the rogue reparse point in D7 v4.6.4 currently in the Pre-Release stage.

The function is on the Tweaks tab > NTFS Junctions > and the button to do the deed is "Destroy Junction"...

Hopefully this will work right off. I already fixed my latest machine on the bench so can't test it out...

EDIT: IT DOES WORK! Just tested on another PC! Will be updating D7 to v4.6.4 final soon for everyone out there with this new pesky malware.

EDIT: v4.6.4 final released!

 

[othersteve]

Glad to hear it worked, guys. It was just a hunch! I would have tested myself but I am busy with a million jobs today, the worst of which is a RAID 5 recovery...

FYI on the systems I have all seen:

* the directory has had the SAME NAME. %windir%\$NtUninstallKB32069$ - I'm sure you can all confirm this?

* the reparse point redirects this dir to %windir%\system32\config for no particular reason that I can determine, but that is beside the point. The reparse point is laid down on TOP of the existing directory with the malware files inside, (I wasn't aware you could do that!) as an attempt to prevent you from actually accessing the files inside that directory.

Yup, that's precisely what I've seen. My routine has always involved offline removal, but it's great to know it's possible to do it from within the host OS now also!

Thanks for all your hard work on D7! It's cool to have provided a slight bit of help in the process.

Edit: I believe this is the same technique ComboFix has used to protect its files in the past (a junction on top of the extracted directory leading back to %SYSTEMDRIVE%). Not sure if it still does, but it's interesting to note nonetheless!

 

[Slaters Kustum Machines]

Ok, I attempted to script the steps to get rid of the rogue reparse point in D7 v4.6.4 currently in the Pre-Release stage.

The function is on the Tweaks tab > NTFS Junctions > and the button to do the deed is "Destroy Junction"...

Hopefully this will work right off. I already fixed my latest machine on the bench so can't test it out...

EDIT: IT DOES WORK! Just tested on another PC! Will be updating D7 to v4.6.4 final soon for everyone out there with this new pesky malware.

EDIT: v4.6.4 final released!

Looks like I will be picking up a machine with this infection tonight, if so I will definitely be trying out your tool as others have posted all of my normal tools are almost pointless.

 

[MisterMalware]

Originally Posted by FoolishTech
"the reparse point redirects this dir to %windir%\system32\config for no particular reason that I can determine"

"The rootkit stores the additional modules in a hidden RC4 encrypted volume inside %windir%\system32\config"
Source: Webroot (Prevx) Blog

Originally Posted by FoolishTech
"the directory has had the SAME NAME. %windir%\$NtUninstallKB32069$ - I'm sure you can all confirm this?"

%windir%\$NtUninstallKBxxxxx$ The KB numbers have varied.
Source: Many ComboFix logs over time.

 

[FoolishTech]

"The rootkit stores the additional modules in a hidden RC4 encrypted volume inside %windir%\system32\config"

Interesting. I dug a little deeper and found a whitepaper from Prevx that describes the encrypted volume:

"The fake volume is stored inside a file located to systemroot\system32\config\<random file name>"

Interestingly enough, on every one of these PCs so far I've not seen ANYTHING additional in system32\config - it seems the payload is stored in the actual $NtUninstallKBxxxxx$ dir which is visible after you take ownership/permissions and remove the reparse point....

So I'm still at the conclusion that there's no particular reason...

So I read further:

"As documented above, the rootkit used to create a file under the %systemroot%\system32\config folder which worked as a hidden
volume container. The file was mounted as a NTFS volume, which was encrypted and decrypted on the fly by using a plain RC4
encryption. The new release of ZeroAccess totally changes this approach: the rootkit doesn’t use anymore its hidden NTFS volume
and it doesn’t use anymore the RC4 encryption – at least not as it is defined.

ZeroAccess now creates a folder under the %systemroot% directory (usually C:\WINDOWS), called $NtUninstallKBxxxxx$ - where
the Xs represent a unique number generated from characteristics of the infected system. The folder name has been chosen to be
familiar with the usual folders created by Windows during the installation of the Windows updates. "

...and I guess I'm right, at least for the newer variants we've been seeing...

Still interesting, is it mentions the KBxxxxx numbers are generated randomly from the system -- but I'm swearing the numbers have been the same on multiple systems I've looked at. *rubs eyes* maybe...

 

[Slaters Kustum Machines]

When I click Destroy Junction I get the following: A directory beneath the reparse point exists! Click YES to delete or NO to explore directory. Clicking no takes me to the Junction listed. Clicking yes gives me "Could not delete the directory." Also my Junction is C:\WINDOWS\$NtUninstallKB47189$ This is in a VM since the one I thought I was getting turned out to be a different issue.

 

[othersteve]

When I click Destroy Junction I get the following: A directory beneath the reparse point exists! Click YES to delete or NO to explore directory. Clicking no takes me to the Junction listed. Clicking yes gives me "Could not delete the directory." Also my Junction is C:\WINDOWS\$NtUninstallKB47189$ This is in a VM since the one I thought I was getting turned out to be a different issue.

Are you on XP or Vista? I only malware test on an XP VM, so...

 

[MobileTechie]

Well done guys that all works nicely.

I'm still confused as to what the reparse point is actually doing. It appears to be a link to the config folder but there is nothing visible in there. When you delete the junction it turns into a normal directory and you can see and delete the files - or is that a normal effect of using that fsutil command - to pull the files from the other end of link into the junction folder?