Robert Hensing's Blog

Software Security . . . and stuff.

Blogs

Anatomy of a Veritas BackupExec Agent Browser hack via TCP 6101

  • Comments 16
  • Likes

I've gotten some really great feedback on my blog now that I'm actually blogging about incident response topics - I appreciate the feedback, keep it coming!

So we here in PSS Security are tied into the security incident response community fairly well and for weeks various security organizations have been reporting large spikes in TCP 6101 scanning occuring that was detected by various sensors throughout the Internet.  The scanning activity was intermingled with an increase in SQL scanning (TCP 1433) as well.  We knew that TCP 6101 was associated with the Veritas BackupExec Agent Browser vulnerability which also installs a copy of MSDE (SQL) so it sure sounded like someone had developed a scan and exploit tool and all we could do was hurry up and wait for our first set of hacking cases involving this vulnerability and this 'spreader' to show up. 

Well it didn't take long - a week or so after the initial scanning activity we got our first case. :)

I don't know all of the specifics on what tipped this customer off that something wasn't right but we sent them our incident response toolkit and sure enough we were able to identify not only that they were indeed hacked but how.

My raw case notes are below, with the customers personally identifiable information (PII) of course removed to protect the innocent.


First we see some suspicious processes running on the machine (not being hidden by a rootkit as you can tell - yea old school hax0rs!)

Copied from: tlist.txt
==========================
 0 1636 spoolrv.exe    
     Command Line: C:\WINDOWS\system32\spoolrv.exe -l -L -p 1366 -d -t -e auth.exe


Copied from: tlist.txt
==========================
 0 1936 service.exe     Svcs:  net-ip
     Command Line: C:\WINDOWS\system32\service.exe


Dumping the services we can see that these are configured to run as services.
NOTE:  The 'Alerter' service - a legitimate service has been hijacked and made to run WINLOGIN.EXE (not winlogOn.exe)
NOTE:  We see the 'IP / TCP Services' service quite a lot implying it's being installed by the same crew or a common 'spreader' used to spread a crews malware around the Internet.

Copied from Services:

Alerter  -  [running]
    Automatic
    LocalSystem
    C:\WINDOWS\system32\WINLOGIN.EXE

Copied from Services:

IP / TCP Services  -  [running]
    Automatic
    LocalSystem
    C:\WINDOWS\system32\service.exe
    Enables advanced IP/ TCP Services Protocol for NetBIOS Support on this computer


Now let's get some MAC (Modified / Accessed / Created) times from the file system to see if we can figure out when all of this badness went down . . .

Copied from: Search Results for: service.exe
==========================
    Directory of c:\WINDOWS\system32
         01/12/2005  12:02p             699,392                 service.exe

Copied from: Search Results for: service.exe
==========================
    Directory of c:\WINDOWS\system32
         01/18/2005  08:34p             699,392                 service.exe

Copied from: Search Results for: service.exe
==========================
   Directory of c:\WINDOWS\system32
         01/12/2005  12:02p             699,392                 service.exe

 


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

Number of Files Searched: 10
Time to Search Files: 8 seconds

dir_creation_time_C_drive.txt
====================
    Directory of c:\WINDOWS\system32
         01/12/2005  12:07p              28,160                 spoolrv.exe


dir_last_access_time_C_drive.txt
====================
    Directory of c:\WINDOWS\system32
         01/18/2005  08:34p              28,160                 spoolrv.exe


dir_last_write_time_C_drive.txt
====================
    Directory of c:\WINDOWS\system32
         01/12/2005  12:07p              28,160                 spoolrv.exe

Okay we've got a date now - yes I know I didn't get the MAC times for winlogin.exe - you'll see why this doesn't matter below.


