Attaque de la chaîne d’approvisionnement de Lazarus en Corée du Sud | WeLiveSecurity

Attaque de la chaîne d’approvisionnement de Lazarus en Corée du Sud

Les chercheurs d'ESET découvrent une nouvelle attaque de la chaîne d'approvisionnement de Lazarus utilisant le logiciel WIZVERA VeraPort

Les chercheurs d’ESET découvrent une nouvelle attaque de la chaîne d’approvisionnement de Lazarus utilisant le logiciel WIZVERA VeraPort

Les données de télémétrie d’ESET ont récemment conduit nos chercheurs à découvrir des tentatives de déploiement du logiciel malveillant Lazarus via une attaque de la chaîne d’approvisionnement en Corée du Sud. Afin de livrer son logiciel malveillant, les attaquants ont utilisé un mécanisme inhabituel de la chaîne d’approvisionnement, en abusant de logiciels de sécurité sud-coréens légitimes et de certificats numériques volés à deux sociétés différentes.

Coffre à outils de Lazarus

Le groupe Lazarus a été identifié pour la première fois dans le rapport de Novetta Operation Blockbuster en février 2016. L’US-CERT et le FBI appellent ce groupe HIDDEN COBRA. Ces cybercriminels ont pris de l’importance avec l’infâme affaire de cybersabotage contre Sony Pictures Entertainment.

Certaines des attaques passées attribuées au groupe Lazarus ont attiré l’attention des chercheurs en sécurité qui se sont appuyés sur les livres blancs de Novetta et al. avec des centaines de pages décrivant les outils utilisés dans les attaques – les banques polonaises et mexicaines, la propagation de WannaCryptor, les campagnes d’hameçonnage contre des entrepreneurs du milieu de la défense américains, l’attaque Lazarus KillDisk contre le casino d’Amérique centrale, etc. – et fournit des éléments permettant d’attribuer ces attaques au groupe Lazarus.

Notez que la panoplie d’outils de Lazarus (c’est-à-dire la collection de tous les fichiers qui sont considérés par l’industrie de la sécurité comme des empreintes digitales de l’activité du groupe) est extrêmement large, et nous pensons qu’il existe de nombreux sous-groupes. Contrairement aux jeux d’outils utilisés par certains autres groupes cybercriminels, aucun des codes sources des outils Lazarus n’a jamais été divulgué dans une fuite publique.

Dernière attaque de la chaîne d’approvisionnement de Lazarus

Pour comprendre cette nouvelle attaque de la chaîne d’approvisionnement, vous devez savoir que les internautes sud-coréens sont souvent invités à installer des logiciels de sécurité supplémentaires lorsqu’ils visitent des sites web gouvernementaux ou bancaires sur Internet.

WIZVERA VeraPort, appelé programme d’installation d’intégration, est une application sud-coréenne qui aide à gérer ces logiciels de sécurité supplémentaires. Une fois WIZVERA VeraPort installé sur leur appareil, les utilisateurs reçoivent et installent tous les logiciels nécessaires à un site web spécifique avec VeraPort (par exemple, des plug-ins de navigateur, des logiciels de sécurité, des logiciels de vérification d’identité, etc.) ). Une interaction minimale de l’utilisateur est nécessaire pour démarrer une telle installation de logiciel à partir d’un site web qui supporte WIZVERA VeraPort. En Corée du Sud, ce logiciel est généralement utilisé par les sites web du gouvernement et des banques. Pour certains de ces sites, il est obligatoire d’avoir installé WIZVERA VeraPort pour que les utilisateurs puissent accéder aux services du site.

Figure 1. Une fenêtre WIZVERA VeraPort affichée à l’utilisateur lors de l’installation d’un logiciel supplémentaire

Les attaquants de Lazarus ont abusé du mécanisme susmentionné d’installation d’un logiciel de sécurité afin de livrer le logiciel malveillant Lazarus à partir d’un site web légitime mais compromis. Toutefois, il convient de noter qu’un déploiement réussi de logiciels malveillants à l’aide de cette méthode nécessite un certain nombre de conditions préalables. Voilà pourquoi elle a été utilisée dans des campagnes limitées de Lazarus. Pour rendre cette attaque possible :

  • la victime doit avoir installé le logiciel WIZVERA VeraPort
  • la victime doit visiter un site web compromis qui a déjà un soutien pour WIZVERA VeraPort
  • ce site web doit avoir des entrées spécifiques dans son fichier de configuration VeraPort qui permettent aux attaquants de remplacer les logiciels ordinaires de son offre logicielle VeraPort par leurs logiciels malveillants.

