Als PDF-Datei herunterladen

2. April 2021

Einleitung

Ende September 2020 wandte sich ein russisches Forschungsinstitut an das Virenlabor von Doctor Web. Die Mitarbeiter des Forschungsinstituts waren über einige technische Probleme besorgt, die von Malware auf einem der Server des lokalen Netzwerks zeugen konnten. Unsere Virenanalysten stellten heraus, dass das Forschungsinstitut gezielt mithilfe von speziellen Backdoor-Programmen angegriffen worden war. Die Untersuchung zeigte, dass das Netzwerk des Unternehmens schon seit langem von mehreren APT-Teams kompromittiert war.

Die im Laufe der Untersuchung ermittelten Daten weisen darauf hin, dass das Netzwerk des Forschungsinstituts bereits im Herbst 2017 zum ersten Mal kompromittiert wurde. Für die Erstinfektion wurde BackDoor.Farfli.130 (eine der Modifikationen des Backdoor-Programms Gh0st RAT) verwendet. Später wurden Trojan.Mirage.12 (im Frühling 2019) und BackDoor.Siggen2.3268 (im Juni 2020) in das Netzwerk integriert.

Spätestens im April 2019 wurde das Netzwerk des Forschungsinstituts von einem weiteren Hacker-Team kompromittiert. Diesmal erfolgte die Infektion mit der Installation des Backdoor-Programms BackDoor.Skeye.1. Während der Untersuchung stellte sich heraus, dass ungefähr zur gleichen Zeit Skeye auch im lokalen Netzwerk eines anderen russischen Forschungsinstituts installiert worden war.

Im Juni 2019 veröffentlichte FireEye einen Bericht über mithilfe dieses Backdoor-Programms durchgeführte gezielte Angriffe auf staatliche Einrichtungen in Zentralasien. Die Virenanalysten von Doctor Web ermittelten, dass dieses Hacker-Team von August bis September 2020 mehrere Trojaner im Netzwerk des Unternehmens installiert hatte, darunter die Backdoor-Programme BackDoor.DNSep.1 und BackDoor.PlugX.

Außerdem stellten unsere Spezialisten heraus, dass im Dezember 2017 das Programm BackDoor.RemShell.24. auf den Servern des betroffenen Forschungsinstituts installiert worden war. Diese Backdoor-Familie wurde im Bericht Operation Taskmasters des IT-Unternehmens Positive Technologies beschrieben. Wir konnten nicht eindeutig ermitteln, welche der APT-Teams dieses Backdoor-Programm installiert hatte.

Wer steckt hinter den Angriffen?

Die verfügbaren Informationen über das erste APT-Team reichen nicht aus, um die Angreifer eindeutig zu einem der oben erwähnten Hacker-Teams zu zählen. Die Analyse der verwendeten Schadprogramme zeigte, dass das erste APT-Team seit mindestens 2015 aktiv war.

Als zweites APT-Team haben wir das Hacker-Team TA428 identifiziert, das die Analysten von Proofpoint im Bericht Operation Lag Time IT beschrieben haben. Dafür spricht Folgendes:

1. Die Codes der Backdoor-Programme BackDoor.DNSep und BackDoor.Cotx enthalten gleiche Teile.
2. BackDoor.Skeye.1 und Trojan.Loader.661 wurden im Rahmen desselben Angriffs eingesetzt, und Trojan.Loader.661 ist als eines der Tools des Teams TA428 bekannt.
3. Die im Rahmen dieser Angriffe analysierten Backdoor-Programme und die, die von TA428 verwendet werden, haben einige gemeinsame Verwaltungsserver und gleiche Elemente der Netzwerkinfrastruktur.

Gehen wir auf die ermittelten Zusammenhänge näher ein. Die Abbildung zeigt einen Teil der im Angriff eingesetzten Infrastruktur, in der sich die Backdoors Skeye und PoisonIvy überschneiden:

Diese Abbildung zeigt die Überschneidungen der Backdoors Skeye und Cotx:

Eine detaillierte Analyse des DNSep-Backdoor-Programms und dessen Vergleich mit dem Cotx-Code ergaben Ähnlichkeiten sowohl in der allgemeinen Logik der Verarbeitung von Befehlen des Verwaltungsservers als auch in spezifischen Implementierungen einzelner Befehle.

Ein weiterer interessanter Fund, der während dieser Untersuchung gemacht wurde, ist das Backdoor-Programm Logtu. Eines seiner Muster wurde von uns im Rahmen der Untersuchung des Vorfalls in Kirgisistan beschrieben. Die Adresse seines Verwaltungsservers stimmt mit der des Servers von Skeye überein: atob[.]kommesantor[.]com. Daher haben wir BackDoor.Skeye.1 analysiert und mit BackDoor.Logtu.1 und BackDoor.Mikroceen.11 verglichen.

