The SOC Files 5: fantasma en el pipeline, o una intrusión fileless en SharePoint de Storm-2603

Resumen ejecutivo

En 2025, varios actores de amenaza explotaron las vulnerabilidades CVE-2025-53770 y CVE-2025-53771 (ToolShell) en Microsoft SharePoint local para lograr la ejecución remota de código mediante solicitudes HTTP manipuladas. Uno de ellos implementó ransomware en los sistemas de la víctima tras la explotación exitosa. Microsoft atribuye esta actividad de ToolShell vinculada con ransomware a Storm-2603 y la distingue de otros actores cuya actividad observada consistía sobre todo en robo de credenciales, espionaje y exfiltración de datos.

En diciembre, nuestro análisis retrospectivo identificó una actividad que evaluamos como coherente con las TTP de Storm-2603. En ella, el atacante usó el proceso de trabajo de IIS como puente en memoria hacia la infraestructura del cliente y mantuvo la capa de acceso y control por completo dentro de w3wp.exe, sin escribir nada en disco. Aunque la actividad posterior de post-explotación generó artefactos en disco, el puente que servía para mantener el acceso persistó en memoria.

Analicemos este ataque con más detalle.

Cronología de la intrusión: latencia estratégica y explotación

La intrusión que se analiza en este informe ocurrió en dos etapas, con un intervalo entre el acceso inicial y la actividad de explotación posterior. La cronología del ataque es la siguiente:

• 20 de diciembre, huella digital de vulnerabilidades: una sola solicitud HTTP apuntó a un endpoint administrativo de SharePoint asociado con el componente ToolPane para determinar si el host era vulnerable a CVE-2025-53770.
• 21 a 23 de diciembre, latencia táctica: tras el sondeo inicial hubo tres días de silencio que separaron la huella digital de vulnerabilidades de la actividad maliciosa posterior y que podrían haber reducido la probabilidad de una detección inmediata.
• 24 de diciembre, reactivación de alta intensidad: en Nochebuena, cuando muchas empresas reducen su personal de seguridad, se ejecutó la cadena completa de RCE mediante el proceso de trabajo de IIS (w3wp.exe) en el mismo endpoint del sondeo inicial.
• 26 de diciembre, descubrimiento del incidente: el intervalo de tres días impidió al principio correlacionar el sondeo del 20 de diciembre con la actividad maliciosa posterior, por lo que el evento quedó con prioridad baja. El análisis retrospectivo determinó que el sondeo fue la fase inicial de la intrusión posterior.

Fase de validación del acceso inicial

Huella digital de vulnerabilidades

Una solicitud de huella digital de vulnerabilidades del 20 de diciembre marcó la primera interacción observada con el objetivo. La solicitud provino de infraestructura asociada con ONYPHE, una plataforma de descubrimiento y administración de superficie de ataque a escala de internet que sirve para identificar activos expuestos, vulnerabilidades y ciberamenazas. Herramientas muy usadas, como Shodan y Censys, solo entregan una lista de activos expuestos a internet correlacionada con datos de código abierto sobre vulnerabilidades conocidas; ONYPHE, en cambio, sí comprueba si el sistema objetivo es realmente vulnerable.

Las características de la solicitud coincidían con las comprobaciones de vulnerabilidades de ONYPHE, que emplean sondeos activos y no intrusivos para identificar sistemas expuestos a internet y vulnerables a determinados CVE. Para ToolShell, ONYPHE adoptó el enfoque de Niels Hofmans (hazcod): intenta inyectar un marcador inofensivo en el servidor objetivo para averiguar si es vulnerable.

Esta fase funcionó como un paso de validación contra la superficie de ejecución de SharePoint expuesta por HTTP:

• El objetivo procesó solicitudes estructuradas mediante el pipeline de ASP.NET sin rechazarlas
• La ruta de la solicitud llegó a la lógica de la aplicación capaz de manejar entradas serializadas
• Ningún control defensivo interrumpió ni alteró el flujo de ejecución en el límite de la aplicación

Unos doce minutos después, una segunda conexión entrante provino de infraestructura asociada con Pfcloud UG, un proveedor que opera con un modelo de bulletproof hosting (BPH). Por el momento en que ocurrió y por el historial documentado de escaneo y actividad abusiva de la IP, la conexión podría representar un reconocimiento de seguimiento contra el objetivo recién identificado. En esta etapa no se intentó ninguna explotación.
.