So our incident response process involves two components - a data collection agent sent to customers and a data viewer that we use back here to anlayze the output of the data collection agent.  The viewer, written in C# by a friend of mine who now works in the Microsoft Security Response Center allows us to perform blindingly fast string searches and it has a nice wizard called 'Date View' that allows you to build a chronological list of 'things' that happened on a given day based on information from the file system (MAC times) and the event log.  Once I get a date - I usually go to 'Date View' and see what else happened on that day - it's usualy very enlightening.  And before you ask - no, I'm sorry but we can't send you our viewer (we don't have a EULA etc.).

First we see the event log entries that lead us to believe that this was a Veritas BackupExec Agent browser exploit (note the source IP - check your flow data for packets from this IP).  Later I will verify that the bits on the box are not patched.

Copied from: Date View
==========================
2005-01-12   11:45:07   | application_eventlog.txt   |   2 0 57429 BackupExecAgentBrowser N/A SERVERNAME The Agent Browser's TCP/IP module experienced a problem receiving an advertisement from the host at IP address 206.74.38.29. The advertisement was ignored.        For more information, click the following link:  
http://eventlookup.veritas.com/eventlookup/EventLookup.jhtml 
2005-01-12   11:45:07   | application_eventlog.txt   |   2 0 57429 BackupExecAgentBrowser N/A SERVERNAME The Agent Browser's TCP/IP module experienced a problem receiving an advertisement from the host at IP address 206.74.38.29. The advertisement was ignored.        For more information, click the following link:  
http://eventlookup.veritas.com/eventlookup/EventLookup.jhtml 
2005-01-12   11:45:07   | application_eventlog.txt   |   2 0 57429 BackupExecAgentBrowser N/A SERVERNAME The Agent Browser's TCP/IP module experienced a problem receiving an advertisement from the host at IP address 206.74.38.29. The advertisement was ignored.        For more information, click the following link:  
http://eventlookup.veritas.com/eventlookup/EventLookup.jhtml 
2005-01-12   11:45:09   | application_eventlog.txt   |   2 0 57429 BackupExecAgentBrowser N/A SERVERNAME The Agent Browser's TCP/IP module experienced a problem receiving an advertisement from the host at IP address 206.74.38.29. The advertisement was ignored.        For more information, click the following link:  
http://eventlookup.veritas.com/eventlookup/EventLookup.jhtml 

So at 11:45am the service was logging to the event log and a few minutes later file start popping up on the drive.  I don't believe in coincidence . . .

In the below output:

  • Notice the name of the service that starts right after the files are placed on the box (one of my all time favorites the 'IP / TCP service' from the low-tech dyslexic service name obfuscating warez monkeys).
  • Notice the placement of RAR files in the 'System Volume Information' directory - a directory which only the NT AUTHORITY\SYSTEM account can access by default - implying we have a service running with SYSTEM permissions now (perhaps the IP / TCP service?) :)
  • Notice the name of the RAR files - seems to be German - I'm pretty sure I can guess what's on THAT CD. :)
  • Notice the .POL file that was created - the miscreants are very into using security policy and templates to harden machines that they've just taken over to avoid 'leech hacking' or 're-hacking' by other crews.
  • And finally - notice the attempted overwrite of the WFP protected binaries.  One can gain a lot of insight as to the relative skill of the crew who hacked this machine simply by looking at this evidence and the skill level it implies.  No rootkit was dropped to hide their presence - simple service name obfuscation was chosen instead, and poorly at that; attempted overwrites of system binaries - this crew doesn't seem to be particularly cluefull or skilled but they don't need to be - they've got super 733t automated auto-rooters / spreaders to do their work for them.  All they do is enter a range of IP addresses and turn it loose.  I'd put these guys in the 'lamer' species (refer to one of my very first blog posts for my miscreant stereotypes).  My blog about the trojaning of the winlogon binary?  Well the software used in that incident was definitely written by someone with advanced skills - but it could be getting used by only moderately skilled (or possibly lame) miscreants - its hard to say, we'll see how widespread it becomes.


