F4-analyzing Network-based evidence for a windows intrusion Dr. John P. Abraham Professor UTPA

JBR Bank Example Live response data is given in previous chapters The bank’s networking staff had Tcpdump running on a Linux monitoring platform sitting on a hub with visibility to the victim system it had started Tcpdump using the following command: –Tcpdump –n –I eth0 –s 1515 –w capture_file.lpc Meaning of switches are given on page 95 –Incident response team split into two smaller files using Tcpslice called s2a.lpc and s2b.lpc.

First analysis Decided to analize the s2a.lpc file first. –Result given on page 96 – 3 minutes long capture, 8 MB in size. Lot of web activity. Port 80. (43.49% of all packets sent out by web servers, and web clients sending 44.05%) Alert Data: First Trace –Snort’s signature-matching engine can find patterns of malicious activity. –Nmap scanning tool. –Alert file in text viewer is given on page 98. See explanation such as web application attack, attempted information leak, etc. The source address is given as well. (destination is the victim server). Looking at page 101, we can see some reconnaissance (scan) activity. Beyond checking for vulnerabilities in the web service, the intruder is now looking for other services that present opportunities for exploitation. Perhaps the intruder is using the Nmap scanning tool.

Session Data – first trace –First we run against the Libcap data to transform it into session data Argus –d –r s2a.lpc –w s2a.argus –d switch tells Argus to run in the background –r switch reads data from the Libcap file s2a.lpc –w switch writes the Argus results into the file s2a.argus. Take a look at page 103 for results. All traffic is directed at port 80 TCP, mainly with a pattern of packets sent by the source and destination, which is consistent with scanning for web vulnerabilities. At the bottom of the page pattern also shows port scanning. The destination port is changed from 1359 to 305 to 698 and so on. The source sends one packet and destination sends one packet reply. Usually in web page multiple packets and responded with. Any time when only one or two packets are sent from the server, it is unusual.

More In contrast to the polite closes seen in the Web reconnaissance, these “sessions” are closed with an RST. These aren’t’ really “sessions” because the three-way handshake, which would have established a true conversation between source and destination was never completed. We can guess all the ports scanned here were closed because the source probably sent a single SYN packet and the destination replied with a single RST ACK packet. »When the scanned port is open, we see a pattern like on page 104. »Here the source sends two packets and the destination sends one. »The source probably sent a SYN, to which the destination replied SYN ACK. »To tear down the connection attempt the source sends an RST

More On page 104 lower end of page we see the snort.log file, where copies of the packets that caused Snort to alert are stored. The first highlighted field, GET/cgi-bin/, caused Snort to report an intruder was trying to determine whether the cgi- bin directory was present on the Web server This is a common vulnerability check because many Common Gateway Interface (CGI) programs are poorly written, offering opportunities for crafty attackers. The second highlighted field, Nikto/1.30, confirms suspicion that Nikto Web vulnerability assessment tool was fired against the Web server. The final highlighted field, 403 Access Forbidden is the web server’s response to this reconnaissance effort. This alert show snort can be programmed not only to watch for activity from intruders but also to monitor responses from victims.

Full Content Data: First trace –To confirm the interpretation of the suspected reconnaissance observed via Snort alerts and Argus session data, we turn to the original Libcap file s2a.lpc. –The following packets demonstrate how the attacker sends a single SYN packet, to which a closed port replies with a single RST ACK. –These are highlighted in the Tcpdump output on page 106 –A possible fingerprint is hex or ascii uuuuuu. Goggle search shows this is associated with Nmap reconnaissance tool. –For closef ports, the source sends one packet, and the destination replies with one packet, and the destination replies with one packet.

Statistical Data: Second Trace –We’ll run through Tcpdstat: page 108 –Most of the action of s2b.lpc appears in the “other” category, accounting for 83.64% of all traffic. –These are all the TCP and UDP protocols that Tcpdstat recognizes. Tcpdstat does NOT know how to interpret Microsoft’s NetBIOS/Server Message Block protocol running on TCP ports 139 and 445 or UDP ports 137 and 138. see page 109 sample source code lifted. A second difference from the first trace is the presence of 16 non-IP packets. You can see this by comparing the total number of packets to the number of IP packets. Although this could be a protocol such as NetBEUI for old Windows networking or IPX for Novell clients, it is probably ARP (Address Resolutions Protocol) traffic.

Alert Data: Second Trace –Command on page 110 –We see that 16 are ARP traffic. –ARP is used to resolve IP addresses to MAC addresses. –Checking the reference in the data on page 111 against the Common Vulnerabilities and Exposure (CVE) database, you find that CAN is described as follows: Buffer overflow in Internet Printing ISAPI extension in Windows 2000 allows remote attackers to gain root privileges via along print request that is passed to the extension through IIS 5. This is bad news. Second event happed four minutes later and third 6 minutes later, from different IP addresses.The intruder may own both machines, or friends are involved.

Microsoft Technet – see p. 112 Clients make SMB requests for resources and servers make SMB responses. SMB (server message Block) is the protocol Microsoft uses to share files, printers, serial ports, and also to communicate between computers using named pipes and mail slots. By sending a specially crafted packet request, an attacker can mount a denial of service attack on the target server machine and crash the system.

Session Data: Second Trace Filter out the Web and SMB and ARP traffic which we already discussed in the first trace. See command on 115, not port 80, not port 137 and so on. –The second to the last entry on page 115 is very important. We see the victim Web server successfully connected to on port This indicates the intruder forced the Web server to speak IRC in hopes of controlling it via that communications medium. –The final session data entry displayed here show s connecting to port 1465 TCP on the victim Web server.

Full content data: second trace –Rather than looking through full content data on a packet by packet basis, we’ll ask tcpflow to rebuild sessions of interest on ports 21, 60,906, 1,465, and 6,667 TCP Tcpflow –r s2b.lpc port 21 or port or port 1465 or port 6667 see page 116 –In this case, tcpflow produces eight files. The filename syntax shows: The source IP and port Followed by the destination IP and port The eight files on pg 116 are the data sent by the source and destination for four separate sessions. On the third file, using tcpflow, we realize the intruder has been allowed on the victim’s server. To see what the IRC session looks like, check the connection to port We can see that intruder tried to access files using ftp. Next we read the responses from the IRC server with destination port 1174 on page 121