Anatomy of a WINS server hack (MS04-045) . . .

Okay - so here is my analysis of a recent WINS hack a customer experienced.  The customer caught this by analyzing their netflow data from their routers . . . they suddenly started sending tremendous amounts of packet love and affection to various IP's around the Internet and they traced the packets to a Windows box on their network and thus the IR process was kicked into full swing. 

They immediately pulled the plug, ran WOLF and started analyzing the data.  As you will see these miscreants leave behind some tells that indicate that they are slightly more skilled than the miscreants from the previous blog post who went up against Windows File Protection . . . and lost. 

As with most IR cases we don't have direct, objective first-hand knowledge of how the compromise occurred - all we can do is piece together the puzzle based on the evidence at hand and make a subjective assumption about what we think probably happened.  Sometimes it's a no brainer and you see something like XP_CMDSHELL being run in the event logs and the customer tells us they have a blank SA password and no firewall - other times we have to do some educating guessing. :)  We rely heavily on Occam's Razor and find it to hold true most of the time.


Okay - with this case I was lucky in that this customer was more sophisticated than most and the customer was able to give me some 'leads' in the form of a process name and a date and time that the gratuitous love and packet affection occured on their network.  When you don't see anything suspicious in the volatile data on a machine (i.e. running processes / suspicious network connections) its very important to have a lead in the form of a date or time to go on usually - otherwise you're just looking for a needle in a hay stack.

Using WOLF Hound (our trusty IR data viewer) I told it to show me everything that happened on the file system and in the event logs on the 9th. 

First we see some unusual events logged from the WINS service on this machine (a Windows 2000 SP4 machine b.t.w. - you will see me blog very little about WS2003 servers . . . I wonder why that is?). 

After the suspicious WINS event log entries we that FTP.EXE gets run (last access time) and it looks like it was run (probably) to pull down a file called przsvc.exe. 

Copied from: Date View
==========================
2005-01-09 16:10:40 | system_eventlog.txt | 0 4192 Wins N/A SERVERNAME An error occurred from which WINS will try to recover. If the recovery fails, check previous event log entries to determine what prevented a successful recovery. Take the appropriate action to solve the error that prevented recovery.
2005-01-09 16:10:40 | system_eventlog.txt | 0 4242 Wins N/A SERVERNAME WINS Push thread encountered an exception. A recovery will be attempted.
2005-01-09 16:10:40 | system_eventlog.txt | 0 4297 Wins N/A SERVERNAME WINS encountered a low memory condition. Check to see if the system is running out of virtual memory.
2005-01-09 16:12:00 | dir_creation_time_C_drive.txt | c:\WINNT\system32 - 19,788 przsvc.exe
2005-01-09 16:12:00 | dir_last_access_time_C_drive.txt | c:\WINNT\system32 - 39,696 ftp.exe
2005-01-09 16:12:00 | dir_last_write_time_C_drive.txt | c:\WINNT\system32 - <DIR> spool
2005-01-09 16:12:00 | dir_last_write_time_C_drive.txt | c:\WINNT\system32\spool - <DIR> .
2005-01-09 16:12:00 | dir_last_write_time_C_drive.txt | c:\WINNT\system32\spool - <DIR> ..
2005-01-09 16:52:00 | dir_creation_time_C_drive.txt | c:\WINNT\system32 - 22,016 spoolsrv.exe
2005-01-09 16:52:00 | dir_last_write_time_C_drive.txt | c:\ - <DIR> data
2005-01-09 16:52:00 | dir_last_write_time_C_drive.txt | c:\Data - <DIR> .
2005-01-09 16:52:00 | dir_last_write_time_C_drive.txt | c:\Data - <DIR> ..

Using FTP to suck stuff down to the box . . . well that's hardly interesting, that's been demo'd in hacking books and hacking classes for years . . . 'that's soooo last century'.  What's interesting about this crew is that they also seem to have the ability to download files via HTTP (probably by calling WININET API's) just in case you're doing some egress filtering and don't allow outbound FTP.  We've seen this done via scripting combined with ADODB.Stream to persist the fetched data before and it's not really hard to write a compiled program to do the same thing and run it as SYSTEM if you know what API's to call.  Could this be new functionality of this particular BOT variant (spoolsrv.exe is an SDBot variant b.t.w.). 

You may notice below that the 'Default User' profile's TIF (Temporary Internet Files) folder is being written around 16:52 . . . it turns out you can repro this yourself - fire up a copy of Internet Explorer running as the SYSTEM account (left as an exercise to the reader) and download some files - observe where they go.  That's right, they go into the 'Default User' profile.  So now it seems we have evidence that someone was running something on the box (SDBot) with elevated privileges and downloading files via IE  (less likely) or by calling the same API's IE calls (more likely). 