Il est important de noter que, d’après notre analyse, nous pensons que ces attaques de la chaîne d’approvisionnement se produisent sur des sites Web qui utilisent WIZVERA VeraPort, plutôt que sur WIZVERA elle-même.

Les sites Web qui prennent en charge le logiciel WIZVERA VeraPort contiennent un composant côté serveur, plus précisément certains JavaScripts et un fichier de configuration WIZVERA. Le fichier de configuration est un fichier XML codé en base64 contenant l’adresse du site web, une liste de logiciels à installer, des URL de téléchargement et d’autres paramètres.

Figure 2. Un exemple de la configuration de WIZVERA VeraPort (édité par ESET)

Ces fichiers de configuration sont signés numériquement par WIZVERA. Une fois téléchargés, ils sont vérifiés à l’aide d’un algorithme cryptographique puissant (RSA), ce qui explique pourquoi les attaquants ne peuvent pas facilement modifier le contenu de ces fichiers de configuration ou créer leur propre faux site web. Cependant, les attaquants peuvent remplacer le logiciel qui doit être livré aux utilisateurs de WIZVERA VeraPort à partir d’un site web légitime mais compromis. Nous pensons que c’est le scénario utilisé par les attaquants de Lazarus.

Figure 3. Schéma simplifié de l’attaque de la chaîne d’approvisionnement de WIZVERA menée par le groupe Lazarus

Il est à noter que les configurations de WIZVERA VeraPort contiennent une option permettant de vérifier la signature numérique des binaires téléchargés avant qu’ils ne soient exécutés, et dans la plupart des cas cette option est activée par défaut. Cependant, VeraPort vérifie seulement que la signature numérique est valide, sans vérifier à qui elle appartient. Ainsi, pour abuser de WIZVERA VeraPort, les attaquants doivent disposer de tout certificat de signature de code valide afin de pousser leur charge utile par cette méthode ou avoir de la chance et trouver une configuration de VeraPort qui ne nécessite pas de vérification de signature de code.

Jusqu’à présent, nous avons observé deux échantillons de logiciels malveillants qui ont été livrés en utilisant cette attaque de la chaîne d’approvisionnement et tous deux ont été signés :

SHA-1FilenameDigital signature
3D311117D09F4A6AD300E471C2FB2B3C63344B1DDelfino.exeALEXIS SECURITY GROUP, LLC
3ABFEC6FC3445759730789D4322B0BE73DC695C7MagicLineNPIZ.exeDREAM SECURITY USA INC

Les attaquants ont utilisé des certificats de signature de code obtenus illégalement afin de signer les échantillons de logiciels malveillants. Il est intéressant de noter que l’un de ces certificats a été délivré à la branche américaine d’une société de sécurité sud-coréenne.

Figure 4. Le certificat de signature de code d’ALEXIS SECURITY GROUP, LLC utilisé pour signer le logiciel malveillant Lazarus

Figure 5. Le certificat de signature de code DREAM SECURITY USA INC utilisé pour signer le logiciel malveillant Lazarus

Les attaquants ont camouflé les échantillons de logiciels malveillants de Lazarus comme des logiciels légitimes. Ces échantillons ont des noms de fichiers, des icônes et des ressources VERSIONINFO similaires à ceux de logiciels sud-coréens légitimes souvent livrés via WIZVERA VeraPort. Les binaires qui sont téléchargés et exécutés via le mécanisme de WIZVERA VeraPort sont stockés dans %Temp%\[12_RANDOM_DIGITS]\.

Il est à noter que la configuration de WIZVERA VeraPort permet non seulement de vérifier les signatures numériques, mais aussi de vérifier le hachage des binaires téléchargés. Si cette option est activée, alors une telle attaque ne peut pas être réalisée aussi facilement, même si le site Internet avec WIZVERA VeraPort est compromis.

Attribution