Explotación activa: Papa Noel se llevó tus datos y dejó una puerta trasera

La actividad maliciosa principal ocurrió el 24 de diciembre. El atacante apuntó al mismo host de SharePoint con una solicitud manipulada desde 45.91.94.204 (45.91.92.0/22, ASN 63473, HostHatch, LLC). Esto provocó la ejecución de una web shell dentro del proceso de trabajo de IIS (w3wp.exe). La carga útil no se escribió en disco: se cargó directo en el runtime de ASP.NET y se usó para procesar las solicitudes posteriores. El implante permaneció activo durante todo el ciclo de vida del dominio de aplicación afectado. Este estado de runtime se perdía al reciclar el grupo de aplicaciones o al reiniciar IIS.

El ataque se originó en un nodo SPN

La dirección IP 45.91.94.204 es un nodo de Safing Privacy Network (SPN). SPN enruta cada conexión por una ruta de VPN de varias capas con múltiples nodos de retransmisión que pueden ocultar la IP de origen.

SPN se presenta como una red diseñada para proteger la privacidad del tráfico de internet. Su infraestructura se parece en muchos aspectos a la de Tor, pero con algunas diferencias. Ofrece las siguientes capacidades:

• Velocidad: rendimiento cercano al de una VPN para transferir datos a alta velocidad.
• Compatibilidad con la capa 3: admite varios protocolos, como TCP, UDP e ICMP (a diferencia de Tor, que solo usa TCP).
• Enrutamiento por aplicación: tunelización directa, sin navegador.
• Identidad múltiple: nodos de salida simultáneos para eludir los límites de tasa por IP.
• Paquetes de tamaño fijo y relleno, que dificultan el análisis de su tráfico.

Al mismo tiempo, es menos común que Tor y con frecuencia elude las listas de bloqueo estándar de Tor.

Arquitectura de la web shell

La web shell que los atacantes inyectaron en el runtime de w3wp.exe es un framework en memoria con varios módulos: el componente principal (G.cs) orquesta la ejecución y varias unidades funcionales repartidas en espacios de nombres la amplían.

La implementación sigue una estructura modular de proyecto en C#, en la que cada capacidad está aislada en su propia unidad de compilación y se invoca de forma dinámica en tiempo de ejecución.

“G.cs”: control del pipeline y C2

Control del pipeline

El componente principal de la web shell es G.cs. Orquesta el contexto de ejecución, el ciclo de vida, el C2 y la administración de sesiones del implante.

Para asegurar la persistencia en el runtime, G.cs hace lo siguiente:

• Registra un VirtualPathProvider personalizado con el método no público RegisterVirtualPathProviderInternal de la clase HostingEnvironment de ASP.NET, para que ASP.NET lo use al procesar rutas virtuales. El proveedor se agrega de forma automática a la cadena de proveedores de rutas virtuales registrados.
  
• Delega la política de tiempo de vida de .NET Remoting del proveedor al proveedor anterior de la cadena, de modo que se conserve el comportamiento de tiempo de vida existente.
  

Además, para evadir las defensas y permitir que el VirtualPathProvider se registre aunque la aplicación en cuyo AppDomain se ejecuta la web shell esté precompilada, el módulo implementa la técnica de subversión de controles de confianza (T1553):

• Usa reflexión para comprobar si la aplicación está precompilada.
• Extrae punteros a los campos de estado interno de la clase BuildManager, que administra la compilación de la aplicación, y los modifica en tiempo de ejecución.
  
• Vuelve a usar reflexión para forzar la inyección en tiempo de ejecución.

G.cs usa la función GetCacheKey() como punto de intercepción del flujo de procesamiento de rutas virtuales. Procesa las solicitudes entrantes al servidor de SharePoint y revisa sus encabezados para filtrar las solicitudes del atacante.

El User-Agent específico en los encabezados de la solicitud activa la ejecución de la web shell. Si la solicitud no cumple esta condición, el implante permanece inactivo, lo que dificulta reconocer su tráfico.

Capa de comando y control (transporte en memoria)

El mismo módulo principal (G.cs) implementa la capa de comunicación.

