Cached NetBIOS Name Tables
When we examine the system event logs later in this chapter, we will see that Windows (up until version 2003) stored
connection specifics by NetBIOS name rather than IP address. As an investigator, this does us no good. An attacker can easily
change his NetBIOS name to "HACKER," do damage to your system, and then change it back to the original value. Your logs
would have the word "HACKER" as the connecting machine.
Because we want to map a NetBIOS name to an IP address to throttle the nefarious individual, we can issue the nbtstat
command during our live response to dump the victim system’s NetBIOS name cache. Please take note that this command will
only show us the NetBIOS name table cache, not a complete history of connections. Therefore, values in this table represent
connections to and from machines a relatively short time ago. When we run the following command (the -c switch instructs
nbtstat to dump the cache):
nbtstat –c
we receive the following results:
Local Area Connection:
Node IpAddress: [103.98.91.41] Scope Id: []
NetBIOS Remote Cache Name Table
Name Type Host Address Life [sec]
——————————————————————————————
95.208.123.64 <20> UNIQUE 95.208.123.64 562
This is a unique response! The "name" of this server is actually the same as the IP address for this computer located at
95.208.123.64. Usually the NetBIOS name would appear in the "Name" column. When we examine additional evidence later in
this chapter, the actual IP address will show up for this computer, which will make our life a lot simpler than having to count
on NetBIOS names.
Users Currently Logged On
If you want to be stealthy during your live response, you could run PsLoggedOn, which is a tool distributed within the PsTools
suite from http://www.sysinternals.com. This tool will return the users that are currently logged onto the system or accessing
the resource shares. When we execute this tool on JBRWWW without command-line parameters, we receive the following
information:
PsLoggedOn v1.21 - Logon Session Displayer
Copyright (C) 1999-2000 Mark Russinovich
SysInternals - http://www.sysinternals.com
Users logged on locally:
8/23/2003 3:32:53 PM JBRWWW\Administrator
Users logged on via resource shares:
10/1/2003 9:52:26 PM (null)\ADMINISTRATOR
There is one user logged in locally. The local Administrator login is attributed to our live response because we must be logged
in with Administrator access to run our tools. The second login is also Administrator, but it is a remote login. Therefore,
someone is currently accessing JBRWWW as we are investigating the system. Notice that this connection has administrator
privileges, which is a prerequisite for PsExec, another tool within the PsTool suite that we will discuss a little later on. Let us
return to our current network connections:
Proto Local Address Foreign Address State
TCP 103.98.91.41:445 95.208.123.64:3762 ESTABLISHED
For a user to be connected remotely, he or she must be connected to a NetBIOS port. For Windows 2000, it is TCP port 445 or
139. For prior versions of Windows, it was only TCP port 139. Therefore, we now know the attacker’s IP address is
95.208.123.64.
The Internal Routing Table
One of the nefarious uses of a compromised server involves the attacker altering the route tables to redirect traffic in some
manner. A benefit for the attacker of rerouting traffic is avoiding a security device, such as a firewall. If there is a firewall in
the way of the attacker’s next victim, he may be able to enter the network through a different router that has more
permissive access control lists. It is possible that your compromised server may enable him to do this. Another reason an
attacker may alter the route table is to redirect the flow of traffic to sniff (capture) the data flying by on the network
connection.
We can examine the routing table by issuing the netstat command with the -rn command-line switch. The following data
comes from the netstat command when executed on JBRWWW:
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x1000003 ...00 c0 4f 1c 10 2b ...... 3Com EtherLink PCI
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 103.98.91.1 103.98.91.41 1
103.98.91.0 255.255.255.0 103.98.91.41 103.98.91.41 1
103.98.91.41 255.255.255.255 127.0.0.1 127.0.0.1 1
103.255.255.255 255.255.255.255 103.98.91.41 103.98.91.41 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
224.0.0.0 224.0.0.0 103.98.91.41 103.98.91.41 1
255.255.255.255 255.255.255.255 103.98.91.41 103.98.91.41 1
Default Gateway: 103.98.91.1
===========================================================================
Persistent Routes:
None
Route Table
Active Connections
Proto Local Address Foreign Address State
TCP 103.98.91.41:445 95.208.123.64:3762 ESTABLISHED
TCP 103.98.91.41:1033 95.208.123.64:21 CLOSE_WAIT
TCP 103.98.91.41:1174 95.145.128.17:6667 ESTABLISHED
TCP 103.98.91.41:1465 95.208.123.64:3753 ESTABLISHED
TCP 103.98.91.41:3992 95.208.123.64:445 TIME_WAIT
TCP 103.98.91.41:4151 103.98.91.200:2222 ESTABLISHED
TCP 103.98.91.41:60906 95.16.3.23:1048 ESTABLISHED
The routing table looks like a normal routing table for this server. Notice that this command also lists open network
connections. The list of open network connections matches exactly the version we saw previously when we issued the
netstat -an command.
...To be continued ......................... (link: http://www.informit.com/articles/article.aspx?p=417509)
Windows Live Response for Collecting and Analyzing Forensically Sound Evidence * By Richard Bejtlich, Keith Jones, Curtis W. Rose * Nov 11, 2005 * Sample Chapter is provided courtesy of Addison Wesley Professional
|
Computer Forensic Services - TR LOGIC, Inc.
|