Durch ESET-Telemetriedaten sind unsere Forscher kürzlich auf Versuche der Lazarus-Gruppe zur Verbreitung von Malware mittels eines Supply-Chain-Angriffs in Südkorea gestoßen. Dabei verwendeten die Angreifer einen ungewöhnlichen Supply-Chain-Mechanismus, bei dem sie legitime südkoreanische Sicherheitssoftware und gestohlene digitale Zertifikate, von zwei verschiedenen Unternehmen, missbrauchten.

Die Cyberangriffe von Lazarus

Die Lazarus-Gruppe wurde erstmals im Februar 2016 in Novettas „Operation Blockbuster“ genannten Bericht identifiziert. US-CERT und das FBI nennen diese Gruppe HIDDEN COBRA. Bekannt wurde diese Gruppe durch den berüchtigten Cybersabotage-Angriff auf Sony Pictures Entertainment.

Einige Lazarus-Angriffe der Vergangenheit, stießen auf großes Interesse von Sicherheitsforschern, die sich bei ihren Analysen auf die Berichte von Novetta et al. stützten, die die verwendeten Angriffstools auf Hunderten von Seiten beschrieben. Die Arbeiten begründen die Zuordnung dieser Angriffe zur Lazarus-Gruppe: Die Angriffe auf polnische und mexikanische Banken, der WannaCryptor-Ausbruch, die Phishing Kampagnen gegen US-Verteidigungsunternehmen, der Lazarus KillDisk-Angriff gegen Central American Casino usw.

Wir weisen darauf hin, dass das Lazarus-Toolset (das heißt die Sammlung aller Dateien, welche von der Sicherheitsbranche als Fingerabdrücke der Gruppenaktivitäten angesehen werden) äußerst umfangreich ist und wir glauben daher, dass es zahlreiche Untergruppen gibt. Im Gegensatz zu den Toolsets anderer Cyberkrimineller, sind die Quellcodes von Lazarus-Tools niemals geleakt worden.

Der neueste Supply-Chain-Angriff von Lazarus

Um diesen neuartigen Supply-Chain-Angriff zu verstehen, sollte man wissen, dass südkoreanische Internetnutzer zum Besuch von Regierungs- oder Internetbanking-Webseiten häufig zusätzliche Sicherheitssoftware nutzen müssen.

WIZVERA VeraPort, das auch als Integrations-Installationsprogramm bezeichnet wird, ist eine südkoreanische Anwendung, mit der solche zusätzliche Sicherheitssoftware verwaltet wird. Wenn WIZVERA VeraPort auf Geräten installiert ist, installiert sie die gesamte Software, die für den Besuch bestimmter Webseiten mit VeraPort erforderlich ist (z. B. Browser-Plug-Ins, Sicherheitssoftware, Identitätsprüfungssoftware usw.). Zum Starten einer solchen Softwareinstallation von einer Website mit WIZVERA VeraPort-Unterstützung, ist nur eine minimale Benutzerinteraktion erforderlich. Normalerweise wird diese Software von Regierungs- und Bankwebsites in Südkorea verwendet, sie ist Voraussetzung dafür, dass Benutzer auf die Dienste der Websites zugreifen können.

Abbildung 1. Ein Fenster von WIZVERA VeraPort, das dem Benutzer bei der Installation zusätzlicher Software angezeigt wird

Die Lazarus-Angreifer missbrauchten den oben Installationsmechanismus für Sicherheitssoftware, um ihre Malware von einer legitimen, aber kompromittierten Webseite auszuliefern. Es sollte aber beachtet werden, dass eine erfolgreiche Malware-Bereitstellung mit dieser Methode eine Reihe von Voraussetzungen erfüllen muss. Deshalb wurde sie in begrenzten Lazarus-Kampagnen verwendet. Für diesen Angriff ist es nötig, dass:

  • Auf dem Rechner des Opfers die WIZVERA VeraPort-Software installiert ist
  • das Opfer eine kompromittierte Website besucht, die WIZVERA VeraPort unterstützt
  • diese Website bestimmte Einträge in ihrer VeraPort-Konfigurationsdatei enthält, die es den Angreifern ermöglichen, reguläre Software in ihrem VeraPort-Softwarepaket durch ihre Malware zu ersetzen.

