Ataque de Lazarus a la cadena de suministro en Corea del Sur


Investigadores de ESET descubren un nuevo ataque a la cadena de suministro de Lazarus que aprovecha el software WIZVERA VeraPort

Los datos de telemetría de ESET llevaron recientemente a nuestros investigadores a descubrir intentos de implementar el malware Lazarus a través de un ataque a la cadena de suministro en Corea del Sur. Para entregar su malware, los atacantes utilizaron un mecanismo de cadena de suministro inusual, abusando del software de seguridad legítimo de Corea del Sur y de los certificados digitales robados de dos compañías diferentes.

Conjunto de herramientas Lazarus

El grupo Lazarus se identificó por primera vez en el informe de Novetta Operación Blockbuster en febrero de 2016; US-CERT y el FBI llaman a este grupo COBRA OCULTA. Estos ciberdelincuentes saltaron a la fama con el infame caso de cibersabotaje contra Sony Pictures Entertainment.

Algunos de los ataques pasados ​​atribuidos al grupo Lazarus atrajeron el interés de los investigadores de seguridad que se basaron en los documentos técnicos de Novetta et al. Con cientos de páginas que describen las herramientas utilizadas en los ataques: los bancos polaco y mexicano, el brote de WannaCryptor, campañas de phishing contra contratistas de defensa de EE. UU., Ataque de Lazarus KillDisk contra casino centroamericano, etc. – y proporciona motivos para la atribución de estos ataques al grupo Lazarus.

Tenga en cuenta que el conjunto de herramientas de Lazarus (es decir, la colección de todos los archivos que la industria de la seguridad considera como huellas digitales de la actividad del grupo) es extremadamente amplio y creemos que existen numerosos subgrupos. A diferencia de los conjuntos de herramientas utilizados por otros grupos de ciberdelincuentes, ninguno de los códigos fuente de las herramientas de Lazarus se ha revelado nunca en una filtración pública.

El último ataque de Lazarus a la cadena de suministro

Para comprender este novedoso ataque a la cadena de suministro, debe tener en cuenta que a los usuarios de Internet de Corea del Sur a menudo se les pide que instalen software de seguridad adicional cuando visitan sitios web gubernamentales o de banca por Internet.

WIZVERA VeraPort, conocido como programa de instalación de integración, es una aplicación de Corea del Sur que ayuda a administrar dicho software de seguridad adicional. Con WIZVERA VeraPort instalado en sus dispositivos, los usuarios reciben e instalan todo el software necesario requerido por un sitio web específico con VeraPort (por ejemplo, complementos del navegador, software de seguridad, software de verificación de identidad, etc.). Se requiere una interacción mínima del usuario para iniciar dicha instalación de software desde un sitio web que admita WIZVERA VeraPort. Por lo general, los sitios web gubernamentales y bancarios de Corea del Sur utilizan este software. Para algunos de estos sitios web es obligatorio tener instalado WIZVERA VeraPort para que los usuarios puedan acceder a los servicios de los sitios.

Figura 1. Se muestra una ventana de WIZVERA VeraPort al usuario al instalar software adicional

Los atacantes de Lazarus abusaron del mecanismo mencionado anteriormente de instalar software de seguridad para entregar el malware Lazarus desde un sitio web legítimo pero comprometido. Sin embargo, debe tenerse en cuenta que una implementación exitosa de malware con este método requiere una serie de condiciones previas; por eso se utilizó en campañas limitadas de Lazarus. Para hacer posible este ataque:

  • la víctima debe tener instalado el software WIZVERA VeraPort
  • la víctima debe visitar un sitio web comprometido que ya tiene soporte para WIZVERA VeraPort
  • este sitio web debe tener entradas específicas en su archivo de configuración VeraPort que permitan a los atacantes reemplazar el software regular en su paquete de software VeraPort con su malware.

Es importante señalar que, según nuestro análisis, creemos que estos ataques a la cadena de suministro ocurren en sitios web que utilizan WIZVERA VeraPort, en lugar de WIZVERA en sí.

Los sitios web que admiten el software WIZVERA VeraPort contienen un componente del lado del servidor, específicamente algunos JavaScripts y un archivo de configuración WIZVERA. El archivo de configuración es XML codificado en base64 que contiene la dirección del sitio web, una lista de software para instalar, descargar URL y otros parámetros.

Figura 2. Un ejemplo de una configuración de WIZVERA VeraPort (redactado por ESET)

