Es wurde viel über die Angriffe des RTM-Bankentrojaners auf Buchhalter und Finanzdirektoren, einschließlich Group-IB-
Experten , geschrieben, aber bisher gab es keine einzige Fallstudie zu Geräten, die im öffentlichen Bereich mit RTM infiziert waren. Um diese Ungerechtigkeit zu korrigieren,
sprach Oleg Skulkin , einer der führenden Experten der Gruppe IB für Computerforensik, ausführlich darüber, wie eine forensische Untersuchung eines mit einem Bankentrojaner infizierten Computers im Rahmen einer Reaktion / Untersuchung auf einen Vorfall durchgeführt werden kann.
Wie alles begann
Die Forscher erfuhren im Dezember 2015 von den Aktivitäten der RTM-Kriminalgruppe. Seitdem wurden Phishing-Mailings, die diesen Trojaner verteilen, mit beneidenswerter Beständigkeit an die elektronischen Postfächer potenzieller Opfer gesendet.
Wie Sie bereits wissen, hat die RTM-Gruppe von September bis Dezember mehr als 11.000 böswillige E-Mails verschickt. Cyberkriminelle werden nicht bei dem stehen bleiben, was erreicht wurde, wie all die neuen Mailings belegen, die wir sowohl auf Sensoren zum Schutz unserer Kunden als auch im Rahmen der Datenerfassung über aktuelle Bedrohungen aufzeichnen.
In diesem Artikel werde ich Ihnen erklären, wie Sie eine forensische Untersuchung oder einfach eine forensische Untersuchung des Images eines Computerlaufwerks durchführen, das mit einem Banking-Trojaner RTM infiziert ist.
Notwendige Einführung
Stellen Sie sich vor, wir wissen nichts über die Infektion des RTM-Computers, sondern nur über die Tatsache eines Kompromisses, dessen Ergebnis der Diebstahl von Geld war. Auf diese Weise können wir den Forschungsprozess interessanter gestalten und ihn auch auf andere Fälle anwenden. Ich möchte auch darauf hinweisen, dass ich im Rahmen dieses Artikels nicht auf das Reverse Engineering des Trojaners eingehen werde: Erstens ist dies nicht die Kompetenz des Forensikers, und zweitens hat mein Kollege Semyon Rogachev ausführlich über
Habré geschrieben .
Wir haben also nur das Image des Computerlaufwerks im Format „E01“ (Encase Image File Format). Zunächst wäre es schön herauszufinden, was drin ist. Zumindest das Betriebssystem, da es von ihm und seiner Version stammt, hängt natürlich vom Vorhandensein bestimmter forensischer Artefakte ab, die wir untersuchen müssen.
1. Wir verwenden das Dienstprogramm mmls aus der Packung des Sleuth-Kits von Brian Carrier:
Was haben wir Mehrere NTFS-Partitionen ähnlich wie Windows. Wir müssen sicherstellen, dass wir versuchen, Registrierungsdateien zu finden, zum Beispiel SOFTWARE.
2. Wir werden die Dienstprogramme fls (das Sleuth Kit) und findstr verwenden, um die entsprechende Datensatznummer in der Hauptdateitabelle (MFT) herauszufinden:
Ok, jetzt können wir die Datei, die wir für die weitere Analyse benötigen, mit icat (dem Sleuth Kit) kopieren:
icat -o 718848 E: \ RTM.E01 234782> SOFTWARE
Wenn wir also eine SOFTWARE-Registrierungsdatei haben, können wir die wichtigsten Informationen extrahieren, aus denen wir beispielsweise RegRipper Harlan Carvey verwenden. Wir interessieren uns derzeit für den Inhalt des Abschnitts Microsoft \ Windows NT \ CurrentVersion:
Jetzt wissen wir, dass auf dem untersuchten Computer Windows 7 Professional mit Service Pack SP1 ausgeführt wurde. Dies bedeutet, dass wir wissen, auf welche forensischen Artefakte wir stoßen und welche wir möglicherweise benötigen.
Wo soll ich mit unserer Suche beginnen? Erinnern Sie sich an das Paradoxon von Jesse Kornblum: "Malware kann sich verstecken, aber sie muss laufen." Ein guter Anfang kann die Suche nach potenziellen Sperrmechanismen im System sein, die es bösartigen Programmen ermöglichen, nach einem Neustart des Computers neu zu starten.
Beginnen wir mit einem einfachen: Nehmen Sie die Registrierungsdatei
NTUSER.DAT aus dem Benutzerverzeichnis (C: \ Benutzer \% Benutzername% \) mit dem letzten Änderungsdatum und extrahieren Sie die Daten mit demselben RegRipper daraus. Wenn wir die Datensatznummer der benötigten Datei mit fls und findstr erneut abrufen möchten, müssen wir fls die Option –p hinzufügen. Dadurch kann das Dienstprogramm die vollständigen Pfade zu den Dateien anzeigen. Warum wird das benötigt? Tatsache ist, dass jeder Benutzer eine NTUSER.DAT-Datei im Verzeichnis hat und SOFTWARE die einzige für das gesamte System ist. In diesem Fall ist es daher wichtig, die Datensatznummer einer bestimmten Datei abzurufen. Im Allgemeinen ist die Verwendung des Sleuth-Kits überhaupt nicht erforderlich. Es gibt bequemere Tools, z. B.
FTK Imager , ein kostenloses AccessData-Entwicklungstool, mit dem nicht nur forensische Kopien erstellt, sondern auch deren Inhalt überprüft werden können:
Beginnen wir mit den tief hängenden Früchten, den sogenannten
„Run Keys“ :
Was haben wir also? Der Abschnitt wurde zuletzt am 7. November geändert. Wenn sich der Benutzer anmeldet, wird die Datei apg.exe von einem nicht standardmäßigen Speicherort aus gestartet. Mal sehen, was noch im Verzeichnis b7mg81 zu finden ist:
TeamViewer? Interessant. Schauen wir uns apg.exe genauer an - verwenden Sie
PPEE :
Sieht aus wie TeamViewer, der als TeamViewer angemeldet ist. Ist es also TeamViewer? Es scheint so. Aber es ist nicht so einfach. Schauen wir uns die Importtabelle an:
Also, msi.dll, irgendwo haben wir diese Datei bereits gesehen und es ist nicht C: \ Windows \ System32, sondern dasselbe b7mg81-Verzeichnis. Gemessen an der Größe hat dies nichts mit der ursprünglichen msi.dll zu tun, was bedeutet, dass sie verfügbar ist -
Hijacking der
DLL- Suchreihenfolge: Das Betriebssystem beginnt mit der Suche nach den erforderlichen Bibliotheken aus dem aktuellen Verzeichnis, was bedeutet, dass anstelle der legitimen msi.dll diejenige geladen wird, die sich befindet in b7mg81.
Eine weitere interessante Datei ist
TeamViewer.ini :
Und hier ist die Gegenforensik: Gemessen an der Konfigurationsdatei hat unser TeamViewer keine Protokolle geführt und wurde anscheinend als RAT verwendet. Nicht schlecht. Es ist Zeit herauszufinden, ob es überhaupt angefangen hat.
Unter Windows gibt es einige Artefakte, die darauf hinweisen, dass ausführbare Dateien ausgeführt werden. Lassen Sie uns weiter mit der Registrierung arbeiten, diesmal mit der
SYSTEM-Datei . Um Daten daraus zu extrahieren, können Sie RegRipper erneut verwenden.
Wir interessieren uns für ControlSet001 \ Control \ Session Manager \ AppCompatCache. Hier finden Sie eine Liste der ausführbaren Dateien mit Pfaden zu ihnen, Datum der letzten Änderung (gemäß dem Attribut $ STANDARD_INFORMATION) sowie ein Flag, das angibt, ob die Datei gestartet wurde oder nicht:
Großartig, unsere Datei wurde mindestens einmal gestartet. Wir haben also einen „Dreh- und Angelpunkt“. Wir wissen, dass TeamViewer am 7. November auf dem Laufwerk des Computers angezeigt wurde, auf dem keine Protokolle geführt wurden, und höchstwahrscheinlich für den Benutzer nicht sichtbar war, da anstelle der legitimen Bibliothek diejenige geladen wurde, die sich in einer befindet Katalog.
Es ist Zeit, eine Zeitleiste zu erstellen. Ich denke, das ist genug von dem, was mit dem Sleuth Kit gebaut werden kann. Beginnen wir mit dem bereits bekannten Dienstprogramm fls:
fls.exe -m "C: /" -o 718848 -r -z GMT D: \ RTM.E01> bodyfile.txt
Verwenden Sie nun mactime, um die resultierende Datei in eine Zeitleiste zu konvertieren:
mactime.pl -d -b bodyfile.txt> timeline.csv
Zeitleisten lassen sich sehr bequem im
Zeitleisten-Explorer von Eric Zimmerman analysieren. Unsere Zeitleiste enthält nur Dateisystemereignisse. Wenn Sie möchten, dass Änderungen in der Registrierung, in Zeitschriften usw. enthalten sind, können Sie plaso verwenden. Persönlich benutze ich es extrem selten, da die Datenverarbeitung sehr lange dauert und das Ergebnis oft ziemlich redundant ist.
Zurück zur Zeitleiste. Der Katalog b7mg81 wurde am 7. November 2018 um 13:59:37 erstellt:
Und zwei Sekunden zuvor wird die Datei 21DA.tmp erstellt:
Wenn Sie beispielsweise bei VirusTotal nach der Prüfsumme suchen, erhalten Sie interessante Ergebnisse:
Offensichtlich wurde unsere RAT aus dieser Datei entpackt. Gehen Sie voran:
Noch früher wurde das LocalDataNT-Verzeichnis mit sehr interessanten Dateien erstellt. Schauen Sie sich zum Beispiel WinPrintSvc.exe an:
Remote Utilities ist ein weiteres Remoteverwaltungstool. Und hier ist eine weitere verdächtige Datei, die einige Sekunden zuvor erstellt wurde:
Überprüfen Sie die Prüfsumme:
Mehrere Antivirenprodukte erkennen es sofort als "
RemoteAdmin ". Anscheinend ist er die Quelle von Remote Utilities. Überprüfen Sie, ob die erkannte RAT gestartet wurde. Dieses Mal verwenden wir die Registrierungsdatei AmCache.hve aus C: \ Windows \ AppCompat \ Programs (mit demselben RegRipper können wir Daten in verdaulicher Form abrufen):
Wie Sie in der Abbildung sehen können, können wir mit AmCache nicht nur das Datum des ersten Starts, sondern auch die Prüfsumme der Datei abrufen.
Wir haben also zwei RATs, aber woher kommen sie? Gute Frage! Wenn Sie immer noch durch die Zeitleiste scrollen, werden Spuren der Erstellung eines ziemlich verdächtigen Verzeichnisses und einer verdächtigen Datei angezeigt:
Trotz der seltsamen Erweiterung hat fnbfdnja.hej eine vertraute Überschrift:
Was zeigt uns die VirusTotal-Prüfsummensuche? Und hier ist was:
Wie Sie in der Abbildung sehen können, erkennt eine Antivirensoftware unsere Datei definitiv - wir haben es mit
RTM zu tun. VT kann uns noch mehr helfen. Wenn wir uns die Registerkarte "Beziehungen" ansehen, sehen wir Folgendes:
Es scheint, dass wir den Helden des Anlasses gefunden haben - dies ist "Documents for October.exe". Oder vielleicht auch nicht, der mit unserer Datei verknüpfte Name ist unterschiedlich, obwohl die Prüfsumme dieselbe ist. Also noch einmal .exe, was bedeutet, dass wir wieder nach Spuren des Starts suchen müssen. Persönlich arbeite ich sehr gerne mit der Registrierung, daher werde ich wieder die Hilfe der bereits bekannten Dateien NTUSER.DAT und RegRipper verwenden.
Schauen Sie sich diesmal
UserAssist an - daraus erhalten wir die Namen und Pfade zu den Dateien, die Daten ihres letzten Starts sowie die Anzahl dieser Starts. Die Datei "Dokumente für October.exe" ist nicht sichtbar, aber eine andere Datei ist sichtbar:
C: \ Benutzer \% Benutzername% \ Desktop \ Documents environment.exe
Nun, das scheint das zu sein, was wir brauchen. Es stimmt, es gibt ein kleines Problem - es ist keine Datei am richtigen Ort. Zurück zur Zeitleiste. Nach dem Erstellen der Datei fnbfdnja.hej geschieht Folgendes:
Dateien im Temp-Verzeichnis gehören wahrscheinlich zu RTM, aber wir sind nicht an ihnen interessiert. Wir interessieren uns für die Dateien $ R6K21RQ.exe und $ I6K21RQ.exe. Genau so sehen die Dateien im "Papierkorb" aus - die erste enthält die Daten selbst, die zweite enthält die Metadaten. Wenn wir uns den Inhalt von $ I6K21RQ.exe ansehen, sehen wir sofort den Pfad zur gewünschten Datei - "Documents environment.exe".
Es ist Zeit, einen Blick darauf zu werfen, was VT uns für seine Prüfsumme bietet:
Wir sehen bereits bekannte Erkennungen - „RTM“. Wie sich herausstellte, stimmte die Prüfsumme unserer Datei mit der Prüfsumme „Dokumente für October.exe“ überein. Darüber hinaus kennt VT einige weitere Dateien mit derselben Prüfsumme:
Es wäre schön, eine Art Netzwerkindikator für Kompromisse zu erhalten. Wir haben keinen Speicherauszug, auch keinen Netzwerkverkehrsauszug. Was soll ich tun? Datei tauschen! Aber wie findet man eine Nadel im Heuhaufen? Und auch hier hilft uns VT ein wenig, diesmal auf
der Registerkarte
Verhalten :
Klingt nach C2, oder? Mal sehen, ob es so etwas in unserer Auslagerungsdatei (pagefile.sys) gibt. Natürlich gibt es:
Wir haben also bestätigt, dass unsere Datei mit 185.141.61 [.] 246 interagiert. Versuchen wir, weitere Netzwerkindikatoren zu finden. Eine der RATs war TeamViewer. Wir werden versuchen, etwas zu finden, das der ID ähnelt. Hierfür können Sie beispielsweise reguläre Ausdrücke verwenden:
Großartig, wir haben einen weiteren Netzwerkindikator - 195.123.219 [.] 87. Swap-Dateien eignen sich natürlich nicht nur zum Auffinden von Netzwerkindikatoren. Wenn wir in VT zur Registerkarte Verhalten zurückkehren, sehen wir, dass unsere Datei Aufgaben im Scheduler erstellt. Wenn wir uns die Zeile „fnbfdnja.hej“ ansehen, finden wir Folgendes:
Die erstellte Aufgabe startet fnbfdnja.hej über rundll32.exe.
Nun, es ist Zeit abzurunden. Es ist Zeit festzustellen, woher die Datei "Documents environment.exe" stammt. Wir wissen bereits, dass dies RTM ist, und da es sich um RTM handelt, ist der wahrscheinlichste Infektionsvektor eine Phishing-E-Mail. In diesem Fall verwendete das Opfer Microsoft Outlook, sodass wir die OST-Datei mit E-Mail an der üblichen Stelle und darin dieselbe Phishing-E-Mail fanden:
Ich möchte unseren Beitrag jedoch nicht zu diesem Thema beenden, sondern zu einem anderen interessanten Artefakt. Wenn wir zur Datei NTUSER.DAT zurückkehren und den Wert des Parameters "Shell" im Abschnitt "Software \ Microsoft \ Windows NT \ CurrentVersion \ Winlogon" überprüfen, wird anstelle der üblichen Datei "explorer.exe" Folgendes angezeigt:
Dies bedeutet, dass das System heruntergefahren wird, nachdem sich der Benutzer angemeldet hat, anstatt den Explorer zu starten, und damit der Abschluss dieses Artikels.