El SIEM de otro: un actor de amenazas abusa de otra prueba gratuita

TL; DR Huntress descubrió que un actor de amenazas estaba explotando vulnerabilidades (como SolarWinds Web Help Desk) y exfiltrando datos de víctimas a una instancia de prueba gratuita de Elastic Cloud SIEM. El actor usó el SIEM para la triaje de víctimas, y la infraestructura reveló detalles sobre su campaña, incluyendo servicios de correo desechable (quieresmail.com), conexiones a una red de correo temporal registrada en Rusia (firstmail.ltd), el uso de un túnel SAFING_VPN, y una posible conexión con otros ataques oportunistas contra Microsoft SharePoint y otro software. Desde entonces, la instancia fue dada de baja.

Antecedentes

En una publicación de blog anterior, Huntress observó a un adversario explotando SolarWinds Web Help Desk y exfiltrando datos comprometidos de víctimas a una instancia expuesta de Elastic Cloud. De inmediato, quisimos compartir inteligencia de amenazas sobre las intrusiones, pero durante esa investigación, descubrimos una nueva madriguera: infraestructura activa del actor de amenazas que usaba para sus campañas.

No somos ajenos a que los adversarios abusen de las pruebas gratuitas de software de seguridad, y esta vez informamos a Elastic y a las partes relevantes para que se pudiera investigar la actividad y abordar las acciones del atacante.

Para dar más tiempo a la notificación y el contacto con las víctimas, así como a nuestra coordinación en varios frentes con las autoridades y la notificación a Elastic, optamos por separar los hallazgos de la investigación de SolarWinds en dos partes: este artículo es la "Parte 2" prometida de nuestra publicación anterior.

Continuaremos desde este punto de partida: un actor de amenazas ejecutó un comando de PowerShell codificado con una clave de API y credenciales incorporadas en el código para exfiltrar datos a una instancia gratuita de Elastic Cloud SIEM.

Exfiltración hacia Elastic

Para dar contexto, quizás recuerdes que hubo un comando de PowerShell codificado ejecutado por el actor de amenazas en el equipo de la víctima. Esto ejecutó el cmdlet Get-ComputerInfo para descubrir información detallada del sistema y luego la envió a un índice de ElasticSearch controlado por el atacante, usando una clave de API incorporada en el código.

Este proceso exfiltró la versión del sistema operativo, detalles de hardware, información del dominio de Active Directory, parches instalados, y los metadatos generales de este endpoint a una instancia de Elastic llamada systeminfo.

Si bien antes habíamos visto a actores de amenazas aprovechando Velociraptor y otras herramientas enfocadas en DFIR para comando y control, esta fue la primera vez que observamos a un adversario usar Elastic Cloud para la exfiltración. El atacante preparó su propia prueba gratuita de Elastic Cloud, usando infraestructura legítima de Elastic, y la usó como repositorio de datos robados en distintas intrusiones. Así podían hacer la triaje de sus víctimas y endpoints comprometidos, literalmente usando tecnología SIEM.

Notificamos a Elastic sobre este abuso de su prueba, y colaboramos para descubrir más detalles notables sobre este adversario. Resultó que el índice systeminfo dentro de la instancia de Elastic Cloud del actor de amenazas exponía detalles no solo de una víctima, sino de múltiples compromisos a lo largo de toda una campaña.

El despliegue

El despliegue de Elastic Cloud se creó el 28 de enero de 2026 a las 01:45 UTC bajo la cuenta en la nube u_706752903_cloud, con el ID de despliegue 7c00a38569a8471083b6b34e1511b9de. La instancia ejecutaba Elasticsearch versión 9.2.4 en la región us-central1 de GCP. El despliegue usaba el nombre predeterminado ("My deployment"). El agente Fleet permaneció en línea y saludable hasta el 7 de febrero, lo que indica que la infraestructura se mantuvo activa a lo largo de toda la campaña.

Elastic confirmó que el adversario registró su cuenta de prueba gratuita con una dirección de correo electrónico que tenía un formato único: lo que parecían ocho letras minúsculas aleatorias, y el dominio  quieresmail[.]com .

Esta convención de nombres y este dominio indican un servicio de correo desechable y temporal. Hemos visto otras direcciones de correo con este dominio quieresmail[.]com con un formato que incluye un nombre o apellido falso seguido de cuatro dígitos que representan un año, o una cadena aleatoria de ocho caracteres como esta. Creemos que este es uno de los dominios de correo desechable operados por la red firstmail.ltd, un servicio de correo temporal registrado en Rusia que gestiona cientos de dominios desechables desde la misma infraestructura.

Figura 1: Captura de pantalla del sitio web de Firstmail

Al notar esto, Elastic nos compartió que se habían creado varias otras pruebas gratuitas con diferentes direcciones de correo desechables, pero todas seguían el mismo formato de cadena aleatoria. Nos indicaron algunas de las direcciones de correo y, curiosamente, más de uno de esos mismos prefijos aleatorios de correo coincidía exactamente con el mismo subdominio que observamos usado para las páginas de Cloudflare Worker: por ejemplo, uno llamado qgtxtebl.workers[.]dev.

Figura 2: Captura de pantalla de la página de Cloudflare Workers

Si bien estas direcciones de correo de FirstMail.ltd se generan de forma aleatoria, los subdominios de Cloudflare Worker Pages son configurables... pero múltiples instancias de estos coincidían y se alineaban.

Nos pareció algo muy peculiar: parecía que el adversario trataba el prefijo de correo generado aleatoriamente como una clave o identificador para partes de su infraestructura y campañas. Esta cadena aleatoria se usó tanto para el correo de registro de su prueba de Elastic Cloud como para sus herramientas de Cloudflare Worker, con las que alojaba sus callbacks de Velociraptor.

