DISMANTLING BLACKENERGY, PART 3 – ALL ABOARD!

Entern  – the act of an Bord gehen eines feindlichen Schiffs as Teil of an Angriff.

In today’s post, I will describe a part of investigation of one cyber security incident that has eventually evolved into a global investigation connected with an attack based on BlackEnergy that has hit a number of industries in Ukraine. As we progressed through investigation and performed a systematic retrospective analysis, we have mapped the attack to the Lockheed Martin’s Cyber Kill Chain methodology and thus I will refer to its structure during my story.

PROLOG

Hier beginnt die Geschichte. Ich muss ein gewisses Maß an Diskretion wahren, daher sind die Benutzernamen und die Namen der Infrastrukturserver verschleiert und geändert. Daten und externe IP-Adressen sind jedoch unverändert und ich teile sie in demselben Zustand, wie sie in den Protokolldateien erschienen. Wir hatten folgenden Aktionsplan: Sobald wir einen Indikator der Gefährdung (IOC) entdeckten, überprüften wir ihn mit den Protokolldaten und auf Grundlage zusätzlicher Entdeckungen korrigierten wir unsere Filter und starteten dann eine weitere Suche. Wir durchforsteten systematisch Gigabyte an Protokollen und das große Ganze begann für uns klarer zu werden, was ich Ihnen in diesem Artikel mitteilen werde.