Wir möchten darauf hinweisen, dass, nach unserer Analyse, diese Supply-Chain-Angriffe auf Websites stattfinden, die WIZVERA VeraPort verwenden, doch nicht auf WIZVERA selbst.

Websites mit WIZVERA VeraPort-Unterstützung enthalten eine serverseitige Komponente, genauer gesagt einige JavaScript-Dateien und eine WIZVERA-Konfigurationsdatei. Die Konfigurationsdatei ist eine Base64-codierte XML-Datei, die die Website-Adresse, eine Liste der zu installierenden Software, Download-URLs und andere Parameter enthält.

Abbildung 2. Ein Beispiel für eine WIZVERA VeraPort-Konfiguration (geschwärzt durch ESET)

Diese Konfigurationsdateien werden von WIZVERA digital signiert. Nach dem Herunterladen werden sie mithilfe eines starken kryptografischen Algorithmus (RSA) überprüft. Daher können Angreifer den Inhalt dieser Konfigurationsdateien nicht einfach ändern oder eine eigene gefälschte Website einrichten. Die Angreifer können jedoch die Software ersetzen, die WIZVERA VeraPort-Benutzern von einer legitimen, aber kompromittierten Website bereitgestellt wird. Wir glauben, dass dieses Szenario von den Angreifern verwendet wurde.

Abbildung 3. Vereinfachtes Schema des von der Lazarus-Gruppe durchgeführten Angriffs auf die WIZVERA Supply Chain

Es ist zu beachten, dass WIZVERA VeraPort-Konfigurationen eine Option zum Überprüfen der digitalen Signatur heruntergeladener Binärdateien enthalten, bevor diese ausgeführt werden. In den meisten Fällen ist diese Option standardmäßig aktiviert. VeraPort überprüft allerdings nur, ob die digitale Signatur gültig ist, ohne zu überprüfen, wem sie gehört. Daher müssen die Angreifer, um WIZVERA VeraPort zu missbrauchen, nur über ein gültiges Code-Signatur-Zertifikat verfügen, um ihre Nutzdaten über diese Methode zu übertragen. Oder sie finden, mit etwas Glück eine VeraPort-Konfiguration, für die keine Code-Signatur-Überprüfung erforderlich ist.

Bisher konnten wir zwei Malware-Beispiele beobachtet, die mit diesem Supply-Chain-Angriff ausgeliefert wurden, beide waren signiert:

SHA-1 Filename Digital signature
3D311117D09F4A6AD300E471C2FB2B3C63344B1D Delfino.exe ALEXIS SECURITY GROUP, LLC
3ABFEC6FC3445759730789D4322B0BE73DC695C7 MagicLineNPIZ.exe DREAM SECURITY USA INC

Die Angreifer verwendeten dabei gestohlene Zertifikate zur Code-Signatur ihrer Malware. Interessanterweise war eines dieser Zertifikate für die US-Niederlassung eines südkoreanischen Sicherheitsunternehmens ausgestellt worden.

Abbildung 4. Das Code-Signaturzertifikat der ALEXIS SECURITY GROUP LLC zum Signieren von Lazarus-Malware

Abbildung 5. Das Codesignaturzertifikat von DREAM SECURITY USA INC, mit dem Lazarus-Malware signiert wurde

Die Angreifer tarnten die Lazarus-Malware-Samples als legitime Software. Diese Samples haben ähnliche Dateinamen, Symbole und VERSIONINFO-Angaben wie legitime südkoreanische Software, die häufig über WIZVERA VeraPort bereitgestellt wird. Binärdateien, die über den WIZVERA VeraPort-Mechanismus heruntergeladen und ausgeführt werden, werden in %Temp%\[12_RANDOM_DIGITS]\ gespeichert.