Estos archivos de configuración están firmados digitalmente por WIZVERA. Una vez descargados, se verifican mediante un algoritmo criptográfico sólido (RSA), por lo que los atacantes no pueden modificar fácilmente el contenido de estos archivos de configuración o configurar su propio sitio web falso. Sin embargo, los atacantes pueden reemplazar el software que se entregará a los usuarios de WIZVERA VeraPort desde un sitio web legítimo pero comprometido. Creemos que este es el escenario que utilizaron los atacantes de Lazarus.

Figura 3. Esquema simplificado del ataque a la cadena de suministro de WIZVERA realizado por el grupo Lazarus

Cabe señalar que las configuraciones de WIZVERA VeraPort contienen una opción para verificar la firma digital de los binarios descargados antes de que se ejecuten, y en la mayoría de los casos esta opción está habilitada por defecto. Sin embargo, VeraPort solo verifica que la firma digital sea válida, sin verificar a quién pertenece. Por lo tanto, para abusar de WIZVERA VeraPort, los atacantes deben tener un certificado de firma de código válido para impulsar su carga útil a través de este método o tener suerte y encontrar una configuración de VeraPort que no requiera verificación de firma de código.

Hasta ahora, hemos observado dos muestras de malware que se entregaron mediante este ataque a la cadena de suministro y ambas fueron firmadas:

SHA-1 Nombre del archivo Firma digital
3D311117D09F4A6AD300E471C2FB2B3C63344B1D Delfino.exe ALEXIS SECURITY GROUP, LLC
3ABFEC6FC3445759730789D4322B0BE73DC695C7 MagicLineNPIZ.exe DREAM SECURITY USA INC

Los atacantes utilizaron certificados de firma de código obtenidos ilegalmente para firmar las muestras de malware. Curiosamente, uno de estos certificados se emitió a la sucursal estadounidense de una empresa de seguridad de Corea del Sur.

Figura 4. El certificado de firma de código de ALEXIS SECURITY GROUP, LLC utilizado para firmar el malware Lazarus

Figura 5. El certificado de firma de código de DREAM SECURITY USA INC utilizado para firmar el malware Lazarus

Los atacantes camuflaron las muestras de malware de Lazarus como software legítimo. Estas muestras tienen nombres de archivo, iconos y recursos VERSIONINFO similares a los del software legítimo de Corea del Sur que a menudo se entrega a través de WIZVERA VeraPort. Los binarios que se descargan y ejecutan a través del mecanismo WIZVERA VeraPort se almacenan en % Temp% (12_RANDOM_DIGITS) .

Cabe señalar que la configuración de WIZVERA VeraPort tiene una opción no solo para verificar firmas digitales, sino también para verificar el hash de los binarios descargados. Si esta opción está habilitada, dicho ataque no se puede realizar tan fácilmente, incluso si el sitio web con WIZVERA VeraPort está comprometido.

Atribución

Atribuimos fuertemente este ataque a la cadena de suministro al grupo Lazarus, basándonos en los siguientes aspectos:

  1. Acuerdo de la comunidad: el ataque actual es una continuación de lo que KrCERT ha llamado Operation Bookcodes. Si bien KrCERT no atribuyó esa campaña al grupo Lazarus, Kaspersky lo hizo en su informe sobre Tendencias APT del segundo trimestre de 2020.
  2. Características y detección del conjunto de herramientas:
    1. El cuentagotas inicial es una aplicación de consola que requiere parámetros, ejecuta las siguientes etapas en cascada y utiliza un cifrado, cf. los ataques al abrevadero contra los bancos polacos y mexicanos
    2. La carga útil final es un módulo RAT, con comunicaciones TCP y sus comandos están indexados por enteros de 32 bits, cf KillDisk en Centroamérica
    3. Muchas herramientas entregadas a través de esta cadena ya están marcadas con NukeSped de ESET. Por ejemplo, el descargador firmado en el Análisis La sección se basa en un proyecto llamado WinHttpClient y conduce a una herramienta similar con hash 1EA7481878F0D9053CCD81B4589CECAEFC306CF2, que enlazamos con una muestra de Operation Blockbuster (CB818BE1FCE5393A83FBFCB3B6F4AC5A3B5B8A4B). La conexión entre los dos últimos es la resolución dinámica de las API de Windows donde los nombres están encriptados con XOR por 0x23, por ejemplo, dFWwLHFMjMELQNBWJLM codifica GetTokenInformation.
  3. Victimología: el grupo Lazarus tiene una larga historia de ataques contra víctimas en Corea del Sur como Operación Troy, incluidos los ataques DDoS Diez días de lluvia en 2011, Ciberataques de Corea del Sur en 2013, o Intercambios de criptomonedas de Corea del Sur objetivo en 2017.
  1. Infraestructura de red: las técnicas del lado del servidor de los webshells y la organización de los C & C se tratan con mucha precisión en el documento técnico n.º 2 de KrCERT. La campaña actual también utiliza una configuración muy similar.
  1. Enfoque excéntrico:
    1. En métodos de intrusión: El método inusual de infiltración es una pista que podría atribuirse a un actor sofisticado y organizado profesionalmente como Lazarus. En el pasado, vimos cómo este grupo aprovechó una vulnerabilidad en el software existente solo en redes específicas, y no fue visible con ningún otro actor de APT. Por ejemplo, el caso de "A Strange Coinminer" entregado a través del software ManageEngine Desktop Central.
    2. En métodos de encriptación: Vimos una variante Spritz de RC4 en los ataques de abrevadero contra bancos polacos y mexicanos; Más tarde, Lázaro usó un RC4 modificado en Operación en (ter) ceción. En esta campaña, es un cifrado de flujo A5 / 1 modificado que se degrada a un XOR de un solo byte en muchos casos.