Detaillierte technische Informationen über die erkannten Schadprogramme finden Sie im beigefügten PDF-Dokument und in der Virenbibliothek von Dr.Web.

Vergleichsanalyse der Codes von BackDoor.DNSep.1 und BackDoor.Cotx.1

Obwohl Cotx und DNSep unterschiedliche Kommunikationskanäle mit dem Verwaltungsserver nutzen, haben wir interessante Übereinstimmungen in den Codes beider Backdoor-Programme gefunden.

Die Funktion, die für die Verarbeitung von Befehlen des Verwaltungsservers verantwortlich ist, verwendet die folgende Struktur als Argument:

struct st_arg
{
  _BYTE cmd;
  st_string arg;
};

Wenn die erforderliche Funktion mehrere Argumente annimmt, werden diese, durch das Zeichen | getrennt, im Feld arg angegeben.

BackDoor.Cotx.1 enthält alle Befehle von BackDoor.DNSep.1 und einige zusätzliche Befehle.

In der untenstehenden Tabelle sehen wir, dass die Codes einiger Funktionen beider Backdoors fast völlig übereinstimmen. Es ist zu beachten, dass Cotx die Unicode-Codierung und DNSep die ANSI-Codierung verwendet.

BackDoor.DNSep.1	BackDoor.Cotx.1
Handler des Befehls zum Senden einer Verzeichnisliste oder der Laufwerkinformationen
Funktion zum Abrufen von Laufwerkinformationen
Funktion zum Auflisten von Dateien in einem Ordner
Funktion zum Sammeln von Informationen zu Dateien in einem Ordner

Aus den während der Analyse ermittelten Daten lässt sich schließen, dass der Entwickler von DNSep Zugriff auf die Quellcodes von Cotx hatte. Da diese Ressourcen nicht allgemein zugänglich sind, vermuten wir, dass der Entwickler (oder das Entwicklerteam) von DNSep irgendwie mit dem TA428-Team verbunden ist. Für diese Version spricht auch die Tatsache, dass ein Muster von DNSep neben einigen von TA428 verwendeten Backdoor-Programmen im kompromittierten Netzwerk gefunden wurde.

Vergleichsanalyse der Codes der Backdoors Skeye, Mikroceen und Logtu

Bei der Analyse des Backdoor-Programms Skeye stellte es sich heraus, dass die Adresse seines Verwaltungsservers auch von Backdoors der Familie Logtu genutzt wurde. Wir verglichen die Muster von BackDoor.Logtu.1 und BackDoor.Mikroceen.11.

Protokollierung

In allen Fällen wird die Protokollierung verschleiert.

• BackDoor.Mikroceen.11– Meldungen im Format %d-%d-%d %d:%d:%d <msg>\r\n werden in die Datei %TEMP%\WZ9Jan10.TMP geschrieben, wobei <msg> eine zufällige Textzeichenfolge ist. Im Muster 2f80f51188dc9aea697868864d88925d64c26abc werden Meldungen in die Datei 7B296FB0.CAB geschrieben.
• BackDoor.Logtu.1 – Meldungen im Format [%d-%02d-%02d %02d:%02d:%02d] <rec_id> <error_code>\n<opt_message>\n\n werden mithilfe der Aktion XOR mit dem Schlüssel 0x31 verschlüsselt, bevor sie in die Datei %TEMP%\rar<rnd>.tmpgeschrieben werden.
• BackDoor.Skeye.1 – Meldungen im Format %4d/%02d/%02d %02d:%02d:%02d\t<rec_id>\t<error_code>\n werden in die Datei %TEMP%\wcrypt32.dll geschrieben.

Die allgemeine Logik der Reihenfolge der Protokollierung von Meldungen ist in allen drei Mustern ähnlich:

• Der Beginn der Ausführung wird aufgezeichnet.
• Bei Logtu und Mikroceen wird eine direkte Verbindung mit dem Verwaltungsserver protokolliert.
• In jedem Fall wird angegeben, über welchen Proxy die Verbindung mit dem Server hergestellt wurde.
• Falls ein Fehler beim Abrufen eines Proxyaus einer Quelle auftritt, wird ein separater Eintrag im Protokoll aufgezeichnet.

