According to ZeuS Tracker, there are still 493 ZeuS Command and Control (C&C) servers online.The number of infected PC’s is estimated to still be around the 4 million mark in the USA, so it can still be considered a threat – particularly to those using outdated (or no) AV and the giant vulnerability that is Windows XP.
A while ago I set up a local ZeuS C&C server for demonstration purposes, and as part of this showed exactly how difficult it can be to remove, bearing in mind it isn’t even close to the complexity of it’s successor Gameover ZeuS which has been observed to use encryption to bypass AV and P2P networking to communicate back to it’s C&C server(s).
I won’t bother going into too much detail on it’s setup (as if you don’t know something as simple as how to deploy a website, chances are you’re not the type that should be toying with a botnet), but ZeuS essentially is comprised of the following:
- A MySQL database.
- A PHP front-end.
- Configuration files to define the agent settings.
- An agent generator.
In my case my C&C server was running Server 2012 using XAMPP, attacking box BT5 R3 (prior to the stable release of Kali), and test victim XP SP3. Once the ZeuS configuration and webinject files are defined, they are used to generate the ‘loader’:
The agent is then hosted both on the C&C server (in the location defined by the loader config) and somewhere accessible by whatever exploit toolkit takes your fancy. For example, a Metasploit meterpreter session could be used to upload the binary and execute it:
Navigating to the ZeuS control-panel will confirm that the agent has compromised the victim machine, and has successfully connected back to the server:
Just to show how effective it can be, after logging in to a WordPress instance on the victim machine, credentials are being sent back to the server in plain-text:
A typical ZeuS install will consist of an executable, two database files, and two registry entries. Examples of the files are as follows:
- EXE: C:\WINDOWS\system32\ntos.exe
- DB: C:\WINDOWS\system32\wsnpoem\audio.dll
- DB: C:\WINDOWS\system32\wsnpoem\video.dll
- EXE: C:\WINDOWS\system32\oembios.exe
- DB: C:\WINDOWS\system32\sysproc64\sysproc86.sys
- DB: C:\WINDOWS\system32\sysproc64\sysproc32.sys
- EXE: C:\WINDOWS\system32\twext.exe
- DB: C:\WINDOWS\system32\twain_32\local.ds
- DB: C:\WINDOWS\system32\twain_32\user.ds
- EXE: C:\WINDOWS\system32\sdra64.exe
- DB: C:\WINDOWS\system32\lowsec\local.ds
- DB: C:\WINDOWS\system32\lowsec\user.ds
A very basic test as to whether or not a system is infected, is to check if these two registry entries are present:
- HKEY_LOCAL_MACHINE\Microsoft\Windows NT\CurrentVersion\Network ‘UID’
- HKEY_LOCAL_MACHINE\Microsoft\Windows NT\CurrentVersion\Winlogon ‘Userinit’ (where the value includes an additional reference to the ZeuS botnet exe).
Which in my case, both are present:
In a default Windows configuration there should be no network UID, this is something used by ZeuS to identify the system. Additionally, the ‘userinit’ entry launches the ZeuS executable under the Winlogon process (i.e. as soon as a user logs on). In this instance, it is located in C:\WINDOWS\system32\sdra64.exe:
removing the threat
With an understanding of the above, an approach to removing the exe can be devised:
- Kill the process.
- Remove registry entries.
- Delete the offending exe and database.
Using Process Explorer search for the name of the exe. A result will be returned indicating that it is running as a process under Winlogon.exe. So, theoretically you could select the process, kill it and rest easy. However, at this point it will just respawn as soon as the user logs on, so the ‘userinit’ registry entry must also be altered (from the location noted above):
- C:\WINDOWS\system32\userinit.exe, C:\WINDOWS\system32\xxxx##.exe
It all seems relatively straight forward until here, where one will notice that upon navigating away from the registry key and then returning to it the value is automatically repopulated by ZeuS. Therefore, must be a rogue process still running under Winlogon that is persisting the registry entry. Returning to Process Explorer and viewing the threads present under Winlogon shows a kernel32.dll!CreateThreads thread with a relatively active context switch:
Upon killing this, the ‘userinit’ registry entry can have it’s value returned to the default, and it will not be repopulated:
A few other removal solutions on the internet fail to realise this aspect of the installation, and either:
- Totally fail to mention (or realise) that the value is rewritten.
- Provide bizarre suggestions like quickly rebooting before it is repopulated. I would go so far as saying that the registry value is instantaneously rewritten by the active process. In fact, I even wrote a batch script that deletes the entry, rewrites it, forces all running processes to die, and reboots the system – much faster than human reactions could ever be capable of doing, yet the value still returned and the ZeuS agent executed upon start-up.
Whinging aside, in addition to the ‘userinit’ edit, the ‘network’ UID entry can be totally removed:
At this point the system can be rebooted.
Following the reboot, it can be confirmed in Process Explorer that the exe is no longer active, and in regedit that the ZeuS related registry entries have not returned. The final step is to delete the offending files:
True confirmation that this is effective is to verify the agent is offline in the ZeuS control panel:
And it is! The server will no longer receive any data from the victim, and in most cases where the server may communicate with thousands of victims, the removal is likely to go unnoticed as the system will simply appear to the attacker as if it’s turned off or disconnected from the internet.