<Previous Page
The bolded lines represent the active network connections. The additional lines (that are not bolded) are open ports, which
we will address in the next section. Because we know that our forensic workstation is at the IP address 103.98.91.200, we
can ignore corresponding connections. A TCP connection over port 2,222 was expected due to the data transferal process we
discussed earlier in this chapter with netcat. After removing all of the other extraneous data, we are left with six interesting
lines:
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:60906 95.16.3.23:1048 ESTABLISHED
The first line is a connection to JBRWWW's Windows 2000 NetBIOS port. Therefore, the IP address 95.208.123.64 could be
issuing commands with a tool like psexec, connecting to a file share with the net use command, or exploiting some other
Microsoft Windows functionality. The second line is very interesting. JBRWWW is connecting to port 21, the FTP port, on
system 95.208.123.64. Because the administrator swears he was not involved in this connection, we flag this line as
suspicious activity. The third line is a connection to an IRC server (TCP port 6,667) at 95.145.128.17. This is another
connection the administrator did not participate in, and we note it as such.
The fourth line does not look familiar to us. A quick search on http://www.portsdb.org shows this could be the "nattyserver"
or "ChilliASP" service. Because this information does not ring a bell, we flag this connection as "possibly suspicious" and move
on. The fifth line details a NetBIOS connection from our victim machine back to 95.208.123.64. This could indicate that the
attacker has issued a net use command on JBRWWW to map a share on his attacking machine to the victim machine. Because
this IP address showed up more than once in the suspicious activity category, we also flag this connection as suspicious. The
last line shows a connection involving JBRWWW’s TCP port 60,906. Ports above 1,024 typically are ephemeral ports. Notice
that it is also connecting to an ephemeral port on a different destination IP address at 95.16.3.23. An untrained eye may
have passed this line over by now, but we add it to our possible suspicious activity category.
Open TCP or UDP Ports
If we return to the lengthy netcat listing shown earlier, all of the lines that are not bolded are open ports. We are interested
in these lines for one reason: an open rogue port usually denotes a backdoor running on the victim machine. Now, we realize
that Windows opens a lot of legitimate ports during the course of doing its business, but we can weed many of them out
quickly.
The first lines up through TCP port 515 are normal Windows ports, typically started when IIS and simple TCP/IP services are
installed on the machine. The next TCP ports, up to the established connections portion of the output, are the ephemeral
ports:
Proto Local Address Foreign Address State
TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1027 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1030 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1031 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1033 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1174 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1465 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1801 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3372 0.0.0.0:0 LISTENING
TCP 0.0.0.0:4151 0.0.0.0:0 LISTENING
TCP 0.0.0.0:60906 0.0.0.0:0 LISTENING
We see that there are a lot of ports open that we cannot identify. They could be legitimately open ports or ports onto which
the attacker has attached a backdoor. With netstat alone, we cannot identify the purpose of the open ports, so we have to
see which executables opened the ports to get a better idea of their purposes.
Executables Opening TCP or UDP Ports
To examine the strange ports that are open on this machine, we must link the open ports to the executables that opened
them. There is a tool that does this called FPort, freely distributed at http://www.foundstone.com. FPort does not need
additional command-line arguments to execute it during our live response. After we executed FPort, we received the following
results:
FPort v1.31 - TCP/IP Process to Port Mapper
Copyright 2000 by Foundstone, Inc.
http://www.foundstone.com
Securing the dot com world
Pid Process Port Proto Path
1292 tcpsvcs -> 7 TCP C:\WINNT\System32\tcpsvcs.exe
1292 tcpsvcs -> 9 TCP C:\WINNT\System32\tcpsvcs.exe
1292 tcpsvcs -> 13 TCP C:\WINNT\System32\tcpsvcs.exe
1292 tcpsvcs -> 17 TCP C:\WINNT\System32\tcpsvcs.exe
1292 tcpsvcs -> 19 TCP C:\WINNT\System32\tcpsvcs.exe
1044 inetinfo -> 21 TCP C:\WINNT\System32\inetsrv\inetinfo.exe
1044 inetinfo -> 25 TCP C:\WINNT\System32\inetsrv\inetinfo.exe
1044 inetinfo -> 80 TCP C:\WINNT\System32\inetsrv\inetinfo.exe
380 svchost -> 135 TCP C:\WINNT\system32\svchost.exe
8 System -> 139 TCP
1044 inetinfo -> 443 TCP C:\WINNT\System32\inetsrv\inetinfo.exe
8 System -> 445 TCP
1292 tcpsvcs -> 515 TCP C:\WINNT\System32\tcpsvcs.exe
492 MSTask -> 1025 TCP C:\WINNT\system32\MSTask.exe
784 msdtc -> 1027 TCP C:\WINNT\System32\msdtc.exe
860 mqsvc -> 1029 TCP C:\WINNT\System32\mqsvc.exe
8 System -> 1030 TCP
1044 inetinfo -> 1031 TCP C:\WINNT\System32\inetsrv\inetinfo.exe
1372 ftp -> 1033 TCP C:\WINNT\system32\ftp.exe
1224 iroffer -> 1174 TCP C:\WINNT\system32\os2\dll\iroffer.exe
1224 iroffer -> 1465 TCP C:\WINNT\system32\os2\dll\iroffer.exe
860 mqsvc -> 1801 TCP C:\WINNT\System32\mqsvc.exe
860 mqsvc -> 2103 TCP C:\WINNT\System32\mqsvc.exe
860 mqsvc -> 2105 TCP C:\WINNT\System32\mqsvc.exe
860 mqsvc -> 2107 TCP C:\WINNT\System32\mqsvc.exe
784 msdtc -> 3372 TCP C:\WINNT\System32\msdtc.exe
1348 t_NC -> 4151 TCP D:\win_2k\intel\bin\t_NC.EXE
1224 iroffer -> 4153 TCP C:\WINNT\system32\os2\dll\iroffer.exe
1424 nc -> 60906 TCP C:\WINNT\system32\os2\dll\nc.exe
1292 tcpsvcs -> 7 UDP C:\WINNT\System32\tcpsvcs.exe
1292 tcpsvcs -> 9 UDP C:\WINNT\System32\tcpsvcs.exe
1292 tcpsvcs -> 13 UDP C:\WINNT\System32\tcpsvcs.exe
1292 tcpsvcs -> 17 UDP C:\WINNT\System32\tcpsvcs.exe
1292 tcpsvcs -> 19 UDP C:\WINNT\System32\tcpsvcs.exe
380 svchost -> 135 UDP C:\WINNT\system32\svchost.exe
8 System -> 137 UDP
8 System -> 138 UDP
1244 snmp -> 161 UDP C:\WINNT\System32\snmp.exe
1256 snmptrap -> 162 UDP C:\WINNT\System32\snmptrap.exe
8 System -> 445 UDP
224 lsass -> 500 UDP C:\WINNT\system32\lsass.exe
440 svchost -> 520 UDP C:\WINNT\System32\svchost.exe
212 services -> 1026 UDP C:\WINNT\system32\services.exe
860 mqsvc -> 1028 UDP C:\WINNT\System32\mqsvc.exe
1044 inetinfo -> 1032 UDP C:\WINNT\System32\inetsrv\inetinfo.exe
1044 inetinfo -> 3456 UDP C:\WINNT\System32\inetsrv\inetinfo.exe
860 mqsvc -> 3527 UDP C:\WINNT\System32\mqsvc.exe
The unidentified ports from the last section are bolded in this text. The first five lines can most likely be attributed to system
binaries opening TCP ports 1,025, 1,027, 1,029, 1,030, and 1,031. The next line shows that someone was running the native
FTP client on JBRWWW. Because the administrator states that he was not running the FTP client, we flag this behavior as
suspicious activity.
The next two lines detail an executable running in C:\winnt\system32\os2\dll that is named iroffer.exe:
Pid Process Port Proto Path
1224 iroffer -> 1174 TCP C:\WINNT\system32\os2\dll\iroffer.exe
1224 iroffer -> 1465 TCP C:\WINNT\system32\os2\dll\iroffer.exe
Immediately this information seems suspicious because we are not aware of any OS/2-related DLLs that open network ports.
A quick search at http://www.google.com for "iroffer" turns up a Web site at http://www.iroffer.org. It is a real Web site, and
the tool has legitimate purposes. Apparently, this tool is a bot that connects to IRC channels and offers remote control of
JBRWWW! Thus, these two lines provide confirmation that there was an incident involving JBRWWW.
The next five lines in the FPort output show ports opened by mqsvc.exe, a binary affiliated with the message queue in
Windows. The next line detects our live response netcat session:
Pid Process Port Proto Path
1348 t_NC -> 4151 TCP D:\win_2k\intel\bin\t_NC.EXE
We renamed our netcat binary on the CD-ROM to t_NC.EXE to symbolize that it was "trusted." It was also renamed so that
we would not accidentally run a copy of nc.exe from the victim machine. More information will be presented about live
response toolkits in Chapter 16. If we move to the next two lines, we realize that they provide us with most of the
information regarding the attacker's backdoors:
Pid Process Port Proto Path
1224 iroffer -> 4153 TCP C:\WINNT\system32\os2\dll\iroffer.exe
1424 nc -> 60906 TCP C:\WINNT\system32\os2\dll\nc.exe
It seems as if the attacker has not only iroffer on the system but a netcat session as well. We cannot tell what the attacker is
doing with the netcat session with only these two lines. It could be an outbound connection, or it could be in listening mode,
allowing inbound connections free access to a command shell. When we reexamine the netstat output shown earlier, we see
that port 60,906 is actively listening. Therefore, we could conclude through netcat and FPort that the attacker's backdoor on
60,906 is currently listening for connections and is actively connected to a rogue IP address.
We neglected to mention the UDP ports in the previous section, for good reason. UDP is typically used less than TCP because
it is a stateless protocol, so UDP ports may be un-familiar to you. One way of determining open UDP ports is to check http:
//www.portsdb.org along with the analysis of a similarly configured Windows 2000 server with IIS and basic Unix services
installed. Of course, that is the hard way of doing it. If you compare the executable files that open UDP ports with the
legitimately opened TCP ports on JBRWWW, you will see that they are opened by similar system binaries. Of course, to truly
make sure they are system binaries, we must compare the MD5 checksum of these files with a known, trusted source such as
Microsoft or by comparing them to copies found on an uncompromised server.
continued page (3) >
The bolded lines represent the active network connections. The additional lines (that are not bolded) are open ports, which
we will address in the next section. Because we know that our forensic workstation is at the IP address 103.98.91.200, we
can ignore corresponding connections. A TCP connection over port 2,222 was expected due to the data transferal process we
discussed earlier in this chapter with netcat. After removing all of the other extraneous data, we are left with six interesting
lines:
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:60906 95.16.3.23:1048 ESTABLISHED
The first line is a connection to JBRWWW's Windows 2000 NetBIOS port. Therefore, the IP address 95.208.123.64 could be
issuing commands with a tool like psexec, connecting to a file share with the net use command, or exploiting some other
Microsoft Windows functionality. The second line is very interesting. JBRWWW is connecting to port 21, the FTP port, on
system 95.208.123.64. Because the administrator swears he was not involved in this connection, we flag this line as
suspicious activity. The third line is a connection to an IRC server (TCP port 6,667) at 95.145.128.17. This is another
connection the administrator did not participate in, and we note it as such.
The fourth line does not look familiar to us. A quick search on http://www.portsdb.org shows this could be the "nattyserver"
or "ChilliASP" service. Because this information does not ring a bell, we flag this connection as "possibly suspicious" and move
on. The fifth line details a NetBIOS connection from our victim machine back to 95.208.123.64. This could indicate that the
attacker has issued a net use command on JBRWWW to map a share on his attacking machine to the victim machine. Because
this IP address showed up more than once in the suspicious activity category, we also flag this connection as suspicious. The
last line shows a connection involving JBRWWW’s TCP port 60,906. Ports above 1,024 typically are ephemeral ports. Notice
that it is also connecting to an ephemeral port on a different destination IP address at 95.16.3.23. An untrained eye may
have passed this line over by now, but we add it to our possible suspicious activity category.
Open TCP or UDP Ports
If we return to the lengthy netcat listing shown earlier, all of the lines that are not bolded are open ports. We are interested
in these lines for one reason: an open rogue port usually denotes a backdoor running on the victim machine. Now, we realize
that Windows opens a lot of legitimate ports during the course of doing its business, but we can weed many of them out
quickly.
The first lines up through TCP port 515 are normal Windows ports, typically started when IIS and simple TCP/IP services are
installed on the machine. The next TCP ports, up to the established connections portion of the output, are the ephemeral
ports:
Proto Local Address Foreign Address State
TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1027 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1030 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1031 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1033 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1174 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1465 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1801 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3372 0.0.0.0:0 LISTENING
TCP 0.0.0.0:4151 0.0.0.0:0 LISTENING
TCP 0.0.0.0:60906 0.0.0.0:0 LISTENING
We see that there are a lot of ports open that we cannot identify. They could be legitimately open ports or ports onto which
the attacker has attached a backdoor. With netstat alone, we cannot identify the purpose of the open ports, so we have to
see which executables opened the ports to get a better idea of their purposes.
Executables Opening TCP or UDP Ports
To examine the strange ports that are open on this machine, we must link the open ports to the executables that opened
them. There is a tool that does this called FPort, freely distributed at http://www.foundstone.com. FPort does not need
additional command-line arguments to execute it during our live response. After we executed FPort, we received the following
results:
FPort v1.31 - TCP/IP Process to Port Mapper
Copyright 2000 by Foundstone, Inc.
http://www.foundstone.com
Securing the dot com world
Pid Process Port Proto Path
1292 tcpsvcs -> 7 TCP C:\WINNT\System32\tcpsvcs.exe
1292 tcpsvcs -> 9 TCP C:\WINNT\System32\tcpsvcs.exe
1292 tcpsvcs -> 13 TCP C:\WINNT\System32\tcpsvcs.exe
1292 tcpsvcs -> 17 TCP C:\WINNT\System32\tcpsvcs.exe
1292 tcpsvcs -> 19 TCP C:\WINNT\System32\tcpsvcs.exe
1044 inetinfo -> 21 TCP C:\WINNT\System32\inetsrv\inetinfo.exe
1044 inetinfo -> 25 TCP C:\WINNT\System32\inetsrv\inetinfo.exe
1044 inetinfo -> 80 TCP C:\WINNT\System32\inetsrv\inetinfo.exe
380 svchost -> 135 TCP C:\WINNT\system32\svchost.exe
8 System -> 139 TCP
1044 inetinfo -> 443 TCP C:\WINNT\System32\inetsrv\inetinfo.exe
8 System -> 445 TCP
1292 tcpsvcs -> 515 TCP C:\WINNT\System32\tcpsvcs.exe
492 MSTask -> 1025 TCP C:\WINNT\system32\MSTask.exe
784 msdtc -> 1027 TCP C:\WINNT\System32\msdtc.exe
860 mqsvc -> 1029 TCP C:\WINNT\System32\mqsvc.exe
8 System -> 1030 TCP
1044 inetinfo -> 1031 TCP C:\WINNT\System32\inetsrv\inetinfo.exe
1372 ftp -> 1033 TCP C:\WINNT\system32\ftp.exe
1224 iroffer -> 1174 TCP C:\WINNT\system32\os2\dll\iroffer.exe
1224 iroffer -> 1465 TCP C:\WINNT\system32\os2\dll\iroffer.exe
860 mqsvc -> 1801 TCP C:\WINNT\System32\mqsvc.exe
860 mqsvc -> 2103 TCP C:\WINNT\System32\mqsvc.exe
860 mqsvc -> 2105 TCP C:\WINNT\System32\mqsvc.exe
860 mqsvc -> 2107 TCP C:\WINNT\System32\mqsvc.exe
784 msdtc -> 3372 TCP C:\WINNT\System32\msdtc.exe
1348 t_NC -> 4151 TCP D:\win_2k\intel\bin\t_NC.EXE
1224 iroffer -> 4153 TCP C:\WINNT\system32\os2\dll\iroffer.exe
1424 nc -> 60906 TCP C:\WINNT\system32\os2\dll\nc.exe
1292 tcpsvcs -> 7 UDP C:\WINNT\System32\tcpsvcs.exe
1292 tcpsvcs -> 9 UDP C:\WINNT\System32\tcpsvcs.exe
1292 tcpsvcs -> 13 UDP C:\WINNT\System32\tcpsvcs.exe
1292 tcpsvcs -> 17 UDP C:\WINNT\System32\tcpsvcs.exe
1292 tcpsvcs -> 19 UDP C:\WINNT\System32\tcpsvcs.exe
380 svchost -> 135 UDP C:\WINNT\system32\svchost.exe
8 System -> 137 UDP
8 System -> 138 UDP
1244 snmp -> 161 UDP C:\WINNT\System32\snmp.exe
1256 snmptrap -> 162 UDP C:\WINNT\System32\snmptrap.exe
8 System -> 445 UDP
224 lsass -> 500 UDP C:\WINNT\system32\lsass.exe
440 svchost -> 520 UDP C:\WINNT\System32\svchost.exe
212 services -> 1026 UDP C:\WINNT\system32\services.exe
860 mqsvc -> 1028 UDP C:\WINNT\System32\mqsvc.exe
1044 inetinfo -> 1032 UDP C:\WINNT\System32\inetsrv\inetinfo.exe
1044 inetinfo -> 3456 UDP C:\WINNT\System32\inetsrv\inetinfo.exe
860 mqsvc -> 3527 UDP C:\WINNT\System32\mqsvc.exe
The unidentified ports from the last section are bolded in this text. The first five lines can most likely be attributed to system
binaries opening TCP ports 1,025, 1,027, 1,029, 1,030, and 1,031. The next line shows that someone was running the native
FTP client on JBRWWW. Because the administrator states that he was not running the FTP client, we flag this behavior as
suspicious activity.
The next two lines detail an executable running in C:\winnt\system32\os2\dll that is named iroffer.exe:
Pid Process Port Proto Path
1224 iroffer -> 1174 TCP C:\WINNT\system32\os2\dll\iroffer.exe
1224 iroffer -> 1465 TCP C:\WINNT\system32\os2\dll\iroffer.exe
Immediately this information seems suspicious because we are not aware of any OS/2-related DLLs that open network ports.
A quick search at http://www.google.com for "iroffer" turns up a Web site at http://www.iroffer.org. It is a real Web site, and
the tool has legitimate purposes. Apparently, this tool is a bot that connects to IRC channels and offers remote control of
JBRWWW! Thus, these two lines provide confirmation that there was an incident involving JBRWWW.
The next five lines in the FPort output show ports opened by mqsvc.exe, a binary affiliated with the message queue in
Windows. The next line detects our live response netcat session:
Pid Process Port Proto Path
1348 t_NC -> 4151 TCP D:\win_2k\intel\bin\t_NC.EXE
We renamed our netcat binary on the CD-ROM to t_NC.EXE to symbolize that it was "trusted." It was also renamed so that
we would not accidentally run a copy of nc.exe from the victim machine. More information will be presented about live
response toolkits in Chapter 16. If we move to the next two lines, we realize that they provide us with most of the
information regarding the attacker's backdoors:
Pid Process Port Proto Path
1224 iroffer -> 4153 TCP C:\WINNT\system32\os2\dll\iroffer.exe
1424 nc -> 60906 TCP C:\WINNT\system32\os2\dll\nc.exe
It seems as if the attacker has not only iroffer on the system but a netcat session as well. We cannot tell what the attacker is
doing with the netcat session with only these two lines. It could be an outbound connection, or it could be in listening mode,
allowing inbound connections free access to a command shell. When we reexamine the netstat output shown earlier, we see
that port 60,906 is actively listening. Therefore, we could conclude through netcat and FPort that the attacker's backdoor on
60,906 is currently listening for connections and is actively connected to a rogue IP address.
We neglected to mention the UDP ports in the previous section, for good reason. UDP is typically used less than TCP because
it is a stateless protocol, so UDP ports may be un-familiar to you. One way of determining open UDP ports is to check http:
//www.portsdb.org along with the analysis of a similarly configured Windows 2000 server with IIS and basic Unix services
installed. Of course, that is the hard way of doing it. If you compare the executable files that open UDP ports with the
legitimately opened TCP ports on JBRWWW, you will see that they are opened by similar system binaries. Of course, to truly
make sure they are system binaries, we must compare the MD5 checksum of these files with a known, trusted source such as
Microsoft or by comparing them to copies found on an uncompromised server.
continued page (3) >
| 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. |