RG04D – Defeating a live trojan infection with AM

By Max Ranzau


So I got hit by a virus this week. Boo-hoo, it happens to all of us. Anyway, this was a rather nasty piece of work which flew straight in under the radar of my scanner. It appears that I got 3 beasties for the price of one, as the first two Win64/Sirefef.AL+AH vira seemed to work in tandem with the Win64/Patched.B.Gen trojan. It seems this is the sign of the times that vira work in teams – if one gets it foot in the door on your computer, thanks to the marvels of the Internet, it’ll invite all it’s buddys inside for a cup of tea as well…

Anyhow, the Win64/Patched.B.Gen trojan had managed to infect windows\system32\services.exe. This rendered my realtime scanner/cleaner (ESET Nod32 v4) unable to clean it out, as this executable is used and locked by Windows. While Nod32 could contain the outbreak by preventing the Sirefef pair from spreading, I had a mexican standoff on my hands. This is what the logs looked like:


As mentioned initially, one thing is defeating this viral combo, but it leaves a lot of damage behind, as it smashes your Windows Firewall to bits (pun somewhat intended), kills the Background Intelligent Transfer Service and Shared Internet access service (which windows firewall and windows update depends on) and what not. I googled around and came across a good solution from Chanh over at Doing It Scared. Read also the comments on that article, as there’s a lot of goodies in there as well.

By following the instructions, it successfully endede there. Yet having solved my own situation, I was left wondering – what if some other poor sod now is sitting with the responsibility of cleaning up a whole bunch of infected machines. What then? Sounds like a job for RES Automation Manager. So this article is not as much about solving the problem as people smarter than me figured that out already – This article is about automating the solution, so you can safely repeat it on any number of affected computers. As mentioned, there are two steps to this. One is killing the virus, and the other is cleaning up the mess it leaves behind.


Step 1 – Killing the bastards

From what I’ve been able to gather, this virus likes to infect the C:\Windows\Services.exe file. From the perspective of the Automation Manager alone, replacing this executable with a clean copy could be a dicey affair, as services.exe is among other things the parent process for most services, including the RES AM Agent service. Initially, Working manually, I got a clean copy of services.exe ready to paste into c:\window\system32, then killed the services.exe (I had procexp on hand, but I suppose you could use the built-in taskkill command). This gives you exactly 1 minute before the system shuts down to past in the clean services.exe. Killing services.exe with a service seems like sawing off the branch you’re sitting on, so let’s look at a better approach

Windows has since medival times offers the ability to copy and rename files at reboot, which is used for installation of drivers and other things that can’t happen while the OS is running. The key to this system is a registry REG_MULTI_SZ key called PendingFileRenameOperations, found under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager. While the powers that be are less then helpful on the usage of this key (basically Technet says don’t touch it), others have figured out how to use it. There is a nice article about that here. This registry value is the way to getting the infected services.exe knocked out. Some of you proficient in Automation Manager might think the AM abilities to schedule a task to run at boot and every boot could be used here instead. Well, this requires that the agent is running, being pulled up by – yep, you guessed it: Services.exe. I trust you now see why that isn’t an option.

So, what we want to do with Automation Manager is the following:

  1. Download a clean services.exe binary to the infected computer (An zip is included in the Chanh article here. Mirror here) Download this file as you’ll need some of the other files there
  2. Enter the correct settings into the PendingFileRenameOperations value, as described below.
  3. Reboot the machine, and presto! The OS nicely takes care of the rest and replaces the infected file. It even cleans up after you and deletes the source file you download.

Presuming you download the clean services.exe to the root of the c:\ drive, the entry into PendingFileRenameOperations should look something like this:

Please pay special attention to the weird formatting of these strings. The source file’s full path must be prefixed by \??\ and the destination file must have !\??\ in front, so it looks like this.


When you pop the above items into a Automation Manager module, the result should look something like shown below, and I suppose you go with it from there, but there’s more things to deal with in section two as we have to repair all the damage the outbreak did.

In itself, this module can actually be used for a bunch of different purposes than slaying viras and trojans. For example Automation Manager doesn’t currently have native capability to install a boot-time driver (yes, it can install printer drivers, but that’s not the same). So with a bit of creativity, you can tweak this module to replace any file you need on a Windows rig.