La actividad

La telemetría de uso de Kibana reveló que el operador dedicó una cantidad considerable de tiempo a la triaje de datos de víctimas a través de la interfaz Discover durante siete días.

Solo el 28 de enero, el día en que se puso en marcha el despliegue, el operador registró 164 interacciones durante casi 150 minutos de uso activo. La actividad continuó en los días siguientes: 46 interacciones el 29 de enero, 105 el 30 de enero, luego una pausa antes de retomar el 2 de febrero, cuando llegó la primera oleada de datos de víctimas. El 4 de febrero marcó la actividad más dirigida, con 106 búsquedas de campos, 23 filtros aplicados y 15 consultas de búsqueda enviadas en poco menos de 13 minutos, lo cual es consistente con una triaje sistemática de objetivos de alto valor, como controladores de dominio y endpoints unidos al dominio.

A lo largo de toda la campaña, hubo aproximadamente 249 minutos de uso activo de Discover, 449 interacciones en total, y evidencia de que al menos un índice fue eliminado el 2 de febrero, posiblemente una recopilación anterior que se eliminó antes de que se poblara el conjunto de datos actual.

Las sesiones de inicio de sesión administrativo en la instancia de Elastic Cloud provinieron de estas direcciones IP:

1. 154.26.156[.]181
2. 51.161.152[.]26

En conversaciones con numerosos otros equipos de seguridad y varias agencias de la ley, existe consenso en que estas direcciones IP provienen de un túnel SAFING_VPN. Esto parece ser Safing “SPN” o “SVPN”, una opción de red de privacidad especializada alternativa a las VPN tradicionales y a Tor.

Cabe destacar que la IP 51.161.152[.]26 también fue observada por Unit 42 en un caso de explotación de ToolShell contra Microsoft SharePoint, otro ataque oportunista que aprovecha vulnerabilidades recientes de día cero o n-day que le dan al adversario ejecución de código con facilidad.

Otra telemetría de las sesiones de Kibana en Elastic Cloud también dio una huella digital del navegador del operador y de la estación de trabajo sospechosa:

El índice systeminfo contenía aproximadamente 216 endpoints víctima únicos al momento del análisis.

Los datos de las víctimas se inclinaron abrumadoramente hacia servidores (91%), y la mayoría ejecutaba Windows Server 2019 o 2022. Entre los 47 endpoints unidos a un dominio, identificamos 34 dominios de Active Directory únicos que representaban organizaciones distintas. Los sectores afectados incluyeron agencias gubernamentales, instituciones de educación superior, servicios financieros, organizaciones religiosas y sin fines de lucro, empresas globales de manufactura y automotrices, proveedores de servicios de TI, comercio minorista y construcción. Las víctimas abarcan 37 zonas horarias distintas en varios continentes.

Numerosos nombres de equipo dentro del conjunto de datos de víctimas apuntaron a la explotación continua de otras vulnerabilidades de alta severidad recientes, lo que sugiere que el actor siguió realizando ataques oportunistas contra cualquier software que tuviera una debilidad crítica que llevara a un compromiso inmediato. En concreto, hubo múltiples casos que sugerían intrusiones de Gladinet CentreStack, SmarterMail o SmarterTools, Solarwinds Web Help Desk, y ToolShell contra Microsoft SharePoint. Esta evidencia siguió siendo corroborada por la información compartida por Black Lotus Labs, con quienes también colaboramos y conversamos tras nuestra publicación inicial del blog. Nos dio gusto conectar tanto a ellos como a Elastic para lograr aún más intercambio conjunto de información.

Entre los 216 registros, un grupo de cuatro endpoints se destacó como posiblemente las propias VM de prueba del operador. Los endpoints Hajbepfy, Bekpaseb, Hhbhymne, y Vdfyivhy (nombres de equipo aleatorios de 8 caracteres) compartían una huella digital idéntica: una cadena de compilación SMBIOS personalizada (rel-1.16.3-0-ga6ed6b70-prebuilt.dady.org), un número de serie de BIOS fabricado de DELL 1 serial, y perfiles de hardware QEMU idénticos (CPU Broadwell, ProcessorID 078BFBFF000306D2, 4 GB de RAM, NIC Realtek RTL8139C+).

Dos de los cuatro, Hajbepfy y Bekpaseb, también tenían el fabricante del sistema configurado como DADY con el modelo Dady super powerfulPC, mientras que los otros dos conservaban los identificadores predeterminados de QEMU.

Un hallazgo notable dentro de la instancia de Elastic controlada por el atacante fue una búsqueda guardada de Kibana, llamada “oooo”. El actor de amenazas creó y guardó esta búsqueda el 4 de febrero, y seleccionó específicamente las columnas para el dominio de la víctima, el título, la zona horaria y las direcciones IP. Filtraron las estaciones de trabajo independientes y se enfocaron específicamente en un dominio de víctima. Su objetivo de interés tenía 6 servidores ya comprometidos con sus datos presentes en el índice systeminfo de Elastic, y un nombre de equipo sugería que se trataba de un controlador de dominio. Nuestra investigación nos lleva a creer que esta organización víctima se presenta como una “plataforma SaaS impulsada por IA.”

Hemos realizado el contacto y la notificación a las víctimas, a las organizaciones que creemos que estaban indicadas dentro de los datos descubiertos, y hemos coordinado con Elastic en un esfuerzo conjunto para seguir investigando y dar de baja esta infraestructura del actor de amenazas. Elastic nos ha confirmado que esta instancia ya fue dada de baja.