Cleaning servers

We had another round of hacked servers in the past few weeks. Strangely enough, the rootkit used was very similar to the one used around the time of this cryptic post. Since I cleaned that round the last time, I was able to figure out this lated round pretty quickly.

What hit us was a variant of the Hacker Defender toolkit, but localized into French (I think). I was able to manually remove the puppy before other folks around here were able to locate a remover program. Just because I like sharing, this is what I discovered.

The toolkit creates three services:

• dcrssdrv, hidden, launches %windowsdir%\system32\spool\tracking\in\dcrssdrv.sys
• mmsm, visible, launches %windowsdir%\system32\spool\tracking\in\mmsm.exe
• Description: Optimize transfert between CPU&RAM
• Display Name: Memory Manager
  
• tcp-ip_port_analyzer, hidden, launches %windowsdir\system32\spool\tracking\in\dcrs.exe dcrs.ini
• Description: Manage all Netbios Connections
• Display Name: Tcp-ip Netbios Monitoring
  

The MMSM service launches a Serv-U FTP daemon. The control file for that is mmsm.sys in the same directory as the executable. Investigating this file will tell you where they were planning on stashing files. In my case, they attempted to dump them into C:\Recycler\tracking, but no such directory was created. The really funny bit is that the typo in the mmsm service, and the odd caps in the Tcp-ip_port_analyzer service were identical to that hack back in November. This is the same kit, though clearly used with a different entry-point.

They also created another folder in "C:\System Volume Information\tracking\", which you normally can't get at from explorer. You have to set permissions on the System Volume Information folder in order to get into it. In that folder was various recon and spreading tools, as well as pwdump4 for dumping the local SAM database. They didn't get to anything with any real data in it, so our passwords are safe. Plus, our local admin passwords are longer than 16 characters, so rainbow-tables won't work.

In order to get things back, I set the SYSTEM user to Deny Access for the following directories:

• %windowsdir%\system32\spool\tracking\
• c:\System Volume Information\tracking\

This has the effect of blocking access to these directories for the SYSTEM account. Since these were created by the kit, I had no doubts that setting things that way would cause problems with the OS. Once those were set, I rebooted. As I expected, I got "service unable to start" errors on login, and the Event Log showed the services that couldn't start due to Access Denied errors.

As a result of this, the rootkit wasn't able to initialize and the hidden registry keys were visible again.

• HKLM\System\CurrentControlSet\Services\dcrssdrv
• HKLM\System\CurrentControlSet\Services\mmsm
• HKLM\System\CurrentControlSet\Services\tcp-ip_port_analyzer
• HKLM\System\ControlSet002\Services\dcrssdrv
• HKLM\System\ControlSet002\Services\mmsm
• HKLM\System\ControlSet002\Services\tcp-ip_port_analyzer
• HKLM\System\CurrentControlSet\Control\SafeBoot\Minimal\Tcp-ip_port_analyzer
• HKLM\System\CurrentControlSet\Control\SafeBoot\Network\Tcp-ip_port_analyzer
• HKLM\System\ControlSet002\Control\SafeBoot\Minimal\Tcp-ip_port_analyzer
• HKLM\System\ControlSet002\Control\SafeBoot\Network\Tcp-ip_port_analyzer

The last four entries tell the Registry that the bad process is to be launched in safe-mode. Thus, safe-mode is not a good spot to clean things. Once those services are manually removed, it should all be good and you can delete the directories. You can't delete 'em before, since the kit prevents that sort of white-hat activity; but setting the permissions for System-deny-access gets around that little tweak.

None of the above stuff is googleable that I've found, but I've seen it before. So now when other people get hacked by this crew, they'll have a resource.