Nous attribuons fortement cette attaque de la chaîne d’approvisionnement au groupe Lazarus, en nous basant sur les aspects suivants :

  1. Accord communautaire : L’attaque actuelle est une continuation de ce que KrCERT a appelé l’opération Bookcodes. Alors que KrCERT n’a pas attribué cette campagne au groupe Lazarus, Kaspersky l’a fait dans son rapport sur les tendances d’APT au cours du deuxième trimestre 2020.
  2. Caractéristiques et détection des outils :
    1. Le dropper initial est une application de console qui nécessite des paramètres, exécute les étapes suivantes en cascade et utilise un chiffrement, par exemple les attaques de point d’eau contre les banques polonaises et mexicaines
    2. La charge utile finale est un module RAT, avec des communications TCP et ses commandes sont indexées par des entiers de 32 bits, cf KillDisk en Amérique centrale
    3. De nombreux outils fournis par cette chaîne sont déjà signalés par le NukeSped d’ESET. Par exemple, le Downloader signé dans la section Analyse est basé sur un projet appelé WinHttpClient et il mène à un outil similaire avec le hachage 1EA7481878F0D9053CCD81B4589CECAEFC306CF2, que nous relions avec un échantillon de l’opération Blockbuster (CB818BE1FCE5393A83FBFCB3B6F4AC5A3B5B8A4B). Le lien entre ces deux derniers est la résolution dynamique des API Windows où les noms sont codés XOR par 0x23, par exemple,dFWwLHFMjMELQNBWJLM code GetTokenInformation.
  3. Victimologie : le groupe Lazarus a une longue histoire d’attaques contre des victimes en Corée du Sud comme Operation Troy, y compris les attaques DDoS Ten Days of Rain en 2011, les cyberattaques sud-coréennes en 2013, ou les échanges de cryptomonnaies sud-coréennes ciblés en 2017.
  4. Infrastructure de réseau : les techniques côté serveur des webhells et l’organisation des C&C sont traitées très précisément dans le livre blanc n°2 de KrCERT. La campagne actuelle utilise également une configuration très similaire.
  5. Une approche excentrique :
    1. Dans les méthodes d’intrusion : La méthode d’infiltration inhabituelle est un indice qui pourrait être attribué à un acteur sophistiqué et professionnellement organisé comme Lazare. Dans le passé, nous avons vu comment une vulnérabilité dans un logiciel n’existant que dans des réseaux spécifiques était exploitée par ce groupe, et non visible avec un autre acteur de l’APT. Par exemple, le cas « A Strange Coinminer », diffusé par le logiciel ManageEngine Desktop Central.
    2. Dans les méthodes de chiffrement : Nous avons vu une variante Spritz du RC4 dans les attaques de trous d’eau contre les banques polonaises et mexicaines. Plus tard, Lazarus a utilisé un RC4 modifié dans l’Operation In(ter)ception. Dans cette campagne, il s’agit d’un chiffrement modifié de flux A5/1 qui se dégrade en XOR d’un seul octet dans de nombreux cas.

Analyse du logiciel malveillant

De nombreux groupes d’APT, en particulier Lazarus, ont pour caractéristique commune de libérer leur arsenal en plusieurs étapes qui s’exécutent en cascade : du dropper aux produits intermédiaires (le Chargeur, servant d’injecteur) jusqu’aux charges utiles finales (le Téléchargeur, le Module). Il en va de même pour cette campagne.

Au cours de notre analyse, nous avons constaté des similitudes de code et d’architecture entre le logiciel malveillant Lazarus livré via cette attaque de la chaîne d’approvisionnement WIZVERA et le logiciel malveillant décrit dans le rapport Operation BookCodes (première partie, deuxième partie) publié par la Korea Internet & Security Agency cette année.

Comparaison avec Operation BookCodes

Tableau 1. Caractéristiques communes entre deux opérations Lazarus

Parameter/ CampaignOperation BookCodesVia WIZVERA Vera Port
Location of targetsSouth KoreaSouth Korea
TimeQ1-Q2 2020Q2-Q3 2020
Methods of compromiseKorean spearphishing email (link to download or HWP attachment)
Watering hole website
Supply-chain attack
Filename of the dropperC:\Windows\SoftwareDistribution\Download\BIT[4-5digits].tmpC:\Windows\SoftwareDistribution\Download\BIT388293.tmp
Binary configuration fileperf91nc.inf (12000 bytes)assocnet.inf (8348 bytes)
Loader namenwsapagentmonsvc.dllBtserv.dll
iasregmonsvc.dll
RC4 key1qaz2wsx3edc4rfv5tgb$%^&*!@#$1q2w3e4r!@#$%^&*
Log file%Temp%\services_dll.log%Temp%\server_dll.log

