I was awfully saddened to hear there was going to be no HackEire challenge in 2012, as I had always hoped I would get a chance to attend. However, seems the IRISS-CERT guys might be doing something, so that should be fun
Over at boards.ie in the Tech/Security section, the challenges are slowly appearing. So when I saw the “pcap challenge”, I HAD to have a look. Seeing as I am taking Forensic Science and Analysis starting in September, a major change from what I was studying – Biopharmaceutical Chemistry. Well, I hope to be taking it – I applied, and theoretically should get the place as I have more than enough CAO points. Forensic Science both allows me to use my knowledge of chemistry, and other “hard sciences”, but also provides me with opportunities to further study Digital Forensics and such, which has, er, become of GREAT interest to me as I wish to try help prevent online crime, rather than facilitate. ANYWAYS. Enough of that, lets get down to the fun stuff!
***infodox puts on his network forensics hat***
Now, this post is going to be edited a lot as I progress through, and seeing as it is .pcap files I am analysing, I will be starting off by playing with Wireshark and Xplico, though any other tools I use will also be documented.
The pcap_questions.rtf file has “Questions” about each pcap that you must answer, and I will be keeping strictly to their requirements rather than digressing. However if I see anything funny or interesting I will note it.
So, I am going to start with c1.pcap and start with the first question…
“What was the complete URI of the original web request that led to the client being compromised?”
Well, lets see. The easiest way to filter this would be to use urlsnarf, part of Dug Songs dsniff toolkit. This comes as standard with most penetration testing distributions…
After a bit of parsing (using /dev/brain and gedit), I removed all references to legit sites (yes, even all the advertising ones) and found the following suspect URL’s.
10.20.0.165 – – [04/Jun/2012:04:42:04 +0100] “GET http://10.20.0.111:8080/banking.htm HTTP/1.1″ – – “-” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)”
10.20.0.165 – – [04/Jun/2012:04:42:04 +0100] “GET http://10.20.0.111:8080/banking.htm?UOjiXfyAbAISuH HTTP/1.1″ – – “-” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)”
10.20.0.165 – – [04/Jun/2012:04:42:04 +0100] “GET http://10.20.0.111:8080/banking.htmTysdAWdqQEBybyCGKQkGJyVuQsNWvmIFg.gif HTTP/1.1″ – – “http://10.20.0.111:8080/banking.htm?UOjiXfyAbAISuH” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)”
Now I had an IP address, so I opened the .pcap in Wireshark and proceeded to check what the hell was going to and from the “malicious” server.
I used the following filters:
ip.src == 10.20.0.111
ip.dst == 10.20.0.111
I then started peeking through the packet data to see could I find anything interesting…
What was the complete URI of the original web request that led to the client being compromised?
What file type was requested in the final web request to the malicious server? (Answer a, b, c ,d or e)
a. windows executable
> e, a .GIF file
What is the sha1 hash of the afore-mentioned file?
> NOT FOUND YET, HAVE TO EXTRACT… Will look into extracting the file later
What is the number of the first frame that indicates that the client has been compromised?
> 4722 in Wireshark seems to be the SYN packet in the reverse shell
At one point, the malicious server sends a malicious file to the client. What type of file is ? (Answer a, b, c ,d or e)
a. windows executable
> NOT FOUND YET, HAVE TO EXTRACT!
What is the sha1 hash of the malicious file?
> NOT FOUND YET, HAVE TO EXTRACT…
What vulnerable software is exploited (in the following format, ff3.5, ff3.6, ff5, Word2010, ie7, Safari2, Chrome2, AdobeReader, ie6, ff4)?
> FF4 According to User Agent (Mozilla/4.0)
When the capture ends, is the client still connected to the malicious attacker? Answer either “yes” or “no”.
> YES, the connection to port 4444 never has a FIN or RST so I can assume it is still ongoing.
Can you give the corresponding CVE security bulletin that covers the vulnerability here that was exploited (answer in form of CVE-$year-$number).
> NOT FOUND (YET)
From the capture, it is clear that the attacker gets a certain form of access (i.e. the interface), what (type of) access does the attacker “get” on the client?
> Shell access, based on the junk data, an encrypted reverse shell. Based on port data, Meterpreter. Further investigation into the payload used is necessary.
— Post Changelog —
1. The editor broke and pasted the first three paragraphs into the top like a million times. oops…