Description: #################### ### Introduction ### #################### The goal of pkts2db.pl was to not completely take away the analysis from the analyst. Instead, it simply puts the packets in a SQLite database that allows the analyst to easily query it to answer as many or as little questions as (s)he has. Scansearcher.pl was also created to automatically run queries that can be used to detect port scans, and then put the results in an HTML report. You can create an HTML report with: perl pkts2db.pl -r evidence04.pcap -d evidence04.db perl scansearcher.pl -d evidence04.db -o evidence04.html perl scansearcher.pl -d evidence04.db -s 10.42.42.253 -t 10.42.42.50 -o evidence04.details.html The analysis below was accomplished without scansearcher.pl. The questions and answers are at the EOF. perl pkts2db.pl -r evidence04.pcap -d evidence04.db sqlite evidence04.db sqlite> .header ON sqlite> .mode column ############################# ### 1. Detects port scans ### ############################# SELECT saddr, daddr, MIN(dport) ||':'|| MAX(dport) AS dport_range, COUNT(DISTINCT dport) AS uniq_dports FROM ip, tcp WHERE ip.id = tcp.id AND tcp.flags = 2 GROUP BY saddr, daddr ORDER BY uniq_dports DESC LIMIT 10; saddr daddr dport_range uniq_dports ------------ ----------- ----------- ----------- 10.42.42.253 10.42.42.25 1:65389 1000 10.42.42.253 10.42.42.50 1:65389 1000 10.42.42.253 10.42.42.56 1:65389 1000 10.42.42.25 10.42.42.50 139:139 1 Right away, you can see 10.42.42.253 is clearly scanning ports on three hosts, which answers the first question. The destination port ranges and number of unique destination ports per host is consistent with Nmap when no ports are specified with the -p option. ######################################################## ### 2. IP addresses sending the most SYNs per minute ### ######################################################## SELECT strftime('%Y-%m-%d %H:%M', time) AS datetime, saddr, daddr, COUNT(DISTINCT dport) AS uniq_dports, COUNT(*) AS syn_per_min FROM ip, tcp WHERE ip.id = tcp.id AND tcp.flags = 2 GROUP BY datetime, saddr, daddr ORDER BY syn_per_min DESC LIMIT 10; datetime saddr daddr uniq_dports syn_per_min ---------------- ------------ ----------- ----------- ----------- 2010-02-02 18:43 10.42.42.253 10.42.42.25 952 1697 2010-02-02 18:34 10.42.42.253 10.42.42.25 665 1245 2010-02-02 18:34 10.42.42.253 10.42.42.50 1000 1001 2010-02-02 18:34 10.42.42.253 10.42.42.56 1000 1001 2010-02-02 18:43 10.42.42.253 10.42.42.50 1000 1000 2010-02-02 18:43 10.42.42.253 10.42.42.56 1000 1000 2010-02-02 18:35 10.42.42.253 10.42.42.25 60 60 2010-02-02 18:36 10.42.42.253 10.42.42.25 60 60 2010-02-02 18:37 10.42.42.253 10.42.42.25 60 60 2010-02-02 18:38 10.42.42.253 10.42.42.25 60 60 This shows how many SYN segments were sent per minute. The large amount of connection requests sent per minute, is further evidence that 10.42.42.253 is up to no good. Running the same query with "ORDER BY datetime ASC" may also be useful for providing a timeline of SYN segments sent per minute. ############################################ ### 3. Most common source ports for SYNs ### ############################################ SELECT saddr, sport, COUNT(sport) AS sport_cnt FROM ip, tcp WHERE ip.id = tcp.id AND tcp.flags = 2 GROUP BY saddr, sport ORDER BY sport_cnt DESC LIMIT 10; saddr sport sport_cnt ------------ ---------- ---------- 10.42.42.253 36020 3000 10.42.42.253 36021 396 10.42.42.253 36022 349 10.42.42.253 36136 4 10.42.42.253 34237 3 10.42.42.253 35130 3 10.42.42.253 43761 3 10.42.42.253 44487 3 10.42.42.253 48877 3 10.42.42.253 53283 3 During SYN scans, Nmap will use the same source port on SYN segments. This is most likely what you are seeing here. ################################################ ### 4. Most common sequence numbers for SYNs ### ################################################ SELECT saddr, seq, COUNT(*) AS seq_count FROM ip, tcp WHERE ip.id = tcp.id AND tcp.flags = 2 GROUP BY saddr, seq ORDER BY seq_count DESC LIMIT 10; saddr seq seq_count ------------ ---------- ---------- 10.42.42.253 289350607 3000 10.42.42.253 289285070 396 10.42.42.253 289219533 349 10.42.42.253 1405980936 4 10.42.42.25 279808938 1 10.42.42.25 1047333297 1 10.42.42.25 1142317008 1 10.42.42.25 1337458087 1 10.42.42.25 1698659375 1 10.42.42.25 2203996472 1 Some sequence numbers are not only appearing too frequently to be normal, but the sequence number counts match the source port counts from query #3, which again, suggests Nmap was used. ########################### ### 5. Open Ports found ### ########################### SELECT saddr, sport AS open_port, COUNT(*) AS count FROM ip, tcp WHERE ip.id = tcp.id AND daddr = "10.42.42.253" AND tcp.flags = 18 GROUP BY saddr, sport; saddr open_port count ----------- ---------- ---------- 10.42.42.50 135 12 10.42.42.50 139 3 These are the ports for services that sent SYN-ACK segments to the port scanner (10.42.42.253), which means the scanner now knows those ports are open. ###################################################### ### 6. Session info involving the known open ports ### ###################################################### SELECT time, saddr, sport, daddr, dport, tcp.flags FROM ip, tcp WHERE ip.id = tcp.id AND saddr = "10.42.42.50" AND sport IN (135,139) AND daddr = "10.42.42.253" AND tcp.flags = 18 ORDER BY time ASC LIMIT 5; time saddr sport daddr dport flags -------------------------- ----------- ---------- ------------ ---------- ---------- 2010-02-02T18:34:07.824240 10.42.42.50 139 10.42.42.253 56257 18 2010-02-02T18:34:08.106871 10.42.42.50 135 10.42.42.253 42214 18 2010-02-02T18:43:10.204354 10.42.42.50 139 10.42.42.253 36020 18 2010-02-02T18:43:10.331093 10.42.42.50 135 10.42.42.253 36020 18 2010-02-02T18:44:04.27378 10.42.42.50 135 10.42.42.253 43490 18 This query gives more details on the sessions involving open ports, which will then be used in the next query. ################################################################################################# ### 7. Takes information from above query to find flags on all segments in first two sessions ### ################################################################################################# SELECT time, saddr, sport, daddr, dport, tcp.flags FROM ip, tcp WHERE ip.id = tcp.id AND saddr IN ("10.42.42.50","10.42.42.253") AND daddr IN ("10.42.42.50","10.42.42.253") AND sport IN (135,139,56257,42214) AND dport IN (135,139,56257,42214) ORDER BY time ASC; time saddr sport daddr dport flags -------------------------- ------------ ---------- ----------- ---------- ---------- 2010-02-02T18:34:07.823920 10.42.42.253 56257 10.42.42.50 139 2 2010-02-02T18:34:07.824240 10.42.42.50 139 10.42.42.25 56257 18 2010-02-02T18:34:07.824470 10.42.42.253 56257 10.42.42.50 139 16 2010-02-02T18:34:07.826540 10.42.42.253 56257 10.42.42.50 139 20 2010-02-02T18:34:08.106735 10.42.42.253 42214 10.42.42.50 135 2 2010-02-02T18:34:08.106871 10.42.42.50 135 10.42.42.25 42214 18 2010-02-02T18:34:08.107037 10.42.42.253 42214 10.42.42.50 135 16 2010-02-02T18:34:08.107218 10.42.42.253 42214 10.42.42.50 135 20 This shows that the first port scan was a TCP Connect scan because the three way handshake was completed and then torn down with a RST-ACK segment. ####################################### ### 8. Hosts discovered by scanner #### ####################################### SELECT saddr, daddr, count(*) as count FROM ip WHERE daddr = "10.42.42.253" GROUP BY saddr, daddr ORDER BY count DESC LIMIT 10; saddr daddr count ----------- ------------ ---------- 10.42.42.50 10.42.42.253 2027 10.42.42.56 10.42.42.253 2013 10.42.42.25 10.42.42.253 2007 Three hosts sent data to the port scanner, so 10.42.42.253 knows they are alive. ################################ ### 9. Flags used by scanner ### ################################ SELECT saddr, tcp.flags, MIN(dport) ||':'|| MAX(dport) AS dport_range, COUNT(*) as flag_cnt FROM ip, tcp WHERE ip.id = tcp.id and saddr = "10.42.42.253" GROUP BY tcp.flags ORDER BY flag_cnt DESC; saddr flags dport_range flag_cnt ------------ ---------- ----------- ---------- 10.42.42.253 2 1:65389 7414 10.42.42.253 16 1:139 11 10.42.42.253 4 135:139 10 10.42.42.253 41 1:1 4 10.42.42.253 17 135:139 3 10.42.42.253 24 135:139 3 10.42.42.253 20 135:139 2 10.42.42.253 0 135:135 1 10.42.42.253 43 135:135 1 10.42.42.253 194 135:135 1 Here you can see the port scanner sent some unusual TCP flag combinations such as 0, 41, 43, and 194, which are characteristic of Nmap when the -O option is used for OS fingerprinting. #################### ### 10. UDP Scan ### #################### SELECT saddr, daddr, MIN(dport) ||':'|| MAX(dport) AS dport_range, COUNT(DISTINCT dport) AS uniq_dports FROM ip, udp WHERE ip.id = udp.id AND saddr = "10.42.42.253" GROUP BY saddr, daddr ORDER BY uniq_dports DESC LIMIT 10; saddr daddr dport_range uniq_dports ------------ ----------- ----------- ----------- 10.42.42.253 10.42.42.25 39217:39217 1 10.42.42.253 10.42.42.50 36476:36476 1 10.42.42.253 10.42.42.56 40228:40228 1 It doesn't appear as though a UDP scan took place. These are actually Nmap's UDP probes as you will see later in query #15 for the extra credit question. #################### ### 11. RST Scan ### #################### SELECT saddr, daddr, MIN(dport) ||':'|| MAX(dport) AS dport_range, COUNT(DISTINCT dport) AS uniq_dports FROM ip, tcp WHERE ip.id = tcp.id AND saddr = "10.42.42.253" AND tcp.flags = 20 GROUP BY saddr, daddr ORDER BY uniq_dports DESC LIMIT 10; saddr daddr dport_range uniq_dports ------------ ----------- ----------- ----------- 10.42.42.253 10.42.42.50 135:139 2 Doesn't look like a RST scan was used to get live hosts. ##################### ### 12. XMAS Scan ### ##################### SELECT saddr, daddr, MIN(dport) ||':'|| MAX(dport) AS dport_range, COUNT(DISTINCT dport) AS uniq_dports FROM ip, tcp WHERE ip.id = tcp.id AND saddr = "10.42.42.253" AND tcp.flags = 41 GROUP BY saddr, daddr ORDER BY uniq_dports DESC LIMIT 10; saddr daddr dport_range uniq_dports ------------ ----------- ----------- ----------- 10.42.42.253 10.42.42.25 1:1 1 10.42.42.253 10.42.42.50 1:1 1 10.42.42.253 10.42.42.56 1:1 1 No XMAS scan was found, however, when Nmap is used with the -O for OS fingerprinting, a segment with XMAS flags (FIN, PSH and URG) is sent to TCP port 1 on the target like you can see here. #################### ### 13. ACK Scan ### #################### SELECT saddr, daddr, MIN(dport) ||':'|| MAX(dport) AS dport_range, COUNT(DISTINCT dport) AS uniq_dports FROM ip, tcp WHERE ip.id = tcp.id AND saddr = "10.42.42.253" AND tcp.flags = 16 GROUP BY saddr, daddr ORDER BY uniq_dports DESC LIMIT 10; saddr daddr dport_range uniq_dports ------------ ----------- ----------- ----------- 10.42.42.253 10.42.42.50 1:139 3 10.42.42.253 10.42.42.25 1:1 1 10.42.42.253 10.42.42.56 1:1 1 No ACK scan, however, sending an ACK segment to port 1 is characteristic of Nmap. ############################# ### 14. MAC to IP mapping ### ############################# SELECT smac, saddr FROM ip GROUP BY smac, saddr; smac|saddr 0016cb926edc|10.42.42.25 00238b821f4a|10.42.42.253 002622cb1e79|10.42.42.56 705ab651d7b2|10.42.42.50 This query shows the MAC to IP address relationships. See the bug comments at the EOF for why the SQLite output mode was changed. ########################### ### 15. Nmap UDP Probes ### ########################### SELECT saddr, sport, daddr, dport, count(*) as count FROM ip, udp WHERE ip.id = udp.id AND ipid = 4162 AND udp.len = 308 GROUP BY saddr, daddr ORDER BY count DESC LIMIT 20; saddr sport daddr dport count ------------ ---------- ----------- ---------- ---------- 10.42.42.253 36045 10.42.42.56 40228 2 10.42.42.253 36045 10.42.42.25 39217 1 10.42.42.253 36045 10.42.42.50 36476 1 Nmap sends 308 byte UPD probes with a static IP ID of 4162, and as you can see the source port also doesn't change when it should. Nmap uses a UDP payload of all C's in these UDP probes, and sure enough, Windump shows they do contain the letter C. WinDump.exe -c 1 -nnvXr evidence04.pcap "udp and src port 36045 and dst port 40228" reading from file evidence04.pcap, link-type EN10MB (Ethernet) 18:44:10.697812 IP (tos 0x0, ttl 63, id 4162, offset 0, flags [none], proto: UD P (17), length: 328) 10.42.42.253.36045 > 10.42.42.56.40228: UDP, length 300 0x0000: 4500 0148 1042 0000 3f11 00db 0a2a 2afd E..H.B..?....**. 0x0010: 0a2a 2a38 8ccd 9d24 0134 00a2 4343 4343 .**8...$.4..CCCC 0x0020: 4343 4343 4343 4343 4343 4343 4343 4343 CCCCCCCCCCCCCCCC 0x0030: 4343 4343 4343 4343 4343 4343 4343 4343 CCCCCCCCCCCCCCCC 0x0040: 4343 4343 4343 4343 4343 4343 4343 4343 CCCCCCCCCCCCCCCC 0x0050: 4343 4343 4343 4343 4343 4343 4343 4343 CCCCCCCCCCCCCCCC 0x0060: 4343 4343 4343 4343 4343 4343 4343 4343 CCCCCCCCCCCCCCCC 0x0070: 4343 4343 4343 4343 4343 4343 4343 4343 CCCCCCCCCCCCCCCC 0x0080: 4343 4343 4343 4343 4343 4343 4343 4343 CCCCCCCCCCCCCCCC 0x0090: 4343 4343 4343 4343 4343 4343 4343 4343 CCCCCCCCCCCCCCCC 0x00a0: 4343 4343 4343 4343 4343 4343 4343 4343 CCCCCCCCCCCCCCCC 0x00b0: 4343 4343 4343 4343 4343 4343 4343 4343 CCCCCCCCCCCCCCCC 0x00c0: 4343 4343 4343 4343 4343 4343 4343 4343 CCCCCCCCCCCCCCCC 0x00d0: 4343 4343 4343 4343 4343 4343 4343 4343 CCCCCCCCCCCCCCCC 0x00e0: 4343 4343 4343 4343 4343 4343 4343 4343 CCCCCCCCCCCCCCCC 0x00f0: 4343 4343 4343 4343 4343 4343 4343 4343 CCCCCCCCCCCCCCCC 0x0100: 4343 4343 4343 4343 4343 4343 4343 4343 CCCCCCCCCCCCCCCC 0x0110: 4343 4343 4343 4343 4343 4343 4343 4343 CCCCCCCCCCCCCCCC 0x0120: 4343 4343 4343 4343 4343 4343 4343 4343 CCCCCCCCCCCCCCCC 0x0130: 4343 4343 4343 4343 4343 4343 4343 4343 CCCCCCCCCCCCCCCC 0x0140: 4343 4343 4343 4343 CCCCCCCC ######################### ### 16. Nmap TCP Ping ### ######################### SELECT time, saddr, sport, daddr, dport, tcp.flags FROM ip, tcp WHERE ip.id = tcp.id AND saddr = "10.42.42.253" ORDER BY time ASC LIMIT 5; time saddr sport daddr dport flags -------------------------- ------------ ---------- ----------- ---------- ---------- 2010-02-02T18:34:06.956656 10.42.42.253 46104 10.42.42.50 80 2 2010-02-02T18:34:07.564250 10.42.42.253 59856 10.42.42.56 80 2 2010-02-02T18:34:07.564252 10.42.42.253 40921 10.42.42.25 80 2 2010-02-02T18:34:07.769446 10.42.42.253 38232 10.42.42.50 554 2 2010-02-02T18:34:07.769449 10.42.42.253 43771 10.42.42.56 554 2 By default, Nmap first sends a TCP ping by sending a SYN segment to port 80 if Nmap is running as a non-privileged user, and it will send an ACK segment to port 80 if Nmap is running as a privileged user. It appears as though Nmap *might* of (at least for the TCP Connect scan) been running as a non-privileged user because its TCP pings had the SYN flag set instead of the ACK flag. Reference: http://www.networkuptime.com/nmap/page4-4.shtml ############################ ### 17. Nmap ICMP Probes ### ############################ SELECT MIN(time) as first_seen, saddr, daddr, type, code, COUNT(*) AS count FROM ip, icmp WHERE ip.id = icmp.id AND saddr = "10.42.42.253" AND type = 8 AND code = 9 GROUP BY saddr, daddr ORDER BY count DESC LIMIT 10; first_seen saddr daddr type code count -------------------------- ------------ ----------- ---------- ---------- ---------- 2010-02-02T18:44:10.647405 10.42.42.253 10.42.42.56 8 9 2 2010-02-02T18:44:10.647413 10.42.42.253 10.42.42.25 8 9 1 2010-02-02T18:44:10.671387 10.42.42.253 10.42.42.50 8 9 1 10.42.42.253 has sent some Nmap ICMP echo probes with bogus code of 9 that's used when OS fingerprinting is enabled with -O. ########################################################### ### 18. Application bytes sent due to Nmap version scan ### ########################################################### SELECT time, saddr, sport, daddr, dport, SUM(appbytes * count) as app_bytes FROM (SELECT time, saddr, sport, daddr, dport, (ip.len - (ip.hlen + tcp.hlen)) AS appbytes, count(*) as count FROM ip, tcp WHERE ip.id = tcp.id AND appbytes > 0 AND saddr IN ("10.42.42.253","10.42.42.50") AND daddr IN ("10.42.42.253","10.42.42.50") GROUP BY saddr, daddr, sport, dport, appbytes) GROUP BY saddr, daddr, sport, dport ORDER BY time ASC LIMIT 30; time saddr sport daddr dport app_bytes ------------------------- ------------ ---------- ----------- ---------- ---------- 2010-02-02T18:44:10.32066 10.42.42.253 37926 10.42.42.50 139 18 2010-02-02T18:44:10.32071 10.42.42.253 43490 10.42.42.50 135 32 2010-02-02T18:44:10.32917 10.42.42.50 139 10.42.42.25 37926 5 2010-02-02T18:44:10.35978 10.42.42.253 43492 10.42.42.50 135 168 2010-02-02T18:44:10.36684 10.42.42.50 135 10.42.42.25 43492 24 Windump was used to verify that the data contained in the packets could be from Nmap being run with -sV to get the version of services. Nmap v5.21 was also run against TCP ports 135 and 139 on another computer and recorded with Windump. That PCAP was then put into another database using pkts2db.pl. The above query run on that new database showed very similiar results to what you see here. ############################# ### Questions and Answers ### ############################# 1. What was the IP address of Mr. X’s scanner? Answer: 10.42.42.253 2. For the FIRST port scan that Mr. X conducted, what type of port scan was it? (Note: the scan consisted of many thousands of packets.) Pick one: Answer: TCP Connect 3. What were the IP addresses of the targets Mr. X discovered? Answer: 10.42.42.25, 10.42.42.50, 10.42.42.56 4. What was the MAC address of the Apple system he found? Answer: 00:16:cb:92:6e:dc (Apple Computer) The answer could of been found by using the Net::MAC::Vendor Perl module, but because there weren't many MAC addresses in the PCAP file, it was found by searching http://standards.ieee.org/regauth/oui/index.shtml. 5. What was the IP address of the Windows system he found? Answer: 10.42.42.50 6. What TCP ports were open on the Windows system? (Please list the decimal numbers from lowest to highest.) Answer: 135, 139 7. X-TRA CREDIT (You don’t have to answer this, but you get super bonus points if you do): What was the name of the tool Mr. X used to port scan? How can you tell? Can you reconstruct the output from the tool, roughly the way Mr. X would have seen it? Answer: Nmap was used to launch TCP Connect and SYN scans against three hosts without specifying the ports to scan with the -p option. The -O and -sV options were also used at some point, I believe during the SYN scan. The reasons for this conclusion is listed below: 1. The port ranges and number of unique ports scanned shown in query #1. 2. The same source port and sequence number on the SYNs sent during the SYN scan as shown in queries #3 and #4. 3. The unusual TCP flags found in query #9 that are characteristic of Nmap being used with the -O option. 4. Segments with XMAS flags set sent to port 1 shown in query #12 that resembles Nmap run with -O. 5. ACK segments sent to port 1 in query #13, which is also characteristic of Nmap. 6. The Nmap's UDP probes found in query #15. 7. The Nmap TCP pings found in query #16. 8. Nmap Echo probes used when -O is enabled found in query #17. 9. It appears as though service version information was obtained with -sV as discovered in query #18. The estimated output from the first scan is below: $ nmap -sT 10.42.42.50, 10.42.42.56, 10.42.42.25 Starting Nmap 5.21 ( http://nmap.org ) at 2010-02-02 18:34:06 Nmap scan report for 10.42.42.56 Host is up. All 1000 scanned ports on 10.42.42.56 are closed MAC Address: 00:26:22:cb:1e:79 (COMPAL INFORMATION (KUNSHAN) CO., LTD.) Nmap scan report for 10.42.42.25 Host is up. All 1000 scanned ports on 10.42.42.25 are closed MAC Address: 00:16:cb:92:6e:dc (Apple Computer) Nmap scan report for 10.42.42.50 Host is up. Not shown: 998 closed ports PORT STATE SERVICE 135/tcp open msrpc 139/tcp open netbios-ssn MAC Address: 70:5a:b6:51:d7:b2 (COMPAL INFORMATION (KUNSHAN) CO., LTD.) Nmap done: 3 IP addresses (3 hosts up) ################## ### Known bugs ### ################## 1. There seems to be a bug in the column output mode in at least SQLite v3.6.22 on Windows 7. Number(s) get omitted at the end of some IP addresses. For example, in the second row in the below output, the 3 is left off of 10.42.42.253. It works fine in other output modes, however. .mode column SELECT smac, saddr FROM ip GROUP BY smac, saddr; smac saddr ------------ ----------- 0016cb926edc 10.42.42.25 00238b821f4a 10.42.42.25 <--- WRONG 002622cb1e79 10.42.42.56 705ab651d7b2 10.42.42.50 .mode list SELECT smac, saddr FROM ip GROUP BY smac, saddr; smac|saddr 0016cb926edc|10.42.42.25 00238b821f4a|10.42.42.253 <--- CORRECT 002622cb1e79|10.42.42.56 705ab651d7b2|10.42.42.50 2. The second problem is more of an issue than a bug. When dealing with larger PCAP files, it may be necessary to switch from SQLite to a more robust database like MySQL due to performance issues.