Los infostealers se han convertido en una pieza importante del ecosistema del cibercrimen porque permiten transformar el compromiso de un único equipo en algo mucho más valioso: credenciales, cookies de sesión, información financiera, datos de aplicaciones y otros elementos que pueden facilitar fraudes, secuestro de cuentas o nuevos accesos a una organización.
Phantom Stealer pertenece a esta categoría, pero analizar únicamente qué información puede robar ofrece una visión incompleta de la amenaza. Lo realmente interesante se encuentra en la cadena que permite llevar el malware desde un correo aparentemente legítimo hasta la memoria de un equipo Windows sin presentar necesariamente un ejecutable convencional al usuario.
Investigaciones publicadas por Fortra en junio de 2026 y Seqrite en julio del mismo año muestran campañas diferentes de Phantom Stealer con un patrón común: ingeniería social, archivos comprimidos, ejecución mediante scripts, varias capas de ofuscación y un uso intensivo de PowerShell y de técnicas de ejecución en memoria. Las diferencias entre ambas investigaciones son también importantes, porque demuestran que Phantom Stealer no debe asociarse a una única cadena de infección.
Phantom Stealer no es solamente el payload final
Uno de los errores al analizar un infostealer consiste en concentrarse exclusivamente en el ejecutable encargado de robar información. En una intrusión real, el malware final es solo una parte del problema. Antes han tenido que producirse el acceso inicial, la interacción del usuario, la ejecución de uno o varios cargadores y la evasión de diferentes controles de seguridad.
Fortra documentó el 16 de junio de 2026 una campaña activa dirigida especialmente contra organizaciones del sector bancario. La muestra analizada llegaba dentro de un archivo RAR y utilizaba un BAT presentado como una solicitud de presupuesto empresarial. Una vez ejecutado, el BAT iniciaba una cadena ofuscada que terminaba cargando Phantom Stealer en memoria.
Seqrite documentó el 22 de julio de 2026 otra operación. En este caso, los atacantes utilizaban comunicaciones relacionadas con logística, banca y fiscalidad. Los archivos comprimidos contenían JavaScript malicioso y la cadena continuaba mediante varias etapas PowerShell hasta desplegar Phantom Stealer v3.5.0.
Por tanto, BAT o JavaScript no deben considerarse características universales del malware. Son mecanismos de entrega observados en campañas concretas. Lo relevante desde el punto de vista defensivo es el patrón: un contenido empresarial sirve como señuelo y un script aparentemente secundario comienza a reconstruir las siguientes etapas.
Fase 1: el acceso inicial comienza con ingeniería social
El ataque necesita conseguir que el destinatario realice una acción. Para ello, los operadores recurren a escenarios empresariales plausibles en los que abrir un documento o archivo parece formar parte del trabajo habitual.
En la campaña estudiada por Fortra, el archivo estaba presentado como una solicitud de presupuesto. Seqrite observó, entre otros señuelos, una comunicación que imitaba una gestión logística y otra que simulaba una notificación de una autoridad fiscal. Esta adaptación es relevante porque reduce la distancia entre el contexto del mensaje y las tareas normales de la persona que lo recibe.
El archivo comprimido aporta además una capa adicional entre el sistema de correo y el contenido ejecutable. MITRE ATT&CK T1566.001 clasifica esta técnica como Spearphishing Attachment. El éxito, sin embargo, sigue dependiendo en gran medida de que el destinatario extraiga y ejecute el contenido.
La imagen anterior debe interpretarse como un esquema conceptual del acceso inicial y no como la reproducción de un correo concreto de las campañas investigadas. Las extensiones y componentes exactos dependen de la operación analizada.
Fase 2: el primer script oculta la verdadera carga
Una vez que la víctima ejecuta el contenido, el ataque abandona la capa de ingeniería social y entra en una cadena diseñada para dificultar el análisis.
La campaña de Seqrite constituye un buen ejemplo. El JavaScript incluido en el archivo comprimido estaba ofuscado mediante cadenas ocultas, índices numéricos y funciones indirectas. Tras recuperar las cadenas era posible observar referencias a PowerShell, objetos COM, operaciones con archivos y WMI. El JavaScript no era Phantom Stealer: actuaba como cargador de la siguiente etapa.
Además, el script contenía un PowerShell codificado en Base64. Durante la ejecución reconstruía ese contenido y transfería el control a powershell.exe. Este diseño permite ocultar gran parte de la lógica real hasta que la cadena se encuentra en ejecución.
En la campaña estudiada por Fortra el mecanismo era diferente. Un BAT fuertemente ofuscado contenía una gran cantidad de información codificada y acababa reconstruyendo un script PowerShell. Fortra también documentó mecanismos de persistencia en esa campaña, incluyendo una copia oculta del BAT en AppData, una entrada RunOnce y manipulación relacionada con COM.
Esto demuestra por qué una regla que busque únicamente una extensión o un nombre de archivo ofrece una cobertura limitada. Los artefactos pueden cambiar; la relación anómala entre un archivo recibido por correo, un intérprete de scripts y PowerShell suele tener más valor defensivo.
Fase 3: PowerShell como orquestador
PowerShell proporciona a los atacantes una plataforma ya disponible en Windows capaz de manipular datos, utilizar bibliotecas .NET y ejecutar contenido directamente en memoria. Su presencia no es maliciosa por sí misma, pero una cadena que comienza en un adjunto externo y desemboca en PowerShell oculto merece especial atención.
En el análisis de Seqrite, el primer cargador PowerShell contenía la siguiente etapa cifrada con AES. Los componentes necesarios se almacenaban codificados en Base64 y la recuperación del contenido se realizaba utilizando funcionalidades criptográficas de .NET. Una vez obtenido el script en claro, la cadena continuaba mediante ejecución en memoria.
La siguiente etapa recuperaba un ensamblado .NET protegido y el payload de Phantom Stealer. Seqrite observó que el cargador entregaba el PE final a un ensamblado reflectivo junto con la ruta de aspnet_compiler.exe, delegando en ese componente la inyección y ejecución.
Fortra encontró otra construcción. El PowerShell de su muestra aplicaba sucesivamente Base64, operaciones XOR y AES-256-CBC para recuperar shellcode asociado a DonutLoader. El resultado acababa inyectando Phantom Stealer en explorer.exe y mantenía el payload final fuera del disco.
La comparación es especialmente útil: ambas operaciones alcanzan un objetivo similar utilizando implementaciones distintas. Por ello, no debe asumirse que Phantom Stealer siempre utiliza explorer.exe, aspnet_compiler.exe, una secuencia criptográfica concreta o un único tipo de cargador.
Fase 4: ejecución en memoria y evasión
La ejecución en memoria reduce los artefactos tradicionales que pueden analizarse mediante firmas estáticas. Esto no significa que la actividad sea invisible: continúan existiendo procesos, relaciones padre-hijo, accesos a memoria, descodificación de contenido y comunicaciones de red. Lo que cambia es el lugar donde resulta más rentable observar.
En la campaña de Fortra, el payload no aparecía como un PE convencional almacenado en disco durante la fase final. El shellcode de DonutLoader encapsulaba el componente .NET y la ejecución terminaba dentro de explorer.exe. La investigación también documentó ofuscación de comandos, caracteres Unicode destinados a complicar la decodificación, nombres de API ocultos y comprobaciones para impedir ejecuciones duplicadas.
Seqrite observó asimismo carga reflectiva, ofuscación por capas e inyección de procesos. Estas conductas pueden relacionarse con técnicas de MITRE ATT&CK como T1027 – Obfuscated Files or Information, T1140 – Deobfuscate/Decode Files or Information, T1620 – Reflective Code Loading y T1055 – Process Injection.
La conclusión defensiva es importante: la ausencia de un ejecutable sospechoso en disco no equivale a ausencia de compromiso.
Fase 5: Phantom Stealer comienza la recolección
Una vez ejecutado el payload final comienza la fase que da sentido económico a toda la operación. Seqrite documentó la recopilación de información del host, software instalado, credenciales de navegadores, cookies, tarjetas almacenadas, historial de navegación, datos relacionados con monederos de criptomonedas y aplicaciones de mensajería.
Fortra describe objetivos similares y añade capacidades relacionadas con navegadores como Chrome, Firefox y Edge, además de aplicaciones como Discord, Telegram y Steam. Su investigación también identifica captura de pulsaciones, screenshots y contenido del portapapeles.
Este tipo de información resulta especialmente sensible porque el impacto no se limita a una contraseña. Una cookie o token de sesión puede mantener valor mientras la sesión continúe siendo aceptada; las credenciales corporativas pueden abrir un segundo vector de acceso; y la información financiera o relacionada con criptomonedas puede utilizarse directamente para obtener beneficio económico.
Proofpoint Threat Research estudió en 2025 la relación entre Phantom Stealer y Stealerium. Sus investigadores encontraron un solapamiento considerable de código y señalaron que algunas muestras contienen referencias a ambas familias. Proofpoint agrupa determinadas variantes bajo la denominación Stealerium debido a ese solapamiento y documenta diferencias en las funciones utilizadas para generar y enviar los informes.
Esta relación obliga a ser prudentes con la atribución basada únicamente en una cadena, namespace o función aislada. La reutilización de código entre familias y variantes puede introducir ambigüedad.
Fase 6: preparación y exfiltración
Una vez recopilada la información, el malware debe transferirla fuera del equipo comprometido. Aquí vuelven a aparecer diferencias entre campañas.
Seqrite observó en su análisis de Phantom Stealer v3.5.0 una exfiltración basada en SMTP. El malware organizaba los datos por categorías, establecía una sesión SMTP sobre el puerto TCP 587, utilizaba ESMTP y posteriormente STARTTLS. De esta forma, los datos podían abandonar el equipo mediante un protocolo utilizado legítimamente para correo electrónico y con la comunicación posterior protegida mediante TLS.
Fortra documentó una arquitectura con varios mecanismos de exfiltración, entre ellos Telegram, Discord, FTP y SMTP. Esto introduce redundancia: bloquear un único destino o protocolo no garantiza necesariamente que una variante configurada con otros canales pierda su capacidad para extraer información.
En consecuencia, la detección debe prestar atención tanto al destino como al comportamiento. Un proceso que normalmente no debería iniciar sesiones SMTP, conexiones hacia servicios de mensajería o transferencias de datos después de acceder a perfiles de navegadores puede ofrecer una señal más resistente al cambio de infraestructura.
MITRE ATT&CK: técnicas relevantes
Las investigaciones disponibles permiten relacionar las cadenas observadas con varias técnicas de MITRE ATT&CK. No todas tienen que aparecer simultáneamente en cada campaña.
T1566.001 – Spearphishing Attachment: entrega mediante adjuntos maliciosos.
T1059.007 – JavaScript/JScript: ejecución del cargador JavaScript en la campaña documentada por Seqrite.
T1059.003 – Windows Command Shell: ejecución mediante BAT y cmd observada por Fortra.
T1059.001 – PowerShell: ejecución y reconstrucción de las siguientes etapas.
T1027 – Obfuscated Files or Information: ocultación de scripts y payloads.
T1140 – Deobfuscate/Decode Files or Information: recuperación del contenido durante la ejecución.
T1620 – Reflective Code Loading: carga de componentes directamente en memoria observada en la campaña analizada por Seqrite.
T1055 – Process Injection: ejecución del payload dentro de otro proceso.
T1555.003 – Credentials from Web Browsers: obtención de credenciales almacenadas en navegadores.
T1005 – Data from Local System: recopilación de información del sistema local.
T1041 – Exfiltration Over C2 Channel: exfiltración de información a través de canales de mando y control.
T1048.003 – Exfiltration Over Unencrypted Non-C2 Protocol: técnica incluida por Fortra en el mapeo de la actividad SMTP observada en su campaña.
Qué debería buscar un equipo de detección
Los indicadores de compromiso siguen siendo útiles para responder a una campaña concreta, pero hashes, dominios y direcciones IP tienen una vida operativa limitada. En una familia distribuida comercialmente y utilizada por diferentes operadores, el comportamiento ofrece una base más duradera para el hunting.
Un primer punto de control se encuentra en el correo. Los archivos RAR o ZIP procedentes de remitentes externos que contienen BAT, JavaScript u otros scripts deberían someterse a controles especialmente restrictivos. El contexto también importa: una solicitud de presupuesto, una notificación logística o una comunicación fiscal inesperada no debería recibir confianza únicamente porque el contenido parezca coherente.
En endpoint resulta útil correlacionar la apertura de archivos descargados con la posterior creación de procesos de scripting. Una secuencia en la que un archivo comprimido conduce a JavaScript o cmd.exe y después a powershell.exe ofrece mucha más información que cualquiera de esos eventos de forma aislada.
La telemetría de PowerShell es igualmente importante. En EDR deberían investigarse cargas reflectivas, escrituras o modificaciones de memoria en procesos legítimos y relaciones inusuales entre intérpretes de scripts y procesos del sistema.
La red constituye la última oportunidad antes de que los datos abandonen la organización. Conexiones SMTP salientes desde estaciones de trabajo o procesos que normalmente no envían correo, comunicaciones anómalas con servicios de mensajería y transferencias posteriores al acceso masivo a datos de navegadores merecen investigación.
Medidas de mitigación
La protección frente a este tipo de campaña necesita varias capas. En correo conviene inspeccionar archivos comprimidos y restringir tipos de contenido ejecutable o interpretable que no sean necesarios para la actividad de la organización. En endpoint debe reducirse la ejecución innecesaria de scripts y utilizar controles capaces de detectar comportamientos, no únicamente firmas.
El uso de MFA reduce el valor de determinadas credenciales robadas, aunque no debe considerarse una solución completa frente al robo de sesiones. Cuando existe sospecha de compromiso deben revisarse las sesiones activas y revocarse cuando corresponda, además de rotar credenciales potencialmente expuestas.
También resulta recomendable limitar el almacenamiento de contraseñas sensibles en navegadores cuando la política de la organización disponga de mecanismos más adecuados, aplicar mínimo privilegio y mantener visibilidad sobre PowerShell, procesos, memoria y conexiones salientes.
Si se confirma una infección, la respuesta no debería terminar eliminando el malware. Es necesario asumir que la información accesible para el infostealer puede haber sido comprometida y actuar sobre identidades, sesiones, secretos y cuentas relacionadas.
Conclusión
Phantom Stealer demuestra por qué el análisis de un infostealer debe comenzar mucho antes de la fase de robo de información. La cadena completa combina ingeniería social, ejecución mediante scripts, ofuscación, PowerShell, carga en memoria y finalmente recopilación y exfiltración de datos.
Las campañas de 2026 analizadas por Fortra y Seqrite también muestran que no existe una única receta. Una utiliza RAR y BAT, mecanismos de persistencia y una cadena que termina en DonutLoader y explorer.exe; otra utiliza archivos comprimidos con JavaScript, varias etapas PowerShell, un ensamblado .NET reflectivo y Phantom Stealer v3.5.0. El objetivo final es similar, pero los caminos técnicos son diferentes.
Esta variabilidad es precisamente el motivo por el que la defensa no debe construirse alrededor de un hash o un nombre de archivo. Correlacionar correo, ejecución de scripts, actividad PowerShell, manipulación de memoria, acceso a credenciales y tráfico saliente proporciona una visión mucho más sólida de la intrusión.
El verdadero riesgo de Phantom Stealer no reside únicamente en que pueda obtener una contraseña. Reside en su capacidad para convertir una interacción aparentemente rutinaria con un correo empresarial en una cadena de ejecución diseñada para llegar hasta las identidades y datos que permiten continuar el ataque.
Fuentes y referencias
Fortra – Phishing Campaign Targets Banks with Fileless Phantom Stealer Malware, 16 de junio de 2026.
Seqrite – Abusing Trusted Business Workflows: A Multi-Stage Phantom Stealer Campaign, 22 de julio de 2026.
Proofpoint Threat Research – Not Safe for Work: Tracking and Investigating Stealerium and Phantom Infostealers, 3 de septiembre de 2025.
MITRE ATT&CK Enterprise, referencia de tácticas y técnicas relacionadas con las campañas analizadas.