Téléchargeur signé initial

Il s’agit du composant Lazarus livré via le détournement de VeraPort décrit plus haut. Les téléchargeurs initiaux signés sont des binaires protégés par Themida, qui téléchargent, chiffrent et exécutent d’autres charges utiles en mémoire, sans les déposer sur le disque. Ce téléchargeur envoie une requête HTTP POST à un serveur C&C codé en dur, déchiffre la réponse du serveur en utilisant l’algorithme RC4, et l’exécute en mémoire en utilisant son propre chargeur de fichiers PE.

Figure 6. La demande POST faite par le téléchargeur initial

Il est intéressant de noter que les deux échantillons découverts envoient une petite pièce d’identité codée en dur dans le corps de la requête POSTE : MagicLineNPIZ.gif ou delfino.gif.

Figure 7. Schéma de la compromission initiale

Dropper

C’est la première étape de la cascade. Bien que l’on ne puisse pas voir de polymorphisme ou d’obscurcissement dans le code, celui-ci encapsule trois fichiers chiffrés dans ses ressources. De plus, c’est une application console qui attend trois paramètres dans un état chiffré : le nom du premier fichier (le chargeur, Btserv.dll), le nom du second fichier (le téléchargeur, bcyp655.tlb), et la clé de déchiffrement nécessaire pour les valeurs précédentes (542).

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

L’extraction des ressources est l’un des deux rôles principaux du dropper. Il procède à celle-ci dans le dossier %WINDOWS%\SYSTEM32, en déchiffrant le chargeur et en préservant l’état chiffré du téléchargeur qui sera déchiffré juste avant d’être injecté dans un autre processus. Il supprime également le fichier de configuration assocnet.inf qui sera ensuite exploité par les charges utiles finales, à savoir le téléchargeur et le module. Il choisit ensuite un service en vérifiant la liste suivante de trois noms de service légitimes Winmgmt,ProfSvc et wmiApSrv, puis injecte le téléchargeur dans le service correspondant en utilisant l’injection de DLL réfléchie.

Le nom du fichier du téléchargeur est stocké dans la valeur suivante du registre Windows :

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

Figure 8. Le code décompilé du dropper

Chargeur

Ce composant est un fichier protégé par Themida. Nous estimons que la version de Themida est 2.0-2.5, ce qui est conforme au rapport de KrCERT (page 20). Le Loader sert de simple injecteur qui recherche ses paramètres d’injection dans les ressources : le nom du fichier chiffré et la clé de déchiffrement qui est la chaîne « 542 ». L’instance livrée par le dropper recherche le fichier bcyp655.tlb (le Downloader). Elle crée un mutex Global\RRfreshRA_Mutex_Object. Le choix du service ciblé et la méthode d’injection sont les mêmes que pour le dropper.

Parlons un peu de la méthode de chiffrement utilisée par le dropper et par ce loader. La clé commune est la chaîne « 542 », qui est initialement fournie comme paramètre de ligne de commande au Dropper et ensuite comme ressource chiffrée sur 3 octets pour le Loader. Pour étendre une courte clé maîtresse à une clé étendue plus grande (appelée « key scheduling »), le hachage MD5 de la chaîne est calculé, qui est 7DCD340D84F762EBA80AA538B0C527F7. Ensuite, on prend les trois premiers mots doubles, on les désigne par A := 0x7DCD340D, B := 0x84f762EB, C:= 0xA80aa538. La longueur d’un tampon chiffré est divisée par 3, et c’est le nombre d’itérations qui transforme la séquence initiale (A,B,C) en la clé appropriée. Dans chaque itération, (X,Y,Z) devient (X^Y, Y^Z, X^Y^Z). Parce que l’opération XOR (dénommée ^) est commutative et transitive, et que son carré est égal à zéro, ce qui laisse tout inchangé, nous pouvons calculer qu’après 8 itérations nous obtenons l’identité, donc la clé pourrait atteindre seulement 7 états différents par paire et est égale aux 12 premiers caractères du hachage MD5 de « 542 » si la longueur est un multiple de 24.