Copied from: Date View
==========================
2005-01-12   12:02:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32 -  699,392                 service.exe
2005-01-12   12:02:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32 -  699,392                 service.exe
2005-01-12   12:04:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32 -  1,671 shells~1.oxc    shellsuccesslog.oxc
2005-01-12   12:04:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32 -  2,781 shellc~1.oxc    shellconfig.oxc
2005-01-12   12:04:56   | system_eventlog.txt   |   4 0 7035 Service Control Manager DOMAINNAME\USERNAME  SERVERNAME The IP / TCP Services service was successfully sent a start control. 
2005-01-12   12:04:56   | system_eventlog.txt   |   4 0 7036 Service Control Manager N/A SERVERNAME The IP / TCP Services service entered the running state. 
2005-01-12   12:05:00   | dir_creation_time_C_drive.txt   |   c:\System Volume Information -  15,000,000 dr-ent~1.r00    dr-entdeckung-cd1.r00
2005-01-12   12:05:00   | dir_last_write_time_C_drive.txt   |   c:\System Volume Information -  15,000,000 dr-ent~1.r00    dr-entdeckung-cd1.r00
2005-01-12   12:06:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\GroupPolicy\Machine -  2,120                 twilight.pol
2005-01-12   12:06:00   | dir_last_access_time_C_drive.txt   |   c:\WINDOWS\system32\GroupPolicy\Machine -  2,120                 twilight.pol
2005-01-12   12:06:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\GroupPolicy -  <DIR>                          machine
2005-01-12   12:06:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\GroupPolicy\Machine -  <DIR>                          .
2005-01-12   12:06:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\GroupPolicy\Machine -  <DIR>                          ..
2005-01-12   12:06:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\GroupPolicy\Machine -  2,120                 twilight.pol
2005-01-12   12:07:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32 -  28,160                 spoolrv.exe
2005-01-12   12:07:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32 -  37,828                 auth.exe
2005-01-12   12:07:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32 -  4,776                 winlogin.exe
2005-01-12   12:07:00   | dir_last_access_time_C_drive.txt   |   c:\WINDOWS\inf -  29,100                 syssetup.inf
2005-01-12   12:07:00   | dir_last_access_time_C_drive.txt   |   c:\WINDOWS\system32\dllcache -  47,104                 sc.exe
2005-01-12   12:07:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32 -  28,160                 spoolrv.exe
2005-01-12   12:07:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32 -  37,828                 auth.exe
2005-01-12   12:07:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32 -  4,776                 winlogin.exe
2005-01-12   12:07:10   | application_eventlog.txt   |   4 1 100 ESENT N/A SERVERNAME svchost (1272) The database engine 5.02.3790.0000 started. 
2005-01-12   12:07:16   | system_eventlog.txt   |   4 0 64001 Windows File Protection N/A SERVERNAME File replacement was attempted on the protected system file c:\windows\system32\sc.exe.  This file was restored to the original version to maintain system stability.  The file version of the bad file is 5.1.2600.0, the version of the system file is 5.2.3790.0. 
2005-01-12   12:07:36   | system_eventlog.txt   |   4 0 7035 Service Control Manager DOMAINNAME\USERNAME  SERVERNAME The Alerter service was successfully sent a start control. 
2005-01-12   12:07:36   | system_eventlog.txt   |   4 0 7036 Service Control Manager N/A SERVERNAME The Alerter service entered the running state. 
2005-01-12   12:07:43   | system_eventlog.txt   |   4 0 64002 Windows File Protection N/A SERVERNAME File replacement was attempted on the protected system file c:\windows\system32\sc.exe.  This file was restored to the original version to maintain system stability.  The file version of the system file is 5.2.3790.0. 
2005-01-12   12:07:51   | system_eventlog.txt   |   1 0 7034 Service Control Manager N/A SERVERNAME The Backup Exec Agent Browser service terminated unexpectedly.  It has done this 1 time(s).