Bemerkenswert ist, dass eine solche detaillierte und verschleierte Protokollierung nicht oft der Fall ist. Die Verschleierung besteht darin, dass einige Meldungscodes und manchmal zusätzliche Daten protokolliert werden. Auch die Reihenfolge der Protokollierung von Ereignissen sieht in allen Fällen ähnlich aus:

• Beginn der Ausführung
• Versuch, eine direkte Verbindung herzustellen
• Abruf von Proxy-Adressen
• Eintrag über die Herstellung einer Verbindung über einen bestimmten Server

Suche nach einem Proxyserver

Auch die Reihenfolge der Verbindungsherstellung mit dem Verwaltungsserver sieht für alle drei Muster ähnlich aus. Zunächst versucht das Backdoor-Programm, eine direkte Verbindung mit dem Server herzustellen. Im Fehlerfall kann es Proxyserver verwenden, deren Adressen aus drei Quellen zusätzlich zu der integrierten Quelle stammen.

BackDoor.Mikroceen.11 kann Proxyserver-Adressen wie folgt abrufen:

• aus der Datei %WINDIR%\debug\netlogon.cfg;
• aus der eigenen Protokolldatei
• bei der Suche nach Verbindungen mit Remote-Hosts über die Ports 80, 8080, 3128 und 9080 in der TCP-Tabelle

Suche nach einem Proxy in der eigenen Protokolldatei:

Suche in aktiven Verbindungen:

BackDoor.Logtu.1 kann Proxyserver-Adressen wie folgt abrufen:

• aus der Registry HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer;
• aus dem Bereich HKU der Registry mithilfe der SID eines aktiven Nutzers
• über WinHTTP API WinHttpGetProxyForUrl durch eine Anfrage an google.com.

BackDoor.Skeye.1 kann Proxyserver-Adressen wie folgt abrufen:

• aus dem Bereich HKCU Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer;
• aus dem Bereich HKU mithilfe der SID eines aktiven Nutzers
• bei der Suche nach Verbindungen mit Remote-Hosts über die Ports 80, 8080, 3128 und 9080 in der TCP-Tabelle

Überschneidungen in der Netzwerkinfrastruktur

Einige Muster nutzten dieselbe Netzwerkinfrastruktur. Das Bild zeigt Beziehungen zwischen den Familien.

IDs

Die Muster von Logtu und Mikroceen enthalten Strings, die als IDs von Builds oder Versionen dienen. Einige davon haben dasselbe Format.

In vielen Mustern hat diese Id den Wert TEST oder test.

In BackDoor.Logtu.1 (9ea2488f07bf3edda23d9b7759c2d0c3c8501f92):

In BackDoor.Mirkoceen.11 (81bb895a833594013bc74b429fb1f24f9ec9df26):

Die Vergleichsanalyse ergab folgende Ähnlichkeiten in den betrachteten Familien:

• Logik der Protokollierung und der Protokollverschleierung
• Logik der Verbindungsherstellung mit dem Verwaltungsserver und Suchalgorithmen für Proxy-Adressen
• Genutzte Netzwerkinfrastruktur

Schlussfolgerung

Während der Untersuchung erkannten und beschrieben unsere Spezialisten mehrere Backdoor-Familien, einschließlich bereits bekannter Muster. Interessant ist, dass die Anwesenheit des ersten APT-Teams und die Funktion seiner Malware im kompromittierten Netzwerk bis 2017 unbemerkt blieb.

Die analysierten Muster enthalten ähnliche Code-Auszüge und es gibt Überschneidungen in ihrer Netzwerkinfrastruktur. Wir vermuten, dass die ermittelten Beziehungen darauf hinweisen, dass die betrachteten Backdoors von denselben Hacker-Teams entwickelt wurden.

Die Spezialisten von Doctor Web empfehlen, die Funktion wichtiger Netzwerkressourcen ständig zu überwachen und auf Ausfälle zu achten, da diese von Malware im Netzwerk zeugen könnten. Die Gefahr besteht nicht nur darin, dass Unternehmensdaten kompromittiert werden können, sondern auch darin, dass Cyberkriminelle jahrelang im Netzwerk eines Unternehmens anwesend sein, dessen Funktion überwachen und sich jederzeit Zugriff auf vertrauliche Informationen verschaffen können. Wenn Sie den Verdacht haben, dass Ihr Unternehmensnetzwerk infiziert wurde, wenden Sie sich an das Virenlabor von Doctor Web, das unter anderem virenbedingte Vorfälle untersucht. Umgehende Maßnahmen ermöglichen es, den Schaden auf ein Minimum zu reduzieren und schwerwiegende Auswirkungen gezielter Angriffe zu verhindern.

Merkmale der Kompromittierung