This is a little more sophisticated than usual - but it's not a new technique - we've seen this used on occasion in the past but usually from vbscripts wrapped inside of .CHM files that were downloaded and run via Internet Explorer 0-days.

2005-01-09 16:52:00 | dir_last_write_time_C_drive.txt | c:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5 - 32,768 index.dat
2005-01-09 16:52:00 | dir_last_write_time_C_drive.txt | c:\WINNT\system32 - 22,016 spoolsrv.exe
2005-01-09 16:55:00 | dir_creation_time_C_drive.txt | c:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\41YZG527 - 2,539,520 winzip~1.exe winzip81sr1eval[1].exe
2005-01-09 16:55:00 | dir_creation_time_C_drive.txt | c:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\G5AZ8XYZ - 464,957 nfs-cd~1.zip nfs-cd[1].zip
2005-01-09 16:55:00 | dir_creation_time_C_drive.txt | c:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\STMBS1EB - 2,848,655 aim_1_~1.exe aim[1].exe
2005-01-09 16:55:00 | dir_last_write_time_C_drive.txt | c:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\G5AZ8XYZ - 464,957 nfs-cd~1.zip nfs-cd[1].zip
2005-01-09 16:55:00 | dir_last_write_time_C_drive.txt | c:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\STMBS1EB - 2,848,655 aim_1_~1.exe aim[1].exe
2005-01-09 16:56:00 | dir_creation_time_C_drive.txt | c:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\QDF591YV - 2,628,632 lusetu~1.exe lusetup[1].exe
2005-01-09 16:56:00 | dir_last_write_time_C_drive.txt | c:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\41YZG527 - 2,539,520 winzip~1.exe winzip81sr1eval[1].exe
2005-01-09 16:56:00 | dir_last_write_time_C_drive.txt | c:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\QDF591YV - 2,628,632 lusetu~1.exe lusetup[1].exe
2005-01-09 17:08:00 | dir_creation_time_C_drive.txt | c:\WINNT\system32 - 51,733 plugin1.dat
2005-01-09 17:08:00 | dir_creation_time_C_drive.txt | c:\WINNT\Temp - 84 del.bat
2005-01-09 17:08:00 | dir_last_access_time_C_drive.txt | c:\WINNT\Temp - 84 del.bat
2005-01-09 17:08:00 | dir_last_write_time_C_drive.txt | c:\WINNT\Temp - 84 del.bat
2005-01-09 17:09:00 | dir_last_write_time_C_drive.txt | c:\WINNT\system32 - 51,733 plugin1.dat

We collect some files that are more than likely 'suspicious' when we run WOLF. 
Del.bat seems like it might be one of those files and we just happened to snag a copy - let's have a look:

Copied from: Files Collected
==========================
Contents of: del.bat
================

@echo off
:repeat
del "%1"
if exist "%1" goto repeat
del "C:\WINNT\TEMP\del.bat"

Copied from: Date View
==========================
2005-01-09 17:08:00 | dir_creation_time_C_drive.txt | c:\WINNT\system32 - 51,733 plugin1.dat
2005-01-09 17:08:00 | dir_creation_time_C_drive.txt | c:\WINNT\Temp - 84 del.bat
2005-01-09 17:08:00 | dir_last_access_time_C_drive.txt | c:\WINNT\Temp - 84 del.bat
2005-01-09 17:08:00 | dir_last_write_time_C_drive.txt | c:\WINNT\Temp - 84 del.bat
2005-01-09 17:09:00 | dir_last_write_time_C_drive.txt | c:\WINNT\system32 - 51,733 plugin1.dat

So what I found interesting about this batch file is that it's like a crude dead mans switch.  Delete whatever I pass in on the command line and then delete myself when done - nice.  So say I start a server process and its running and then I call this batch file with the path to the server process as the first parameter.  If the file is in use, the delete operation will fail and this batch file will simpy loop until the process is ended (assuming a process or a DLL is what is being passed in to the batch file as %1) and the file can finally be deleted.  Finally - when the filename I pass in to the batch file as %1 does finally manage to get deleted - the batch file will delete itself . . . since it was still there - it doesn't look like it was ever called.

After this series of events - all was quiet on this server until a few days later when all we see is the previously downloaded malware that was placed in the IE TIF folder get accessed (although this looks to have been due to an incremental backup of the file system by some backup network backup software according to the event log):

Copied from: Date View
==========================
2005-01-14 00:00:00 | dir_last_access_time_C_drive.txt | c:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\41YZG527 - 2,539,520 winzip~1.exe winzip81sr1eval[1].exe
2005-01-14 00:00:00 | dir_last_access_time_C_drive.txt | c:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\G5AZ8XYZ - 464,957 nfs-cd~1.zip nfs-cd[1].zip
2005-01-14 00:00:00 | dir_last_access_time_C_drive.txt | c:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\QDF591YV - 2,628,632 lusetu~1.exe lusetup[1].exe
2005-01-14 00:00:31 | security_eventlog.txt | 8 2 538 Security SERVERNAME\IUSR_SERVERNAME SERVERNAME IUSR_SERVERNAME SERVERNAME (0x0,0xA1207C) 3
2005-01-14 00:01:00 | dir_last_access_time_C_drive.txt | c:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\STMBS1EB - 2,848,655 aim_1_~1.exe aim[1].exe

