2015-10-28 - TRAFFIC ANALYSIS EXERCISE - ANSWERS
NOTICE:
- The zip archives on this page have been updated, and they now use the new password scheme. For the new password, see the "about" page of this website.
ASSOCIATED FILES:
- Zip archive containing the pcap: 2015-10-28-traffic-analysis-exercise.pcap.zip 9.7 MB (9,654,231 bytes)
- Zip archive of malware found on the infected host: 2015-10-28-traffic-analysis-exercise-malware.zip 74.7 kB (74,704 bytes)
OTHER PEOPLE'S ANSWERS
Links to write-ups below have answers which are a good supplement to this exercise. As always, I appreciate the effort people making in posting their work on these exercises!
MY ANSWERS
DETAILS
Here are the alerts I got when running the pcap through Security Onion using tcpreplay, with the Gootkit information highlighted:
Our best way to track this? Start by filtering on http.request and finding the exploit kit (EK) traffic near the end of the pcap. Based on the alerts seen in Security Onion, I've highlighted the first HTTP GET request to the EK landing page in the image below:
Follow the TCP stream, and you'll find the referer that led to the EK landing page:
Back to the list of HTTP requests, you'll find the referrer URL a few HTTP requests before the EK landing page. This is the "gate" or "redirect" between the comrpomised website and the EK landing page.
Follow the TCP stream, and that gate shows another referer which is (in this case) the compromised website:
See the HTTP requests and go to that HTTP GET request for the compromised website:
Follow the TCP stream, and you'll see a parameter with the gate URL on the page from the compromised website.
There was other malicious script on the compromised website that generated other suspicious traffic in the pcap. However, none of that is relevant to this particular infection chain of events. Malware.kiwi posted a pretty good flow chart of the other traffic, which you can see here (or read through his entire write-up on it for more context).
I don't include hat extra traffic in the incident report, because it doesn't apply to that incident. Everything else is just noise--more rabbit holes that an analyst could follow, taking up time and effort when there are more important matters to investigate.
That's why I always recommend people work their way backwards when investigating EK traffic. Start with the EK landing page and work your way back to the compromised website.
However, the extra information is useful in another context. For example, the domains and IP addresses for those other .xyz domains are certainly malicious. Analysts could search through traffic, logs, or IDS events to see if any other hosts have experienced similar activity.
FINAL WORDS
As always, thinks for following along. Hope you all found this helpful!
Shown above: Google image search for Midge Figgins.
Click here to return to the main page.