Nachdem es im ersten Teil dieser Mini-Serie um das Aufsetzen der virtuellen Umgebung für die Analyse von IoT-Malware ging, schauen wir heute auf die eigentliche Analyse. Diese hielt einige interessante Herausforderungen bereit.
Kampf gegen die eigenen Werkzeuge
Eine unerwartete Wendung bei der Untersuchung von AcidRain war, dass es bei der Ausführung der Malware in einer Analyseumgebung nicht die erwarteten Resultate gab. AcidRain startete korrekt, wurde jedoch mitten im Prozess unerwartet gestoppt. Es stellte sich heraus, dass die Qiling-Umgebung eine Feinheit nicht bedacht hatte und einen Bug aufwies. Dieser führte dazu, dass – vereinfach gesagt – die Analyseumgebung die Malware praktisch „abgeschossen“ hatte.
Nachdem dieser Bug behoben war, ergab sich ein neues Problem:
Es gab einen Anfang und ein Ende in den Logdateien – doch dazwischen fehlten eine ganze Menge an Informationen. Hier war die Ursache, dass Qiling mit Hintergrundprozessen nicht richtig umgehen kann, und daher Protokolldateien unvollständig waren. Als die Ursache feststand und beseitigt war, konnte die Analyse von AcidRain weitergehen.
Suchen und Zerstören
Die Kernfunktion von AcidRain ist das Löschen von Daten, die auf den infizierten Geräten gespeichert sind. Da jedoch auf diesen Geräten kein Windows-System läuft, kann AcidRain auch nicht nach Laufwerksbuchstaben suchen, sondern muss die intern verwendeten Gerätenamen finden. Diese tragen Namen wie /dev/sda1 oder /dev/mtd1.
Daten, die sich dort befinden, überschreibt das Schadprogramm so lange, bis der Speicher (zum Beispiel eine SSD oder ein interner Flash-Baustein) voll ist.
Wie das genau funktioniert, welche Stolpersteine es bei der Analyse gab und wie es endlich gelang, AcidRain komplett zu emulieren, steht detailliert im technischen Artikel auf cyber.wtf (Artikel in englischer Sprache, Link öffnet sich in einem neuen Fenster).