Then all was quiet again for few more days and then on the 20th it looks like someone updated the main piece of malware the morning that the IR process kicked into gear:

Copied from: Date View
==========================
2005-01-20 08:15:00 | dir_last_write_time_C_drive.txt | c:\WINNT\system32 - 19,788 przsvc.exe

What's interesting is the way in which this malware (have not received a specimen yet) was loading - it was using a lesser known autostart technique that has been used in the past by things like Beast and Sub7.

Copied from: Search Results for: przsvc.exe
==========================
Files containing instances of 'przsvc.exe'

Number of Files Searched: 1
Time to Search Files: 0 seconds

registry.txt
====================
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\{9F81D88C-C298-9935-C5D1-40AA4DB91155}]
"stubpath"=(REG_EXPAND_SZ)"C:\\WINNT\\system32\\przsvc.exe s"

So to conclude, I have a theory based on suspicious WINS related event log entries that this box was comrpomised using a WINS remote shell exploit.  Fortunately we have a tool that allows me to get the patch-level of a machine during the data collection phase - MBSA.  MBSA was able to show me what I needed to see:

Copied from: mbsacli_patch_status.txt
==========================
Patch NOT Found MS04-041 885836
A required registry key does not exist. It is necessary in order
for this patch to be considered installed.
[SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Hotfix\KB885836\Installed]

 Patch NOT Found MS04-043 873339
File version is less than expected.
[C:\WINNT\system32\hypertrm.dll, 5.0.2195.6684 < 5.0.2195.7000]

 Patch NOT Found MS04-044 885835
File version is less than expected.
[C:\WINNT\system32\lsasrv.dll, 5.0.2195.6902 < 5.0.2195.6987]

 Patch NOT Found MS04-045 870763
File version is less than expected.
[C:\WINNT\system32\wins.exe, 5.0.2195.6870 < 5.0.2195.7005]

Ouch baby - very ouch.

Copied from: mbsacli_patch_status.txt
==========================
* SQL SERVER 2000 GOLD

 Warning
The latest service pack for this product is not installed.
Currently SQL Server 2000 Gold is installed. The latest service
pack is SQL Server 2000 SP3.

 Patch NOT Found MS00-092 280380
File version is less than expected.
[d:\program files\microsoft sql server\MSSQL\binn\odsole70.dll,
2000.80.194.0 < 2000.80.223.0]

 Patch NOT Found MS01-032 299717
File version is less than expected.
[d:\program files\microsoft sql server\MSSQL\binn\sqlservr.exe,
2000.80.194.0 < 2000.80.296.0]

 Patch NOT Found MS01-041 298012
File version is less than expected.
[d:\program files\microsoft sql server\MSSQL\binn\ssmsrp70.dll,
2000.80.194.0 < 2000.80.213.0]

 Note MS02-035 263968
Please refer to 306460 for a detailed explanation.

This box is at severe risk as it is missing multiple security updates that are remotely exploitable including SQL updates!  Worse still - the box only has a 6 character minimum password policy and the passwords never expire! 

Given that this box was not behind a firewall it's only a matter of time before the admin password is guessed and/or another remotely exploitable vulnerability is used to take control of this machine.

Copied from: net_accounts.txt
==========================
Thu Jan 20 16:11:24 2005
Force user logoff how long after time expires?: Never
Minimum password age (days): 0
Maximum password age (days): Unlimited
Minimum password length: 6
Length of password history maintained: 2
Lockout threshold: 5
Lockout duration (minutes): 5
Lockout observation window (minutes): 5
Computer role: SERVER
The command completed successfully.

Our advice to this customer is to follow standard best practices for internet facing boxes as documented in all of our Windows 2000 hardening guides which can be found at https://www.microsoft.com/security/guidance

At the very least they need to immediately consider:

  1. Increasing the strength of their password policy (I recommend 10 character or more minimums and educate people about the use of pass-phrases)
  2. Set a password expiration of no more than 70 days
  3. Shut down un-needed servcies (this box was running everything and then some)
  4. Install all critical security updates for both the OS and the server applications within 24 hours (even more critical since this box is plugged directly into the Internet with an Internet routable IP) or better yet turn on Automatic Updates or consider using SUS etc.
  5. For the love of God use a firewall to screen inbound access to some of those high profile ports!

On the plus side this customer DID have account logon auditing enabled on this server and I can confirm that no Windows accounts were harmed in taking over of this server (this time).