Copied from: Date View
==========================
2005-01-12   13:37:00   | dir_creation_time_C_drive.txt   |   c:\System Volume Information -  50,000,000 smp-su~1.r00    smp-supersize.r00
2005-01-12   13:39:00   | dir_creation_time_C_drive.txt   |   c:\System Volume Information -  15,000,000 dr-ent~1.r01    dr-entdeckung-cd1.r01
2005-01-12   13:39:00   | dir_last_access_time_C_drive.txt   |   c:\System Volume Information -  15,000,000 dr-ent~1.r01    dr-entdeckung-cd1.r01
2005-01-12   13:39:00   | dir_last_write_time_C_drive.txt   |   c:\System Volume Information -  15,000,000 dr-ent~1.r01    dr-entdeckung-cd1.r01
2005-01-12   13:41:00   | dir_last_access_time_C_drive.txt   |   c:\System Volume Information -  50,000,000 smp-su~1.r00    smp-supersize.r00
2005-01-12   13:41:00   | dir_last_write_time_C_drive.txt   |   c:\System Volume Information -  50,000,000 smp-su~1.r00    smp-supersize.r00


I thought I'd point this out as well . . . antivirus software is not anti-hacker software; I can't stress this enough!


Copied from: Date View
==========================
2005-01-12   20:51:02   | application_eventlog.txt   |    0 2 Norton AntiVirus N/A SERVERNAME       Scan Complete: Viruses:0   Infected:0   Scanned:521286   Files/Folders/Drives Omitted:78
 


Okay so we seem to have identified when the miscreants got on the box and what their motives were (to use you as a free hosting provider); now lets look at the 'how' part of this incident and see if our theory about BackupExec abuse has merit.  The file in question that makes up the Veritas BackupExec Agent Browser service is: benetns.exe.  I've got the MAC times and the file version (which is highlighted in red) below:


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

Number of Files Searched: 14
Time to Search Files: 7 seconds

dir_creation_time_C_drive.txt
====================
    Directory of c:\Program Files\VERITAS\Backup Exec\NT
         10/07/2003  12:25a              29,144                 benetns.exe


dir_last_access_time_C_drive.txt
====================
    Directory of c:\Program Files\VERITAS\Backup Exec\NT
         01/18/2005  08:34p              29,144                 benetns.exe


dir_last_write_time_C_drive.txt
====================
    Directory of c:\Program Files\VERITAS\Backup Exec\NT
         10/07/2003  12:25a              29,144                 benetns.exe