Die Konfiguration von WIZVERA VeraPort bietet nicht nur die Option, digitale Signaturen zu überprüfen, sondern auch den Hash der heruntergeladenen Binärdateien. Falls diese Option aktiviert ist, kann ein solcher Angriff nicht so leicht durchgeführt werden, selbst wenn die Website mit WIZVERA VeraPort kompromittiert wurde.

Wer hinter den Angriffen steckt

Wir schreiben diesen Supply-Chain-Angriff entschieden der Lazarus-Gruppe zu. Dies geschieht auf Basis der folgenden Aspekte:

  1. Zuschreibung in der Sicherheitscommunity: Der aktuelle Angriff ist eine Fortsetzung der sogenannten „Operation Bookcodes“ (nach KrCERT). KrCERT schrieb diese Angriffe nicht der Lazarus-Gruppe zu, Kaspersky dies jedoch sehr wohl getan, in seinem Bericht über die APT-Trends im zweiten Quartal 2020.
  2. Eigenschaften und Erkennung des Angriffs-Toolsets:
    1. Der initiale Dropper ist eine Konsolenanwendung, die Parameter benötig und die nächsten Schritte in einer Kaskade ausführt. Dabei wird die gleiche Verschlüsselung verwendet, wie für die Watering-Hole-Attacken gegen polnische und mexikanische Banken.
    2. Die endgültige Nutzlast ist ein RAT-Modul mit TCP-Kommunikation, dessen Befehle durch 32-Bit-Ganzzahlen indiziert sind, wie auch bei KillDisk in Central America
    3. Viele über diese Kette ausgelieferte Tools wurden schon NukeSped-Erkennung von ESET geflagt. Beispielsweise wird der Downloader im Abschnitt "Analyse" von den Malware-Autoren als WinHttpClient bezeichnet und führt zu einem ähnlichen Tool mit dem Hash 1EA7481878F0D9053CCD81B4589CECAEFC306CF2, das wir mit einem Sample aus Operation Blockbuster (CB818BE1FCE5393A83FBFCB3B6F4AC5A3B5B8A4B) in Zusammenhang bringen. Die Verbindung zwischen den beiden letzteren besteht in der dynamischen Auflösung von Windows-APIs, bei denen die Namen mit 0x23 XOR-verschlüsselt sind, z.B. dFWwLHFMjMELQNBWJLM codiert GetTokenInformation.
  3. Opferforschung: Die Lazarus-Gruppe verbindet eine lange Geschichte mit Angriffen auf südkoreanische Opfer wie bei Operation Troy, aber auch den DDoS-Angriffen 10 Days of Rain im Jahr 2011, südkoreanischen Cyberangriffen im Jahr 2013 oder Angriffen auf südkoreanische Krypto-Währungsbörsen im Jahr 2017.
  4. Netzwerkinfrastruktur: Die serverseitigen Techniken von Webshells und die Organisation der C&C-Server werden im KrCERT-Whitepaper Nr. 2 sehr genau beschrieben. Bei der aktuellen Kampagne wird ein sehr ähnliches Setup verwendet.
  5. Exzentrischer Erklärungsansatz:
    1. Intrusion-Techniken: Die ungewöhnliche Infiltrationsmethode passt zu einem hoch entwickelten und professionell organisierten Akteur wie Lazarus. Schon in der Vergangenheit konnten wir beobachten, wie eine Software-Sicherheitslücke, die nur in bestimmten Netzwerken vorhanden war, von dieser, und sonst bei keiner anderen, APT-Gruppe ausgenutzt wurde. Zum Beispiel der Fall von „A Strange Coinminer“, der über die ManageEngine Desktop Central-Software bereitgestellt wird.
    2. Verschlüsselungsmethoden: Wir haben eine Spritz-Variante von RC4 bei den Watering-Hole-Attacken gegen polnische und mexikanische Banken gesehen; später verwendete Lazarus einen modifizierten RC4 in Operation In(ter)ception. In dieser Kampagne handelt es sich um eine modifizierte A5/1-Stream-Verschlüsselung.

