Robert Hensing's Blog

Software Security . . . and stuff.

Blogs

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

  • Comments 20
  • Likes

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 http://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).

 

Comments
  • >>I recommend 10 character or more minimums
    >>password expiration of no more than 70 days

    Dream on, Pollyanna.
    Post-it notes stuck to every monitor.
    Slips of paper under every keyboard.

    That's more secure?

    You make it sound like these customers are at fault for not applying an avalance of patches, many of which break functioning systems.

    Who wrote the exploit riddled software in the first place?

  • Nice - obviously somebody needs to read my blog on pass-phrases to see just how easy it is to create hack-proof, easy to remember passwords for Windows accounts.

    You provided some rather memorable pass-phrases in your comment:

    "Dream on, Pollyanna." - great pass-phrase!
    "Slips of paper under every keyboard." - I like it, that's a good passphrase!

    And for the disgruntled admin this is an excellent passphrase they are likely to easily remember:
    "Who wrote the exploit riddled software in the first place?"

    And for the record that would be *vulnerability* ridden software to you stranger - exploits, exploit the vulnerabilities. :)

  • Now all you have to do is make sure that all the 1 billion users of windows systems read your previous blog on pass-phrases. And if they don't, it's their fault of their system gets cracked.

  • Keep 'em coming! These investigations are extremely interesting and I appreciate you sharing them. BTW, we have implemented the pass-phrase instead of password scheme here and everybody loves it!

  • An easier updating service was promised. Called Microsoft update I think. Is it coming? It was going to come by last year. Well I think that 2006 might be a better date.

  • WUS - Windows Update Services - scheduled for sometime 2005
    MUS - Microsoft Update Services - scheduled for sometime 2005

    Can't get any more specific than that

  • I like these anatomy reports! nice work

    Florian

  • 1/27/2005 3:05 PM passwd freak

    > Post-it notes stuck to every monitor.
    > Slips of paper under every keyboard.
    > That's more secure?

    Yes. Abuse will be done by insiders, not by every random scanner coming in over the internet.

  • Norman: yes, but current trends in system security breaks is increasing numbers of insiders

  • So WUS and Microsoft Update website are coming this year. Very good.
    Actually I believe that Windows Update Services WUS is a bad name that will cause confusion. There is already the Windows Update website that updates only Windows. So customers will wrongly think that WUS is only for updating Windows. In any case the unified updating service will be called Microsoft Update so why not call WUS Microsoft Update Service or just leave the old Software Update Services name? This will not make people think that WUS is only for Windows.
    I guess though in the end Microsoft Update website will be available in 2006 and not this year since there is no beta yet so it seems that its release date might slip again.

  • You've mentioned WOLF in several of your reports. Is WOLF -

    * Available for download?
    * A product currently offered for sale?
    * A product in development?
    * An in-house tool that is only available to members of your IR team?
    *

  • It's the last one - sorry, not available for download or public consumption in any way. Its a support tool used by our IR team.

  • very good read