Information, tools and how-to's for the new intrusion analyst. Mentoring by blogging.

Monday, February 24, 2014

SPI View in Moloch

The Moloch packet capture and analysis tool (https://github.com/aol/moloch) has an SPI view tab with expandable views of the data it's indexed in Elastic Search. The categories are: General, HTTP, DNS, IRC, Certificates, SSH, Socks, Email and SMB. After doing a search in the Sessions tab, when you click on SPI View (or SPI Graph or Connections) the tab is populated initially with your search query. Making use of index fields in these categories can cut down significantly on your analysis time.

For example, many times you'll need to look at multiple sessions from a source that has launched various attacks on an external host. After searching for the IP of the attacker, you could expand each connection in the Sessions tab to view the response of the server under attack, and this is much faster using Moloch than pulling packets from your pcaps manually. However, there's a quicker way to see an overview of all of the attacks that might mitigate the need to view each connection individually using SPI View.

Example:

We have a large number of alerts from an external host trying a number of different exploits on a server or servers. Our IDS is showing us alerts from the HI_CLIENT_WEBROOT_DIR rule, all ending with either a directory traversal attempt to enumerate /etc/passwd/ or do a file inclusion exploit involving http://www.google.com/humans.txt to see if remote file inclusion is possible. From the SPI VIEW tab we can enable the URI field under the HTTP category and display the captured URI of all packets from the attacker. We know the servers being targeted are Windows based, so we can disregard the directory traversal attempts to /etc/passwd, and we can look at one connection and see that the remote file inclusion attempt results in an 301 Moved Permanently status code. Now looking at all the URI's we can see all attacks were of the same type, and therefore not successful, without looking at each individual session.

Our other alternative would have been to check one of each type of attack and review them all en masse as unsuccessful. But without this extra step of analysis and due diligence, we might have missed an different type of attack buried in the noise (this particular session registered over 1,400 connections in Moloch). Some attackers will use a large, noisy flooding of attacks they know will not succeed to attempt to obfuscate one targeted attack that has a high probability of success, hoping the analyst will either be overwhelmed by the number of alerts or just investigate a few and discard the rest. This can result in missing the singular exploit attempt. Having an intelligent packet capture and analysis tool like Moloch helps mitigate this method