En lugar de depender de frameworks externos o de beacons estándar, usa un protocolo binario personalizado con ofuscación basada en XOR para intercambiar datos con el C2. Las comunicaciones se confunden con el tráfico normal de la aplicación. Mediante el hook de GetCacheKey(), el módulo intercepta las solicitudes HTTP estándar. Cuando detecta un User-Agent específico en los encabezados de la solicitud, lo analiza, extrae la carga útil y, si hace falta, establece una conexión TCP con un host de destino dentro de la red de la víctima.

Para permitir el control interactivo, G.cs establece un túnel de proxy full-duplex y guarda en memoria los sockets de destino activos para emparejar canales HTTP simultáneos de lectura y escritura.

Para el pivoteo y el movimiento lateral, se admiten conexiones TCP desde el servidor C2 hacia hosts arbitrarios dentro de la red objetivo. El tráfico pasa por el host de SharePoint mediante proxy.

Como se aprecia en las capturas de pantalla, para implementar el proxy de tráfico los atacantes usaron la herramienta suo5. Sus autores la promueven como una herramienta estable de proxy directo para escenarios en los que se prohíben las conexiones salientes a internet.

Para mejorar su rendimiento, G.cs manipula el ThreadPool: aumenta sus límites de operaciones simultáneas y el tiempo de espera máximo.

“Prog.cs”: punto de entrada de la ejecución y despachador de tareas

Prog.cs es el punto de entrada que recibe argumentos de línea de comandos y los pasa a uk/London.cs. Este último actúa como orquestador y se encarga de analizar los comandos y de escalar privilegios (mediante suplantación a través de una canalización con nombre). Lo revisaremos con más detalle más adelante. Si se indica el comando “suo5”, London.cs hace que G.cs se enganche al runtime de ASP.NET como una shell en memoria. Una vez activo, G.cs procesa el tráfico web entrante de forma independiente dentro de la memoria del servidor web.

Módulos de interacción con el host

Los módulos siguientes ofrecen capacidades de interacción directa con el sistema, y cada uno se implementa como una unidad independiente. London.cs los activa cuando recibe el comando correspondiente de Prog.cs.

“FileDownloader.cs”

El módulo FileDownloader.cs descarga archivos arbitrarios desde URL externas que proporciona el C2. Guarda los archivos descargados en el directorio ProgramData sin ninguna interacción del usuario.

“LoggedOnUsers.cs”

Este módulo enumera los usuarios con sesión iniciada e identifica sus tipos de sesión (interactiva, de servicio, remota). Los resultados se guardan en memoria. Los atacantes pueden recuperarlos con las capacidades de proxy y tunelización que ofrece G.cs.

“ProcessList.cs”

Este módulo enumera los procesos en ejecución con las rutas completas de los ejecutables correspondientes en disco. Los resultados se guardan en memoria. Los atacantes pueden recuperarlos mediante G.cs.

“NetworkInfo.cs”

El módulo extrae información sobre las conexiones de red existentes, como los protocolos usados, las IP, los puertos locales y remotos y el estado de la conexión. También enumera las interfaces y los encabezados de red. Los resultados se guardan en memoria y los atacantes pueden recuperarlos mediante G.cs.

“MSI.cs”

Este módulo instala y ejecuta en silencio los paquetes MSI que FileDownloader.cs descargó previamente.

“User.cs”

Este módulo se encarga de crear cuentas administrativas con el subsistema nativo SAM RPC (espacio de nombres SAMRPCNative) en lugar de las herramientas estándar de línea de comandos. Esto podría indicar un intento de evadir la detección y de dar a los atacantes un acceso privilegiado y sigiloso a los sistemas objetivo, que persiste una vez que la web shell termina su trabajo.

SAMRPCNative

El espacio de nombres SAMRPCNative implementa un wrapper P/Invoke de bajo nivel en C# para la biblioteca nativa samlib.dll de Windows y consta de tres tipos: SAMStructs.cs, SAMMethods.cs y SAMEnums.cs.

“SAMEnums.cs”

Implementa listas estructuradas a nivel de bits y flags constantes que asignan códigos numéricos a su significado de seguridad en SAM y traduce los códigos de estado que devuelve el sistema.

“SAMStructs.cs”

Define las estructuras de datos nativas que P/Invoke necesita para alinear la memoria y para marshalling. Da formato y alinea las estructuras de datos de forma segura.

