Actualización 11 de sept. @ 9 a. m. hora del Este
Agradecemos los comentarios, preguntas y debates de la comunidad en torno a esta publicación del blog. A la luz de esas preguntas, quisimos publicar información más detallada para ofrecer más información sobre el periodo de tiempo que se había destacado inicialmente en esta publicación, y explicar cómo investigamos específicamente este incidente.
Como puedes ver en el gráfico a continuación, nuestros analistas del SOC desinstalaron el agente 84 minutos después de que se instaló en el endpoint. Esto ocurrió después de que examinaran indicadores maliciosos, que incluían el nombre del equipo, el malware original y el intento del equipo de comprometer cuentas de víctimas. En ese momento, los analistas investigaron más a fondo para determinar la intención original del usuario, incluyendo si buscaba una forma de abusar de nuestro producto. Tras la investigación, todos los indicadores, combinados con el hecho de que este equipo había estado involucrado en compromisos anteriores, llevaron a los analistas a determinar que el usuario era malicioso y, finalmente, a desinstalar el agente.
NOTA: Una versión anterior de esta publicación sugería que el actor de amenazas había desinstalado el agente:
"Aquí es donde se interrumpen nuestros datos de EDR, ya que es posible que se hayan dado cuenta de nuestra presencia y hayan desinstalado el agente."
Por transparencia, esto no es exacto. Volvimos a consultar con el SOC después de redactar este blog para verificar la naturaleza exacta de la desinstalación del agente, y confirmaron que lo habían desinstalado a la fuerza cuando tuvieron pruebas suficientes para determinar que un actor de amenazas estaba usando el endpoint.
Esperamos continuar la conversación en torno a esta investigación, sobre qué son los productos de detección y respuesta para endpoints (EDR) administrados y qué propósito cumplen, entre otros temas. Recientemente detallamos algunas de estas conversaciones en nuestro Tradecraft Tuesday de esta semana, a continuación.
------------------------
Actualización 9 de sept. @ 3 p. m. hora del Este
Lo que estás a punto de leer es algo que todas las empresas de detección y respuesta para endpoints (EDR) realizan como consecuencia de investigar amenazas. Dado que estos servicios están diseñados para monitorear y detectar amenazas, los sistemas EDR necesitan, por naturaleza, la capacidad de monitorear la actividad del sistema, tal como se describe en nuestra documentación del producto, Política de privacidad y Términos de servicio.
A raíz de las preguntas sobre cómo y por qué Huntress publicó esta información, quisimos aclarar varios aspectos importantes de nuestra investigación. Tenemos la obligación de 1) investigar y responder a amenazas de seguridad e investigar malware, y 2) educar a la comunidad en general sobre esas amenazas. Estos dos objetivos influyeron en nuestra decisión de redactar y publicar esta entrada de blog.
Cuando encontramos por primera vez el endpoint mencionado en este blog, fue porque estábamos respondiendo a numerosas alertas relacionadas con la ejecución de malware en él. Parte de este proceso implica que nuestro equipo del SOC investigue minuciosamente las señales y recopile artefactos relacionados con la telemetría de EDR en el endpoint. Solo tras investigar más a fondo esta telemetría observamos señales que indicaban un comportamiento malicioso. Para ese momento, también descubrimos que el nombre único del equipo usado por la persona coincidía con uno que habíamos rastreado en varios incidentes previos a la instalación del agente.
En este punto, determinamos que el equipo en el que se había instalado el agente de Huntress era, de hecho, malicioso. Quisimos ayudar a la comunidad en general compartiendo lo que aprendimos sobre las técnicas que el actor de amenazas utilizaba en este incidente. Al decidir qué información publicar sobre esta investigación, consideramos cuidadosamente varios factores, como mantener estrictamente nuestras obligaciones de privacidad, además de difundir telemetría de EDR que reflejara específicamente amenazas y comportamientos que pudieran ayudar a los defensores.
En general, esta investigación es el resultado de lo que buscamos hacer mejor: transparencia, educación y acabar con los hackers. Sigue leyendo para saber más.
------------------------
Resumen
Aquí en Huntress, nos encanta exponer las técnicas de los adversarios, y también nos encanta cuando los actores de amenazas cometen errores. Así que imagina nuestro deleite cuando un actor de amenazas instaló Huntress en su propio equipo operativo, después de encontrarnos a través de una de nuestras campañas publicitarias e iniciar una prueba, dándonos una vista interna amplia de cómo están usando IA para crear flujos de trabajo, buscando herramientas como Evilginx, y más.
------------------------
Todos sabemos que los atacantes a menudo descargan productos de seguridad para "evaluarlos", pero a menudo solo podemos imaginar cómo decidieron apuntar a una tecnología en particular, o las acciones que tomaron mientras probaban dicho software. Recientemente tuvimos el placer de tener una vista en primera fila de lo que hizo un atacante, simplemente porque instaló nuestro agente y nos permitió recopilar información directamente de él. Aquí contaremos esta extraña historia.
¿Cómo llegamos hasta aquí?
Como la mayoría de las buenas historias, esta comienza en la mitad y avanza y retrocede. Empecemos por cómo esta persona de interés llamó nuestra atención. Uno de los trucos del oficio para interesar a la gente en tus productos es la publicidad. Por eso, publicamos anuncios para ayudar a atraer a clientes potenciales hacia nuestros productos. Un efecto adverso aquí podría ser atraer también algo de atención "no deseada". Así comienza esta aventura: todo empezó con un anuncio de Google bien ubicado.
El atacante se topó con nuestro anuncio mientras investigaba otra solución de seguridad. Confirmamos que así nos encontró al examinar su historial del navegador Google Chrome. Un ejemplo de cómo pudo haberle aparecido en ese momento se puede ver en la Figura 1.
Figura 1: Búsqueda en Google de Bitdefender, que lleva a un anuncio de Huntress
Parece que el atacante se interesó en Huntress mientras probaba simultáneamente Bitdefender. Después de llegar a nuestra página de comparación, apenas pudo contenerse e inició una prueba de inmediato. Podemos seguir su recorrido a través de su historial de Chrome, como se ve en la Figura 2 a continuación.
Figura 2: Historial del navegador que muestra cómo una búsqueda de Bitdefender llevó a una prueba de Huntress
No es ningún secreto que los actores de amenazas pueden instalar productos de seguridad con fines de investigación o incluso para uso legítimo, y de hecho, el adversario estaba interesado en otros productos de seguridad además de Bitdefender y Huntress. Encontramos evidencia de que había comprado una suscripción de Malwarebytes (incluida la extensión del navegador Malwarebytes browser guard).
Figura 3: El atacante intenta mantenerse seguro con una extensión del navegador Malwarebytes instalada 🤣
Señales de alerta del actor de amenazas, y nuestra respuesta
Supimos que se trataba de un adversario, y no de un usuario legítimo, por varias pistas reveladoras. La señal de alerta más notable fue que el nombre único de la máquina usado por esta persona era el mismo que habíamos rastreado en varios incidentes antes de que instalara el agente. Una investigación más profunda reveló otras pistas, como el historial del navegador del actor de amenazas, que parecía mostrarlo intentando atacar activamente organizaciones, redactar mensajes de phishing, encontrar y acceder a instancias en ejecución de Evilginx, entre otras cosas. También sospechamos que la máquina operativa donde se instaló Huntress se está usando como punto de salto por varios actores de amenazas, pero no contamos con evidencia sólida para sacar conclusiones firmes por el momento.
Los analistas de Huntress se pusieron a trabajar evaluando los indicadores de compromiso pendientes encontrados en el equipo del adversario y cómo se relacionaban con los datos hallados en las autenticaciones a identidades en Huntress. Las búsquedas retroactivas revelaron otras 20 identidades comprometidas; a muchas de ellas el adversario ya había accedido antes de que Huntress se implementara contra la identidad, cuya actividad se limitaba a renovar tokens de sesión para mantener el acceso.
En general, el análisis de la infraestructura operativa principal del adversario, alojada en el Sistema Autónomo (AS) "12651980 CANADA INC." (ahora conocido como VIRTUO), reveló un patrón de acceso a más de 2471 identidades únicas a lo largo de las últimas dos semanas, muchas de las cuales fueron detectadas de forma preventiva mediante capacidades adicionales de detección, como la creación de reglas de correo maliciosas o el robo de tokens de autenticación de sesión.
La inteligencia recopilada en lo anterior ha dado como resultado detecciones de alta confianza contra la infraestructura del adversario, y ha preparado a nuestros sistemas y analistas para responder a estos incidentes en mucho menos tiempo y con una confianza extrema en la malicia, eliminando los intentos del adversario de evadir nuestras detecciones.
En definitiva, pudimos ver las actividades diarias específicas del actor de amenazas, desde sus metodologías hasta los tipos específicos de organizaciones (e incluso personas) que le interesaban. También lo vimos empezar a experimentar con herramientas y buscar tutoriales, tratando de aprender más. Por ejemplo, después de instalar el agente de Huntress, el actor de amenazas tomó medidas para entender mejor Autoruns.
Figura 4: El actor de amenazas intentando entender mejor Autoruns
En general, a lo largo de tres meses vimos una evolución en la forma en que el actor de amenazas refinó sus procesos, incorporó IA en sus flujos de trabajo y se dirigió a distintas organizaciones y mercados verticales, como se describe en la Figura 5 a continuación.
Figura 5: Una descripción general de algunas de las actividades del actor de amenazas que vimos a lo largo de los meses
A continuación se presentan algunas de las metodologías específicas que observamos.
Metodologías del atacante
Uso de IA para la eficiencia operativa
El historial del navegador Chrome dio una vista de primera mano de cómo el adversario está usando herramientas de IA para aumentar la eficiencia operativa de sus flujos de trabajo. Si bien anteriormente ha habido muchos informes sobre cómo los cibercriminales usan IA (basados en indicadores en mensajes de phishing o contenido de páginas de destino), esta es la primera vez que tenemos una vista cercana de un actor de amenazas integrando IA en sus operaciones para automatizar, y acelerar, su flujo de trabajo.
El 25 de mayo, el actor de amenazas se registró en Make.com, que es un software legítimo de automatización de flujos de trabajo, antes de investigar la función de integración de Telegram Bot de la plataforma como una forma de lanzar procesos automatizados (como se ve en la Figura 6 a continuación). Luego, el actor de amenazas exploró varios sitios de preguntas frecuentes para entender mejor cómo funcionan las API de Telegram Bot y cómo configurar webhooks.
Figura 6: Registrándose en Make.com
Figura 7: Profundizando en las API de Telegram Bot
Con el tiempo, el actor de amenazas comenzó a entender mejor cómo podía usar Make.com para flujos de trabajo específicos, y su historial del navegador muestra que empezó a depender cada vez más de la plataforma. Para cuando llegó el 29 de junio, el actor de amenazas había desarrollado por completo su flujo de trabajo con Make. Como se ve en la Figura 8, el actor de amenazas primero identificaba la organización de interés (generalmente después de recibir un “soplo” de Telegram) antes de usar Google Translate para traducir o redactar mensajes relacionados con esas organizaciones. Si bien no tenemos información detallada sobre cómo el actor de amenazas usaba Make para estos flujos de trabajo específicos, podemos ver que formaba parte del proceso para automatizar funciones específicas.
Figura 8: El actor de amenazas empieza a depender de flujos de trabajo automatizados
El actor de amenazas también pareció estar interesado en otras herramientas de IA para ayudar con la generación de datos y la redacción. Vimos múltiples búsquedas en Google de "free ai no signup" y de "csv generator ai". También vimos al actor de amenazas usando Toolbaz AI, que es un asistente de redacción; la función de generador de hojas de cálculo CSV de DocsBot AI, que es una herramienta de chatbot con IA; y la función de generador de datos con IA de Explo AI, que es una herramienta de análisis integrada.
Cómo encontrar instancias en ejecución de Evilginx
Vimos evidencia de que el actor de amenazas buscaba instancias en ejecución del framework de ataque de intermediario Evilginx usando Censys, y luego intentaba acceder a esas instancias.
Figura 9: Uso de Censys para buscar instancias en ejecución de Evilginx
Figura 10: Un ejemplo de la instancia de Evilginx a la que el atacante intentó acceder
Además de Evilginx, también encontramos evidencia de múltiples herramientas instaladas en el sistema del actor de amenazas, o, en algunos casos, interés en herramientas según el historial del navegador del actor de amenazas. Estas herramientas incluían la herramienta de reconocimiento y ataque GraphSpy, la herramienta de código abierto Bloodhound, el framework TeamFiltration usado para enumeración y exfiltración, y más.
Figura 11: Varias herramientas que el atacante pudo haber usado
Interés en servicios de proxy residencial
El historial del navegador Chrome también reveló visitas del actor de amenazas a múltiples páginas web de proxy residencial, incluyendo LunaProxy y Nstbrowser (que se presenta como un navegador antidetección y admite el uso de proxies residenciales). El actor de amenazas visitó la página de planes de precios de LunaProxy, investigó productos específicos y consultó guías de inicio rápido a lo largo de mayo, junio y julio. Los servicios de proxy residencial se han vuelto cada vez más populares entre los actores de amenazas como forma de dirigir su tráfico a través de direcciones IP residenciales, lo que les permite ocultar actividad maliciosa, como evitar alertas de inicio de sesión sospechoso mientras usan credenciales comprometidas.
Figura 12: Una búsqueda en VirusTotal de LunaProxy.exe, que estaba en el historial de Chrome
Métodos de investigación y reconocimiento
Las entradas del historial del navegador Chrome también nos dieron una visión detallada de los métodos de reconocimiento del atacante. El actor de amenazas pasó mucho tiempo investigando empresas de diferentes sectores, desde bancos específicos hasta "top real estate companies in the US" (también buscando "real estate agents in California").
El actor de amenazas no solo buscaba empresas individuales, también examinaba todas las partes del ecosistema que rodea a las organizaciones de interés, desde sus bases de clientes hasta empresas asociadas de terceros a lo largo de la cadena de suministro. Por ejemplo, el actor de amenazas pareció empezar a apuntar a empresas de software a principios de julio, buscando este tipo de empresas mediante Google Search y usando herramientas de marketing con bases de datos como ReadyContacts e InfoClutch para evaluar cuántos clientes tenían y su participación de mercado.
El actor de amenazas también usó la plataforma BuiltWith, que permite a los usuarios identificar y analizar las pilas tecnológicas usadas por los sitios web. El 8 de julio, las entradas del navegador muestran al atacante llevando a cabo un nivel extenso de investigación sobre un proveedor de ecommerce prominente para la gestión de pagos y suscripciones, incluyendo una lista de sus clientes, contactos y participación de mercado. El actor de amenazas luego usó BuiltWith para buscar los sitios web que dependían de ese proveedor, antes de navegar a la página de registro de BuiltWith, presumiblemente para acceder a esa lista.
El actor de amenazas realizó una cantidad considerable de investigación sobre herramientas usadas para extraer datos de grupos de Telegram, incluyendo herramientas de extracción como Apify, la extensión de Chrome Axiom y la plataforma RapidAPI (Figura 13).
Figura 13: Mientras investigaba herramientas de extracción de datos, el actor de amenazas encontró RapidAPI
Uso de Google Translate
El actor de amenazas usó Google Translate extensamente, y el navegador Chrome los muestra primero visitando sitios web de bancos, y luego usando la plataforma de traducción, probablemente para ayudar a redactar mensajes relacionados con phishing, como se ve en la Figura 14.
Figura 14: El actor de amenazas usó los servicios de Google Translate extensamente
El atacante a menudo usó urlscan para obtener información sobre varios sitios web. Los datos parecen haber llegado por Telegram usando el método getUpdates.
Figura 15: Parte del historial de Chrome relacionado con un dato en particular
Figura 16: Mensaje de Google Translate
Figura 17: Mensaje de Google Translate: nombre de usuario y contraseña
Figura 18: Mensaje de Google Translate: nombre de usuario y contraseña
Había varias entradas en el historial del navegador que mostraban el uso de Google Translate para traducir mensajes del portugués al inglés junto con la navegación por bancos en Brasil, y luego evidencia de redacción de mensajes más adelante en su historial.
Dark web: mercado STYX
También vimos que el actor de amenazas mostró interés en STYX Market, un foro de la dark web que existe desde 2023, y que investigadores calificaron recientemente como una “estrella en ascenso para registros de stealers, credenciales robadas y servicios de lavado”. Después de hacer una investigación inicial sobre STYX, así como en otros grupos y canales de chat de Telegram, decidieron revisar el sitio por sí mismos, registrando una cuenta antes de revisar el catálogo de cuentas de red de voz sobre IP, registros de stealers, tarjetas SIM y más.
Figura 19: El actor de amenazas mostró interés en STYX Market
Figura 20: Una publicación de SOCRadar sobre STYX Market llamó la atención del actor de amenazas
Actividades de EDR
Rara vez se tiene la oportunidad de observar en vivo a un actor de amenazas real. Tuvimos esa oportunidad cuando instalaron nuestro agente. Comienza de manera bastante común. No sabemos con qué habrán soñado después de terminar su turno a las 2 a. m. UTC la noche anterior, pero, como mencionamos antes, puedes verlos iniciar una prueba, descargar el agente e instalarlo.
Figura 21: A las 2 a. m. UTC, tras unas 10 horas de inactividad, el actor de amenazas mostró de pronto interés en Bitdefender, lo que los llevó a Huntress
La actividad más interesante al comenzar su día el 9 de julio de 2025 fue navegar a urlscan.io para inspeccionar login.incipientcroop[.]com. Poco después, iniciaron sesión en Make.com y comenzaron a trabajar en un proyecto llamado Voltage_Office356bot (nota el error tipográfico).
Figura 22: Línea de tiempo de EDR e historiales de navegador
Figura 23: Información de urlquery para login.incipientcroop[.]com
Figura 24: Más abajo en la página de urlquery para login.incipientcroop[.]com, hay evidencia de Voltage_Office356bot
Hay evidencia de que el actor de amenazas tuvo acceso a datos de cookies de dos personas distintas, y accedió a ellos mediante Notepad++. Procedieron a abrir el primer archivo:
C:\Program Files\Notepad++\notepad++.exe C:\Users\Administrator\Downloads\Telegram
Desktop\Cookies_[victim1]@[redacted1][.].com.json
Luego comenzaron a buscar qué podían encontrar, con una búsqueda en Google de “email osint”.
Figura 25: Buscando “email osint”
Luego abrieron el segundo archivo de cookies:
C:\Program Files\Notepad++\notepad++.exe C:\Users\Administrator\Downloads\Telegram
Desktop\Cookies_[victim2]@[redacted2][.].com.json
Después iniciaron Nstbrowser.exe y LunaProxy:
C:\Program Files\Nstbrowser\Nstbrowser.exe
C:\Program Files (x86)\LunaProxy_cata\socks5\LunaProxyDivert.exe SOCK5 [snip]
Navegaron a un artículo titulado Say Hello to your new cache flow de Synacktiv, sobre WHFB y Entra ID, seguido de una búsqueda en Google de “whfb prt”, que los llevó al sitio web de un investigador reconocido, Dirk-Jan Mollema.
Después de esto revisaron su dirección IP:
C:\Windows\system32\curl.exe ipinfo[.]io
Y luego volvieron a revisar su dirección IP:
C:\Windows\system32\curl.exe ipinfo[.]io
Luego intentaron usar una herramienta llamada ROADtools Token eXchange (roadtx):
C:\Users\Administrator\AppData\Local\Programs\Python\Python313\Scripts\roadtx.exe prtauth -r msgraph -c msteams
Y luego intentaron, por error, ejecutar la misma herramienta (como ejecutable) mediante Python:
C:\Users\Administrator\AppData\Local\Programs\Python\Python313\python.exe C:\Users\Administrator\AppData\Local\Programs\Python\Python313\Scripts\roadtx.exe prtauth -r msgraph -c msteams
Luego la ejecutaron de nuevo:
C:\Users\Administrator\AppData\Local\Programs\Python\Python313\Scripts\roadtx.exe describe
Y luego intentaron ejecutarla otra vez, por error, usando Python:
C:\Users\Administrator\AppData\Local\Programs\Python\Python313\python.exe C:\Users\Administrator\AppData\Local\Programs\Python\Python313\Scripts\roadtx.exe describe
Parecían tener problemas. En este punto navegaron a la publicación de Dirk-jan Mollema sobre Phishing for Microsoft Entra primary refresh tokens.
Figura 26: Buscando una respuesta con la palabra clave whfb prt
Mientras estaban allí, obtuvieron nueva inspiración y descubrieron un pequeño script útil que podría facilitarles la vida:
Figura 27: Extracto del blog de Dirk-jan, que señala un pequeño script ingenioso
En ese momento, volvieron a su proyecto Voltage_Office356bot antes de ejecutar este nuevo script que habían descargado.
Figura 28: Acceso al proyecto Voltage_Office356bot y ejecución del script de ataque
Comenzaron a intentar ejecutar el script de Python:
C:\Users\Administrator\AppData\Local\Programs\Python\Python313\python.exe main.py -f roadtx.prt --wfb
Revisaron el uso de nuevo:
C:\Users\Administrator\AppData\Local\Programs\Python\Python313\python.exe main.py --wfb
C:\Users\Administrator\AppData\Local\Programs\Python\Python313\python.exe main.py -h
Luego, comenzaron a ejecutarlo contra la víctima original cuyo archivo de cookies vimos antes:
C:\Users\Administrator\AppData\Local\Programs\Python\Python313\python.exe main.py --wfb -u [victim2]@[redacted2][.]com
Volvieron al archivo de cookies de la primera víctima:
C:\Program Files\Notepad++\notepad++.exe C:\Users\Administrator\Downloads\Telegram
Desktop\Cookies_[victim1]@[redacted1][.].com.json
Aquí es donde nuestros datos de EDR se interrumpen, ya que es posible que se hayan dado cuenta de nuestra presencia y hayan desinstalado el agente.
Horas trabajadas en un día
El historial del navegador del atacante nos da un nivel sin precedentes de información sobre su actividad diaria, búsquedas, flujos de trabajo, investigación y más. El historial del navegador muestra al actor de amenazas trabajando intensamente casi todos los días entre el 29 de mayo de 2025 y el 9 de julio de 2025.
Figura 29: Gráfico de la cantidad de horas por día (la etiqueta alterna fechas) trabajadas según las actividades del navegador
En muchos de estos días, las entradas del navegador se registraron a lo largo de la mayoría de las horas del día, llegando a 12 o 14 horas. Pero hubo algo de variación, como se ve en la Figura 29, arriba: en varios días, el actor de amenazas trabajó tan solo una o dos horas.
Cuando nos enfocamos en algunos de los días en que se trabajaron más horas, podemos ver algunas de las cosas que despertaron el interés del atacante en esos días. Analizamos las URL para ver a qué negocios o categorías podrían pertenecer, y luego vimos cuántas veces el atacante visitó estos sitios.
Podemos observar algunas tendencias. Durante estos días, el atacante dedicó mucho tiempo a investigar varias entidades bancarias y personal bancario. Para ampliar un poco más algunas de las etiquetas del gráfico:
Infraestructura de ataque: Sitios web o servidores maliciosos configurados por un atacante (quizás no este) que alojan frameworks como Evilginx y otras herramientas conocidas.
Banca: Varios sitios web bancarios.
Extensión del navegador: Varias extensiones del navegador, como bloqueadores de anuncios, etc., instaladas por el atacante para protegerse.
Corporativo y negocios: Varios sitios web de negocios que no entran en otra categoría.
Cripto: Varios sitios web de criptomonedas y blockchain.
Ciberseguridad: Varios sitios web de proveedores de ciberseguridad. El atacante a menudo se inscribía en pruebas gratuitas de varios proveedores para probar cosas.
Gobierno y militar: Varios sitios web oficiales de gobiernos o militares.
Noticias, medios e información: Varios sitios de noticias como CNN, etc. El atacante a menudo leía artículos relacionados con diversas filtraciones de datos.
OSS: Proyectos de código abierto, a menudo alojados en github o gitlab.
Reconocimiento: Actividades en las que el atacante usaba Censys, Urlscan, Google, etc., para hacer reconocimiento de un objetivo en particular.
Investigación: Cuando el atacante investigaba una vulnerabilidad, herramienta o ataque en particular.
Sandbox: El atacante a menudo parecía interesado en varios tipos de malware que estaban en VirusTotal, Joe's Sandbox y otros sandboxes en línea.
Redes sociales: Varias publicaciones de Telegram, X y otras redes sociales leídas por el atacante.
Software: Varios programas legítimos, como 7zip.
Telecomunicaciones: Un sitio web de telecomunicaciones, como Verizon.
Infraestructura web y de TI: Varios servicios de alojamiento en línea, como Mega, Amazon AWS y Azure.
Figura 30: Actividades del 29 de mayo de 2025
Podemos ver que del 29 de mayo al 1 de junio de 2025, el atacante se enfocó principalmente en varios sitios web bancarios. Profundizando más en sus actividades, se le ve investigando varios bancos, leyendo sobre bots de Telegram y luego descargando un blueprint de Make.
Figura 31: Una mirada más profunda a algunas de las actividades del 29 de mayo de 2025
Al día siguiente, parece que el atacante dedicó un poco más de tiempo a investigar varias infraestructuras de ataque, además de enfocarse en bancos y actividades similares a las vistas anteriormente.
Figura 32: Actividades del 30 de mayo de 2025
El 31 de mayo de 2025 y el 1 de junio de 2025, el atacante volvió a enfocarse principalmente en investigar sitios web bancarios.
Figura 33: Actividades del 31 de mayo de 2025
Figura 34: Actividades del 1 de junio de 2025
Figura 35: Regiones en las que se enfocó el atacante del 29 de mayo al 1 de junio de 2025
Otro dato interesante fue que el atacante se concentró sobre todo en bancos y sitios de Nigeria durante este período, e incluso buscó cosas como:
“No. 1 regulated crypto exchange in Nigeria.”
“top crypto companies nigeria”
“Best Crypto Exchanges in Nigeria”
“Top Criptomoneda Companies in Nigeria”
Aunque no sabemos dónde se encuentra el atacante, la máquina en la que había instalado nuestro agente parecía estar ubicada en Estados Unidos, en la costa oeste, según la zona horaria interna de la máquina y su dirección IP.
Figura 36: Actividades del 9 de julio de 2025
Parece que el atacante pasó bastante tiempo revisando nuestras diversas capacidades después de iniciar una prueba con nosotros. La figura 36 muestra cuánto más tiempo pasó interactuando con el sitio web de Huntress, y en particular con el panel de la cuenta una vez que inició la prueba.
Lecciones aprendidas
Este incidente nos dio información detallada sobre las actividades diarias de un actor de amenazas, desde las herramientas que le interesaban hasta la forma en que investigaba y abordaba distintos aspectos de los ataques.
Al confirmar que el nombre de la máquina era uno usado por un adversario, decidimos publicar estos detalles porque brindan una comprensión invaluable sobre la mentalidad y los comportamientos de los actores de amenazas detrás de los ataques. Para otros defensores, esperamos que esta información ayude a dar contexto sobre las formas en que los actores de amenazas investigan y lanzan ataques desde el backend, y sobre los distintos tipos de organizaciones, herramientas y plataformas que les interesan.