Am Sonntagmorgen, den 25. Oktober, erhielt ich einen Anruf aus unserer IT-Administrationsabteilung mit der Nachricht, dass die Domänencontroller-Server während der Nacht plötzlich heruntergefahren und nie wieder hochgefahren waren. Als unser Team vor Ort war, baten wir zuerst um die Abbilder der „abgestürzten“ Server (natürlich hatten wir virtuelle Abbilder). Die erste Analyse zeigte klar, dass beide Server ihren MBR überschrieben hatten. Wir schafften es, den MBR durch Anwendung einiger praktischer TestDisk-Tricks wiederherzustellen (https://en.wikipedia.org/wiki/TestDisk) und setzten die Analyse fort. Die Dinge wurden interessanter. Die meisten Dateien auf der Festplatte waren mit Nullen gefüllt, sodass sie alle wie gleiche Dateien mit gleicher Größe aussahen, aber im Inneren waren nur Nullen! Unter den Dateien, die überlebten, dienten einige Ereignisprotokolldateien als Ausgangspunkt, um alle anomalen Ereignisse auf der Zeitachse zu kartieren. Ich werde die entdeckten Indikatoren in umgekehrter Reihenfolge von dem Moment beschreiben, als der Vorfall passierte, bis zum Anfang (Eindringen).

KAPITEL 1. HANDLUNGEN UND ZIELE DES ANGRIFFS

Während wir mit den Protokolldaten der wiederhergestellten Domänencontroller arbeiteten, erhielten wir einen weiteren Anruf, dass ein weiterer Server mit ähnlichen Symptomen „infiziert“ wurde, diesmal jedoch ein Anwendungsserver. Also bekamen wir auch ein Abbild dieses Servers:
Wir analysierten die Ereignisse, die unmittelbar vor dem „Absturz“ auftraten, und kartierten sie auf unserer Zeitleiste:Lassen Sie mich ein wenig erklären, was genau hier angezeigt wird. Ein Bereich mit blauer Umrandung markiert die Ergebnisse der Aktionen, die wir als Serverabstürze erlebt haben. Unmittelbar vor dem Herunterfahren wurden unautorisierte Anmeldeversuche von Domänenadmin-Konten protokolliert. Zu den durchgeführten Aktionen gehört die Modifizierung des svchost.exe -Dienstes und das Starten eines untergeordneten Dienstes msDefenderSvc:

https://www.virustotal.com/en/file/f52869474834be5a6b5df7f8f0c46cbc7e9b22fa5cb30bee0f363ec6eb056b95/analysis/Links davon gibt es ein weiteres interessantes Ereignis, das beweist, dass die globale Richtlinie geändert wurde:

Ohne große Vermutungen und durch einen Blick auf den Skriptinhalt sehen wir, dass beim Anmelden eines Benutzers am PC eine Datei namens ololo.exe (die ich teilweise rückübersetzt und hier beschrieben habe: https://socprime.com/en/blog/dismantling-killdisk-reverse-of-the-blackenergy-destructive-component/) automatisch von einem Netzwerkfreigabe heruntergeladen wird.

Darüber hinaus haben wir durch die Analyse der Protokolle der Workstations (ein wenig vorauseilend möchte ich sagen, dass wir die Protokolle von über hundert Workstations überprüft haben) die folgende Anomalie entdeckt: eine Reihe von Ereignissen, die von privilegierten Benutzern stammen, die geplante Aufgaben auf Benutzer-PCs geändert haben:

So sah das Ereignis in den Protokollen des Domänencontrollers aus:

Und so zeigte es sich auf dem Benutzer-PC:

Dies war im Grunde ein „Todesschuss“, nur für den Fall, dass der Domänencontroller seine Aufgabe nicht abschließen und früher abstürzt, als er die Gruppenrichtlinie auf die Workstations verbreiten kann. Infolgedessen können wir diesen Teil des Angriffs eindeutig den „Handlungen zu Zielen“ des Kill-Chain-Modells zuordnen. In diesem Fall besteht das Ziel darin, die Daten auf der größtmöglichen Anzahl von PCs zu zerstören.

KAPITEL 2. „INSTALLATION UND AUSNUTZUNG“ ALIAS BEREITSTELLUNG VON BLACKENERGY DURCH AUSNUTZUNG VON SCHWACHSTELLEN.

Was passierte also, bevor die Gegner Zugang zu den Servern erhielten? Durch die Analyse der Ereignisprotokolle haben wir folgende Abfolge der Ereignisse entdeckt:Beschreibung der nummerierten Angriffsphasen:

1 & 2 – unautorisierter VPN-Zugang und sofortiger RDP-Zugang zu Domänencontrollern

3 – Installation des VBoxDrv.sys (CVE-2008-3431) -Dienstes. Dieser Schritt war erforderlich, um die Treibersignaturdurchsetzung (DSE, Driver Signature Enforcement ist eine obligatorische Prüfung von Treibersignaturen) ohne Neustart zu umgehen ( http://www.coresecurity.com/content/virtualbox-privilege-escalation-vulnerability ).

4 – da die DSE im Rahmen des vorherigen Schritts neutralisiert wurde, stellt die Installation von selbstsignierten Treibern adpu320.sys and amdide.sys kein Problem mehr dar.

Beide .sys-Dateien haben denselben Hash-Wert. Seit dem 06.11.2015 konnten nur 2 Antivirenlösungen sie erkennen, aber selbst damals war klar, dass wir es mit BlackEnergy (beide Domänencontroller hatten eine Antivirenlösung laufen, aber es war nicht eine der beiden, die es erkennen konnten):4 Tage später erkannten bereits 12 Antiviren diese Muster.

Daraus können wir schließen, dass diese Angriffsphase erfolgreich den Phasen „Installation“ und „Ausnutzung“ des Cyber-Kill-Chain-Modells zugeordnet werden kann.

KAPITEL 3. „HANDLUNGEN ZU ZIELEN“, „AUFKLÄRUNG“

Es ist offensichtlich, dass die Administratoren-Konten kompromittiert wurden, und es ist vernünftig zu vermuten, dass auch deren Workstations unautorisiertem Zugriff ausgesetzt waren. Basierend auf der Analyse ihrer Workstation-Protokolle (und einigen Hunderten von anderen Workstations) wurde eine anomale Aktivität im Zusammenhang mit der Nutzung des Remote-Verwaltungsdienstprogramms von Sysinternals -Suite PsExec entdeckt:

Die Zeitleiste oben zeigt ein Fragment der Aktivität im Zusammenhang mit der Datensammlung von den Workstations.

Und so sieht das Ereignis in den Workstation-Protokollen aus:

Diese Phase kann erneut dem Cyber-Kill-Chain-Modell zugeordnet werden, mit entsprechender Zuordnung zu „Aufklärung“ und „Handlungen zu Zielen“ (die Ziele sind die Datensammlung über die Infrastruktur und die Benutzer). Ich habe diese Phase auch zu „Aufklärung“ zugeordnet, da es stark vermutet wird, dass die Gegner zusätzliche Daten von den Workstations gesammelt haben, um ihren Angriff weiter zu inszenieren.

KAPITEL 4. „BEFEHL UND KONTROLLE (C2)“, KOMMUNIKATION MIT BLACKENERGY-SERVERN

Wir führten eine parallele Analyse sowohl der Workstation-Protokolle als auch der Firewall-Protokolle durch. Da klar war, dass BlackEnergy uns angreift, nutzten wir alle veröffentlichten Forschungen und Artikel zu diesem Thema, um die Kommunikation mit bekannten Kommandozentralen zu überprüfen:Wie in diesem Teil der Zeitleiste zu sehen ist, verfolgen wir den Verlauf des Angriffs bis zurück zum Mai 2015! Der 15.05.2015 ist der Tag, an dem die erste Kommunikation mit einem der bekannten Befehls- und Kontrollserver, der ebenfalls Teil des Tor-Netzwerks ist (5.149.254.114), stattfand.

Unglücklicherweise enthielt eine Workstation, die die Kommunikation mit diesem Kommandozentrum führte, auch eine Datei mit Passwörtern für mehrere YouTube-Profile, und am 22.05.2015 wurden diese Konten gehackt. Der Hack wurde von zwei weiteren Servern aus durchgeführt 185.61.138.143 and 46.28.68.158 (wieder Tor-Knoten) mit gefälschten E-Mail-Adressen und Wiederherstellungstelefonnummern. Durch den Angriff wurde kein wesentlicher Schaden verursacht, und zu dieser Zeit sah es nicht einmal wie ein gezielter Hack aus. Die Konten wurden schnell wiederhergestellt, eine Zwei-Faktor-Authentifizierung hinzugefügt, Schlussfolgerungen gezogen und der Vorfall wurde bis November 2015 geschlossen gehalten – der Tag, an dem er eindeutig Teil eines größeren Puzzles wurde!

Ich glaube, dass diese Angriffsphase als „Befehl & Kontrolle (C2)“ kategorisiert werden kann:

KAPITEL 5. „ZUSTELLUNG“ DER BLACKENERGY-MODULE

Wir erhielten eine Liste aller Workstations, die die Kommunikation mit Kommandozentralen aus den Firewall-Protokollen durchgeführt hatten, und erstellten einen Filter basierend auf den IP-Adressen dieser Workstations. Dieser Filter wurde verwendet, um die gesamte Aktivität dieser Maschinen im Jahr 2015 zu durchsuchen, um Anomalien und Muster zu finden. Die Muster wurden gefunden. Eine gemeinsame Verbindung (neben einer Anzahl gewöhnlicher Server wie Google oder Facebook/VK/Twitter etc.) stellte sich als ein einzelner Server mit einer IP-Adresse von 176.53.127.194 (und wieder ist dies ein Tor-Knoten!) heraus:

Am 23.04.2015 erhielt einer der Mitarbeiter eine gewöhnliche E-Mail, die bei näherer Betrachtung einige interessante Details aufwies (natürlich zum Zeitpunkt der Untersuchung, mehr als ein halbes Jahr nachdem die E-Mail geöffnet wurde):
Werfen wir zunächst einen Blick auf die E-Mail-Header:

Empfangen: von mx1-mail.com (mx1-mail.com [5.149.248.67]) Do, 23. Apr 2015 09:43:45 +0300

Empfangen: von webmail.rada.gov.ua (port=80 helo=webmail.rada.gov.ua)

von mx1-mail.com [5.149.248.67] mit esmtp (Absender <info@rada.gov.ua>)

Von: «info@rada.gov.ua» <info@rada.gov.ua>

Rückweg: info@rada.gov.ua

5.149.248.67 – eine bereits bekannte IP-Adresse, die für das Senden ähnlicher E-Mails an andere Organisationen verwendet wurde (https://cys-centrum.com/ru/news/black_energy_2_3).

Bezüglich des Anhangs enthält eine .xls-Datei das folgende Makro:

By putting together all 864 elements of the array А, as an output we will receive vba_macro.exe, das ist in Wirklichkeit ein BlackEnergy-Dropper

https://www.virustotal.com/ru/file/ca7a8180996a98e718f427837f9d52453b78d0a307e06e1866db4d4ce969d525/analysis/1458721530/

https://www.hybrid-analysis.com/sample/ca7a8180996a98e718f427837f9d52453b78d0a307e06e1866db4d4ce969d525?environmentId=1Dropper stellt eine Verbindung zu einem uns bereits bekannten Kommandozentrum her:Danach erhält die Malware weitere „Anweisungen“, formt eine Datei namens FONTCACHE.DAT, und lädt sie mithilfe von rundll32.exe da FONTCACHE.DAT ist tatsächlich eine Variante von packet.dll – zurück aus der Hacker-Enzyklopädie 2002, entwickelt von Whirlwind Software für Windows-Betriebssysteme:C:WINDOWSsystem32rundll32.exe C:WINDOWSsystem32rundll32.exe" "C:Documents and Settings<USER>Local SettingsApplication DataFONTCACHE.DAT"Dann schreibt es dies in den Autostart:C:Documents and Settings<USER>Start MenuProgramsStartup{22A16F66-CB92-4B66-8BDE-26B5CD34553F}.lnkNun lass uns einen genaueren Blick auf das Bild im E-Mail-Footer werfen, das nicht laden konnte:Ein Link zu unserem „Bild“ sieht folgendermaßen aus:src=”http://176.53.127.194/bWFpbF9pdmFub3YuaXZhbkBkb21lbi51YQ==.pngNach einigem Base64-Decodieren verwandelt es sich in:src=”http://176.53.127.194/mail_ivanov.ivan@domen.ua.pngDaher ist dies ein Alarm für die Gegner, der bestätigt, dass Ivan Ivanov erfolgreich eine E-Mail geöffnet hat und bereit ist, „weitere Anweisungen zu erhalten“.

Ich möchte noch einmal betonen, dass es im April nur eine E-Mail gab, die nur einen Empfänger hatte.

Jetzt schauen wir uns die E-Mails an, die im Juli eingegangen sind (Massenversand an über 2000 Adressen). Ein gemeinsames Muster ist, dass alle E-Mails denselben „Marker“ enthalten, der an die gleiche IP zurückmeldete (176.53.127.194) und den Empfänger genau identifiziert hat. Es handelte sich also nicht nur um eine Spam-Kampagne, sondern um eine gezielte Kampagne, und der einzige Unterschied war das Fehlen des Präfixes „mail_“ in der dekodierten Nachricht:

Die gleiche IP-Adresse im Header:

Received: from mx1-mail.com (mx1-mail.com [5.149.248.67]) by

Received: from webmail.rada.gov.ua (port=80 helo=webmail.rada.gov.ua)

by  mx1-mail.com [5.149.248.67] mit esmtp (envelope-from  <pravyysektor@rada.gov.ua>)

Von: „pravyysektor@rada.gov.ua“ <pravyysektor@rada.gov.ua>

Datum: Di, 28 Jul 2015 09:08:38 +0200

Return-Path: pravyysektor@rada.gov.ua

Briefinhalt, der deutlich unseren „Marker“ zeigt:Trotz der Tatsache, dass Massenversand die gesamte Firma ansprach, offensichtlich ein Spam, und dass E-Mails mit einem solchen Text verboten sind, öffnen einige Nutzer dennoch die E-Mail, was zu einem Ausbruch der Kommunikation mit einem bekannten Command-and-Control-Center führte:Wie auf der Zeitleiste zu sehen, lud die erste Kommunikation 28.863 Bytes herunter, die nächste bereits 359.276 Bytes usw. Die Kommunikationen hatten eine klare Reihenfolge und klare Struktur:

Es besteht kein Zweifel daran, diese Phase des Angriffs als „Zustellung“ zu klassifizieren:

Wie wir sehen können, hat der Angriff alle Anzeichen der APT-Struktur, die klar durch die Cyber-Kill-Chain-Methodik beschrieben werden können.

BEWERTUNG DER KONSEQUENZEN

Auf der negativen Seite: Die Daten wurden auf zwei Domänencontrollern, einem Anwendungsserver und etwas mehr als einem Dutzend PCs zerstört.Auf der positiven Seite der Dinge:  Wir haben einen kostenlosen Penetrationstest erhalten, unbezahlbare Erfahrungen mit realen APT-Untersuchungen gesammelt, wir haben eine Reihe von Tools erstellt/angepasst, die nicht nur unsere Arbeit mit Log-Verarbeitung, sondern auch Malware-Rückanalyse automatisieren (aber ich greife vorweg, das ist ein Thema für einen weiteren Artikel). Die Geschäftsleitung hat ein viel besseres Verständnis für den Zweck von InfoSec bekommen (unbezahlbar!). Diese einzelne Demonstration einer realen Bedrohung und der darauffolgenden Untersuchung hat uns mehr geholfen als frühere Bedenken oder hypothetische Bedrohungen zu äußern. Gründliche Teamarbeit mit IT-Administratoren hat unsere professionelle Zusammenarbeit auf die nächste Stufe gebracht. Daher betrachte ich diese Ereignisse als echtes Cyber-Kampftraining und die besten Lektionen, um ein echtes Verständnis für die Methoden und Techniken des Gegners zu erhalten.

Abschließend möchte ich sagen, dass viele Dinge aus dem Artikel ausgelassen wurden und einige Stücke noch gründlich untersucht werden.

Es gibt zwei Ziele, die ich mit der Veröffentlichung dieser Untersuchung erreichen möchte:

1. Um zu zeigen, dass auf der einen Seite, BlackEnergy ist kein Mega-Monster, das auf einen unbewohnbaren Planeten geworfen werden kann und dass nach einem halben Jahr seine eigene Operationsbasis aufbauen kann, die sein Überleben sichern kann 🙂 Auf der anderen Seite, es ist ein mächtiges und spezialisiertes Werkzeug, das in den Händen eines Spezialisten großen Schaden beim Opfer des Angriffs anrichten kann.
2. Um zu unterstreichen, dass ein Angriff, der BlackEnergy einsetzt, nur eines der Beispiele für die Entwicklung von Technologien ist, die aktiv von Cyberkriminellen genutzt werden. Dies sind keine einfachen Cyber-Überfälle, wir haben es mit fein organisierten und präzise geplanten Operationen zu tun, ähnlich denen, die von militärischen Spezialeinheiten durchgeführt werden (das Artikelbild wurde aufgrund dieser Assoziation gewählt).

Basierend auf dem obigen können wir eines der Szenarien für die Nutzung solcher Informationen erstellen: Warum sollte man eine Bank hacken müssen, wenn man einfach Zugang zu einer Infrastruktur eines Zulieferunternehmens kaufen kann, das eine ständige Site-to-Site-VPN-Verbindung hat und einen „offiziell autorisierten“ Zugang erhält (wir können uns auf einen Cartoon über eine Bank und einen Hausmeister beziehen: https://www.youtube.com/watch?v=fB2b-lTjCQA ).

Wie üblich, wäre ich allen dankbar, die ihre Log-Daten nach den erwähnten Indikatoren (IOC’s) nach dem Lesen des Artikels überprüfen.

In den nachfolgenden Artikeln werde ich einige Methoden teilen, die es ermöglichen, bestimmte Indikatoren der gegnerischen Aktivitäten, die beschrieben wurden, zu erkennen, und ein Komplex von organisatorischen und technischen Maßnahmen aufzubauen, die darauf abzielen, die Wahrscheinlichkeit solcher Vorfälle in einer Organisation zu minimieren oder zumindest die Wahrscheinlichkeit ihrer schnellen Entdeckung zu erhöhen.

CREDITS

Großer Dank geht an meine Kollegen für ihren Enthusiasmus, ihre Hartnäckigkeit und eine gut gemachte Arbeit. Ich möchte Marina Krotofil und dem Team von Andrii Bezverkhyi für ihre Hilfe bei der Vorbereitung der Analyse und des Artikels ausdrücklichen Dank aussprechen. Zusätzlicher Dank geht an HPE , LanTec and SOC Prime für materielle und technische Hilfe mit Hardware und Software, die während der Untersuchung und der Bekämpfung des Angriffs bereitgestellt wurden.

Übersetzt aus dem Original von Andrii Bezverkhyi | Geschäftsführer SOC Prime