Step 2 – Cleaning up the mess

As discussed previously, there’s quite a bit of repair work to be done as this won’t be done by your average virus scanner. Most of this is re-defining services in the registry, but as it also involves setting registry permissions to those services, As mentioned, the Chanh article referenced earlier kindly provides a set of registry files plus a clean services.exe file. You would need to import all these into Automation Manager as those registry trees were completely hosed by the intruders.

These registry entries will redefine the Windows Firewall, Bits, etc. services, but before you can change permissions on the registry settings, you HAVE to reboot first, as the NT services can’t be added as accounts before they are registered.

The last piece is to ensure the proper permissions are set on several registry keys as shown in Chanh’s article. Currently the Automation Manager’s registry permissions task is rather limited in it’s capability. As of AM 2012 SR1, It can only set Read and Full control on a given registry key, which is not granular enough for our purpose here. At this point I’ve looked through several tools which perhaps could do the job:

  • Built in REGINI and Automation Manager 2012 – cannot set special permissions.
  • SubInACL – doesn’t work on Win7 or x64
  • RegDACLE – even though it looked like it might be able to, I had to give up on it. It didn’t work.
  • SetACL – worked perfectly, except on services – that is, up until yesterday, see below.

I nearly thought I had to scrap this article, as I couldn’t find any way to automate setting special registry permissions for services. As a last ditch effort, I reached out to Mr. Helge Klein, the author of SetACL. I explained what I was trying to do and he kindly compiled a new version of SetACL which was able to add services to registry permissions. Huge kudos and thanks goes to Helge for the quick response and outstanding effort.

If you don’t know about it yet, SetACL is a swiss army knife on steoroids for setting permissions on pretty much anything, files, registry, services, you name it. On the helgeklein.com site, you will find the download and a full reference to the dozens of commandline switches this tool offers. Helge has given me permission to include the SetACL tool in the Automation Manager buildingblock below. This is version

The commandline you need to set permissions for a service is SetACL.exe -on “HKLM\<keypath without trailing backslash>” -ot reg -actn ace -ace “n:nt service\<service shortname>;p:<permission,names,seperated,by,commas>”. Note that the HKLM abreviation of HKEY_LOCAL_MACHINE works as is. Effectively, restoring the correct security permissions, as specified in step 2.3 of Chanh’s article, would look like this:

SetACL.exe -on “HKLM\CurrentControlSet\services\BFE\Parameters\Policy” -ot reg -actn ace -ace “n:nt service\mpssvc;p:query_val,set_val,create_subkey,enum_subkeys,notify,read_access”

You can find the rest of the options on the command line reference page. At this point you can probably imagine the virtually limitless possibilities with the combintion of SetACL and the RES Automation manager. For your convenience, I’ve put all commandlines to restore service registry permisisons for BFE, MpsSvc and SharedAccess, into the buildingblock. While we’re at it, there is one more piece I’d like to address. Since SetACL comes as separate 32- and 64 bit binaries, I’ve included both in the module and use Automation Manager’s conditions to decide which binary is downloaded.

The last thing to deal with is the dead file leftovers from Sirefef.AH+AL. These are located in a fake installer folder under C:\Windows\Installer\{ac0761cf-6c1e-211c-f34c-20bdbe96fd0d}. This folder is actually rather easy to spot, as the a-f alpha characters in the foldername are all lower-case, where as al the other folders in the Installer folder are uppercase. Since the files are dead, we just use a File delete task in Automation Manager to clean out this junk.

That being said, the completed module, with all commands in place, should look something like this (click to enlarge):

While every effort has been made to ensure that this buildingblock does what it’s supposed to do, mainly kill and repair after this particular virus attack, the fact remains that we are messing with the gray matter of the windows registry. Before you let loose the dogs of war, please try this in your lab, or at least on a machine which is fubar from infection anyway. If you use this module, be sure to send thanks to Helge Klein for SetACL, as it’s guys like him that make practical automation magic like this possible.

Click here to download the buildingblock:


No Comments

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a comment

Comments are welcome as always. Just do the math below. * Time limit is exhausted. Please reload the CAPTCHA.