“SAMMethods.cs”

Contiene declaraciones de API externas (P/Invoke) importadas de samlib.dll para realizar acciones como conectarse al servidor SAM, crear usuarios y abrir dominios.

Esta capa es fundamental para los atacantes porque permite las operaciones de cuentas.

Escalada de privilegios

El espacio de nombres uk contiene primitivas ofensivas para la escalada de privilegios. Para elevar los privilegios a SYSTEM, usa una técnica de suplantación local de tokens mediante la interfaz de Encrypting File System Remote Protocol (EFSRPC), tomada de la herramienta EfsPotato.

Esta funcionalidad se implementa en la clase uk/London. La clase crea una canalización con nombre maliciosa mientras la clase EfsrTiny, una versión reducida de la herramienta EfsPotato, se conecta al servidor RPC de LSASS.exe. Luego, la función London.RpcThread llama a la función EfsRpcEncryptFileSrv de EfsrTiny con una ruta \\localhost manipulada. Así engaña a LSASS.exe para que se conecte de vuelta a la canalización con nombre del atacante. Por último, la función London.Exp usa ImpersonateNamedPipeClient para forzar y suplantar el token de LSASS.exe y generar un proceso nuevo con privilegios SYSTEM mediante CreateProcessAsUser. Como la web shell reside dentro del proceso de trabajo de IIS, cuenta con el SeImpersonatePrivilege necesario para aplicar esta técnica.

El espacio de nombres uk también implementa una capa mínima de cliente MSRPC al definir de forma explícita estructuras como RPC_CLIENT_INTERFACE y MIDL_STUB_DESC, con lo que hace spoofing de un stub de interfaz. Esto permite la interacción directa con el runtime de RPC de Windows (Rpcrt4.dll) sin depender de stubs generados por MIDL ni de abstracciones de RPC de nivel superior, y da control directo sobre el binding y el marshalling, más allá de las restricciones de las API de cliente estándar.

Actividad de post-explotación

Poco después de la inyección de la web shell, el proceso de trabajo infectado generó msiexec.exe para instalar una carga útil MSI remota alojada en el almacenamiento en la nube de Supabase. Esa carga útil MSI era Velociraptor, una herramienta de código abierto para análisis forense digital y respuesta a incidentes; en concreto, su versión 0.73.4.0, vulnerable a CVE-2025-6264, que los atacantes aprovecharon para ejecutar comandos en la red objetivo.

En octubre de 2025, Cisco Talos informó que actores de amenaza aprovechaban Velociraptor como framework de ejecución posterior al compromiso y atribuyó esta actividad a Storm-2603. La herramienta permite ejecutar comandos arbitrarios y sirve para distintos fines. En nuestro caso se usó para la persistencia, el descubrimiento, la recopilación de datos y la ejecución de cargas útiles.

El atacante usó Velociraptor para implementar varios mecanismos de tunelización independientes, entre ellos Zoho Assist-Unattended Support para el acceso remoto no autorizado, la tunelización de la CLI de VS Code, Cloudflare Tunnel y una utilidad ligera de proxy inverso. Así intentó conservar el acceso aunque detectaran y eliminaran algunas de sus herramientas. Además, en esta etapa ya no dependía del ciclo de vida del proceso de trabajo de IIS ni de la vulnerabilidad ToolShell.

Intentos de inutilizar EDR

Una vez con acceso al sistema objetivo, el atacante pudo cargar un controlador vulnerable que muchos atacantes usan activamente para terminar soluciones EDR. Detectamos el controlador principal en C:\ProgramData\rsndispot.sys (054a32d6033b1744dca7f49b2e466ea2). Además, el atacante empleó una DLL maliciosa (2d9ebf9c042f596f435865b40edad928) en un ataque de carga lateral de DLL. Identificamos esta DLL como una herramienta para terminar procesos de antivirus (AV killer) del ransomware Warlock. Su posible propósito era terminar las soluciones de seguridad mediante el controlador vulnerable rsndispot.sys.

Intento de implementación de ransomware

Los atacantes intentaron ejecutar ransomware en el sistema comprometido. Sin embargo, el módulo de defensa proactiva de Kaspersky Endpoint Security bloqueó el proceso del ransomware y evitó esta actividad. La DLL de malware que obtuvimos se identificó como el ransomware Warlock.