checksym.csv
====================
   ,BENETNS.EXE,828,C:\PROGRAM FILES\VERITAS\BACKUP EXEC\NT\BENETNS.EXE,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(9.1:4691.0),(9.1:4691.0),VERITAS Software Corporation,Backup Exec Agent Browser,29144,29592723,1835412992,"October 7, 2003 12:25:32 AM",
   ,BENETNS.EXE,828,C:\WINDOWS\SYSTEM32\NTDLL.DLL,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(5.2:3790.0),(5.2:3790.0),Microsoft Corporation,NT Layer DLL,739840,29553350,262758400,"March 25, 2003 7:00:00 AM",
   ,BENETNS.EXE,828,C:\WINDOWS\SYSTEM32\KERNEL32.DLL,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(5.2:3790.0),(5.2:3790.0),Microsoft Corporation,Windows NT BASE API Client DLL,988160,29553350,262758400,"March 25, 2003 7:00:00 AM",
   ,BENETNS.EXE,828,C:\PROGRAM FILES\VERITAS\BACKUP EXEC\NT\BENETUTL.DLL,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(9.1:4691.0),(9.1:4691.0),VERITAS Software Corporation,Backup Exec Network Communications Utilities,12760,29592723,1855412992,"October 7, 2003 12:25:34 AM",
   ,BENETNS.EXE,828,C:\WINDOWS\SYSTEM32\WSOCK32.DLL,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(5.2:3790.0),(5.2:3790.0),Microsoft Corporation,Windows Socket 32-Bit DLL,22528,29553350,262758400,"March 25, 2003 7:00:00 AM",
   ,BENETNS.EXE,828,C:\WINDOWS\SYSTEM32\WS2_32.DLL,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(5.2:3790.0),(5.2:3790.0),Microsoft Corporation,Windows Socket 2.0 32-Bit DLL,89600,29553350,262758400,"March 25, 2003 7:00:00 AM",
   ,BENETNS.EXE,828,C:\WINDOWS\SYSTEM32\MSVCRT.DLL,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(6.1:8638.0),(7.0:3790.0),Microsoft Corporation,Windows NT CRT DLL,327168,29553350,262758400,"March 25, 2003 7:00:00 AM",
   ,BENETNS.EXE,828,C:\WINDOWS\SYSTEM32\WS2HELP.DLL,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(5.2:3790.0),(5.2:3790.0),Microsoft Corporation,Windows Socket 2.0 Helper for Windows NT,19968,29553350,262758400,"March 25, 2003 7:00:00 AM",
   ,BENETNS.EXE,828,C:\WINDOWS\SYSTEM32\ADVAPI32.DLL,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(5.2:3790.0),(5.2:3790.0),Microsoft Corporation,Advanced Windows 32 Base API,572928,29553350,262758400,"March 25, 2003 7:00:00 AM",
   ,BENETNS.EXE,828,C:\WINDOWS\SYSTEM32\RPCRT4.DLL,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(5.2:3790.137),(5.2:3790.137),Microsoft Corporation,Remote Procedure Call Runtime,660992,29625092,199008768,"March 15, 2004 10:09:08 PM",
   ,BENETNS.EXE,828,C:\PROGRAM FILES\VERITAS\BACKUP EXEC\NT\BECLASS.DLL,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(9.1:4691.0),(9.1:4691.0),VERITAS Software Corporation,Backup Exec Class Library,398808,29592723,1535412992,"October 7, 2003 12:25:02 AM",
   ,BENETNS.EXE,828,C:\WINDOWS\SYSTEM32\USER32.DLL,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(5.2:3790.245),(5.2:3790.245),Microsoft Corporation,Windows USER API Client DLL,576000,29683381,2820292224,"December 30, 2004 4:22:25 PM",
   ,BENETNS.EXE,828,C:\WINDOWS\SYSTEM32\GDI32.DLL,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(5.2:3790.0),(5.2:3790.0),Microsoft Corporation,GDI Client DLL,269312,29553350,262758400,"March 25, 2003 7:00:00 AM",
   ,BENETNS.EXE,828,C:\WINDOWS\SYSTEM32\MSWSOCK.DLL,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(5.2:3790.0),(5.2:3790.0),Microsoft Corporation,Microsoft Windows Sockets 2.0 Service Provider,260096,29553350,262758400,"March 25, 2003 7:00:00 AM",
   ,BENETNS.EXE,828,C:\WINDOWS\SYSTEM32\OLE32.DLL,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(5.2:3790.138),(5.2:3790.138),Microsoft Corporation,Microsoft OLE for Windows,1189376,29625092,199008768,"March 15, 2004 10:09:08 PM",
   ,BENETNS.EXE,828,C:\WINDOWS\SYSTEM32\MPR.DLL,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(5.2:3790.0),(5.2:3790.0),Microsoft Corporation,Multiple Provider Router DLL,57344,29553350,262758400,"March 25, 2003 7:00:00 AM",
   ,BENETNS.EXE,828,C:\WINDOWS\SYSTEM32\NETAPI32.DLL,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(5.2:3790.0),(5.2:3790.0),Microsoft Corporation,Net Win32 API DLL,324608,29553350,262758400,"March 25, 2003 7:00:00 AM",
   ,BENETNS.EXE,828,C:\WINDOWS\SYSTEM32\VERSION.DLL,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(5.2:3790.0),(5.2:3790.0),Microsoft Corporation,Version Checking and File Installation Libraries,17408,29553350,262758400,"March 25, 2003 7:00:00 AM",
   ,BENETNS.EXE,828,C:\WINDOWS\SYSTEM32\WINSPOOL.DRV,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(5.2:3790.0),(5.2:3790.0),Microsoft Corporation,Windows Spooler Driver,143360,29553350,262758400,"March 25, 2003 7:00:00 AM",
   ,BENETNS.EXE,828,C:\WINDOWS\SYSTEM32\COMDLG32.DLL,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(6.0:3790.0),(6.0:3790.0),Microsoft Corporation,Common Dialogs DLL,267264,29553350,262758400,"March 25, 2003 7:00:00 AM",
   ,BENETNS.EXE,828,C:\WINDOWS\SYSTEM32\SHLWAPI.DLL,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(6.0:3790.212),(6.0:3790.212),Microsoft Corporation,Shell Light-weight Utility Library,287232,29664860,889581440,"September 29, 2004 2:40:43 PM",
   ,BENETNS.EXE,828,C:\WINDOWS\WINSXS\X86_MICROSOFT.WINDOWS.COMMON-CONTROLS_6595B64144CCF1DF_5.82.0.0_X-WW_8A69BA05\COMCTL32.DLL,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(6.0:3790.0),(5.82:3790.0),Microsoft Corporation,Common Controls Library,574464,29553263,4084913152,"March 24, 2003 8:43:36 PM",
   ,BENETNS.EXE,828,C:\WINDOWS\SYSTEM32\SHELL32.DLL,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(6.0:3790.205),(6.0:3790.205),Microsoft Corporation,Windows Shell Common Dll,8170496,29657396,4005478784,"August 23, 2004 12:16:31 PM",
   ,BENETNS.EXE,828,C:\WINDOWS\SYSTEM32\MSVCP60.DLL,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(6.5:2144.0),(6.5:2144.0),Microsoft Corporation,Microsoft (R) C++ Runtime Library,397312,29553350,262758400,"March 25, 2003 7:00:00 AM",
   ,BENETNS.EXE,828,C:\WINDOWS\SYSTEM32\OLEAUT32.DLL,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(5.2:3790.0),(5.2:3790.0),Microsoft Corporation,,497664,29553350,262758400,"March 25, 2003 7:00:00 AM",
   ,BENETNS.EXE,828,C:\WINDOWS\WINSXS\X86_MICROSOFT.WINDOWS.COMMON-CONTROLS_6595B64144CCF1DF_6.0.100.0_X-WW_8417450B\COMCTL32.DLL,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(6.0:3790.0),(6.0:3790.0),Microsoft Corporation,User Experience Controls Library,928768,29553263,4084913152,"March 24, 2003 8:43:36 PM",
   ,BENETNS.EXE,828,C:\WINDOWS\SYSTEM32\CLUSAPI.DLL,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(5.2:3790.0),(5.2:3790.0),Microsoft Corporation,Cluster API Library,57344,29553350,262758400,"March 25, 2003 7:00:00 AM",
   ,BENETNS.EXE,828,C:\WINDOWS\SYSTEM32\WSHTCPIP.DLL,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(5.2:3790.0),(5.2:3790.0),Microsoft Corporation,Windows Sockets Helper DLL,18432,29553350,262758400,"March 25, 2003 7:00:00 AM",
   ,BENETNS.EXE,828,C:\WINDOWS\SYSTEM32\DNSAPI.DLL,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(5.2:3790.0),(5.2:3790.0),Microsoft Corporation,DNS Client API DLL,151040,29553350,262758400,"March 25, 2003 7:00:00 AM",
   ,BENETNS.EXE,828,C:\WINDOWS\SYSTEM32\WINRNR.DLL,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(5.2:3790.0),(5.2:3790.0),Microsoft Corporation,LDAP RnR Provider DLL,15360,29553350,262758400,"March 25, 2003 7:00:00 AM",
   ,BENETNS.EXE,828,C:\WINDOWS\SYSTEM32\WLDAP32.DLL,SYMBOLS_NO,0,0,"December 31, 1969 19:00:00",0,,,,,(5.2:3790.0),(5.2:3790.0),Microsoft Corporation,Win32 LDAP API DLL,161792,29553350,262758400,"March 25, 2003 7:00:00 AM",

