Im März 2014 veröffentlichte die französische Zeitung Le Monde einen Bericht darüber, dass das Communications Security Establishment Canada (CSEC) Frankreich verdächtige, für Spionage-Zwecke schädliche Software zu entwickeln. Der Bericht basierte auf einer Präsentation, die im Zuge der NSA-Affäre um Edward Snowden offengelegt wurde. Im Januar dieses Jahres veröffentlichte der Spiegel die Folien.

Laut der CSEC-Präsentation wurde die fragliche Schadsoftware von ihren Entwicklern „Babar“ getauft – vermutlich angelehnt an die bekannte französische Zeichentrickfigur „Babar der Elefant“. Seitdem hat sich eine Vielzahl an Malware-Forschern daran gemacht, das Rätsel von Babar zu lösen. Eine der ersten war Marion Marschalek (Cyphort) mit ihrem Bericht über die Malware namens „Bunny“. Bunny weist einige Ähnlichkeiten zu der von CSEC beschriebenen Babar-Malware auf. Mitte Februar veröffentlichte Marion dann einen weiteren Bericht – diesmal über Babar selbst –, in dem sie ausführlich die Spionage-Funktionen der Malware beschrieb. Zur gleichen Zeit befasste sich Paul Rascagnères (G Data) in einem Blog Post mit den Gemeinsamkeiten zwischen Babar und Bunny und kam zu dem Schluss, dass die untersuchten Samples aller Wahrscheinlichkeit nach mit der in den CSEC-Folien beschrieben Malware verwandt sind.

In diesem Artikel geht es um eine weitere Schadsoftware, von der wir glauben, dass sie von den gleichen Entwicklern hergestellt wurde wie Babar und Bunny. Diese Komponente wird von ihren Autoren „Casper“ genannt – vermutlich ebenfalls nach einer bekannten Zeichentrickfigur.

Im April 2014 griff Casper syrische Nutzer an, was die Malware zu der bislang neuesten Variante der bekannten Cartoon-Gruppe macht. Für den Angriff nutzten Caspers Entwickler Zero Day Exploits in Adobe Flash, die – überraschenderweise – auf einer syrischen Regierungswebseite gehostet wurden. Bei Casper handelt es sich um ein hochentwickeltes Aufklärungs-Tool, das sehr darum bemüht ist, auf der angegriffenen Maschine unentdeckt zu bleiben. Besonders interessant sind die Strategien, die speziell gegen Antiviren-Programme angewendet werden.

Kontext

Mitte April 2014 beobachtete Vyacheslav Zakorzhevsky (Kaspersky), dass die Webseite jpic.gov.sy zwei Zero Day Exploits für Flash hostete, die es auf eine Schwachstelle abgesehen hatten, die später CVE-2014-0515 benannt wurde. Die entsprechende Webseite wurde 2011 vom Syrischen Justizministerium aufgesetzt, um Syrischen Bürgern die Möglichkeit zu geben, um nach einer Entschädigung für Schäden zu fragen, die durch den Bürgerkrieg verursacht wurden. Die Webseite ist noch immer online und scheint zurzeit sauber zu sein, obwohl sie im September 2014 von einigen „Hacktivisten“ angegriffen worden war.

Während der Vorfälle war es Zakorzhevsky nicht möglich, die Payloads abzurufen, die von diesen Exploits verbreitet wurden. Dank der Erkennungstechnologie ESET LiveGrid® waren unsere ESET-Researcher in der Lage, zwei der Payloads zu finden. Die URLs und die Daten bezüglich des Zeitraums, in dem sie gesehen wurden, stimmten mit Zakorzhevskys Beschreibungen überein.

In gemeinsamer Anstrengung mit Marion Marschalek, Paul Rascagnères und Researchern vom Computer Incident Response Center Luxembourg (CIRCL) konnten wir vor kurzem schließlich bestimmen, dass die verbreiteten Payloads mit hoher Wahrscheinlichkeit von den Akteuren entwickelt wurden, die auch für Babar und Bunny verantwortlich sind.

Analyse von Caspers Binärprogrammen