Ce qui est intéressant, c’est la façon dont le reste de la division de la longueur par 3 est traité. Si le nombre d’itérations était augmenté de ce reste, alors nous n’atteindrions qu’un autre des 7 états de la clé. Cependant, la difficulté réside dans le changement de fonctionnement : ^ est remplacé par l’opération OR dans le code pour le reste. Par exemple, la clé avec le reste 1 devient {FE F7 3A F9 F7 D7 FF FD FF F7 FF FD} pour l’un des états (de (C, A^B, B^C) pour être précis), nous obtenons donc de nouvelles transformations possibles de la clé qui ont tendance à être plus susceptibles d’être des uns que des zéros.

C’était la partie préparant la clé. L’algorithme de chiffrement lui-même ressemble à A5/1 à première vue. Il s’agit d’une technologie secrète développée en 1987 et utilisée dans la confidentialité des communications par voie hertzienne dans la norme de téléphonie cellulaire GSM jusqu’à sa rétro-ingénierie en 1999. La partie cruciale de l’algorithme est constituée de trois registres à décalage à rétroaction linéaire (LFSR). Cependant, seules les longueurs des LFSR dans le code du logiciel malveillant coïncident avec la mise en œuvre officielle, et non les constantes.

Tableau 2. Comparaison des algorithmes de chiffrement entre les logiciels malveillants et la mise en œuvre officielle

LFSRMalware codeOfficial A5/1
1Length: 19Length: 19
Constants: 13, 16, 17, 18Constants: 13, 16, 17, 18
2Length: 22Length: 22
Constants: 12, 16, 20, 21Constants: 20, 21
3Length: 23Length: 23
Constants: 17,18,21,22Constants: 7, 20, 21, 22

La boucle de déchiffrement dans chaque itération dérive essentiellement une clé XOR de 1 octet pour l’octet correspondant du tampon chiffré. Le but des LFSR est de pouvoir transformer la clé, ce qui rend le processus beaucoup plus compliqué. Mais en raison de la modification mentionnée de l’opération, les LFSR ne l’affecteraient pas et la clé XOR de 1 octet reste la même pour toutes les itérations.

Le téléchargeur, alias WinHttpClient

Le téléchargeur principal est déposé par le composant Dropper sous le nom bcyp655.tlb  et injecté dans l’un des services par le chargeur. Son but principal est de délivrer des étages supplémentaires sur les ordinateurs de la victime. Le protocole réseau est basé sur HTTP mais nécessite plusieurs étapes pour établir une connexion de confiance.

Le logiciel malveillant prend les empreintes digitales du système de la victime, comment le mondre la figure 9.

Figure 9. La longueur de la mémoire tampon est de 0x114 et contient l’ID de la campagne, l’adresse IP locale, la version de Windows, la version du processeur (cf. KrCERT page 59, Figure [4-17])

La première étape est l’autorisation. Après avoir envoyé des paramètres génériques de code et de id générés de manière aléatoire, la réponse attendue commence par <!DOCTYPE HTML PUBLIC Authentication En> suivi de données supplémentaires délimitées par un point-virgule. Cependant, dans la demande POST suivante, les paramètres sont déjà basés sur l’IP de la victime. Comme nous ne savions pas quelles victimes étaient visées, au cours de notre enquête, nous avions toujours reçu la réponse « Pas trouvé », et non pas le « OK » qui indiquerait une réussite.

Figure 10. Échange de messages primaires avec C&C ayant des paramètres génériques code et id

Figure 11. Secondary message exchange with C&C having a specific parameter name

Si la victime passe ces messages d’introduction et que la connexion est reconnue, alors la réponse déchiffrée commence par un artefact intéressant : le mot clé ohayogonbangwa!!. Dans l’ensemble, nous n’avons pas trouvé ce mot sur Internet, mais la signification la plus proche pourrait être « Ohayo, Konbangwa » (おはようこんばんぐぁ), qui signifie « Bonjour, bonsoir » en japonais. À partir de là, d’autres messages sont échangés, l’échange final demandant de charger un exécutable en mémoire.

 

Figure 12. Artefact japonais dans le code

Module, la charge utile finale de la RAT