Qué deben buscar los defensores

Artefactos de deserialización de ToolPane y del CLR

Cuando los atacantes intentaron acceder a ToolPane, se observó la presencia simultánea, dentro del mismo dominio de aplicación, del ensamblado App_Web_toolpane.aspx compilado de forma dinámica y del ensamblado auxiliar Microsoft.GeneratedCode.

Ambos ensamblados se usan en escenarios legítimos. Los ensamblados App_Web_* se generan durante la compilación normal de páginas de ASP.NET, y XmlSerializer suele producir Microsoft.GeneratedCode en flujos de serialización legítimos. Sin embargo, una solicitud al endpoint de ToolPane que provoca la carga inmediata de Microsoft.GeneratedCode en la misma ventana de ejecución indica que el runtime está procesando datos serializados que llegan en la solicitud.

Detección de la explotación de la deserialización

Primero, recomendamos leer este artículo (en ruso) sobre cómo detectar intentos de explotación de la deserialización en el CLR, con ejemplos de reglas Yara y recomendaciones de monitoreo.

A continuación, resumimos la idea principal de la lógica de detección.

Las vulnerabilidades de deserialización deben tratarse como una clase distinta de eventos de explotación. En el CLR, la deserialización no es solo convertir bytes en valores: es reconstruir un grafo de objetos a partir del flujo de entrada. Los formatters se encargan de serializar y deserializardatos, y uno de los más usados es BinaryFormatter. BinaryFormatter emplea el formato NRBF, que define el flujo como una secuencia de registros que describen clases, arreglos, tipos primitivos y referencias entre objetos. Los datos que recibe el deserializador determinan la forma del grafo resultante. En la práctica, esto significa que el flujo de entrada define no solo valores, sino también los tipos, las relaciones y los puntos del ciclo de vida concretos que el runtime debe materializar.

Microsoft afirma de forma explícita que BinaryFormatter es inseguro y no se puede hacer seguro; desde .NET 9, la implementación integrada se eliminó en la práctica del uso ordinario. Aun así, el propio Microsoft sigue usándolo en sus productos, incluido SharePoint, porque es potente y fácil de usar. Para corregir los problemas relacionados con BinaryFormatter se necesitan cambios de arquitectura. Otros mecanismos afines, como LosFormatter (como el que se usa en la página vulnerable), tienen riesgos similares.

El riesgo central de la deserialización insegura es que el CLR puede resolver tipos inesperados, instanciar objetos al margen de las invariantes normales del constructor e invocar mecanismos especiales del ciclo de vida, como ISerializable, IObjectReference, IDeserializationCallback y los métodos marcados con [OnDeserialized]. Es decir, los datos que controla el atacante obligan al runtime a construir un grafo con tipos que tienen efectos secundarios ejecutables.

Por lo tanto, una estrategia práctica de detección debe centrarse en los artefactos de construcción del grafo. Los eventos del cargador del CLR identifican los ensamblados y los dominios de aplicación pertinentes. Después, la inspección de memoria y de metadatos revela los nombres de tipos y las estructuras de serializadores generados que se asocian con la presunta cadena de gadgets. En escenarios como ToolShell, la deserialización insegura suele producir ensamblados auxiliares (con evidencia en los loader events) cuyos metadatos contienen nombres de tipos completamente calificados, nombres de gadgets y representaciones en cadenas de los tipos genéricos construidos (basta con buscarlos con reglas Yara). En nuestro caso, hay que buscar artefactos como Microsoft.GeneratedCode y App_Web_toolpane.aspx* (evidencia de que hubo deserialización en los eventos del cargador) y cadenas que identifican ObjectDataProvider, ExpandedWrapper y LosFormatter (evidencia de que el flujo de entrada se deserializó en objetos peligrosos dentro de esos ensamblados).

Cabe señalar que estos indicadores no son significativos por sí solos; su valor radica en que muestran que el runtime ya recibió datos que requieren generar código auxiliar para reconstruir un grafo de objetos peligroso.