Die beiden Samples, die wir gefunden haben, bestehen aus dem gleichen Kernprogramm, sind allerdings unterschiedlich verpackt. Beim ersten Sample handelt es sich um eine ausführbare Datei, die das Kernprogramm ablegt und dafür sorgt, dass es sich dauerhaft auf der Maschine einnistet. Das zweite Sample ist eine Windows-Bibliothek, die das Kernprogramm direkt in den Arbeitsspeicher ablegt – ebenfalls in Form einer Bibliothek. Deren Name haben die Malware-Entwickler sichtbar gelassen: „Casper_DLL.dll“.

In diesem Artikel werden wir uns auf die erste der beiden Payloads konzentrieren, da sich sie zweite in ihrem Verhalten nicht unterscheidet.

Dropper

Der Dropper heißt „domcommon.exe“. Das Datum der Kompilation ist auf den 18. Juni 2010 gesetzt. Wie wir später erklären werden, gehen wir davon aus, dass es sich hierbei um ein gefälschtes Datum handelt.

Seine Ausführung basiert auf einer XML-Konfigurationsdatei, die zur Laufzeit mit dem RC4-Algorithmus und einem hartkodierten 16-Byte-Schlüssel entschlüsselt wird. Vor der Entschlüsselung wird mit einer Prüfsumme kontrolliert, ob der Schlüssel unverändert im Speicher vorliegt. Abbildung 1 zeigt die entschlüsselte Konfigurationsdatei des Droppers.

Casper spielt Schach gegen Antiviren-Software

Zuerst extrahiert der Dropper den <STRATEGY>-Tag von seiner Konfigurationsdatei. Dieser Tag definiert, wie sich die Malware abhängig von der auf der Maschine genutzten Antiviren-Software verhalten soll.

Wahl der Strategie

Zuerst fragt der Dropper die Namen von Antiviren-Programmen ab, die sich auf der Maschine befinden könnten. Dazu führt er die Windows Management Instrumentation (WMI) Abfrage „SELECT * FROM AntiVirusProduct“ aus und fängt vom Ergebnis das Feld „displayName“ ab. Existiert in der Konfigurationsdatei ein <AV>-Tag mit einem „NAME“-Attribut, das dem Namen eines installierten Antiviren-Produkts entspricht, wird die entsprechende Ausführungsstrategie festgelegt. In diesem Fall gibt es für vier Antiviren-Programme eine definierte Strategie.

Wenn für die installierte Antiviren-Software keine passende Strategie gefunden wird oder auf dem Rechner keine Schutzsoftware läuft, wird die Standardstrategie verwendet, die in den Attributen des <STRATEGY>-Tags beschrieben wird. Alternativ wird die Strategie der Konfigurationsdatei überschrieben, wenn im Ordner des Droppers eine Datei namens „strategy.xml“ vorhanden ist.

Mögliche Schritte

Eine Strategie ist eine Reihe an Attributen, die sowohl die Ausführung des Droppers als auch die der Payload beeinflussen. Manche dieser Attribute definieren, wie bestimmte Aktionen durchgeführt werden, andere, ob eine Aktion ausgeführt wird. Die folgende Tabelle beschreibt die verschiedenen Aktionen, die von den Attributen angeboten werden.

Die verschiedenen Möglichkeiten, die durch den <STRATEGY>-Tag beschrieben werden, legen nahe, dass Caspers Autoren tiefgehende Kenntnisse über die verhaltensbasierten Erkennungstechnologien bestimmter Antiviren-Produkte haben.

So wird der Code nur in einen neuen Prozess injiziert, wenn auf dem Rechner keine der vier definierten Antiviren-Programme existiert. In diesen Fällten ist das das „INJECTION“-Attribut auf „NO“ gesetzt. Interessanterweise ist das „ESCAPE“-Attribut bei drei Antiviren-Programmen auf „YES“ gesetzt. Läuft auf der Maschine eines dieser Produkte, wird sich der Dropper also selbstständig entfernen, ohne Caspers Payload einzusetzen.