Malware-Analyse

Es ist ein gemeinsames Merkmal vieler APT-Gruppen, insbesondere von Lazarus, dass sie ihr Arsenal in mehreren Schritten freisetzen, die als Kaskade ausgeführt werden: vom Dropper über Zwischenstufen (der Loader, der als Injektor dient) bis zu den endgültigen Payloads (dem Downloader, das Modul). Gleiches gilt für diese Kampagne.

Bei unserer Analyse haben wir Ähnlichkeiten in Bezug auf Code und Architektur festgestellt, zwischen der Lazarus-Malware für diesen WIZVERA-Supply-Chain-Angriff und der Malware, die im diesjährigen „Operation BookCodes“-Bericht (Teil 1, Teil 2) der Korea Internet & Security Agency beschrieben ist.

Vergleich mit Operation BookCodes

Tabelle 1: Gemeinsame Merkmale zwischen zwei Lazarus-Operationen

Parameter/ Campaign Operation BookCodes Via WIZVERA Vera Port
Location of targets South Korea South Korea
Time Q1-Q2 2020 Q2-Q3 2020
Methods of compromise Korean spearphishing email (link to download or HWP attachment)
Watering hole website
Supply-chain attack
Filename of the dropper C:\Windows\SoftwareDistribution\Download\BIT[4-5digits].tmp C:\Windows\SoftwareDistribution\Download\BIT388293.tmp
Binary configuration file perf91nc.inf (12000 bytes) assocnet.inf (8348 bytes)
Loader name nwsapagentmonsvc.dll Btserv.dll
iasregmonsvc.dll
RC4 key 1qaz2wsx3edc4rfv5tgb$%^&*!@#$ 1q2w3e4r!@#$%^&*
Log file %Temp%\services_dll.log %Temp%\server_dll.log

Signierter initialer Downloader

Diese Lazarus-Komponente wird über den zuvor beschriebenen VeraPort-Hijack bereitgestellt. Die signierten initialen Downloader sind Themida-geschützte Binärdateien, die andere Nutzdaten im Speicher herunterladen, entschlüsseln und ausführen, ohne sie auf der Festplatte abzulegen. Dieser Downloader sendet eine HTTP-POST-Anforderung an einen fest codierten C&C-Server, entschlüsselt die Antwort des Servers mithilfe des RC4-Algorithmus und führt sie mit seinem eigenen Loader für PE-Dateien im Speicher aus.

Abbildung 6. Die POST-Anforderung des ersten Downloaders

Interessanterweise senden beide entdeckten Samples eine kleine, fest codierte ID im Body der POST-Anforderung: MagicLineNPIZ.gif or delfino.gif.

Abbildung 7. Schema der initialen Kompromittierung

Der Dropper

Dies ist die erste Stufe der Kaskade. Während man im Code keinerlei Polymorphismus oder Verschleierung sehen kann, enthält sie drei verschlüsselte Dateien. Darüber hinaus erwartet die Konsolenanwendung drei Parameter in einem verschlüsselten Zustand: den Namen der ersten Datei (der Loader, Btserv.dll), den Namen der zweiten Datei (Downloader, bcyp655.tlb) und den erforderlichen Entschlüsselungsschlüssel für die vorherigen Werte (542).

BIT388293.tmp oJaRh5CUzIaOjg== aGlzejw/PyR+Zmg= 542

