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
PowerPoint Slideshow about ' F4-analyzing Network-based evidence for a windows intrusion' - rivka
An Image/Link below is provided (as is) to download presentation
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
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. http://www.insecure.org/nmap
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.
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.
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.
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.
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-2001-0241 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.
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 184.108.40.206 on port 6667. 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 s220.127.116.11 connecting to port 1465 TCP on the victim Web server.