Attack Chains

Finding attacks in a large amount of snort alerts turned out to be a real challenge. Almost all the events investigated seemed to be a side-effect of some sort of benign (or at least quite harmless) traffic. However, we have one more idea which seems to be interesting to pursue: Assume we are not interested in users in the internal network attacking other users on the inside. This assumption seems legitimate because the deployment of the snort sensor already excludes the monitoring of this type of activity. The chosen deployment of snort only reveals attacks either entering or leaving the internal networks (see also Section 2.4). To identify an attack, we use the following hypothesis: An attacker triggers a snort alert while he tries to break into a machine on the internal network. This alert does not necessarily have to be an attack. It might simply be reconnaissance activity. Recording the time of this inbound attack, we can search the rest of the snort alerts for alerts showing up at a later time originating from the machine that was targeted in the first alert. This method reveals internal machines that were either compromised or an attack response triggered an alert (e.g., id check returned root). We hope to find activity where an external machine attacks an internal one, compromises it and launches some follow-up activity from that machine. A disadvantage of this method is that using the data captures given, this method will not return a great amount of activity. The reasons for that are twofold:

1. An attacker might compromise an internal machine and not use that machine to issue any further attacks; therefore leaving no traces after the initial attack.
2. If an external attacker compromises an internal system and never launches an attack targeting an outside machine the snort logs will not reveal anything.

Despite the limitations of this approach, it seemed worthwhile generating some graphs. Figure 3.3 shows the output of a script we wrote to detect attack-chains[14]. It turns out to be quite difficult to analyze the findings:

• A total of six machines were identified launching attacks against internal machines and then showing up as sources of other snort alerts (red nodes).
• Four machines were targets of the attacks (blue nodes).
• Only a small number of machines were involved in traffic originating from targeted machines (white nodes). We expected to see machines that were first compromised and then started some kind of scanning activity, resulting in more end-points contacted. The expected scanning activity could be anything from nessus or nmap scan to scans for specific cgi scripts on Web servers.
• One chain can be eliminated from the graph in Figure 3.3. It shows a Web request (FRONTPAGE _vti rpc access) followed by a ATTACK-RESPONSES 403 Forbidden. This seems to be normal traffic showing someone uploading a Web page via frontpage and then getting a response back indicating that his privileges did not allow for the action. (This traffic is shown on the lower right of Figure 3.3.)
• The chain of events on the lower left of the graph, which is completely disconnected from the rest, can be removed as well. It shows a DNS zone transfer TCP followed by a P2P Napster Client Data event. The zone transfers are real zone transfer attempts. However, the subsequent P2P message is not related to the zone transfer at all. Therefore we decided to remove these nodes from the investigation as well.
• Some snort alerts triggered by one ``compromised'' machine (32.245.166.236) are quite strange. For example the CGI phf access. The PHF attack is a very old one which exploited a vulnerability in the phf cgi script [2]. This cgi has been removed from Web server distributions for years already. Nessus[6] has a built-in check which checks for the presence of the phf cgi script. This could be an indicator that the machine launched some kind of vulnerability scan against other machines. However, it seems strange that only one machine was targeted with this event. Investigating this event showed that the URL triggering the alert was: www.health.state.ny.us/nysdoh/phforum/jobs/hriload.htm. This turns out to be a false positive. The snort rule is too loose and triggers on all the uricontent:"/phf";.
• The machines 207.68.185.58, 207.68.176.190, 207.68.176.250 resolve to ``msnsearch.com''. This explains all the other events targeting this machine. They are all false positives, triggering on either the HTTP requests or the responses from the search engine.

Figure 3.4 shows a sanitized version of the attack-chain graph, where all the nodes identified to be unimportant or even false positives, were removed.

Figure 3.4: Attack-chain graph with false positives and other unimportant nodes removed.

There are three different initial attack events: SCAN nmap TCP, ISS header field buffer overflow attempt and SHELLCODE x86 setgid 0. All of these events represent quite aggressive attacks and seem to be good indicators for a successful compromise of an internal system. To finish an analysis of all events in Figure 3.4, we need some more information about the topology and the role of the single machines. As an immediate remedial step, we recommend having a look at the two remaining stepping stone machines: ``32.245.166.236'' and ``32.245.166.119''. Especially because it is not the first time that we tripped over them during our analysis.