Análisis de malware

Es una característica común de muchos grupos APT, especialmente Lazarus, que desatan su arsenal dentro de varias etapas que se ejecutan en cascada: desde el cuentagotas hasta los productos intermedios (el Loader, que sirve como inyector) hasta las cargas útiles finales (el Downloader , el módulo). Lo mismo es cierto para esta campaña.

Durante nuestro análisis, encontramos similitudes en el código y la arquitectura entre el malware Lazarus entregado a través de este ataque a la cadena de suministro de WIZVERA y el malware descrito en el informe Operation BookCodes (parte uno, la segunda parte) publicado por la Agencia de Seguridad e Internet de Corea este año.

Comparación con Operation BookCodes

Cuadro 1. Características comunes entre dos operaciones de Lazarus

Parámetro / Campaña Operación BookCodes A través del puerto de WIZVERA Vera
Ubicación de los objetivos Corea del Sur Corea del Sur
Hora Q1-Q2 2020 Q2-Q3 2020
Métodos de compromiso Correo electrónico de spearphishing coreano (enlace para descargar o adjunto de HWP)
Sitio web del abrevadero
Ataque a la cadena de suministro
Nombre de archivo del cuentagotas C: Windows SoftwareDistribution Download BIT (4-5 dígitos) .tmp C: Windows SoftwareDistribution Download BIT388293.tmp
Archivo de configuración binaria perf91nc.inf (12000 bytes) assocnet.inf (8348 bytes)
Nombre del cargador nwsapagentmonsvc.dll Btserv.dll
iasregmonsvc.dll
Llave RC4 1qaz2wsx3edc4rfv5tgb $% ^ & *! @ # $ 1q2w3e4r! @ # $% ^ & *
Archivo de registro % Temp% services_dll.log % Temp% server_dll.log

Descargador inicial firmado

Este es el componente de Lazarus entregado a través del secuestro de VeraPort descrito anteriormente. Los descargadores iniciales firmados son archivos binarios protegidos por Themida, que descargan, descifran y ejecutan otras cargas útiles en la memoria, sin dejarlas en el disco. Este descargador envía una solicitud HTTP POST a un servidor C&C codificado, descifra la respuesta del servidor usando el algoritmo RC4 y la ejecuta en la memoria usando su propio cargador para archivos PE.

Figura 6. La solicitud POST realizada por el descargador inicial

Curiosamente, ambas muestras descubiertas envían una pequeña ID codificada en el cuerpo de la solicitud POST: MagicLineNPIZ.gif o delfino.gif.

Figura 7. Esquema del compromiso inicial

Cuentagotas

Esta es la etapa inicial de la cascada. Si bien no se puede ver ningún polimorfismo u ofuscación en el código, encapsula tres archivos encriptados en sus recursos. Además, es una aplicación de consola que espera tres parámetros en un estado cifrado: el nombre del primer archivo (el cargador, Btserv.dll), el nombre del segundo archivo (el Descargador, bcyp655.tlb) y la clave de descifrado necesaria para los valores anteriores (542).

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

