Hints given to us:
IU is investigating the system which was contaminated by malicious code.
As a result of analyzing TimeLine, it seems to be contaminated after February 9th 2012.
Contaminating path would be from visiting Web page. IU analyses various user traces of Internet, however IU can't find malicious URL.
Maybe traces would be removed, when it was contaminated. Find correct malicious URL and the time it was contaminated. (cf. Remove http(s)://)
The time is based on Korea Standard Time(UTC +09:00).
Answer: malicious_URL|YYYY-MM-DDThh:mm:ss
('|' is just a character)
Download : 05D659000025F95CD07B2B36E94B0C15
This is a mirror of the original file:
05D659000025F95CD07B2B36E94B0C15.zip
Recommended Tools:
SQLite Browser (sqlitebrowser.sourceforge.net/)
DCode (http://www.digital-detective.co.uk/freetools/decode.asp)
Any hex viewer / editor or even notepad++
Analysing the File:
When 1 first analyse the file, the returned output from TRiD say it's a 7-zip file. I quickly extracted out the contents. I found out that it's a "cookie" file located deep at \Users\proneer\AppData\Local\Google\Chrome\User Data\Default
This probably mean that it's a SQLite file. Reading the hints given to us and given that it's a SQLite file. With information from the SQLite website, http://sqlite.org/faq.html#q20
It seems that a record can be deleted from the database. It's just that it is not viewable with normal sqlite tools.
So how do we find that data and how do we distinguish it from the non-deleted data? When you delete a record, the space allocated to the record gets added to a free-list.
In other words, the size of the database doesn't get any smaller with record removal, but the space is marked as available for future records.
According to the FAQ in SQLite website, "If SQLITE_SECURE_DELETE is not used and VACUUM has not been run, then some of the deleted content might still be in the database file, in areas marked for reuse."
So attackers, please run vacuum if you really want to delete your entry. :P
Ok, let's open the file in notepad++. Since the objective is to find the malicious url, let's do a quick search on .net .com .org .kr and compare it with all the entries found with SQLite browser.
Once we did that, we did found an extra entry as indicated in the image below, test.wargame.krutma134301300.282793704.1328799447.1328799457.1328799457.10 , that was not found with SQLite browser.
Solving the Puzzle:
But how do we know what is the time? Ok, according to http://www.randycullom.com/chatterbox/archives/2008/10/google_analytic.html
The 3rd set of numbers after utma is the timestamp of the first visit/session for the user.
Using Dcode with 1328799447, we got back Thu, 09 February 2012 23:57:27. +0900 as shown in the image below.
So using all the information that we have gathered thus far, The correct key that for Forensics 300 is : test.wargame.kr|2012-02-09T23:57:27
cheers
0x4a61636f62
No comments:
Post a Comment