Die Extraktion von Ressourcen ist eine von zwei Hauptrollen der Dropper. Dies geschieht im Ordner %WINDOWS%\SYSTEM32, wobei der Loader entschlüsselt wird und der verschlüsselte Status des Downloaders beibehalten wird, der erst unmittelbar vor der Injektion in einen anderen Prozess entschlüsselt wird. Außerdem wird die Konfigurationsdatei assocnet.inf heruntergeladen, die später von der endgültigen Payload, nämlich dem Downloader und dem Modul, genutzt wird. Anschließend wählt er einen Dienst aus, indem es die folgende Liste von drei legitimen Dienstnamen überprüft: Winmgmt; ProfSvc; wmiApSrv; und den Downloader unter Verwendung einer Reflective DLL-Injection in den angepassten Dienst injiziert.

Der Dateiname des Loaders wird im folgenden Windows-Registrierungswert gespeichert:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages

Abbildung 8. Der dekompilierte Code des Droppers

Der Loader

Diese Komponente ist eine durch Themida geschützte Datei. Wir schätzen die Version von Themida auf 2,0-2,5, was mit dem Bericht von KrCERT (Seite 20) übereinstimmt. Der Loader dient als einfacher Injektor, der in den Ressourcen nach seinen Injektionsparametern sucht: dem Namen der verschlüsselten Datei und dem Entschlüsselungsschlüssel, der die Zeichenfolge „542“ ist. Die vom Dropper gelieferte Instanz sucht nach der Datei bcyp655.tlb (dem Downloader). Es wird ein Mutex Global\RRfreshRA_Mutex_Object erstellt. Die Wahl des Zieldienstes und der Injektionsmethode ist die gleiche wie beim Dropper.

Lassen Sie uns hier etwas über die Verschlüsselungsmethode sprechen, die vom Dropper und vom Loader verwendet wird. Der gemeinsame Schlüssel ist die Zeichenfolge „542“, die zunächst als Befehlszeilenparameter für den Dropper und anschließend als 3-Byte-verschlüsselte Ressource für den Loader bereitgestellt wird. Um einen kurzen Hauptschlüssel zu einem größeren erweiterten Schlüssel zu erweitern (so genanntes key scheduling), wird der MD5-Hash der Zeichenfolge berechnet, der 7DCD340D84F762EBA80AA538B0C527F7 lautet. Dann nimmt es die ersten drei Doppelwörter, bezeichnen wir sie als A:= 0x7DCD340D, B:= 0x84f762EB, C:= 0xA80aa538. Die Länge eines verschlüsselten Puffers wird durch 3 geteilt, und dies ist die Anzahl der Iterationen, die die Anfangssequenz (A, B, C) in den richtigen Schlüssel umwandeln. In jeder Iteration wird (X, Y, Z) zu (X ^ Y, Y ^ Z, X ^ Y ^ Z). Da die XOR-Operation (mit ^ bezeichnet) kommutativ und transitiv ist und ihr Quadrat Null ist (wodurch alles unverändert bleibt) können wir berechnen, dass wir nach 8 Iterationen die Identität erhalten, sodass der Schlüssel nur 7 paarweise unterschiedliche Zustände erreichen kann. Er ist gleich den ersten 12 Zeichen des MD5-Hash von "542", wenn die Länge ein Vielfaches von 24 ist.

Interessant ist, wie der Rest der Längenteilung durch 3 behandelt wird. Wenn die Anzahl der Iterationen um diesen Rest erhöht würde, würden wir nur einen weiteren der 7 Zustände des Schlüssels erreichen. Der Clou liegt jedoch in der Änderung der Operation: ^ wird für den Rest durch die ODER-Operation im Code ersetzt. Zum Beispiel wird der Schlüssel mit dem Rest 1 zu {FE F7 3A F9 F7 D7 FF FD FF F7 FF FD} für einen der Zustände (von (C, A ^ B, B ^ C) um genau zu sein), also erhalten wir neue mögliche Transformationen des Schlüssels, bei denen es sich eher um Einsen als um Nullen handelt.