La extracción de recursos es una de las dos funciones principales del cuentagotas; lo hace en el % WINDOWS% SYSTEM32 carpeta, descifrando el cargador y conservando el estado cifrado del descargador, que se descifrará justo antes de inyectarse en otro proceso. También suelta el archivo de configuración assocnet.inf que luego será aprovechado por las cargas útiles finales, a saber, el Descargador y el Módulo. Luego, elige un servicio al verificar la siguiente lista de tres nombres de servicios legítimos Winmgmt; ProfSvc; wmiApSrv; e inyecta el Downloader en el servicio coincidente mediante la inyección de DLL reflectante.

El nombre de archivo del cargador se almacena en el siguiente valor de registro de Windows:

HKLM SYSTEM CurrentControlSet Control Lsa Security Packages

Figura 8. El código descompilado del cuentagotas

Cargador

Este componente es un archivo protegido por Themida. Estimamos que la versión de Themida es 2.0-2.5, lo que concuerda con el informe de KrCERT (página 20). El cargador sirve como un inyector simple que busca sus parámetros de inyección en los recursos: el nombre del archivo cifrado y la clave de descifrado que es la cadena “542”. La instancia entregada por el cuentagotas busca el archivo bcyp655.tlb (el Descargador). Crea un mutex Global RRfreshRA_Mutex_Object. La elección del servicio específico y el método de inyección son los mismos que en el gotero.

Hablemos un rato sobre el método de cifrado utilizado por el cuentagotas y por este cargador. La clave común es la cadena “542”, que inicialmente se proporciona como un parámetro de línea de comando al Dropper y posteriormente como un recurso cifrado de 3 bytes para el Loader. Para expandir una clave maestra corta a una clave expandida más grande (lo que se denomina programación de claves), se calcula el hash MD5 de la cadena, que es 7DCD340D84F762EBA80AA538B0C527F7. Luego, toma las primeras tres palabras dobles, denotémoslas A: = 0x7DCD340D, B: = 0x84f762EB, C: = 0xA80aa538. La longitud de un búfer cifrado se divide por 3, y este es el número de iteraciones que transforma la secuencia inicial (A, B, C) en la clave adecuada. En cada iteración (X, Y, Z) se convierte en (X ^ Y, Y ^ Z, X ^ Y ^ Z). Debido a que la operación XOR (denotada ^) es conmutativa y transitiva, y su cuadrado es cero, lo que deja todo sin cambios, podemos calcular que después de 8 iteraciones obtenemos la identidad, por lo que la clave podría alcanzar solo 7 estados diferentes por pares y es igual a los primeros 12 caracteres del hash MD5 de "542" si la longitud es un múltiplo de 24.

Lo interesante es cómo se trata el resto de la división de longitud por 3. Si el número de iteraciones se incrementara en este resto, entonces alcanzaríamos solo otro de los 7 estados de la clave. Sin embargo, el giro está en el cambio de operación: ^ se reemplaza con la operación OR en el código para el resto. Por ejemplo, la clave con el resto 1 se convierte en FE F7 3A F9 F7 D7 FF FD FF F7 FF FD para uno de los estados (de (C, A ^ B, B ^ C) para ser precisos), por lo que obtenemos nuevas posibles transformaciones de la clave que tienden a ser más unos que ceros.

Esa fue la parte que preparó la clave. El algoritmo de cifrado en sí parece A5 / 1 a primera vista. Era una tecnología secreta desarrollada en 1987 y utilizada en la privacidad de las comunicaciones por aire en el estándar de telefonía celular GSM hasta que se sometió a ingeniería inversa en 1999. La parte crucial del algoritmo es Tres registros de desplazamiento de retroalimentación lineal (LFSR). Sin embargo, solo las longitudes de LFSR en el código de malware coinciden con la implementación oficial, no con las constantes.

Tabla 2. Comparación de algoritmos criptográficos entre malware y la implementación oficial

LFSR Código de malware A5 / 1 oficial
1 Longitud: 19 Longitud: 19
Constantes: 13, 16, 17, 18 Constantes: 13, 16, 17, 18
2 Longitud: 22 Longitud: 22
Constantes: 12, 16, 20, 21 Constantes: 20, 21
3 Longitud: 23 Longitud: 23
Constantes: 17,18,21,22 Constantes: 7, 20, 21, 22