Weil die Liste der <AV>-Tags ziemlich kurz ist, gehen wir davon aus, dass es sich hierbei um die Antiviren-Produkte handelt, die die Casper-Autoren auf den anvisierten Zielen vorzufinden glauben. Nur am Rande: Das Attribut „VERSION“, das in einem der <AV>-Tags vorhanden ist, wird zwar zu keiner Zeit im Code genutzt, weist aber dennoch auf die Absicht hin, verschiedene Produktversionen zu unterscheiden. Ein solches Maß an Präzision im Umgang mit Antiviren-Software sehen wir nur selten.

Zeit, die Payload abzulegen

Ist das „ESCAPE“-Attribut in der ausgewählten Strategie auf „NO“ gesetzt – wie es bei der Standardstrategie der Falls ist – wird der Dropper die Befehle ausführen, die in der Konfigurationsdatei in Form von XML-Tags bereitgestellt sind:

Vorherige Versionen deinstallieren

Der erste Befehl instruiert den Dropper, andere Casper-Instanzen zu entfernen, die sich möglicherweise auf dem System befinden. Der entsprechende <UNINSTALL>-Tag beinhaltet ein „name“-Attribut, welches als Identifier genutzt wird. Um diesen Identifier zu tarnen und aufmerksame Nutzer von weiteren Untersuchungen abzulenken, werden vertrauenswürdige BIOS-Informationen (Intel, NEC…) aus der Windows-Registry als Präfix genutzt.

Das Programm wird in zwei Schritten deinstalliert, wobei sich beide Schritte auf die verschiedenen Methoden bezüglich der Persistenz von Casper beziehen:

• Wenn er existiert, wird der geplante Task, dessen Name mit dem des Identifiers übereinstimmt, vom System entfernt
• Wenn ein passender Registry-Eintrag existiert, werden die Anwendung und der Eintrag vom System entfernt

Installation der Payload

Die Installation der Payload wird dann durch den <INSTALL>-Tag ausgeführt, welcher zwei Payload-Versionen bietet – eine für 32-Bit- (<x86>) und eine für 64-Bit-Systeme (<x64>).

Die Attribute des <INSTALL>-Tags werden dann von einer der beiden vorher erwähnten Installationsmethoden verwendet. Wenn auf der Maschine Windows 7 oder eine neuere Windows-Version vorhanden ist, wird die Persistenz über einen geplanten Task fixiert. Andernfalls wird sie durch den folgenden Windows Registry Key gesetzt:

„HKLM\Software\Microsoft\Windows\CurrentVersion\Run“

Der <INSTALL>-Tag stellt einen Parameter bereit, der an die Payload weitergegeben wird. Der Wert des Parameters ist entscheidend für die „richtige“ Ausführung der Payload. Die eigentliche Überprüfung in der Payload ist interessant gelöst: Der Parameter wird in einem speziellen Algorithmus genutzt, um Bibliotheks-Funktionen im Arbeitsspeicher zu finden. Ist der Wert falsch, werden auch die Adressen dieser Bibliotheks-Funktionen nicht richtig sein, was zu einem zufällig aussehenden Absturz der Payload führt.

Dropper säubert sich selbst

Vor dem Ende seiner Ausführung entfernt sich der Dropper selbstständig vom System. Dafür nutzt er die Methode, die im „AUTODEL“-Attribut definiert ist. Es sei darauf hingewiesen, dass die Payload zu diesem Zeitpunkt noch nicht gestartet wurde: Aufgrund der oben beschriebenen Persistenz-Methode wird sie erst beim nächsten Neustart ausgeführt.

Payload

Wie auch der Dropper basiert die Ausführung von Caspers Payload auf einer XML-Konfigurationsdatei, die zur Laufzeit entschlüsselt wird:

Diese Konfigurationsdatei beginnt mit einem Zeitstempel: Montag, der 7. April 2014, 21:27:05 GMT. Deshalb gehen wir davon aus, dass das Erstellungsdatum – auf 2010 gesetzt – gefälscht wurde.

Eine Reihe an <PARAM>-Tags bestimmen dann das Verhalten der Payload, wie in der folgenden Tabelle zu sehen ist.

Die Payload generiert dann einen einzigartigen Identifier für die Maschine und fügt ihn am Ende der Konfiguration in einem <UID>-Tag ein. Schließlich wird die Konfiguration mit RC4 verschlüsselt und in der Windows Registry gespeichert.

