Eine Besonderheit der Gruppe, die hinter dieser Bedrohung steckt, ist die Tatsache, dass nach der Entwicklung neuer Tools die alten Tools nicht zerstört oder aufgegeben, sondern weiterhin gepflegt und genutzt werden. Dank unserer Sammlung an Samples konnten wir die folgende zeitliche Abfolge ermitteln:
Cobra kann als erweiterbares Framework betrachtet werden. Dieses Framework wird in der Regel von einer Aufklärungs-Malware wie etwa Tavdig – auch bekannt unter den Bezeichnungen Wipbot (Symantec) und Epic Backdoor (Kaspersky) – heruntergeladen und verbreitet. Das folgende Schema zeigt den „Modus Operandi“ der Uroburos Angreifer:
Diese Malware mithilfe von IOCs (Indicators of Compromise) zu erkennen, ist recht kompliziert, da die Malware-Entwickler sich bemüht haben, viele Faktoren zu randomisieren. Beispielsweise verbreiten die Angreifer die Malware in verschiedenen Verzeichnissen unter Verwendung der dort vorhandenen, auch zufällig ausgewählten Dateien, um die Malware-Konfiguration zu speichern.
Aufgrund dieser Eigenschaften haben sich die Experten der G DATA SecurityLabs dazu entschieden, eine Analyse des Frameworks zu veröffentlichen, das von der Datei mit dem folgenden MD5-Hashwert verbreitet wird: cb1b68d9971c2353c2d6a8119c49b51f. Die Sicherheitslösungen von G DATA erkennen diese Datei als Backdoor.TurlaCarbon.A (Engine A) bzw. Win32.Trojan.Cobra.B (Engine B).
Wir finden den Kompilierungspfad in der folgenden im Dropper eingebetteten Datei:
f:\Workshop\Projects\cobra\carbon_system\x64\Release\carbon_system.pdb
Es lässt sich leicht erkennen, dass „Carbon System“ ein Teil des Projekts „Cobra“ ist.
Dropper
Der Dropper wird dazu genutzt, vier Dateien auf dem infizierten System zu installieren. Die abgelegten Dateien werden in den Ressourcen der Binärdatei gespeichert. Im Dropper ist die 32-Bit- und die 64-Bit-Version der ausführbaren Dateien eingebettet. Er installiert die folgenden Dateien:
- miniport.dat: Konfigurationsdatei;
- Phase 1: Der Dateiname wird zufällig aus folgenden Optionen ausgewählt: ipvpn.dll, srsvc.dll oder kmsvc.dll. Diese Bibliothek wird als Dienst registriert;
- Phase 2: Der Dateiname ist msimghlp.dll. Dies ist die Koordinationszentrale der Malware (vom Entwickler als „System“ bezeichnet);
- Phase 3: Der Dateiname ist msximl.dll. Diese Bibliothek (vom Entwickler als „User“ bezeichnet) wird in die Browser und E-Mail-Clients injiziert, damit die Kommunikation nach außen über Web-Anforderungen erfolgen kann;
Die Persistenz wird durch die Erstellung eines Dienstes (HKLM\SYSTEM\CurrentControlSet\Service\) erzielt. Der Name des Dienstes hängt vom gewählten Dateinamen aus Phase 1 ab:
| Dateiname|Name des Dienstes|Angezeigter Name|Beschreibung (aus der Binärdatei per Copy&Paste übernommen) |
| ipvpn.dll|ipvpn|Virtual Private Network Routing Service|Provides enchanced network management while active VPN connection established. Support All necessary functions and maintain dynamic table rules. Enforcement technologies that use virtual networks may not function properly without this service |
| srsvc.dll|srservice|System Restore Service|Performs system restore functions. To stop service, turn off System Restore from the System Restore tab in My Computer. |
| kmsvc.dll|hkmsvc|Health Key and Certificate Management Service|Provides X.509 certificate and key management services for the Network Access Protection Agent (NAPAgent). Enforcement technologies that use X.509 certificates may not function properly without this service |
Die Beschreibungen weisen Rechtschreibfehler auf; die Satzstruktur deutet möglicherweise darauf hin, dass die Texte von Nicht-Muttersprachlern geschrieben wurden.
Phase 1 wird immer im Ordner %SystemRoot%\system32\ installiert. Um Objekte in %SystemRoot% installieren zu können, haben sich die Angreifer Administratorrechte beschafft, bevor sie den Dropper ausgeführt haben. Die drei anderen Dropper-Dateien werden in ein zufällig ausgewähltes vorhandenes Verzeichnis unter %ProgramFiles% gespeichert.
Während der Installation, die in einer Befehlszeile ausgeführt wird, zeigt der Dropper die folgenden Informationen an:
Die im Screenshot gezeigte Zeichenfolge „LUCKY STRIKE!!!“ wird angezeigt, wenn die Installation erfolgreich durchgeführt wurde. Bei einem etwaigen Installationsfehler wird „Idioten???“ angezeigt. Um den Zufallsinstallationspfad zu finden, ändert der Dropper eine (ebenfalls zufällig ausgewählte) legitime .inf-Datei im Ordner %SystemRoot%\inf\ab.
Die folgenden Informationen werden am Ende der Datei hinzugefügt:
[B8744A58]
root=C:\Program Files\Windows NT\Accessoiries\en-US
Die eingeklammerte ID ist eine eindeutige Kennung, und die Root-Variable enthält den Pfad, in dem die drei zusätzlichen Dateien installiert werden.
Die von den Entwicklern genutzten Tricks – zufällige Dateinamen und zufällige Installationspfade – werden dazu genutzt, die Erkennung mithilfe von IOCs zu erschweren. Im Allgemeinen verwenden Sicherheitsexperten Spuren dieser Art, um den Befall der Systeme mit Malware zu erkennen.
Phase 1: Loader
MD5: 43e896ede6fe025ee90f7f27c6d376a4
Die Sicherheitslösungen von G DATA erkennen diese Datei als Backdoor.TurlaCarbon.A (Engine A) und Win32.Trojan.Cobra.A (Engine B).
Die erste Phase ist nicht sehr umfangreich, da die Anzahl der Befehle und Aktionen ziemlich gering ist. Vereinfacht gesagt besteht ihr Zweck allein darin, die zweite Phase zu laden. Für diese Aufgabe prüft die erste Phase alle Dateien in %SystemRoot%\inf\, um den Eintrag mit der bereits erwähnten eindeutigen Kennung zu finden und so den Pfad für Phase 2 zu ermitteln. Danach wird die Bibliothek der zweiten Phase geladen; anschließend wird die exportierte Funktion ModuleStart() ausgeführt:
Phase 2: die Koordinationszentrale
MD5: e6d1dcc6c2601e592f2b03f35b06fa8f
Version: 3.71
Die Sicherheitslösungen von G DATA erkennen diese Bedrohung als Backdoor.TurlaCarbon.A (Engine A) und Win32.Trojan.Cobra.B (Engine B).
Die zweite Phase wird von den Entwicklern der Malware als „System“ bezeichnet. Der interne Name der Bibliothek lautet carbon_system.dll.
Sinn und Zweck dieses Programmcodes ist es, im Hintergrund zu bleiben und verschiedene Anfragen und Aufgaben zu koordinieren, die von den anderen DLLs bzw. Named Pipe-Verbindungen stammen.
Mutex-Erstellung
Die Koordinationszentrale erstellt mehrere Mutexe. Diese Mutexe werden aus zwei Gründen eingesetzt:
- Sie sollen in der dritten Phase erkennen, ob die Koordinationszentrale korrekt auf dem infizierten System gestartet wurde.
- Sie sollen sicherstellen, dass die Koordinationszentrale nur einmal ausgeführt wird.
Hier die erstellten Mutexe:
- Global\MSCTF.Shared.MUTEX.zRX
- Global\DBWindowsBase
- Global\IEFrame.LockDefaultBrowser
- Global\WinSta0_DesktopSessionMut
- Global\{5FA3BC02-920F-D42A-68BC-04F2A75BE158}
- Global\SENS.LockStarterCacheResource
- Global\ShimSharedMemoryLock
Arbeitsdateien und -verzeichnisse
Die folgenden Arbeitsdateien und –verzeichnisse werden von der Koordinationszentrale verwendet. Die Koordinationszentrale schafft einen einzigen Zufallspfad und speichert anschließend alle genannten erforderlichen Ordner unter diesem einen zufällig generierten Pfad:
- %randompath%\Nls\: Verzeichnis im Zusammenhang mit den durchzuführenden Tasks
- %randompath%\0208\: Verzeichnis im Zusammenhang mit den temporären Dateien
- %randompath%\System\: Verzeichnis im Zusammenhang mit den zusätzlichen Plug-Ins
- %randompath%\System\bootmisc.sdi: wird anscheinend nicht verwendet
- %randompath%\0208\C_56743.NLS: Dateien im Zusammenhang mit den durchzuführenden Tasks und den Plug-Ins
- %randompath%\Nls\b9s3coff.ax: Dateien im Zusammenhang mit den durchzuführenden Tasks und der Named Pipe
- %randompath%\Nls\a67ncodc.ax: Datei im Zusammenhang mit den durchzuführenden Tasks
- %randompath%\vndkrmn.dic: Protokolldatei
- %randompath%\qavsrc.dat: Protokolldatei
- %randompath%\miniport.dat: Konfigurationsdatei
- %randompath%\asmcerts.rs: Zweck derzeit nicht bekannt
- %randompath%\getcert.rs: Zweck derzeit nicht bekannt
Die Dateien werden beim Start der Malware nicht automatisch erstellt. Die Dateien werden nur dann erstellt, wenn die Koordinationszentrale diese benötigt.
Konfigurationsdatei
Die Konfigurationsdatei (miniport.dat) wird in der 2. und 3. Phase genutzt. Die Datei wird mit dem CAST-128-Algorithmus verschlüsselt. Derselbe Algorithmus wurde auch von Uroburos zum Verschlüsseln der Dateisysteme genutzt. Folgender Schlüssel kommt zum Einsatz: { 0x12, 0x34, 0x56, 0x78, 0x9a, 0xbc, 0xde, 0xf0, 0xfe, 0xfc, 0xba, 0x98, 0x76, 0x54, 0x32, 0x10 }
Hinweis: Gemäß der Logik müsste 0xfc eigentlich 0xdc lauten.
Hier ein Beispiel für die Konfigurationsdatei:
paul@gdata:~/Carbon/$ ./decrypt.py miniport.dat
[NAME]
object_id=acce6511-ba11-fa11-f0047d1
iproc = iexplore.exe,outlook.exe,msimn.exe,firefox.exe,opera.exe,chrome.exe
ex = #,netscape.exe,mozilla.exe,adobeupdater.exe,chrome.exe
[TIME]
user_winmin = 1800000
user_winmax = 3600000
sys_winmin = 3600000
sys_winmax = 3700000
task_min = 20000
task_max = 30000
checkmin = 60000
checkmax = 70000
logmin = 60000
logmax = 120000
lastconnect=1419925298
timestop=
active_con = 900000
time2task=3600000
check_lastconnect=1419925298
[CW_LOCAL]
quantity = 0
[CW_INET]
quantity = 4
address1 = soheylistore.ir:80:/modules/mod_feed/feed.php
address2 = tazohor.com:80:/wp-includes/feed-rss-comments.php
address3 = jucheafrica.com:80:/wp-includes/class-wp-edit.php
address4 = 61paris.fr:80:/wp-includes/ms-set.php
[CW_INET_RESULTS]
quantity = 4
address1 = soheylistore.ir:80:/modules/mod_feed/feed.php
address2 = tazohor.com:80:/wp-includes/feed-rss-comments.php
address3 = jucheafrica.com:80:/wp-includes/class-wp-edit.php
address4 = 61paris.fr:80:/wp-includes/ms-set.php
[TRANSPORT]
system_pipe = comnap
spstatus = yes
adaptable = no
[DHCP]
server = 135
[LOG]
logperiod = 7200
lastsend=1419924312
[WORKDATA]
run_task=
run_task_system=
[VERSION]
System=3/71
User=3/62Sämtliche unter [CW_INET] und [CW_INET_RESULTS] aufgeführten Websites sind legitime Wordpress-Websites, die infiziert wurden. Als dieser Artikel geschrieben wurde, waren alle diese Websites bereinigt und gepatcht.
Das Dateiformat ist dasselbe wie das .ini-Dateiformat von Windows. Die Entwickler nutzen die Windows-API, um die Konfiguration zu analysieren (GetPrivateProfileStringA()).
Die Datei enthält:
- eine eindeutige Kennung, um den infizierten Computer zu identifizieren (object_id)
- den in Phase 3 verwendeten Command&Control Server (addressX)
- die Version von „System“ und der Bibliothek „User“ (in [VERSION] )
- das Intervall und den Zeitpunkt der Ausführung verschiedener interner Tasks ([TIME] )
- den Namen der Named Pipe, die als Kommunikationskanal zwischen dem „System“ und dem „User“ verwendet wird (system_pipe)
- den Namen des Prozesses, in den Phase 3 injiziert wird (iproc)
- …
Kommunikation über Named Pipes
Die Koordinationszentrale erstellt zwei Named Pipes für die Kommunikation mit Phase 3 oder um Meldungen von einem externen Computer zu empfangen:
\\.\\pipe\sdlrpc- \\.\\pipe\comnap (der Name in der Konfigurationsdatei)
Funktionen
Die Koordinationszentrale erstellt neun Threads, um die verschiedenen Funktionen zu handhaben. Schauen wir uns nun einmal die interessantesten Threads an.
Ein Thread wird zur Überprüfung verwendet, ob sich die Parameter in der Konfigurationsdatei geändert haben.
Ein zweiter Thread wird dazu verwendet, den verfügbaren Speicherplatz auf der Festplatte zu ermitteln. Wenn wenig Speicherplatz auf der Festplatte frei ist, erzeugt die Koordinationszentrale den folgenden Eintrag in der Protokolldatei:
Der abgebildete Screenshot zeigt ebenfalls eine recht interessante Verwendung der englischen Sprache. Wir gehen davon aus, dass „Survive me“ (DE: überlebe mich) wohl so etwas wie „Rescue me“ (DE: Rette mich) im Sinne von „help me to survive“ (Hilf mir zu überleben) bedeuten soll.
Ein dritter Thread zur Bearbeitung der Tasks wird erstellt. Eine Task ist ein auszuführender Befehl, der vom C&C Server gesendet wird. Der auszuführende Programmcode wird lokal auf dem infizierten Computer gespeichert. Die Koordinationszentrale ist (durch Ausführen des Exports start()) in der Lage, Bibliotheken oder die Befehlszeile von Windows auszuführen. Die Befehlszeile kann mit der aktuellen Benutzerberechtigung oder mit der Berechtigung eines anderen Benutzers (über CreateProcessA() oder CreateProcessAsUserA()) ausgeführt werden:
Ein vierter Thread wird dazu verwendet, die Protokollrotationsdatei (vndkrmn.dic) zu erstellen.
Ein fünfter Thread wird dazu verwendet, die an die Named Pipes gesendeten Daten zu erstellen und zu lesen.
Ein sechster Thread wird verwendet, um Plug-Ins zu laden. Für die Koordinationszentrale ist ein Modul eine Bibliotheksdatei mit einem speziellen Export namens ModuleStart(). Die Plug-In-Liste ist in der Konfigurationsdatei gespeichert ([PLUGINS]). Dieser Thread ist dem dritten Thread sehr ähnlich, weist aber einige geringfügige Unterschiede auf. Die Funktion zur Ausführung der Plug-Ins ist nicht identisch.
Schließlich wird noch ein siebter Thread dazu verwendet, um Phase 3 (msximl.dll) in die Browser und E-Mail-Clients zu injizieren. Die Liste der Zielprozesse wird in der Konfigurationsdatei gespeichert:
iproc = iexplore.exe,outlook.exe,msimn.exe,firefox.exe,opera.exe,chrome.exe
Wie üblich wird die injizierte Bibliothek über die Exporte ModuleStart() ausgeführt.
Protokolldatei
Die Koordinationszentrale und die Phase 3 erzeugen eine gemeinsame Protokolldatei. Die Datei wird mit demselben Algorithmus und demselben Schlüssel wie die Konfigurationsdatei verschlüsselt. Hier ein Beispiel des Inhalts:
paul@gdata:~/Carbon$ ./decrypt.py infected/vndkrmn.dic
[LOG]
start=1
30/12/14|08:28:44|acce6511-ba11-fa11-f0047d1|s|ST|3/71|0|
30/12/14|08:29:50|acce6511-ba11-fa11-f0047d1|s|INJ|C:\Program Files\Windows Mail\en-US\msximl.dll|
30/12/14|08:30:28|acce6511-ba11-fa11-f0047d1|s|INJ|0|2204|
30/12/14|08:30:28|acce6511-ba11-fa11-f0047d1|u|ST|3/62|"C:\Program Files\Internet Explorer\iexplore.exe" :2204|
30/12/14|08:30:28|acce6511-ba11-fa11-f0047d1|u|ST|2204:END|
30/12/14|08:30:39|acce6511-ba11-fa11-f0047d1|u|W|-1|0|ALL|NOINET|
30/12/14|08:30:41|acce6511-ba11-fa11-f0047d1|u|W|-1|0|ALL|NOINET|
30/12/14|08:37:18|acce6511-ba11-fa11-f0047d1|s|STOP|3/71|0|
30/12/14|08:37:18|acce6511-ba11-fa11-f0047d1|s|STOP|OK|
30/12/14|08:39:45|acce6511-ba11-fa11-f0047d1|s|ST|3/71|0|
30/12/14|08:41:13|acce6511-ba11-fa11-f0047d1|s|INJ|C:\Program Files\Windows Mail\en-US\msximl.dll|
30/12/14|08:41:34|acce6511-ba11-fa11-f0047d1|s|INJ|0|2196|
30/12/14|08:41:34|acce6511-ba11-fa11-f0047d1|u|ST|3/62|"C:\Program Files\Internet Explorer\iexplore.exe" :2196|
30/12/14|08:41:34|acce6511-ba11-fa11-f0047d1|u|ST|2196:END|
30/12/14|08:41:35|acce6511-ba11-fa11-f0047d1|u|OPER|Wrong config: no lastconnect|
30/12/14|08:41:36|acce6511-ba11-fa11-f0047d1|u|P|0|NULL|0|Sleep:41|
30/12/14|08:41:38|acce6511-ba11-fa11-f0047d1|u|OPER|Wrong config: no lastconnect|
30/12/14|08:41:39|acce6511-ba11-fa11-f0047d1|u|W|-1|0|tazohor.com:/|nrt|
30/12/14|08:41:40|acce6511-ba11-fa11-f0047d1|u|W|-1|0|61paris.fr:/|nrt|
30/12/14|08:41:40|acce6511-ba11-fa11-f0047d1|u|W|0|NULL|0|Sleep:1816467|
30/12/14|08:41:40|acce6511-ba11-fa11-f0047d1|u|P|0|NULL|0|Sleep:604Das Protokollformat ist wie folgt:
Datum|Uhrzeit|Eindeutige Kennung|Quelle|Nachricht
Die Quelle weist folgende Werte auf:
- S: für die Koordinationszentrale (bzw. das „System“)
- U: für die injizierte Bibliothek (bzw. „User“)
Das Format der Nachricht ist nicht immer gleich. Beim ersten Teil handelt es sich jedoch um die ausgeführte Funktion:
- ST: Start (entweder für die Koordinationszentrale oder die injizierte Bibliothek); der zweite Teil der Nachricht ist die Version (z. B. 3.71 für die Koordinationszentrale und 3.62 für die injizierte Bibliothek) und im Hinblick auf die injizierte Bibliothek der Name des Host-Prozesses
- STOP: Stopp
OPER: Meldung für den Betreiber (zum Beispiel wenn die Festplattenspeicherkapazität gering ist)
W: Web-Anfragen
INJ: Injektion; der zweite Teil der Nachricht ist der Dateipfad (lib), der zur Injektion in beispielsweise den Browser oder die PID verwendet wird
L: Bibliotheksprotokollmeldung laden
S: Protokollrotationsmeldung
T: Meldung im Zusammenhang mit der Task-Ausführung
Phase 3: die injizierte Bibliothek
MD5: 554450c1ecb925693fedbb9e56702646
Version: 3.62
Die Sicherheitslösungen von G DATA erkennen diese Bedrohung als Backdoor.TurlaCarbon.A (Engine A) und Win32.Trojan.Cobra.B (Engine B).
Phase 3 wird von den Entwicklern als „User“ bezeichnet. Der interne Name der Bibliothek lautet CARBON.dll.
Der Zweck dieser Phase ist die Kommunikation nach außen über Web-Anforderungen. Die Kommunikation wird dazu genutzt, Daten nach außen zu schmuggeln und Befehle (bzw. Plug-Ins oder Code, der ausgeführt werden soll) zu empfangen.
Mutex-Prüfung
Die erste Task der Prüfung 3 besteht in der Prüfung, ob die von der Koordinationszentrale erstellten Mutexe verfügbar sind oder nicht. Dadurch soll sichergestellt werden, dass die Koordinationszentrale korrekt gestartet wurde:
Überprüfen der Internetverbindung
Vor der Kommunikation mit dem C&C Server überprüft Phase 3, ob eine Internetverbindung vorhanden ist. Dazu wird eine Verbindung mit folgenden Servern erstellt:
- www.google.com
- www.yahoo.com
- www.bing.com
- update.microsoft.com
- windowsupdate.microsoft.com
- microsoft.com
Falls die Verbindung nicht funktioniert, wird die folgende Meldung in die Protokolldatei geschrieben:
|u|W|-1|0|ALL|NOINET|
Kommunikation mit dem C&C Server
Die Kommunikation mit den Betreibern wird über die in der Konfigurationsdatei gespeicherten URL geführt. Zunächst führt die Malware einen GET-Request aus, um festzustellen, ob der C&C Server betriebsbereit ist.
Ist die erste Abfrage erfolgreich, wird eine zweite Anfrage an den Server gesendet. Diese unterscheidet sich von der ersten insofern, dass einige Daten in einen HTTP-Cookie integriert werden . Der Inhalt des Cookie ist: catid, task, id, forumid, itemid, link, layout, start, limit (keiner der Parameter ist zwingend erforderlich). Die in diesem Cookie gesendeten Daten sind mit dem CAST-128-Algorithmus verschlüsselt und codiert.
Die Malware kann auch POST-Anfragen generieren. Hier ein Beispiel des Musters:
POST hxxp://%s/%s?uid=%d&context=%s&mode=text&data=%s
Die Malware nutzt dieselbe Technik wie Tavdig, um Befehle zu erhalten. Die Daten sind im folgenden Screenshot zwischen den Feldern <div> und </div> erkennbar:
Zusätzliche Funktionen
Phase 3 ist in der Lage, genauso wie die Koordinationszentrale, Tasks auszuführen. Der Code für die Funktionen ist exakt derselbe wie der Code, der von der Koordinationszentrale verwendet wird. Wir gehen davon aus, dass der Grund hierfür Copy&Paste ist. Der „User“ ist (durch Ausführen des Exports start()) in der Lage, Bibliotheken oder die Befehlszeile von Windows auszuführen. Die Befehlszeile kann mit der aktuellen Benutzerberechtigung oder mit der Berechtigung eines anderen Benutzers (über CreateProcessA() oder CreateProcessAsUserA()) ausgeführt werden.
Fazit
Diese Analyse zeigt, dass die Akteure, die hinter Uroburos, Agent.BTZ und Carbon System stecken, qualifiziert und immer noch aktiv sind. Das von uns analysierte Sample zeigt, wie die Entwickler versucht haben, die Entdeckung und die Nutzung von IOCs (Indicators of Compromise) zu erschweren. Hier eine Übersicht über einige der von uns festgestellten Tricks:
- Nutzung zufälliger Namen für Dienste
- Nutzung zufälliger Dateinamen
- Nutzung zufälliger Verzeichnisnamen für die Installation
- Konfiguration der Bezeichnungen für Named Pipes
- …
Carbon System ist ein echtes erweiterbares Framework mit Plug-In-Management. Da diese Plug-Ins von den kontaktierten C&C Servern bereitgestellt werden, können dies beliebige Dateien sein – nichts muss vorab als Paket vorbereitet werden. Aufgrund der Art der Malware-Angriffe können wir uns vorstellen, dass diese Plug-Ins unterschiedlichste Komponenten für die Cyber-Spionage sein können, angefangen von Keyloggern über Vorrichtungen für die Beschaffung von Anmeldeinformationen bis hin zu Abhörmechanismen und vieles mehr. Ein Unternehmen bzw. eine Organisation, die angegriffen wird, wäre für die Angreifer ein offenes Buch.
Die Architektur ist komplex; sie weist eine Koordinationszentrale und eine Bibliothek auf, die in die Browser- und E-Mail-Clientprozesse injiziert werden. Dieses Konzept ähnelt ganz offensichtlich dem Konzept, das wir bei der Analyse von Uroburos erkannt haben. Das Framework könnte als „Entwurf“ betrachtet werden. Dennoch handelt es sich um eine sehr leistungsstarke Abwandlung von Uroburos (nur im sog. „Userland“). Wir sind der Auffassung, dass Uroburos ein Produkt ist, das aus der Weiterentwicklung der Malware „Cobra“ entstanden ist. Uroburos ist zwar ein neuer Zweig, jedoch kein linearer Nachfolger.
Mit Blick auf das Gesamtbild, das wir bis jetzt erhalten haben, können wir sagen, dass die ganze Kampagne sehr professionell aufgezogen ist. Wir haben verschiedene Samples analysiert und viele Schlüsse gezogen. Auch wenn es noch viele offene Fragen gibt, die beantwortet werden müssen, kommen wir der erfolgreichen Schlangenbeschwörung der „Snakes“ näher – der Cobra, des giftigen Tiers mit dem tödlichen Biss, und Uroburos, der sich selbst erhaltenden, gruseligen Gestalt aus Schlange und Drache. Diese Art der Reptilienkunde war für uns sehr interessant. Wir freuen uns schon darauf, mehr über diese Kampagnen in Erfahrung zu bringen.