Francamente, los actores de amenazas rara vez son originales. Comparten los mismos manuales de juego, las mismas tácticas y, muchas veces, ni se molestan en cambiar el nombre de las herramientas de seguridad ofensiva. A principios de noviembre de 2024, el Huntress SOC investigó lo que parecía ser un Tradecraft mundano que, al examinarlo más de cerca, reveló una perspectiva novedosa sobre el comportamiento de un actor de amenazas para lograr persistencia y acceso remoto.
Acceso inicial
Los actores de amenazas no aparecen mágicamente en una red. Más bien, deben obtener su punto de apoyo de alguna manera. Huntress tiene en preparación un blog dedicado por completo al acceso inicial y a nuestras ideas sobre cómo mitigarlo, ya que negarle a un actor de amenazas el acceso inicial a tu red evita tener que preocuparte o actuar frente a cualquier Tradecraft posterior.
En el caso de este blog, el adversario obtuvo acceso inicial a través de una instancia de RD-Web expuesta públicamente. Se descubrió que esta instancia de RD-Web había sido objeto de ataques de fuerza bruta, mediante los cuales varios actores de amenazas aprovecharon la oportunidad de entrar a la red gracias a la inseguridad que RDP había traído al perímetro.
La fuerza bruta no es sofisticada, pero sí da resultados a los actores de amenazas. Un ataque de fuerza bruta contra un servicio de autenticación sin MFA inevitablemente logra acceso. Se accedió a la cuenta de un usuario mediante fuerza bruta desde las siguientes direcciones IPv4 públicas entre el 28 de octubre y el 12 de noviembre:
- 217.138.216[.]60
- 23.158.40[.]185
- 147.135.112[.]230
- 31.220.5[.]23
- 78.141.202[.]136
- 147.45.79[.]193
Movimiento lateral
Los actores de amenazas normalmente no quieren quedarse en la máquina de aterrizaje, sino entender más sobre el nuevo terreno y moverse por él hacia máquinas de mayor nivel. El actor de amenazas usó la herramienta legítima PsExec no solo para moverse lateralmente, sino también para ejecutar comandos en varias máquinas a la vez.
Mediante PsExec, el usuario comprometido ejecutó dos archivos por lotes desde la sesión remota de PsExec. Estos archivos completaron las siguientes acciones:
openrdp.bat facilitó las conexiones RDP a las máquinas al manipular tanto el registro como las reglas del firewall. Su contenido se muestra a continuación:
mimon.bat se encargó de garantizar la instalación exitosa de MeshAgent, eliminar la protección de LSA y habilitar WDigest para facilitar el almacenamiento de credenciales en texto plano. El contenido de este archivo es:
Huntress ya ha compartido mucho sobre cómo investigar PsExec, pero una función poco valorada de PsExec es su capacidad de ejecutar comandos en todas las máquinas de la red a la vez, siempre que el usuario comprometido tenga los privilegios necesarios.
> Computer | …..si se especifica un comodín (\\*), PsExec ejecuta el comando en todas las máquinas del dominio actual.
Por lo tanto, los actores de amenazas, como el de este caso, pueden tener un enorme impacto negativo en cascada sobre el entorno.
MeshAgent renombrado
Tras el acceso inicial logrado mediante fuerza bruta exitosa, el actor de amenazas escaló sus privilegios y tomó control de una cuenta de Administrador.
A través de su actividad con PsExec, procedió a impulsar la instalación de una instancia maliciosa de MeshAgent renombrada: "C:\Program Files\Windows NT\nvspbind\nvspbind.exe", el nombre de un binario de virtualización (pero volveremos a esto en breve).
Un análisis rápido del binario mostró que la instancia de MeshAgent se comunicaba con el siguiente dominio: wss[://]193.46.255[.]73:443/agent[.]ashx
Siguiendo este hilo de investigación, una búsqueda en línea de esta IP mostró que tenía asociado el nombre de equipo WIN-O5926T00T93. Este nombre de equipo no solo no coincidía con la convención de nomenclatura de las máquinas legítimas en Active Directory, sino que además es un indicador estático revelador que se puede rastrear: Huntress ha descubierto que los actores de amenazas rara vez cambian los nombres de sus equipos, lo que ofrece oportunidades de detección de alta fidelidad para los defensores cuando estos equipos logran autenticarse.
Además, al examinar la dirección de retorno de llamada de MeshAgent, esta se presentaba como un "Windows Network Virtual Adapter (v3.1.56.8342) - Login ," lo cual, dicho sin rodeos, era extraño.
Para aclarar: Windows Network Virtual Adapter es una tecnología dedicada a la virtualización basada en equipos y no tiene nada que ver con actividad maliciosa. Lo que el actor de amenazas intentó hacer aquí fue pasar desapercibido al renombrar su MeshAgent del lado del cliente con el nombre de un binario de virtualización ("C:\Program Files\Windows NT\nvspbind\nvspbind.exe") y el lado del servidor como "Windows Network Virtual Adapter (v3.1.56.8342) - Login," cuando en realidad es solo el inicio de sesión de MeshAgent.
Esta es una evasión de defensa poco refinada pero efectiva para su acceso remoto. Probablemente logran evitar sospechas gracias a la "consistencia" en los esquemas de nomenclatura de cliente y servidor.
La intrusión se cerró y se informó al socio de todos los hallazgos. Pero el Huntress SOC no se dio por satisfecho del todo: ¿podría este actor de amenazas haber desplegado una actividad similar en otro lugar, en una red completamente distinta?
Cazando el Tradecraft
La caza de amenazas es el arte de consultar específicamente un conjunto detallado de telemetría con preguntas de seguridad concretas hasta que el investigador quede satisfecho. Los objetivos de la caza de amenazas son muchos, pero en este momento la meta del SOC era identificar si este actor de amenazas había comprometido otros entornos con un Tradecraft similar.
Después de que el Huntress SOC neutralizara y concluyera la intrusión anterior, se llevó a cabo un análisis retroactivo de todos los datos de Huntress en busca del Tradecraft específico de MeshAgent/Nvspbind. Se obtuvo un resultado:
Este caso ya lo conocíamos: la primera alerta había ocurrido una semana antes de la investigación anterior. El Huntress SOC había respondido a una alerta de Defender por volcado de credenciales, que bloqueó "avrestore.exe" y "ARest1.exe." Se determinó que estos binarios no eran mimikatz, sino que, de hecho, formaban parte de un kit de herramientas previamente documentado para fuerza bruta, usado para facilitar el movimiento lateral.
Ahora, una semana después, nuestra caza de amenazas retrospectiva había descubierto un último artefacto persistente de la operación del actor de amenazas: la conexión remota MeshAgent/Nvspbind. Además, en este caso adicional, la causa raíz también fue una fuerza bruta contra RDP, junto con el uso de WDigest nuevamente por parte del actor de amenazas para el acceso a credenciales, lo que sugiere que este actor de amenazas es consistente en su Tradecraft y en su manual de juego.
Conclusiones
Al Huntress SOC le encanta arruinarles el día a los ciberdelincuentes. Este actor de amenazas mostró un Tradecraft novedoso y curioso para su infraestructura de acceso remoto y comando y control, pero que, de todos modos, se puede rastrear y detectar en beneficio de la comunidad de seguridad de la información.
Los casos compartidos aquí resaltan la importancia de que los investigadores de seguridad creen y se comprometan con ciclos continuos de retroalimentación entre las iteraciones de detección y caza. Esto garantiza que los actores de amenazas no tengan tregua ni respiro para ninguna persistencia insidiosa ni puertas traseras que crean disfrutar en paz.
Para los defensores de redes, estos casos dejan las siguientes lecciones que podemos recomendar:
- Revisar y reforzar continuamente el perímetro externo, eliminando los servicios de autenticación, como RDP, del internet público cuando sea posible.
- Exigir MFA donde se deban exponer servicios externos, y asegurarse de que todos los servicios de MFA funcionen de verdad: el MFA de terceros para RDP es notoriamente difícil de configurar correctamente.
- Donde sea posible, implementar listas de aprobación de software para garantizar que ni los actores de amenazas ni los usuarios puedan ejecutar fácilmente cualquier herramienta o programa que deseen de forma descuidada.
Indicadores de compromiso
| Elemento | Detalles |
|---|---|
| ARestore.exe | Hash SHA256: fcea81909388611359bbaf41871300075e192a3246b9e1bebc5f3f0aaa2b2c9a |
| ARest1.exe |
Hash SHA256: b629fe2363a23f7c0a6f40235ca25098321ba49bc397b36e2856a1ae76055c56 |
| nvspbind.exe | Hash SHA256: fdf51eba1b48ed4180dfbb66d8e299794998252517597aff4a44162183f7dcd9 Línea de comando: C:\Program Files\Windows NT\nvspbind\nvspbind.exe" --meshServiceName="nvspbind |
| 193.46.255[.]73 | Servidor para la malla |
| 146.70.36[.]132 | SurfShark VPN |
| 217.138.216[.]60 | SurfShark VPN |
| WIN-O5926T00T93 | Estación de trabajo del adversario |
MITRE ATT&CK
| Táctica | ID de la técnica | Procedimiento | Descripción |
|---|---|---|---|
| Acceso inicial | T1110 | Fuerza bruta | Se usaron varias IPv4 públicas para atacar por fuerza bruta una instancia de RD-Web y obtener acceso a la red. |
| Movimiento lateral | T1569.002 | PsExec | Se usó PsExec para ejecutar archivos por lotes (openrdp.bat y mimon.bat) y habilitar RDP e instalar componentes maliciosos. |
| Persistencia | T1059.003 | Scripts por lotes | Los archivos por lotes modificaron claves del registro y reglas del firewall, y habilitaron el almacenamiento de credenciales en texto plano. |
| Evasión de defensa | T1036.005 | Renombrado de binarios maliciosos | Se renombró el binario de MeshAgent para imitar un binario de adaptador virtual legítimo (nvspbind.exe) y un nombre de adaptador del lado del servidor. |
| Acceso a credenciales | T1003.001 | Exposición de credenciales mediante WDigest | Se modificaron valores del registro para habilitar WDigest y almacenar credenciales en texto plano. |
| Comando y control | T1219 | Herramienta de acceso remoto (MeshAgent) | MeshAgent se configuró para comunicarse con un dominio malicioso y se disfrazó como software legítimo. |
Crédito a Faith Stratton y Josh Allman por la investigación de la causa raíz y los hallazgos relacionados de la caza de amenazas.
Gracias a Austin Worline y Jamie Dumas por la investigación inicial de la intrusión.
Un agradecimiento especial a Anton Ovrutsky por hallazgos adicionales y por editar el blog.