Los gadgets que se usan para explotar vulnerabilidades como ToolShell están representados de forma práctica en herramientas de tipo corpus, como ysoserial.net / YSoNet, que reúnen cadenas de gadgets conocidas para la deserialización insegura en .NET. Con fines defensivos, el valor de estos proyectos no está en su capacidad ofensiva, sino en el catálogo de tipos y estructuras que se pueden buscar en flujos, en memoria y en ensamblados auxiliares. La presencia de cualquiera de ellos en memoria o en un ensamblado auxiliar debe tratarse como un indicador sólido de explotación.

Para simplificar la detección de exploits de deserialización, creamos una herramienta llamada CLRDeserializationExploitFinder. Permite detectar intentos de explotación de ToolShell y, ademas, puede detectar otras cadenas “gadgets” que cubre ysoserial.net.

Detección de una web shell o implante en runtime basado en VPP

Un mecanismo basado en VirtualPathProvider debe tratarse como una clase aparte de implante en runtime (fileless). En ASP.NET, HostingEnvironment.RegisterVirtualPathProvider registra un nuevo proveedor de rutas virtuales (VPP) en el sistema de compilación de la aplicación. Una vez registrado, la aplicación puede servir rutas virtuales durante la compilación dinámica como si fueran páginas ordinarias en disco. La compilación dinámica no exige que la carga útil exista como archivo en el sistema de archivos. Opera por completo dentro del límite de confianza de la propia aplicación. Durante la compilación pueden generarse archivos temporales, pero no sirven como artefactos forenses confiables. Como los VPP también pueden tener usos legítimos, el modelo defensivo debe empezar con un inventario de las implementaciones legítimas de VirtualPathProvider. En todos los demás casos, el registro o el uso de un VPP nuevo debe tratarse como anómalo.

Para ver cómo funciona la generación dinámica de páginas virtuales con ASP.NET, IIS y el CLR, y cómo detectar esta actividad, se puede usar nuestro proyecto llamado VirtualPathProvider Lab.

La fuente de telemetría más útil para esta técnica es el proveedor ETW Microsoft-Windows-IIS-Configuration. Para detectar rutas virtuales, los eventos 25 y 47 son los de mayor valor. El evento 25 registra la asignación de ConfigPath a PhysicalPath; el evento 47 registra la asignación de la ruta de configuración a un directorio. En el caso de una ruta respaldada por un VPP, estos eventos generan una inconsistencia: IIS y ASP.NET se comportan como si la ruta tuviera una representación física, aunque el archivo correspondiente no exista en disco. En el ejemplo de VirtualPathProvider Lab, esto aparece como la asignación del recurso virtual googlecheck.aspx a una ruta física donde no hay ningún archivo real. Esta discrepancia entre la resolución de la configuración y la realidad del sistema de archivos constituye el indicador principal de contenido virtual.

El segundo indicador es más negativo que positivo. En los archivos respaldados por disco, el proceso IIS por lo general crea una cadena FileChangeNotificationMonitor, que se refleja en los eventos 17, 18, 19 y 21. En las rutas virtuales que sirve un VirtualPathProvider personalizado, esta cadena no existe o no coincide con el perfil normal de un archivo ordinario, porque no hay objeto físico ni ciclo de vida de cambios en disco correspondiente. Por ello, la combinación de los eventos positivos 25 y 47 con la ausencia simultánea de los eventos 17/18/19/21 esperados para la misma ruta forma un patrón de detección confiable: la ruta existe para IIS como un recurso resuelto por la configuración, pero no tiene respaldo en el sistema de archivos ni la acompaña el monitoreo normal de cambios de archivos.

En resumen, el objetivo de la búsqueda de amenazas aquí es la discrepancia entre la forma en que IIS y ASP.NET resuelven un recurso y lo que realmente existe en disco y en la cadena de monitoreo de cambios. En las aplicaciones conocidas, estos casos se pueden filtrar con una lista de permitidos de implementaciones legítimas de VirtualPathProvider. Todo lo demás debe tratarse como un posible implante en runtime y examinarse mediante ETW, verificación del sistema de archivos e inspección de la memoria del proceso w3wp.exe.

Atribución

Microsoft rastrea a Storm-2603 como un actor de amenaza independiente, sin vínculos identificados con otros grupos conocidos. Es cautelosa al evaluar la motivación del actor, pero menciona que antes implementó los ransomware Warlock y LockBit tras explotar vulnerabilidades de SharePoint local. En el incidente analizado vimos actividades similares de explotación de SharePoint, además de un EDR killer asociado con el ransomware Warlock y de intentos fallidos de ejecutar Warlock.