Il s’agit d’une RAT avec un ensemble de caractéristiques typiques utilisées par le groupe Lazarus. Les commandes comprennent des opérations sur le système de fichiers de la victime ainsi que le téléchargement et l’exécution d’outils supplémentaires de l’arsenal de l’attaquant. Elles sont indexées par des entiers de 32 bits et coïncident avec celles rapportées par KrCERT à la page 61.

Figure 13. Quelques-unes des commandes prises en charge par le module

Conclusion

Les attaquants essaient constamment de trouver de nouveaux moyens de diffuser des logiciels malveillants aux ordinateurs cibles. Les attaquants sont particulièrement intéressés par les attaques de la chaîne d’approvisionnement, car elles leur permettent de déployer secrètement des logiciels malveillants sur de nombreux ordinateurs en même temps. Ces dernières années, les chercheurs d’ESET ont analysé des cas tels que M.E.DocElmedia PlayerVestaCPStatcounter, et l’industrie du jeu vidéo. Nous pouvons prédire sans risque que le nombre d’attaques de la chaîne d’approvisionnement augmentera à l’avenir, en particulier contre les entreprises dont les services sont populaires dans des régions spécifiques ou dans des secteurs industriels verticaux spécifiques.

Cette fois, nous avons analysé comment le groupe Lazarus a utilisé une approche très intéressante pour cibler les utilisateurs sud-coréens du logiciel WIZVERA VeraPort. Comme mentionné dans notre analyse, c’est la combinaison de sites Web compromis avec le support de WIZVERA VeraPort et des options de configuration spécifiques de VeraPort qui permettent aux attaquants de réaliser cette attaque. Les propriétaires de tels sites web pourraient diminuer la possibilité de telles attaques, même si leurs sites sont compromis, en activant des options spécifiques (par exemple en spécifiant des hachages de binaires dans la configuration de VeraPort).

Nous remercions tout particulièrement Dávid Gábriš et Peter Košinár.

Pour toute demande de renseignements, ou pour nous soumettre des échantillons sur le sujet, contactez-nous à l’adresse suivante : threatintel@eset.com.

Indicateurs de compromission (IoCs)

Nom de détection d’ESET

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 des échantillons signés

3D311117D09F4A6AD300E471C2FB2B3C63344B1D
3ABFEC6FC3445759730789D4322B0BE73DC695C7

SHA-1 des échantillons

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

Numéros de série des codes signés

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
https://www.gncaf.or[.]kr/cafe/cafe_board.asp
https://www.hsbutton.co[.]kr/bbs/bbs_write.asp
https://www.hstudymall.co[.]kr/easypay/web/bottom.asp

Mutexes

Global\RRfreshRA_Mutex_Object

Références

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, Wikipedia

Techniques MITRE ATT&CK

Note: Ce tableau a été créé en utilisant la version 8 de MITRE ATT&CK.

TacticIDNameDescription
Resource DevelopmentT1584.004Compromise Infrastructure: ServerThe Lazarus group uses compromised servers as infrastructure.
T1587.001Develop Capabilities: MalwareThe Lazarus group developed custom malware and malware components.
T1588.003Obtain Capabilities: Code Signing CertificatesThe Lazarus group obtained code-signing certificates.
Initial AccessT1195.002Supply Chain Compromise: Compromise Software Supply ChainThe Lazarus group pushed this malware using a supply-chain attack via WIZVERA VeraPort.
ExecutionT1106Native APIThe Lazarus payload is executed using native API calls.
PersistenceT1547.005Boot or Logon Autostart Execution: Security Support ProviderThe Lazarus malware maintains persistence by installing an SSP DLL.
Defense EvasionT1036MasqueradingThe Lazarus malware masqueraded as a South Korean security software
T1027.002Obfuscated Files or Information: Software PackingThe Lazarus group uses Themida-protected malware.
T1055Process InjectionThe Lazarus malware injects itself in svchost.exe.
T1553.002Subvert Trust Controls: Code SigningThe Lazarus group used illegally obtained code-signing certificates to sign the initial downloader used in this supply-chain attack.
Command and ControlT1071.001Application Layer Protocol: Web ProtocolsThe Lazarus malware uses HTTP for C&C.
T1573.001Encrypted Channel: Symmetric CryptographyThe Lazarus malware uses the RC4 algorithm to encrypt its C&C communications.
ExfiltrationT1041Exfiltration Over C2 ChannelThe Lazarus malware exfiltrates data over the C&C channel.

Infolettre

Discussion