Das war der Teil, der den Schlüssel vorbereitete. Der Verschlüsselungsalgorithmus selbst sieht auf den ersten Blick wie A5/1 aus. Es war eine geheime Technologie, die 1987 entwickelt und im GSM-Mobilfunkstandard für den Schutz der drahtlosen Kommunikation verwendet wurde, bis sie im Jahr 1999 durch Reverse Engineering enthüllt wurde. Der entscheidende Teil des Algorithmus sind drei lineare Rückkopplungsschieberegister (linear feedback shift registers, LFSRs). Allerdings stimmen nur die Längen der LFSRs im Malware-Code mit der offiziellen Implementierung überein, nicht die Konstanten.

Tabelle 2: Vergleich der Krypto-Algorithmen zwischen der Malware und der offiziellen Implementierung

LFSR Malware code Official A5/1
1 Length: 19 Length: 19
Constants: 13, 16, 17, 18 Constants: 13, 16, 17, 18
2 Length: 22 Length: 22
Constants: 12, 16, 20, 21 Constants: 20, 21
3 Length: 23 Length: 23
Constants: 17,18,21,22 Constants: 7, 20, 21, 22

Die Entschlüsselungsschleife in jeder Iteration leitet grundsätzlich einen 1-Byte-XOR-Schlüssel für das entsprechende Byte des verschlüsselten Puffers ab. Der Zweck von LFSRs besteht darin, dass sie den Schlüssel transformieren können, sodass der gesamte Prozess viel komplizierter ist. Aufgrund der erwähnten Änderung der Operation würden LFSRs diese jedoch nicht beeinflussen, und der 1-Byte-XOR-Schlüssel bleibt für alle Iterationen gleich.

Der Downloader, auch bekannt als WinHttpClient

Der Haupt-Downloader wird von der Dropper-Komponente unter dem Namen bcyp655.tlb gedroppt und vom Loader in einen der Dienste eingefügt. Ihr Hauptzweck besteht darin, zusätzliche Stufen der Malware auf den Computer des Opfers zu übertragen. Das Netzwerkprotokoll basiert auf HTTP, erfordert jedoch mehrere Schritte, um eine vertrauenswürdige Verbindung herzustellen.

Die Malware-Fingerabdrücke auf dem System des Opfers: siehe Abbildung 9.

Abbildung 9: Die Länge des Puffers beträgt 0x114 und enthält die Kampagnen-ID, die lokale IP-Adresse, die Windows-Version und die Prozessorversion (siehe KrCERT Seite 59, Abbildung [4-17]).

Der erste Schritt ist die Autorisierung. Nach dem Senden von zufällig generierten generischen Parametercodes und IDs beginnt die erwartete Antwort mit <!DOCTYPE HTML PUBLIC Authentication En>, gefolgt von zusätzlichen Daten, die durch ein Semikolon getrennt sind. Bei der nächsten POST-Anforderung basieren die Parameter jedoch bereits auf der IP des Opfers. Da wir nicht wussten, welche Opfer betroffen waren, hatten wir während unserer Untersuchung immer die Antwort "Nicht gefunden" erhalten, nicht das erfolgreiche "OK".

Abbildung 10. Primärer Nachrichtenaustausch mit dem C&C mit generischem Parametercode und ID

Abbildung 11. Sekundärer Nachrichtenaustausch mit dem C&C mit einem bestimmten Parameternamen

Wenn das Opfer diese einleitenden Nachrichten weitergibt und die Verbindung bestätigt wird, beginnt die entschlüsselte Antwort mit einem interessanten Artefakt: einem Schlüsselwort ohayogonbangwa!!. Insgesamt haben wir dieses Wort im Internet nicht gefunden, aber die engste Bedeutung könnte “Owayo, Konbangwa” (おはようこんばんぐぁ) sein, was auf Japanisch "Guten Morgen, guten Abend" bedeutet. Ab diesem Zeitpunkt werden mehr Nachrichten ausgetauscht, wobei beim letzten Austausch eine ausführbare Datei zum Laden in den Speicher angefordert wird.

Abbildung 12: Japanisches Artefakt im Code

Das Modul, die endgültige RAT-Nutzlast