El bucle de descifrado en cada iteración básicamente deriva una clave XOR de 1 byte para el byte correspondiente del búfer cifrado. El propósito de los LFSR es que podrían transformar la clave, por lo que todo el proceso es mucho más complicado. Pero debido al cambio mencionado de la operación, los LFSR no lo afectarían y la clave XOR de 1 byte sigue siendo la misma para todas las iteraciones.

Descargador, también conocido como WinHttpClient

El descargador principal lo suelta el componente Dropper debajo del bcyp655.tlb nombre e inyectado en uno de los servicios por el cargador. Su objetivo principal es entregar etapas adicionales en las computadoras de la víctima. El protocolo de red se basa en HTTP, pero requiere varias etapas para establecer una conexión confiable.

El malware toma las huellas digitales del sistema de la víctima: consulte la Figura 9.

Figura 9. La longitud del búfer es 0x114 y contiene el ID de campaña, la dirección IP local, la versión de Windows, la versión del procesador (consulte KrCERT en la página 59, Figura (4-17))

El primer paso es la autorización. Después de enviar código de parámetros genéricos generados aleatoriamente y carné de identidad, la respuesta esperada comienza con seguido de datos adicionales delimitados por un punto y coma. Sin embargo, en la siguiente solicitud POST, los parámetros ya se basan en la IP de la víctima. Debido a que no sabíamos qué víctimas eran el objetivo, durante nuestra investigación, siempre habíamos recibido una respuesta de "No encontrado", no el "OK" exitoso.

Figura 10. Intercambio de mensajes primarios con C&C que tienen código e id de parámetros genéricos

Figura 11. Intercambio de mensajes secundarios con C&C que tienen un nombre de parámetro específico

Si la víctima pasa estos mensajes introductorios y se reconoce la conexión, entonces la respuesta descifrada comienza con un artefacto interesante: una palabra clave ohayogonbangwa !!. En general, no hemos encontrado esa palabra en Internet, pero el significado más cercano podría ser "Ohayo, Konbangwa" (お は よ う こ ん ば ん ぐ ぁ), que es "Buenos días, buenas noches" en japonés. A partir de este punto, hay más mensajes que se intercambian, y el intercambio final solicita un ejecutable para cargar en la memoria.

Figura 12. Artefacto japonés en el código

Módulo, la carga útil final de RAT

Se trata de una RAT con un conjunto de características típicas utilizadas por el grupo Lazarus. Los comandos incluyen operaciones en el sistema de archivos de la víctima y la descarga y ejecución de herramientas adicionales del arsenal del atacante. Están indexados por enteros de 32 bits y coinciden con los informados por KrCERT en la página 61.

Figura 13. Algunos de los comandos admitidos por Module

Conclusión

Los atacantes intentan constantemente encontrar nuevas formas de enviar malware a los equipos de destino. Los atacantes están particularmente interesados ​​en los ataques a la cadena de suministro, ya que les permiten implementar malware de forma encubierta en muchas computadoras al mismo tiempo. En los últimos años, los investigadores de ESET analizaron casos como M.E.Doc, Jugador Elmedia, VestaCP, Contador de estadísticas, y el industria de juegos. Podemos predecir con seguridad que el número de ataques a la cadena de suministro aumentará en el futuro, especialmente contra empresas cuyos servicios son populares en regiones específicas o en sectores verticales específicos.

Esta vez analizamos cómo el grupo Lazarus utilizó un enfoque muy interesante para apuntar a los usuarios surcoreanos del software WIZVERA VeraPort. Como se mencionó en nuestro análisis, es la combinación de sitios web comprometidos con el soporte de WIZVERA VeraPort y las opciones de configuración específicas de VeraPort lo que permite a los atacantes realizar este ataque. Los propietarios de dichos sitios web podrían disminuir la posibilidad de tales ataques, incluso si sus sitios están comprometidos, habilitando opciones específicas (por ejemplo, especificando hashes de binarios en la configuración de VeraPort).

Un agradecimiento especial a Dávid Gábriš y Peter Košinár.

Para cualquier consulta, o para hacer presentaciones de muestra relacionadas con el tema, contáctenos en amenazaintel@eset.com

Indicadores de compromiso (IoC)

Nombres de detección de 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 de muestras firmadas

3D311117D09F4A6AD300E471C2FB2B3C63344B1D
3ABFEC6FC3445759730789D4322B0BE73DC695C7