The CVE data has links to the vendor bulletins which contain the vulnerable file versions - yup, this box was not patched:
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1172

On a side note - we did verify that when BackupExec is installed on Windows, it does install a copy of MSDE (lightweight database engine that we allow 3rd parties to redistribute that is based on the SQL engine) but it wisely chooses to put it in Windows authentication mode (not 'mixed') meaning you can't authenticate using SQL logins (and thus blank SA passwords) - you have to use a Windows account.  This reduces your exposure a bit but you still have to patch MSDE just like you would a SQL server (because it IS SQL)!


Finally - I had a look at what ports the malware was listening on just for kicks and verified that the Agent Browser was listening on the default vulnerable port.

Copied from: portqry.txt
==========================
======================================================

Process ID: 1624 (WINLOGIN.EXE)

Service Name: Alerter
Display Name: Alerter
Service Type: runs in its own process


======================================================

Process ID: 1636 (spoolrv.exe)

Process doesn't appear to be a service

PID Port  Local IP State   Remote IP:Port
1636 TCP 1366   0.0.0.0  LISTENING  0.0.0.0:4349

======================================================


Copied from: portqry.txt
==========================
======================================================

Process ID: 1936 (service.exe)

Service Name: net-ip
Display Name: IP / TCP Services
Service Type: runs in its own process

