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.