In dieser Challenge (forensics #3) geht es darum, eine schadhafte URL ausfindig zu machen, die für die Infizierung des Zielsystem verantwortlich ist. Gemäß der Aufgabenstellung wurde die URL nach dem 9. Februar 2012 aufgerufen und die Spuren des Aufrufs möglicherweise nach der Infizierung gelöscht.

Das Entpacken der Datei liefert uns wieder ein Benutzerverzeichnis eines Windows-Systems. Es handelt sich erneut um die Daten, des uns bereits bekannten Benutzers “proneer”. Diesmal ist jedoch nicht das komplette “Users”-Verzeichnis enthalten, sondern nur die “Cookies”-Datei des Google Chrome Browsers.

rup0rt@lambda:~/forensic3$ file Cookies
Cookies: SQLite 3.x database

Eine erste Analyse der Datei zeigt uns, dass Google Chrome seine Cookies anscheinend in einer SQLite-Datenbank hinterlegt. Um diese Datei zu betrachten zu können und die darin enthaltenen Cookies auszulesen, verwenden wir das Werkzeug sqlitebrowser und erhalten eine Übersicht der insgesamt 109 gespeicherten Cookies.

Dennoch lässt auch das wiederholte, intensive Untersuchen der Cookie-Einträge keinen Hinweis oder Rückschluss auf eine schadhafte URL zu. Scheinbar hat uns der Aufgabensteller doch nicht belogen 😉 und die Daten scheinen tatsächlich gelöscht worden zu sein. Doch was nun? Die Google-Suche nach “gelöschten SQLite-Daten” führt uns zur SQLite-FAQ, wo folgende Information zu finden ist:

In der SQLite-Datenbank-Datei könnten die gelöschten und von uns gesuchten Daten also noch irgendwo zu finden sein! Anscheinend kommen wir jedoch nicht drum herum uns die Daten “per Hand” anzusehen. Beginnen wir also zunächst mit dem Sichten der lesbaren Zeichen durch das Werkzeug “strings”.

rup0rt@lambda:~/forensic3$ strings Cookies
SQLite format 3
]indexdomaincookies
[...]
8.test.wargame.kr
9!y(
.test.wargame.kr
9!y(
[...]

Hier stoßen wir unter anderem auf eine URL, die uns vorher beim Durchsuchen der SQLite-Datenbank nicht aufgefallen ist. Er erneuter Blick in den “sqlitebrowser” bestätigt, dass diese URL nicht enthalten ist. Es scheint sich also um einen gelöschten Cookie zu handeln. Auch die Benennung “test.wargame.kr” hebt sich von den anderen “normalen” URLs ab. Wir gehen also an dieser Stelle davon aus, dass wir die schadhafte URL gefunden haben.

Die Challenge verlangt die Lösung im Format “malicious_URL|YYYY-MM-DDThh:mm:ss”, was bedeutet, dass wir außerdem das Datum und die Uhrzeit in Erfahrung bringen müssen, zu der das System infiziert wurde. Sehen wir uns also die Informationen aus der SQLite-Datenbank noch etwas genauer an.

rup0rt@lambda:~/forensic3$ strings Cookies | grep wargame
8.test.wargame.kr
.test.wargame.kr
.test.wargame.kr__utmz134301300.1328799447.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)/
.test.wargame.kr__utma134301300.282793704.1328799447.1328799457.1328799457.10/

Hier fallen direkt die vorhanden Zeitstempel sowie die Cookies “__utmz” und “__utma” auf. Diese Cookies stammen von den Google Analytics und dienen dazu, die Seitenbesuche von Benutzern zu verfolgen. Im Detail speichert …
– UTMZ, woher ein Besucher auf die Seite kam (Suchmaschine, Link, Suchwort, …)
– UTMA, die Anzahl der Besuche sowie die Zeiten der erste, letzte und aktuelle Besuche

Uns interessiert die Uhrzeit des ersten Seitenaufrufes, also zerlegen wir den “__utma”-Cookie. Dieser besteht aus sechs durch Punkte getrennte Werte:
#1  134301300   == Domain Hash (ID der Webseite)
#2  282793704   == Visitor ID (einzigartige Benutzer-Identifikationsnummer)
#3  1328799447 == Initial visit (Zeitstempel des ersten Besuches)
#4  1328799457 == Previous Session (Zeitstempel des letzten Besuches)
#5  1328799457 == Current Session (Zeitstempel des derzeitigen Besuches)
#6  10                 == Session number (Anzahl der Besuche auf der Webseite)

Da das System höchst wahrscheinlich bereits beim ersten Seitenaufruf infiziert wurde, entnehmen wir dem “__utma”-Cookie den Wert des “Initial visit”. Als nächstes rechnen wir dessen Wert “1328799447” in das geforderte Datumsformat um.

rup0rt@lambda:~/forensic3$ date -u -d @1328799447 +%Y-%m-%dT%H:%M:%S
2012-02-09T14:57:27

Dieses Datum ist in UTC+0 angegeben. Wir benötigen jedoch UTC+9, was “2012-02-09T23:57:27” entspricht. Jetzt haben wir alle Daten zusammen um den Lösungsstring zu erstellen.

Die Antwort lautet also: “test.wargame.kr|2012-02-09T23:57:27″.