Otras intrusiones documentadas indican que Storm-2603 aprovechó fallas públicas en puertas de enlace de correo perimetrales para obtener el acceso inicial, luego desplegó el framework Velociraptor con privilegios elevados y estableció túneles cifrados persistentes mediante software comercial de administración remota para orquestar el movimiento lateral secundario. Esto coincide con el comportamiento de post-explotación que observamos en nuestro caso. Junto con el escenario de explotación de ToolShell, nos permite atribuir este caso a Storm-2603 con confianza moderada.

Conclusión

La principal lección defensiva del incidente que se analiza en este artículo es que la explotación de un servidor de SharePoint expuesto a internet puede permitir la ejecución de código fileless dentro del límite de confianza de la aplicación. Storm-2603 no necesitó un dropper convencional, un servicio persistente ni un endpoint de C2 expuesto: implementó una web shell dentro de w3wp.exe, desde la cual pudo orquestar la tunelización, la escalada de privilegios, el acceso a credenciales y el movimiento lateral. Por ello, la detección debe ir más allá de la búsqueda de web shells basada en archivos y orientarse al comportamiento en runtime: actividad anómala de w3wp.exe, conexiones salientes inesperadas, coerción de RPC, suplantación de tokens y la introducción de herramientas de administración remota o de DFIR tras el compromiso de la aplicación.

Para atribuir la actividad maliciosa con precisión y definir medidas de respuesta adecuadas, los defensores deben reconstruir las cadenas de ejecución y las relaciones temporales entre las capas de aplicación, host e identidad, conservar la memoria y la telemetría de IIS, y correlacionar el reconocimiento de baja señal con la actividad privilegiada posterior, en lugar de evaluar los eventos de forma aislada. Una explotación confirmada de SharePoint con ejecución de código debe desencadenar la contención a nivel de host, la búsqueda de persistencia, la rotación de credenciales y de la MachineKey expuesta, y una investigación guiada por las TTP, en lugar de una remediación limitada al exploit inicial o a los IoC conocidos.

Los productos de Kaspersky detectan las amenazas mencionadas en este artículo como:

• Trojan.MSIL.Agent.gen
• Trojan.Win64.DLLhijack.cdp

Indicador de compromiso

Indicador de compromiso	Descripción
45.91.94[.]204	Nodo de SPN
0xFD91321BF7FF7245DDA9B7B5D791ACE8	vskp2: implante de web shell
hxxps://vdfccjpnedujhrzscjtq[.]supabase[.]co/storage/v1/object/public/image/v4[.]msi	Paquete vulnerable de Velociraptor
0x3A55D8F8F29716C694671834D8C6CB29	C:\ProgramFiles\Velociraptor\Velociraptor.exe
hxxps://auth[.]qgtxtebl[.]workers[.]dev/	URL del servidor de Velociraptor
199.232.210[.]172	Retransmisor de tráfico de C2
0x991EC6E04413F2D4D29341C17A8A54D5	VS Code legítimo aprovechado de forma indebida
0x3D553B9061C03F891CE97D7D2E64DDEE	VS Code Insiders usado para tunelización
91.224.92[.]121	Servidor de C2 alojado en bulletproof hosting
49.51.132[.]100	Nodo de SPN
hxxps://github[.]com/cloudflare/cloudflared/releases/latest/download/cloudflared-windows-amd64[.]msi	Herramienta legítima de tunelización aprovechada de forma indebida
0x2C32E44A013CBFC5A323EFB7694701D2	Ejecutable de una herramienta de tunelización aprovechada de forma indebida
hxxps://files[.]catbox[.]moe/8f7vex[.]msi	URL de descarga de Zoho Assist Unattended Agent aprovechado de forma indebida
0x112A86ECA3CB5A0B5E20AB744CC5AF93	7z.exe renombrado para carga lateral de DLL
0xA930F81E3FB0A226EC5904D9043A17B8	C:\ProgramFiles(x86)\ZohoMeeting\UnAttended\ZohoMeeting.7z
204.76.203[.]219	Servidor de C2 alojado en bulletproof hosting
0x054a32d6033b1744dca7f49b2e466ea2	Controlador vulnerable