Dies ist ein RAT-Modul mit einer Reihe typischer Funktionen, die von der Lazarus-Gruppe verwendet werden. Die Befehle umfassen Vorgänge im Dateisystem des Opfers sowie das Herunterladen und Ausführen zusätzlicher Tools aus dem Arsenal des Angreifers. Sie werden durch 32-Bit-Ganzzahlen indiziert und stimmen mit den von KrCERT auf Seite 61 gemeldeten überein.

Abbildung 13. Einige der vom Modul unterstützten Befehle

Fazit

Angreifer suchen ständig neue Wege, um Malware auf die Computer ihrer Opfer zu bringen. An Supply-Chain-Angriffen sind Angreifer besonders interessiert, da sie es ihnen ermöglichen, Malware auf vielen Computern gleichzeitig verdeckt auszuliefern. In den letzten Jahren haben ESET-Forscher Fälle wie M.E.Doc, Elmedia Player, VestaCP, Statcounter und die Spielebranche in Asien analysiert. Wir sind sicher, dass die Anzahl der Supply-Chain-Angriffe in Zukunft zunehmen wird, insbesondere gegen Unternehmen, deren Dienstleistungen in bestimmten Regionen oder in bestimmten Branchen beliebt sind.

In diesem Artikel Mal haben wir analysiert, wie die Lazarus-Gruppe einen sehr interessanten Ansatz verwendet hat, um südkoreanische Nutzer der WIZVERA VeraPort-Software ins Visier zu nehmen. Wie in unserer Analyse erwähnt, ist es die Kombination kompromittierter Websites mit WIZVERA VeraPort-Unterstützung und spezifischen VeraPort-Konfigurationsoptionen, mit denen Angreifer diesen Angriff ausführen können. Die Betreiber dieser Websites könnten die Möglichkeit solcher Angriffe verringern, selbst dann, wenn ihre Websites kompromittiert werden. Dazu müssten sie bestimmte Optionen aktivieren (z. B. durch Angabe von Binär-Hashes in der VeraPort-Konfiguration).

Besonderer Dank geht an Dávid Gábriš und Peter Košinár.

Für Anfragen oder Sample-Einreichungen zu diesem Thema wenden Sie sich bitte an threatintel@eset.com.

Indicators of Compromise (IoCs)

ESET detection names

Win32/NukeSped.HW
Win32/NukeSped.FO
Win32/NukeSped.HG
Win32/NukeSped.HI
Win64/NukeSped.CV
Win64/NukeSped.DH
Win64/NukeSped.DI
Win64/NukeSped.DK
Win64/NukeSped.EP

SHA-1 of signed samples

3D311117D09F4A6AD300E471C2FB2B3C63344B1D
3ABFEC6FC3445759730789D4322B0BE73DC695C7

SHA-1 of samples

5CE3CDFB61F3097E5974F5A07CF0BD2186585776
FAC3FB1C20F2A56887BDBA892E470700C76C81BA
AA374FA424CC31D2E5EC8ECE2BA745C28CB4E1E8
E50AD1A7A30A385A9D0A2C0A483D85D906EF4A9C
DC72D464289102CAAF47EC318B6110ED6AF7E5E4
9F7B4004018229FAD8489B17F60AADB3281D6177
2A2839F69EC1BA74853B11F8A8505F7086F1C07A
8EDB488B5F280490102241B56F1A8A71EBEEF8E3

Code signing certificate serial numbers

00B7F19B13DE9BEE8A52FF365CED6F67FA
4C8DEF294478B7D59EE95C61FAE3D965

C&C

http://www.ikrea.or[.]kr/main/main_board.asp
http://www.fored.or[.]kr/home/board/view.php
https://www.zndance[.]com/shop/post.asp
http://www.cowp.or[.]kr/html/board/main.asp
http://www.style1.co[.]kr/main/view.asp
http://www.erpmas.co[.]kr/Member/franchise_modify.asp
https://www.wowpress.co[.]kr/customer/refuse_05.asp
https://www.quecue[.]kr/okproj/ex_join.asp
http://www.pcdesk.co[.]kr/Freeboard/mn_board.asp
http://www.gongsinet[.]kr/comm/comm_gongsi.asp
http://www.goojoo[.]net/board/banner01.asp
http://www.pgak[.]net/service/engine/release.asp