Der Code, der für die Konfiguration verantwortlich ist, weist gewisse Fähigkeiten auf, die in den vorliegenden Casper-Samples nicht genutzt werden – zum Beispiel ein TIMETOLIVE-Attribut, mit dem eine Zeit für die Beendigung von Casper festgelegt werden kann oder ein DELAYED_START-Attribut, mit dem die Interaktion mit dem System hinausgezögert wird.

Schließlich enthält die Konfiguration der Payload genau die gleichen <STRATEGY>-Tags wie der Dropper.

Bericht an den C&C

Während der ersten Ausführung führt Caspers Payload die folgende XML-Datei aus:

<COMMAND name='SYSINFO'/>

Der Handler des „SYSINFO“-Befehls fragt Informationen über das System ab und erstellt einen Bericht, der in mehrere Bereiche aufgeteilt ist:

Die Überschriften der einzelnen Bereiche sind selbsterklärend. Interessanterweise wird die Version der Malware deutlich genannt: 4.4.1. Dieser Bericht wird dann in Base64 kodiert und in Form einer HTTP-POST-Anfrage an den C&C-Server gesendet. Zusätzlich wird er in eine temporäre Datei namens „perfaudio.dat“ geschrieben.

Die POST-Anfrage enthält zudem einen Cookie namens „PREF“, der eine Zusammenfassung aus der UID der Maschine, der Konfigurations-ID, der Version von Casper und dem hartkodierten Zeichen „R“ beinhaltet – alles in Base64 kodiert.

Mögliche Antworten vom C&C

Da der C&C-Server zu der Zeit unserer Untersuchungen offline war, können wir bezüglich der restlichen Ausführung mit Bezugnahme auf die bekannten Fähigkeiten von Casper nur spekulieren.

An diesem Punkt kontaktiert das Binärprogramm regelmäßig den C&C-Server mit einem Cookie, der dem in der SYSINFO-Anfrage gleicht, diesmal allerdings mit „G“ als hartkodiertem Zeichen statt „R“. Unsere Analyse des Binärprogramms zeigt, dass der Server dann eine PNG-Datei zurücksenden kann – mit entsprechendem Header und Format –, von der eine XML-Kommandodatei entschlüsselt und ausgeführt wird.

Zusätzlich zum „SYSINFO“-Befehl kann Casper <COMMAND>-Tags mit den folgenden Werten verarbeiten:

• „EXEC“, um ein Programm auf der Maschine von seinem lokalen Pfad aus auszuführen
• „SYSTEM“, um Befehle in einer Windows-Kommandozeile auszuführen

Außerdem kann Casper <PLUGIN>-Tags verarbeiten, die eine ausführbare Windows-Datei beinhalten, die auf der Maschine ausgeführt werden kann.

Beziehung zwischen Casper und anderen Cartoons

Die beste Möglichkeit, zu beweisen, dass hinter Bunny, Babar und Casper die gleichen Entwickler stehen, ist die Identifizierung des außergewöhnlichen Codes oder Algorithmus, den die Programme nutzen. In unserem Vergleich berücksichtigen wir auch die sogenannte „NBOT“-Malware (auch bekannt als „TFC“), deren Verbindung zu Babar und Bunny von Marion Maschalek in ihrem Babar-Bericht begründet wurde. In der folgenden (unvollständigen) Liste sind die gemeinsamen Features aufgezählt, die uns aufgefallen sind:

• Casper versteckt seine API-Funktionsaufrufe, indem er anstelle der Namen selbst einen Hash nutzt, der durch den Namen der Funktion berechnet wird. Der Hash-Algorithmus ist eine Kombination aus Rotate-Left (ROL) von 7 Bits und Exclusive-Or (XOR) Operationen. NBOT nutzt genau den gleichen Algorithmus, Babar versteckt seine API-Aufrufe zwar in einer ähnlichen Weise, die aber einen anderen Algorithmus nutzt.
• Casper fängt Informationen über das laufende Antiviren-Programm mithilfe der gleichen WMI-Anfrage ab wie Bunny, Babar und NBOT. Darüber hinaus berechnen alle Schadcodes den SHA-256-Hash des ersten Wortes des Antiviren-Namens, wobei dies bei Casper niemals zum Einsatz kam.
• Casper generiert die Trennzeichen für seine HTTP-Anfragen, indem eine bestimmte Zeichenabfolge mit den Ergebnissen des Aufrufs der API Funktion GetTickCount aufgefüllt wird. Derselbe Code ist auch in manchen NBOT-Samples präsent, wie in der folgenden Abbildung zu sehen ist.

