Resumen ejecutivo
defendnot, una herramienta desarrollada por es3n1n, representa un método único para deshabilitar Windows Defender. A diferencia de los métodos convencionales que intentan modificar la configuración del registro o usar políticas administrativas, defendnot adopta un enfoque más sofisticado al registrar un producto antivirus. defendnot logra su objetivo al aprovechar las API no documentadas del Windows Security Center (WSC) para registrar un producto antivirus falso. Esta acción fuerza inherentemente a Windows Defender a un estado deshabilitado, lo que reduce significativamente la barrera para la posterior implementación y ejecución de malware.
Esta publicación no pretende reexaminar la capacidad principal de defendnot, sobre la cual es3n1n ha escrito un blog fenomenal, sino que se enfoca en la perspectiva defensiva: identificar los indicadores críticos y las técnicas para detectar esta evasión dentro de un entorno empresarial. Incluimos reglas Sigma que se pueden usar para detectar esta herramienta en varias etapas de ejecución.
Contexto
defendnot surgió como sucesor de "no-defender," un proyecto anterior del mismo desarrollador, que finalmente fue eliminado de GitHub tras un aviso de retiro por DMCA. Se informó que la iteración original reutilizaba código de soluciones antivirus comerciales existentes. En cambio, defendnot se reconstruyó desde cero, un testimonio de la ingeniería inversa directa de los métodos del Component Object Model (COM) del Windows Security Center (WSC).
El servicio Windows Security Center (WSC) es fundamental para gestionar los productos de seguridad en los sistemas Windows. Es importante destacar que incorpora funciones e interfaces no documentadas, cuyo acceso Microsoft suele restringir mediante acuerdos de confidencialidad (NDA) a proveedores de antivirus legítimos.
En esencia, defendnot explota la interfaz COM IWscAvStatus para registrar un antivirus personalizado, una técnica que Huntress denomina Malicious Security Product AV bypass. Este proceso se basa principalmente en dos métodos:
- Register: Este método inicia el registro del supuesto antivirus.
- UpdateStatus: Este método activa posteriormente el antivirus falso, indicando su estado operativo al WSC.
Figura 1: Nuevas entradas de registro creadas
Figura 2: Entradas de registro predeterminadas de Defender
Sin embargo, el WSC incorpora verificaciones de validación de firmas para garantizar la legitimidad de los procesos de registro. Un proceso arbitrario no puede simplemente invocar estos métodos COM. es3n1n dedicó un esfuerzo considerable a aplicar ingeniería inversa y replicar estas verificaciones de firma del WSC. Este trabajo produjo una lista de binarios potenciales que, si se les inyectara código, pasarían estas estrictas rutinas de validación. defendnot, tal como está implementado, codifica de forma fija a Taskmgr.exe (el Administrador de tareas de Windows) como su kVictimProcess designado para la inyección antes de iniciar la secuencia de registro del antivirus.
Figura 3: Taskmgr.exe codificado como kVictimProcess
Hay varias limitaciones importantes de la herramienta que vale la pena señalar aquí, tal como el autor de la herramienta ha señalado en el proyecto:
- El archivo debe permanecer en el disco (persistencia) para seguir funcionando como un producto de seguridad malicioso y así deshabilitar Defender.
- Defender actualmente detecta defendnot como VirTool:Win64/Defnot.A cuando está en el disco.
- Debido a que WSC no es compatible con Windows Server, defendnot no funcionará correctamente en servidores Windows.
Diagrama de ataque (rudimentario)
Para contextualizar mejor la operación, visualicemos el progreso del ataque. Aunque rudimentario, este diagrama ilustra las etapas clave de la ejecución de defendnot :
Figura 4: defendnot diagrama de ataque (rudimentario)
El diagrama de flujo de ataque anterior ilustra un proceso de ejecución de varias fases diseñado para deshabilitar Windows Defender mediante un registro fraudulento de antivirus. Cada paso numerado en esta cadena de ataque presenta oportunidades únicas de detección que los equipos de seguridad pueden aprovechar para identificar e interrumpir la actividad maliciosa antes de que se logre el objetivo final de evasión de defensas.
Ejecución inicial
defender-loader.exe ejecución
Esta fase representa la ejecución inicial, donde el componente principal del cargador comienza a operar. El cargador funciona como el orquestador de toda la cadena de ataque, encargado de analizar los parámetros de configuración e iniciar las fases siguientes.
Entre las consideraciones clave de detección está monitorear los procesos recién creados, especialmente aquellos con nombres sospechosos o que operan desde ubicaciones inusuales. Los eventos de creación de procesos deben correlacionarse con las actividades del sistema de archivos y las conexiones de red para establecer patrones de comportamiento de referencia.
Figura 5: Sysmon Event ID 1 - defendnot-loader
Regla Sigma: ejecución de defendnot
La ejecución exitosa del componente defender-loader.exe activa la siguiente fase del ataque, donde defendnot comienza a procesar sus parámetros operativos.
Regla YARA para binarios de defendnot
Análisis de argumentos y creación del payload
Analizar argumentos / crear ctx.bin
Tras la ejecución inicial, la herramienta pasa de inmediato al modo de procesamiento de argumentos, analizando los parámetros de línea de comandos para determinar su configuración operativa. Durante esta fase, defendnot genera un archivo de contexto (ctx.bin) que contiene datos de configuración o payloads cifrados necesarios para las actividades de inyección posteriores.
Esta transición de la ejecución a la configuración representa una ventana de detección crítica, ya que defendnot debe realizar operaciones del sistema de archivos que generan telemetría observable. La creación de ctx.bin funciona como un paso preparatorio para la fase de inyección y contiene información del proceso objetivo y datos del payload.
Figura 6: Sysmon Event ID 11 - ctx.bin creación de archivoRegla Sigma: creación de archivo de defendnot
Con el archivo de configuración creado exitosamente, defendnot ahora cuenta con todos los componentes necesarios para iniciar la secuencia de inyección de procesos.
Inyección de procesos
Inyectar defendnot.dll en el proceso víctima (taskmgr.exe de manera predeterminada)
Con los datos de configuración de la fase anterior, defendnot ahora inicia la secuencia de inyección principal. El componente defendnot.dll, guiado por los parámetros establecidos durante el análisis de argumentos, apunta al proceso del Administrador de tareas (taskmgr.exe) como su víctima de inyección predeterminada, aunque se pueden especificar otros procesos mediante argumentos de línea de comandos.
Esta inyección representa la transición de un proceso independiente a operar dentro del contexto de un componente legítimo del sistema Windows, lo que proporciona tanto elevación de privilegios como capacidades de evasión.
Figura 7: Sysmon Event ID 1 - Taskmgr.exe creación de proceso
Regla Sigma: Taskmgr como proceso hijo de defendnot
Figura 8: Sysmon Event ID 7 - Evento de carga de Taskmgr
Una vez inyectado con éxito en el proceso objetivo, tiene los privilegios y el posicionamiento para manipular la infraestructura de seguridad de Windows.
Reglas Sigma relacionadas con estos comportamientos:
Regla Sigma: defendnot.dll cargado a través de Taskmgr
Regla Sigma: imagen sospechosa cargada en Taskmgr
A continuación se muestra la telemetría resultante que exhibió defendnot al realizar la inyección de proceso. Esta técnica clásica de inyección de DLL nos muestra que
defendnot-loader primero debe acceder al proceso taskmgr (ProcessAccess - Sysmon EID 10), asignar memoria virtual (no se ve en Sysmon, pero podría detectarse mediante el
proveedor Threat-Intelligence ETW), realizar una
acción de escritura en memoria (de nuevo, no se ve con Sysmon, pero podría ser mediante el
proveedor Threat-Intelligence ETW), y la
creación/ejecución del hilo remoto (CreateRemoteThread - Sysmon EID 8). Algunas cosas a tener en cuenta:
- La técnica de inyección de procesos puede cambiar (de una inyección de DLL clásica a otra técnica de inyección de procesos).
- defendnot usa TaskMgr como su proceso objetivo, pero podría haber un proceso objetivo diferente.
Figura 9: Otros posibles procesos víctima identificados por es3n1n (captura de pantalla cortesía de es3n1n)
Figura 10: Evento CreateRemoteThread registrado
Regla Sigma: MsMpEng.exe Process Access defendnot loader
Figura 11: Sysmon Event ID 10 - Process Access defendnot-loader
Figura 12: Sysmon Event ID 10 - Process Access Taskmgr
Registro de evasión de antivirus
Registrar un antivirus falso (producto de seguridad malicioso) mediante la interfaz IWscAvStatus
Operando desde el contexto del proceso inyectado, defendnot ahora aprovecha su posición elevada para interactuar con la API de WSC IWscAvStatus y registrarse como un producto antivirus legítimo, dando inicio al proceso de manipulación del software de seguridad.
Esta fase representa la transición de la inyección encubierta a la manipulación activa del sistema, ya que empieza a establecer su presencia dentro de la infraestructura de seguridad de Windows.
La solicitud de registro ahora espera a que el Centro de seguridad de Windows la procese, preparando el terreno para su aceptación como producto de seguridad legítimo.
Aceptación del registro del antivirus
WSC acepta el registro (antivirus falso registrado)
El Centro de seguridad de Windows procesa la solicitud de registro fraudulenta y la acepta como un producto de seguridad (antivirus) legítimo. Esta aceptación marca un punto de transición crítico en el que una amenaza externa se convierte en un componente aceptado de la postura de seguridad del sistema.
Este registro exitoso otorga los privilegios y el mecanismo necesarios para proceder a deshabilitar soluciones de seguridad competidoras sin despertar sospechas en el usuario.
Figura 13: Sysmon Event ID 13 - Registry Key set
Figura 14: Sysmon Event ID 13 - Additional registry key set
Regla Sigma: Modification to Security Center AV Registry Key
Con su legitimidad establecida dentro del marco de seguridad, defendnot ahora puede, opcionalmente, establecer mecanismos de persistencia antes de pasar a su objetivo principal.
Persistencia (opcional)
Registrar AutoRun (opcional)
Una vez establecido con éxito como producto de seguridad registrado, existe la opción adicional de implementar persistencia para asegurar su supervivencia tras reinicios del sistema. Esta fase opcional consiste en crear entradas de registro de inicio automático que reactivarán el producto de seguridad malicioso después de reiniciar el sistema.
Figura 15: Scheduled Task CreationRegla Sigma: defendnot Scheduled Task Creation - Security
Figura 16: Scheduled Task Updated
Se establezca o no la persistencia, defendnot ahora procede a ejecutar su misión principal: neutralizar Windows Defender.
Resultado de la evasión de defensas
Windows Defender queda deshabilitado
La cadena de ataque culmina con la deshabilitación exitosa de Windows Defender, aprovechando la posición establecida como producto de seguridad registrado para justificar la desactivación de mecanismos de protección competidores. Esta fase final representa el logro del objetivo principal: crear un entorno en el que puedan proceder actividades maliciosas adicionales sin interferencia de la solución de seguridad principal del sistema.
La finalización exitosa de esta fase demuestra la efectividad de toda la cadena de ataque, desde la ejecución inicial hasta la manipulación del marco de seguridad.
Figura 17: Windows Event ID 15 - Defender State Off
Figura 18: Windows Event ID 15 - Defender State On
Regla Sigma: defendnot Windows Defender State Toggle Events
Con Windows Defender neutralizado, el entorno ahora está preparado para actividades maliciosas posteriores, habiendo evadido con éxito los mecanismos defensivos principales del sistema mediante una sofisticada técnica de evasión de múltiples etapas.
Figura 19: Se han alterado las configuraciones de GUI de Defender
Figura 20: El antivirus falso se registró con éxito
Capas de detección
Al considerar cómo abordar la detección de cualquier amenaza, es importante tener en cuenta las fuentes de datos y las capas de abstracción, así como los niveles de la Pirámide del Dolor, para optimizar los métodos
de detección. El marco Summiting the Pyramid de MITRE da más contexto a los enfoques de detección al analizar estrategias de robustez de detección. Los
niveles básicos de Summiting son:
Nivel 5: Núcleo de la subtécnica o técnica
Nivel 4: Núcleo de algunas implementaciones de la (sub)técnica
Nivel 3: Núcleo de herramientas preexistentes o dentro del límite
Nivel 2: Núcleo de herramientas traídas por el atacante o fuera del límite
Nivel 1: Valores efímeros
Robustez y Summiting the Pyramid
La robustez en la detección indica cuán resistente es una detección a la evasión o a cambios triviales por parte de un atacante:
- Las capas inferiores de la pirámide (hashes, IP/dominios) son frágiles: fáciles de evadir recompilando, renombrando o cambiando la infraestructura.
- Las capas superiores de la pirámide (comportamientos/TTPs) son robustas: difíciles de cambiar sin alterar fundamentalmente el flujo de trabajo u objetivos del atacante.
Escalar la pirámide significa buscar la detección basada en comportamiento/TTP, que es más robusta frente a los cambios del atacante.
La idea es que las detecciones más efectivas
y robustas usan métodos lo más cercanos posible al núcleo de la técnica. En vez de enfocarse en valores efímeros o IOC como hashes de archivos, usa llamadas a la API de Windows específicas a la
técnica utilizada por el malware o la herramienta. Esto no siempre es posible y a veces puede ser ruidoso. El mejor método suele ser combinar métodos de detección en cada nivel: ser
preciso y de alta fidelidad con detecciones de nivel bajo, mientras se usan niveles de detección más amplios por encima para cubrir las técnicas de evasión de las detecciones de
nivel bajo.
Por ejemplo, veamos algunos métodos posibles en varios niveles para detectar la herramienta defendnot y su técnica, y comparemos su efectividad y robustez.
| Capa de la pirámide | Ejemplo en defendnot | Fuente de detección | Término de robustez | Dificultad de evasión |
|---|---|---|---|---|
| Hash | SHA256 de defendnot.dll | Escaneo de archivos, antivirus, YARA | Débilmente relacionado | Trivial |
| Artefacto | Tarea programada, Registry Run | Registros de eventos, Sysmon, monitor de registro | Generalmente relacionado | Moderada |
| Herramienta | Nombre de proceso/DLL de defendnot, uso | EDR, listado de procesos, correlación SIEM | Estrechamente ligado a la técnica | Más difícil |
| Comportamiento (TTP) | Abuso de WSC COM, inyección de procesos | Eventos Sysmon, EDR, SIEM, analítica | Núcleo de la técnica | Muy difícil |
Por ejemplo, el hash del archivo de la herramienta está débilmente relacionado con la técnica central, no es muy robusto y es trivial de evadir. Si bien puede ser una forma buena y fácil de detectar el uso
por defecto de la herramienta (entonces, ¿por qué no usarlo?), no se debe confiar en él para asegurar la mejor defensa frente a otros usos de la herramienta. Usar métodos de detección de inyección de procesos, o incluso
detectar el abuso real de WSC COM que ocurre, es más robusto y mucho más difícil de evadir, porque es la técnica central usada por la herramienta y no se puede cambiar sin
cambiar la forma en que funciona la herramienta (en cuyo caso sería algo completamente distinto y de todas formas se necesitarían nuevos métodos de detección).
Niveles de robustez aplicados a defendnot
Figura 21: Niveles de robustez aplicados a defendnot
Ahora veamos algunas de las fuentes específicas que se pueden usar para detectar las diversas características, artefactos dejados y técnicas usadas por la herramienta.
Métodos y fuentes de detección de defendnot con niveles de robustez de eventos basados en endpoints aplicados
Conclusiones clave para construir detecciones sobre defendnot
- Núcleo de la técnica (comportamiento/TTPs): detectar el abuso de WSC (p. ej., actividad de registro COM no autorizada) o la inyección de procesos es extremadamente robusto; los atacantes tendrían que cambiar fundamentalmente su enfoque para evadirlo.
- Estrechamente ligado a la técnica (herramienta): monitorear los nombres de proceso o DLL conocidos de defendnot, o ver a Taskmgr.exe como objetivo de inyección, es robusto pero sigue siendo vulnerable al renombrado.
- Generalmente relacionado (artefactos): las tareas de autoarranque, las claves de registro y otros artefactos son útiles, pero los atacantes pueden sustituirlos o limpiarlos.
Conclusión
defendnot representa un enfoque sofisticado para eludir Windows Defender aprovechando mecanismos legítimos (crear un producto de seguridad malicioso) en lugar de intentar romperlos directamente. Demuestra cómo APIs no documentadas, pensadas para que las usen proveedores de seguridad legítimos, pueden ser diseñadas a la inversa y explotadas.
Las técnicas usadas por defendnot, en particular la inyección de procesos en procesos de confianza de Windows y la interacción con APIs no documentadas, resaltan la necesidad de estrategias de defensa en profundidad que se enfoquen en el monitoreo del comportamiento en lugar de simples detecciones basadas en archivos.
Para los defensores, esta herramienta sirve como recordatorio de la importancia de monitorear el comportamiento del sistema y el estado de los productos de seguridad, así como de la necesidad de evolucionar continuamente las capacidades de detección para abordar técnicas de evasión emergentes.
Gracias a Jonathan Johnson (@jsecurity101) por su ayuda en la revisión de esta publicación del blog.