SHA-1 de muestras

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

Números de serie del certificado de firma de código

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 / fail_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

Referencias

KrCERT / CC, "Operation BookCodes TTP # 1 Control de la red local a través de sitios web vulnerables”, Traducción al inglés, 1S t Abril de 2020
KrCERT / CC, "Operación BookCodes TTP # 2 스피어 피싱 으로 정보 를 수집 하는 공격 망 구성 방식 분석”, Coreano, 29th Junio ​​de 2020
P. Kálnai, M. Poslušný: “Lazarus Group: un juego de mahjong jugado en diferentes conjuntos de fichas”, Virus Bulletin 2018 (Montreal)
P. Kálnai: “Desmitificar el malware dirigido contra los bancos polacos”, WeLiveSecurity, febrero de 2017
P. Kálnai, A. Cherepanov “Lazarus KillDisks casino centroamericano”, WeLiveSecurity, abril de 2018
D. Breitenbacher, K. Osis: “Operation In (ter) ception: Las empresas aeroespaciales y militares en la mira de los ciberespías”, Junio ​​de 2020
Novetta et al, "Operación Blockbuster”, Febrero de 2016, https://www.operationblockbuster.com/resources
Marcus Hutchins, “Cómo detener accidentalmente un ciberataque global”, Mayo de 2015
Kaspersky GReAT: "Informe de tendencias APT Q2 2020”, Julio de 2020
A. Kasza: “Continúa la saga Blockbuster”, Palo Alto Networks, agosto de 2017
US-CERT CISA, https://us-cert.cisa.gov/northkorea
WeLiveSecurity: "El pirateo de Sony Pictures se remonta a un hotel tailandés, ya que Corea del Norte niega su participación”, Diciembre de 2014
R. Sherstobitoff, I. Liba. J. Walter: “Diseccionando la Operación Troya: Ciberespionaje en Corea del Sur”, McAfee® Labs, mayo de 2018
McAfee Labs: "Diez días de lluvia”, Julio de 2011
Fireye: "¿Por qué Corea del Norte está tan interesada en Bitcoin?”, Septiembre de 2017
Choe Sang-Hun: “Las redes informáticas en Corea del Sur están paralizadas por los ciberataques”, Marzo de 2013
Cifrado de flujo A5 / 1, Wikipedia

Técnicas MITRE ATT & CK

Nota: esta tabla fue construida usando versión 8 del marco MITRE ATT & CK.

Táctica CARNÉ DE IDENTIDAD Nombre Descripción
Desarrollo de recursos T1584.004 Infraestructura de compromiso: servidor El grupo Lazarus utiliza servidores comprometidos como infraestructura.
T1587.001 Desarrollar capacidades: malware El grupo Lazarus desarrolló malware personalizado y componentes de malware.
T1588.003 Obtenga capacidades: certificados de firma de código El grupo Lazarus obtuvo certificados de firma de código.
Acceso inicial T1195.002 Compromiso de la cadena de suministro: Compromiso de la cadena de suministro del software El grupo Lazarus impulsó este malware mediante un ataque a la cadena de suministro a través de WIZVERA VeraPort.
Ejecución T1106 API nativa La carga útil de Lazarus se ejecuta mediante llamadas a API nativas.
Persistencia T1547.005 Ejecución de inicio automático de inicio o inicio de sesión: proveedor de soporte de seguridad El malware Lazarus mantiene la persistencia al instalar una DLL SSP.
Evasión de defensa T1036 Mascarada El malware Lazarus disfrazado de software de seguridad de Corea del Sur
T1027.002 Archivos o información ofuscados: paquete de software El grupo Lazarus utiliza malware protegido por Themida.
T1055 Inyección de proceso El malware Lazarus se inyecta en svchost.exe.
T1553.002 Controles subvertidos de confianza: firma de código El grupo Lazarus utilizó certificados de firma de código obtenidos ilegalmente para firmar el descargador inicial utilizado en este ataque a la cadena de suministro.
Comando y control T1071.001 Protocolo de capa de aplicación: protocolos web El malware Lazarus usa HTTP para C&C.
T1573.001 Canal cifrado: criptografía simétrica El malware Lazarus utiliza el algoritmo RC4 para cifrar sus comunicaciones C&C.
Exfiltración T1041 Exfiltración sobre canal C2 El malware Lazarus exfiltra datos a través del canal C&C.





Enlace a la noticia original