Imagínate, si quieres, la escena de tú y yo metidos en un estrés.
Estar en el lado receptor de la evasión de defensas es estresante. A mí me estresa. Me emociona, pero también me estresa.
Continuando nuestra serie sobre evasión de defensas (lee la primera parte), quiero compartir este estrés.
En este artículo, vamos a descender a la mazmorra de Huntress y revisar algunos casos enjaulados que tienen que ver con la evasión de defensas. Traeremos a algunos amigos para el viaje y conoceremos su perspectiva.
Ojalá que, después de mostrarte en detalle cómo funciona la evasión de defensas por parte de los adversarios y lo fácil que es evadirlas en general, te sientas tan estresado como yo.😊 😊 😊
Caso uno: Deteriorar las defensas
Los actores de amenazas, como dijo el gran John Ferrell (al que llamamos cariñosamente JDF) en nuestra entrega anterior, usan lo que funciona hasta que deja de funcionar. En Huntress, hemos visto a actores de amenazas "evadir" defensas simplemente presionando los diversos botones integrados que socavan la visibilidad de una solución de seguridad. Clasificado como T1562.001 en ATT&CK, los actores de amenazas pueden usar la funcionalidad legítima de las herramientas de seguridad para deteriorar su eficacia.
En un webinar reciente, mi colega Matt Anderson detalló un caso donde el actor de amenazas trajo un enorme script malicioso de PowerShell. El inicio de este script de PowerShell aprovechaba la funcionalidad integrada de Defender para modificar qué tipo de rutas, procesos y archivos Defender señalaría y cuáles no.
No es que Defender esté apagado aquí. Más bien, el actor de amenazas le ha pedido amablemente a Defender que preste atención a todo excepto a un número selecto de cosas que beneficiarán su campaña.
Podemos mirar por debajo de esta manipulación de Defender, para ver que es penosamente simple y poco impresionante reconfigurar lo que se verá, con un prompt de PowerShell con privilegios:
Y esto no es un problema exclusivo de Defender. Las exclusiones son un mal necesario para todas las soluciones de seguridad, y los administradores de sistemas las usan legítimamente por muchas razones.
Usar las exclusiones como arma funciona bien para los adversarios porque, en la superficie, parece que la solución de seguridad está funcionando, pero por debajo ha sido neutralizada para que no se oponga a las maquinaciones del atacante malicioso. Los actores de amenazas son expertos en saber cómo aprovechar nuestras propias herramientas en nuestra contra, pinchando selectivamente los ojos del Argos que se supone es nuestro centinela panóptico.
Caso dos: Deteriorar las defensas apagándolas
En Huntress, recopilamos una enorme cantidad de telemetría de actividades adversarias. A veces me asombran las técnicas increíbles y la velocidad con la que se mueven nuestros enemigos.
Y otras veces, niego con la cabeza ante la estupidez de nuestros enemigos, como en este caso.
Tuvimos un caso donde el actor de amenazas intentaba manipular y deteriorar el agente de Huntress. Lograron parcialmente ejecutar el proceso de desinstalación de nuestro(s) agente(s).
Lo increíble de esto es que el actor de amenazas no usó ningún comando de enumeración para identificar qué soluciones de seguridad estaban presentes. En cambio, fueron directo contra nosotros. ¡Qué bien saber que infundimos miedo en nuestros enemigos!
Esta vuelta en la campaña de los adversarios me causó diversión y estrés. Aquí te muestro una instantánea in situ de mis niveles de estrés:
Lo estúpido en este caso es que el actor de amenazas intentó cegar a Huntress después de haber ejecutado gran parte de su maldad; intentar desinstalar nuestro agente fue una de las últimas cosas que hicieron en el endpoint. ¿Por qué?! ¿No tumbarías la cámara de vigilancia de la pared primero, antes de cometer el crimen?!
En otro caso que Matt Anderson trabajó recientemente, se encontró con un adversario que tuvo el buen juicio de subvertir las soluciones de seguridad más temprano en su campaña. Una herramienta especialmente insidiosa, Backstab, fue aprovechada por el actor de amenazas para cegar aspectos clave particulares de una solución de seguridad. Específicamente, Backstab usa un componente legítimo del conjunto de herramientas SysInternals para eliminar el proceso "protegido" de los antivirus y EDR, lo que le regala al actor de amenazas una máquina despojada de sus guardianes automatizados.
Backstab no es una herramienta particularmente sigilosa, y tampoco lo es el método de "eliminar" los procesos de los EDR y antivirus... pero a veces los atacantes son así.
Le pregunté a un ser humano increíble en general, la Lead Product Owner, la Ninja Sharon Martin, sobre lo anterior:
Caso tres: Ofuscar, frustrar
Algunos actores de amenazas son increíblemente creativos. Subvierten y fuerzan el uso de herramientas de maneras que los defensores no podrían haber imaginado.
Un método de subversión de defensas que nosotros en Huntress encontramos con frecuencia involucra scripts maliciosos increíblemente ofuscados, atribuido como T1027. Esta técnica le niega al observador humano y a la solución de seguridad la capacidad de leer la intención de los scripts, y en cambio despliega capas de codificación, cifrado y evasión para exasperar las defensas.
A veces pueden ser realmente molestos.
En este caso, tuvimos un fragmento sin sentido de PowerShell ante el cual un defensor solo podía encogerse de hombros a primera vista. Este tipo de PowerShell ofuscado busca evadir al defensor y sus herramientas de seguridad para ejecutar algo malicioso.
Al desenredarlo, vemos la tarea relativamente simple de agregar un usuario malicioso al dominio con una evasión básica de AMSI (más sobre esto en el caso cinco):
En otras ocasiones (molestas), el archivo malicioso en cuestión despliega tantas capas de ofuscación que, como defensor, desenredar el script implica trabajar duro sin trabajar de forma inteligente. En este caso que se muestra abajo, decodificar el script en realidad no vale la pena.
En cambio, podemos ejecutar el script dinámicamente en un sandbox, lo que reveló que el script era una variante pesada en bytes de ASYNCRAT, que intentaba comunicarse con el dominio new50[.]noip[.]me.
Y si nos sintiéramos REALMENTE perezosos, podríamos simplemente mirar las últimas cuatro líneas del script. Esto no estaba ofuscado y la línea aspnet_compiler.exe es una técnica conocida de AsyncRAT para compilar el ejecutable malicioso una vez que llega a la máquina objetivo (T1027.004).
Mi colega John Hammond es algo así como un experto en scripts ofuscados y difíciles. Le pedí a John su opinión:
Caso cuatro: de LNK a EXE
Me encanta la seguridad ofensiva. Como miembro del equipo azul, aprecio que mis contrapartes del equipo rojo impulsen e innoven nuevas técnicas que desafían nuestras suposiciones. Una técnica de seguridad ofensiva en particular que disfruté desentrañar involucraba un ejecutable oculto dentro de un archivo LNK (T1036).
El hilo de tweets entra en detalle sobre la disección y la detección, pero lo fascinante de esta técnica es que roza la manipulación cognitiva y técnica de la que hablamos en la primera entrega.
A primera vista, esto es un buen acceso directo a la antigua usanza. Si apareciera en el escritorio de un usuario, con el ícono reemplazado por el de Chrome o Spotify, ¿por qué un usuario no haría clic en algo que siente familiar y seguro?
Pero al observar más de cerca, tú y yo empezamos a ver que algo no está del todo bien. Lo que vemos aquí es la brillante técnica de @x86matthew para volar bajo el radar defensivo, al incrustar un ejecutable en este acceso directo y disfrazarlo de legítimo e inofensivo.
Bajo la mirada del ojo humano y de una solución de seguridad, este tipo de técnica puede lograr evadir la detección.
Hay otras técnicas envueltas en este LNK -> EXE, como un cifrado XOR ligero (T1140) que cifra y luego descifra los bytes del EXE, para evadir la detección. Pero lo más interesante para mí de esta técnica es que involucra al usuario humano; lo arrulla en una falsa sensación de seguridad al aprovechar accesos directos e íconos específicos para engañarlo y hacer que lo ejecute (T1204.001).
Los usuarios están ocupados tratando de hacer bien su trabajo para la organización. Los actores de amenazas aprovechan eso, sabiendo que un usuario consciente de la seguridad espera una amenaza de los correos electrónicos, ¡pero no de los accesos directos en su propio escritorio! Hablé con Megan Broom, ejecutiva de cuenta en Huntress, para conocer su opinión sobre esta técnica tan astuta:
Caso cinco: Bypass de AMSI
Otra técnica fascinante del equipo rojo consiste en evitar por completo los cimientos de seguridad implementados para monitorear.
Event Tracing for Windows (ETW) y Anti Malware Scanning Interface (AMSI) son pilares de la arquitectura de seguridad moderna que ofrece Windows (ETW no está dedicado estrictamente a la seguridad, también cumple funciones de registro de diagnóstico). Existe una variedad de técnicas adversarias que buscan evadir estos componentes de seguridad y socavar su visibilidad.
En esta técnica específica, se invoca un prompt de PowerShell libre de las ataduras de AMSI y ETW, que por lo tanto puede ejecutar líneas de comando maliciosas que de otro modo serían detenidas y registradas.
En un hilo de Twitter, analicé esta técnica y ofrecí algunas notas sobre detección. Pero lo interesante de esta técnica de evasión de defensas es que debe llevar un ejecutable al disco para funcionar: así que para ejecutar PowerShell evasivo y sin restricciones, un actor de amenazas debe poder ejecutar un ejecutable malicioso que a su vez TAMBIÉN debe ser evadido.
Algo afortunado de la evasión de defensas es que, como cualquier etapa de la campaña del atacante, existen áreas para monitorear, detectar y alertar. Para técnicas avanzadas como esta, capaces de frustrar y subvertir un aparato de seguridad fundamental (ETW y AMSI), la contrapartida es un ejecutable iniciador que podrás detectar, entre otras cosas que detectarás con esta técnica, si tienes bien resueltos los fundamentos del monitoreo de seguridad.
Mantente atento a nuestra próxima entrega, donde profundizaremos un poco más en los aspectos prácticos de monitorear, detectar y defenderse contra la evasión.
Caso seis: Ataque de capa ocho
¿Conoces el modelo OSI, verdad? Cuando empiezas en TI, te enseñan a resolver un problema según las distintas capas. De la capa uno a la ocho. ¿Conoces la capa ocho, verdad?
La capa ocho es la capa del usuario, la capa humana. Así como algunas mesas de ayuda se dedican únicamente a resolver problemas de capa ocho, existen actores de amenazas que dirigen sus ataques a la capa ocho: a los usuarios. Estas son las estafas, los correos de phishing, los archivos adjuntos maliciosos que simulan ser una factura que esperabas. Todos ellos apuntan al usuario.
Tuvimos un caso que nos presentó un socio. El actor de amenazas comprometió una máquina, plantó varias raíces de persistencia insidiosas, se hizo pasar por el software de contabilidad QuickBooks... todo para terminar con una ventana emergente:
Qué fascinante. El actor de amenazas tuvo todo el tiempo del mundo para hacer toda clase de cosas: comprometer el controlador de dominio, instalar un criptominero (o quizás no sea buen momento para andar en cripto), o incluso infectar la red con ransomware. En cambio, decidió usar su acceso malicioso para generar una ventana emergente.
El socio había realizado una investigación inicial, que al corroborarse resultó fascinante de desentrañar. El programa insidioso de 'quickbooks' estaba firmado con un certificado, pero no de un firmante legítimo de QuickBooks, sino de este dominio de @ Gmail claramente ridículo.
Este método de evasión de defensas está completamente orientado al usuario (T1204). Al igual que el caso de LNK/acceso directo que mencionamos antes, este falso QuickBooks era todo un intento de hacer que el usuario llamara al número móvil controlado por el atacante cuando 'QuickBooks' fallara al cargar.
Hablé con la investigadora de este caso, mi colega Cat Contillo:
Caso siete: Carga reflectante
Le pregunté a Matt Anderson su opinión sobre algo particularmente astuto y genial. Compartió este caso:
Otra forma de evitar la detección es convertir en arma aplicaciones conocidas y confiables para que hagan el trabajo sucio. Así, aunque veas el proceso en ejecución, no parece malo porque es normal.
Hay muchas formas distintas de lograr esto, y a menudo vemos la carga reflectante (T1620), donde el malware inicia un binario legítimo de Windows y aprovecha el espacio de memoria de este ejecutable, reemplazándolo con un payload malicioso.
En un caso reciente observado por Huntress, se inyectó un payload en CasPol.exe, un binario legítimo y confiable. Esto significa que normalmente no se activan alarmas ni se llama la atención por usar un binario confiable de Microsoft, una especie de truco de cambiazo usado por el adversario. El extracto de malware a continuación muestra cómo el adversario nombra específicamente el archivo que desea iniciar (CasPol.exe).
El árbol de procesos de Sysinternals Process Monitor a continuación demuestra visualmente el impacto del payload malicioso que se inyectó en la memoria de CasPol.exe.
La actividad maliciosa incluía establecer conexiones TCP, lo que sugiere algún tipo de C2, además de colocar archivos en el endpoint, como scripts .BAT.
La carga reflectiva, como la inyección de procesos, aprovecha la memoria ya asignada a un proceso. Este tipo de tareas permanece "en memoria" y no "toca el disco" ni deja un rastro ruidoso en el sistema de archivos, lo que hace que el monitoreo y la detección por parte del equipo azul sean un poco más complejos.
Las soluciones de seguridad están mejorando en el monitoreo en memoria, pero mientras tanto, los actores de amenazas siguen innovando y abusando de la RAM de nuestras máquinas en nuestra contra.
Un Estrés de Verdad
¿Transmití estos casos lo suficientemente bien como para que entiendas por qué estoy tan estresado? 😅
Espero que hayas disfrutado explorando a fondo nuestros casos cautivos de evasión de defensas. Espero que, al leer este artículo, hayas encontrado varios puntos que resuenan con los temas que identificamos en nuestra primera entrega: que la evasión de defensas puede ser tan técnica como cognitiva y social; una evasión psicológica.
Pero a través de los casos aquí presentados, he intentado comunicar que todavía hay esperanza para el equipo azul. Este fue un recorrido vertiginoso, con fragmentos de detección y monitoreo en el camino. En nuestra próxima entrega, me gustaría enfocarme en los consejos para el equipo azul: cómo podemos defender el honor de nuestra red contra quienes evaden nuestras protecciones.
Gracias a todos los amigos que nos acompañaron en este artículo y aportaron sus comentarios, así como a nuestros amigos del equipo rojo cuyas técnicas hemos analizado. Lee la tercera parte de nuestra serie sobre evasión de defensas.