• Casper entfernt seinen Dropper durch die Ausführung eines Windows-Befehls, erstellt aus der folgenden Zeichenabfolge:

Ich manchen NBOT-Samples können wir eine ähnliche Syntax finden:

• Casper nutzt einen „ID“-Wert von „13001“, während Babar-Samples eine ID von „12075-01“ beinhalten. Zudem verarbeitet die Malware, die 2009 von CSEC entdeckt wurde, eine ID von „08184“ (Folie 8 der CSEC-Präsentation). Dieses ähnliche Format und der steigende Wert im Dezimalformat könnten auf eine Verbindung hinweisen.

Einzeln betrachtet reichen diese Merkmale nicht aus, um eine Verbindung zu begründen, aber alle Gemeinsamkeiten zusammen betrachtet, lassen uns zu dem Schluss kommen, dass Bunny, Babar, NBOT und Casper von den gleichen Entwicklern geschrieben wurden.

Über die Opfer

Laut unseren Daten, kamen alle Nutzer, die während dieser Operation angegriffen wurden, aus Syrien. Vielleicht handelte es sich hierbei um Leute, die die Webseite „jpic.gov.sy“ besucht haben – syrische Bürger, die eine Anfrage einreichen wollten. In diesem Fall könnten sie von der legitimen Seite zu den Exploits umgeleitet worden sein.

Wir waren allerdings nicht in der Lage, zu bestimmen, ob dies wirklich der Fall war. Mit anderen Worten: Es ist genauso wahrscheinlich, dass die Opfer von einer anderen Webseite zu den Exploits umgeleitet wurden, zum Beispiel von einer gehackten Webseite oder über einen Link in einer E-Mail. Sicher ist aber, dass die Exploits, die Casper-Binärprogramme und die C&C-Komponente auf dem Server dieser Webseite gehostet wurden.

Das führt uns zu einer zweiten These: Die Webseite „jpic.gov.sy“ könnte gehackt worden sein, um als Speicher-Umgebung zu fungieren. Das hätte mindestens zwei Vorteile für die Angreifer: Zum einen kann das Hosten der Dateien auf einem syrischen Server die Zugriffe von Syrien aus erleichtern – ein Land, dessen Internetverbindung zur restlichen Welt seit Beginn des Bürgerkriegs relativ instabil ist, wie in Googles Transparenzbericht zu sehen ist. Zum anderen kann es die Suche nach den Verantwortlichen in die Irre führen, indem der Verdacht auf die syrische Regierung gelenkt wird.

Zusammenfassung

Wie bereits erklärt, sind wir der Überzeugung, dass Bunny, Babar und Casper von der gleichen Gruppe entwickelt wurden. Die detaillierte Babar-Analyse in den CSEC-Folien von 2009 deutet darauf hin, dass professionelle Leute am Werk sind, die im Bereich der Spionage keine Anfänger sind. Die Nutzung von Zero Day Exploits ist ein weiterer Hinweis darauf, dass die Casper-Autoren einer mächtigen Organisation angehören. Und die enge Zielgruppe, bestehend aus syrischen Nutzern, deutet auf ein Interesse an der dortigen Politik hin.

Nichtsdestotrotz haben wir in Casper selbst keine Beweise gefunden, die auf ein bestimmtes Land verweisen – insbesondere wurden in den Binärprogrammen keine Hinweise gefunden, die für eine französische Herkunft sprechen, wie es vom CSEC in Bezug auf Babar suggeriert wird.

Hashes

Indikatoren für ein infiziertes System

Picture Credits: PAISAN HOMHUAN / Shutterstock.com