Mutexes

Global\RRfreshRA_Mutex_Object

References

KrCERT/CC, “Operation BookCodes TTPs#1 Controlling local network through vulnerable websites”, English Translation, 1st April 2020
KrCERT/CC, “Operation BookCodes TTPs#2 스피어 피싱으로 정보를 수집하는 공격망 구성 방식 분석”, Korean, 29th June 2020
P. Kálnai, M. Poslušný: “Lazarus Group: a mahjong game played in different sets of tiles”, Virus Bulletin 2018 (Montreal)
P. Kálnai: “Demystifying targeted malware used against Polish banks”, WeLiveSecurity, February 2017
P. Kálnai, A. Cherepanov “Lazarus KillDisks Central American casino”, WeLiveSecurity, April 2018
D. Breitenbacher, K. Osis: “Operation In(ter)ception: Aerospace and military companies in the crosshairs of cyberspies”, June 2020
Novetta et al, “Operation Blockbuster”, February 2016, https://www.operationblockbuster.com/resources
Marcus Hutchins, “How to accidentally stop a global cyber-attack”,  May 2015
Kaspersky GReAT: “APT trends report Q2 2020”, July 2020
A. Kasza: “The Blockbuster Saga Continues”, Palo Alto Networks, August 2017
US-CERT CISA, https://us-cert.cisa.gov/northkorea
WeLiveSecurity: “Sony Pictures hacking traced to Thai hotel as North Korea denies involvement”, December 2014
R. Sherstobitoff, I. Liba. J. Walter: “Dissecting Operation Troy: Cyberespionage in South Korea”, McAfee® Labs, May 2018
McAfee Labs: “Ten Days of Rain”, July 2011
Fireye: “Why Is North Korea So Interested in Bitcoin?”, September 2017
Choe Sang-Hun: “Computer Networks in South Korea Are Paralyzed in Cyberattacks”, March 2013
A5/1 stream cipher, https://en.wikipedia.org/wiki/A5/1

MITRE ATT&CK techniques

Note: This table was built using version 8 of the MITRE ATT&CK framework.

Tactic ID Name Description
Resource Development T1584.004 Compromise Infrastructure: Server The Lazarus group uses compromised servers as infrastructure.
T1587.001 Develop Capabilities: Malware The Lazarus group developed custom malware and malware components.
T1588.003 Obtain Capabilities: Code Signing Certificates The Lazarus group obtained code-signing certificates.
Initial Access T1195.002 Supply Chain Compromise: Compromise Software Supply Chain The Lazarus group pushed this malware using a supply-chain attack via WIZVERA VeraPort.
Execution T1106 Native API The Lazarus payload is executed using native API calls.
Persistence T1547.005 Boot or Logon Autostart Execution: Security Support Provider The Lazarus malware maintains persistence by installing an SSP DLL.
Defense Evasion T1036 Masquerading The Lazarus malware masqueraded as a South Korean security software
T1027.002 Obfuscated Files or Information: Software Packing The Lazarus group uses Themida-protected malware.
T1055 Process Injection The Lazarus malware injects itself in svchost.exe.
T1553.002 Subvert Trust Controls: Code Signing The Lazarus group used illegally obtained code-signing certificates to sign the initial downloader used in this supply-chain attack.
Command and Control T1071.001 Application Layer Protocol: Web Protocols The Lazarus malware uses HTTP for C&C.
T1573.001 Encrypted Channel: Symmetric Cryptography The Lazarus malware uses the RC4 algorithm to encrypt its C&C communications.
Exfiltration T1041 Exfiltration Over C2 Channel The Lazarus malware exfiltrates data over the C&C channel.