PID Port  Local IP State   Remote IP:Port
1936 TCP 20030   0.0.0.0  LISTENING  0.0.0.0:16477
1936 TCP 35689   0.0.0.0  LISTENING  0.0.0.0:8243
1936 TCP 43958   127.0.0.1  LISTENING  0.0.0.0:38995

======================================================

Copied from: portqry.txt
==========================
======================================================

Process ID: 828 (benetns.exe)

Service Name: BackupExecAgentBrowser
Display Name: Backup Exec Agent Browser
Service Type: runs in its own process

PID Port  Local IP State   Remote IP:Port
828 TCP 6101   0.0.0.0  LISTENING  0.0.0.0:12534

======================================================


  

Next up - the anatomy of a WINS exploit . . . stay tuned.

Comments
  • this is good stuff!

    just add some info on how a shop can detect the problems and this will rock!

    you are telling us what was hit that is good and for some things thats all we need ...

    keep it up!

  • so you would have to say the that at the very least this port tcp 6101 should be block at the borders right?
    goes to my basic belief that the inet backbone should not route proprietary ports.. if you need 6101 then it should be tunneled. In this case I'm sure they did not need it!
    anyway good work!

  • From your post it seems that you use the file dates (creation, modification and access) in order to identify and locate other hack attempts and malitious files on the system. You also seem to be using a lot the system log. Isn't this risky? I mean, don't hackers usually modify the dates and erase specific event log entries to cover up? That would be most logical and the easiest of the things to do on their part. Aren't you lucky for finding these kind of tracks?

  • Yes.
    Yes.
    Yes.
    :)

    File times can be modified trivially using a variety of tools - I don't know why we don't see more of that (actually we have recently we think but that's still being investigated)

    Event logs can either be simply emptied by the bad guy using smoething like clearlog.exe or more sophisticated attackers have tools that will remove individual entries. If you clear the logs - I can at least tell what time the logs were cleared and that in and of itself is a date / time based lead. If you remove individual entries - I can detect that too and that is a definite sign you've been pwnt.

    There are lots of things the miscreants COULD do but don't . . . like using alternate data streams. The miscreants favor ease of use and automation and I use that to my advantage when hunting them down. :)

  • Great post!

    I was wondering what was used to get the dump of the Services. I know tlist.exe was used to get the running process and the command line for them. From other posts I know you have a internal tool that this dump is a part of.

  • I use sc.exe and sclist.exe to dump the services . . . if WMIC.EXE is present (i.e. XP or later) I use that too.

    Our viewer goes through the list of services from these tools and the raw registry file we capture and it reconstructs the 'services' applet for us so that we can see all the details of each service in a nice pretty UI. It also highlights known-good ones leaving the bad ones to stand out for us.

  • You say that you use sc.exe and Wmic and the registry for finding out about services. What do you do and how do you detect when these command have been trojaned or if the registry keys have been hidden?

  • We have ways of detecting things hidden by function hooking and all sorts of rootkits etc. The techniques and tools used are not something I"m going to discuss here though. :)

    I can assure you that we've all taken the red pill - we are not confined nor deceived by the laws of the Matrix.

  • Great blog! *Finally* a blog with content, and not about what someone ate for breakfast.

    Could you go into more detail about what you do when temporal analysis leaves little clues? The methods mentioned here, are heavily dependent on time, and for obvious reasons... However, while most attackers may not have the capability or intentions to modify the time, the ones that do are probably going to be a much bigger threat... and more of a challenge to catch. ;) Is it common for you and your clients to capture network traffic of the attacker in order to help get an idea of what the attacker is doing? Actually I guess that and network forensics would make it hard to hide the time of the attack. But it sounds like you got an awsome job and any more information on how you counter the more sophisticated attacks would be great.

    BTW: Is WOLF available for download under the GPL or anything? I figure it's only a matter of time before you get tired of hearing that question and give in. :p

  • Its very rare that the miscreants screw with the time stamp on files. When they do they use versions of touch.exe or hacked versions of it which allow setting less restrictive date ranges on the files / folders they want to hide. It doesn't matter - our approach doesn't *rely* on this and this is how we know they're doing it. :)

    We don't do a lot of network forensics for two reasons:
    1. Most IT shops don't configure their routers to gather / log netflow data in/out of their networks - which is a shame.

    2. Most IT shops have already pulled the plug or disabled the tap by the time we run WOLF.


    Finally - no WOLF is not available for public download - it's a support tool used to assist us in responding to security incidents experienced by our customers.

    And I'm not a big fan of the GPL. :)

  • Well at least it's good to know that a lot of anti-forensics is in limited use. It's unfortunate that so many get away just because law enforcement doesn't get involved. It seems like a good step to fixing that would be to encourage businesses to contact law enforcement by having something similar to rape shield laws so they can remain anonymous. I don't know all of the implications that would have, but right now the victims are anonymous because they aren't reporting the crime. However, making them anonymous while trying to catch the attacker obviously seems more preferable...

    Can you say what program WOLF uses to dump the event logs?

  • I agree - it would be nice of more businesses went to law enforcement agencies instead of to private companies to report intrusions. There are a couple of problems with this:

    1. LE would crumble under the work load. :) Most LE agencies are dangerously understaffed with 'cybercrime' experts as it is - any sort of increase in workload would crush them or make them impose criteria like 'we only investigate cases involving $xxx,xxx in damag' - oh wait, they already DO that. :)

    2. There are not many laws compelling companies to report intrusions and thus it doesn't happen. Once there are more 'due dilligence' laws and other such laws then we will start to see LE get more and more involved, but right now this is limitted to like . . . the state of California and I the medical industry (I think, through SOX). I'm not a legal expert by any means and don't even want to pretend to play one via my blog.

  • lol yeah good point... Maybe they should focus on quality instead of quantity then. I'm sure if law enforcement hung out on IRC they would be able to take a lot of groups down. I wouldn't be surprised if they already do that though... They seem to take down a piracy group evey once in a while, but I haven't heard of any hacking groups being caught recently.