1 puntos por GN⁺ 2025-05-13 | 1 comentarios | Compartir por WhatsApp
  • Comparte la experiencia del proceso de desarrollo de defendnot, una herramienta que desactiva Windows Defender usando directamente la API del servicio Windows Security Center (WSC)
  • El proyecto comenzó mientras intentaba superar las limitaciones técnicas y los problemas legales del proyecto anterior, no-defender
  • Avanzó con la ingeniería inversa y la depuración en medio de varios obstáculos, como un entorno especial (MacBook arm64, depuración remota, alta latencia)
  • Analizó la evasión del registro de Defender y el mecanismo de validación de procesos, y tras múltiples intentos y fallos logró que funcionara de forma estable
  • Al final también completó la función de ejecución automática, y al mismo tiempo reflexiona sobre lo duro que fue todo el proceso

Introducción

  • Comparte el recorrido de implementación de la herramienta defendnot, que desactiva Windows Defender
  • En lugar de centrarse en los principales detalles técnicos, está organizado alrededor de los problemas reales y el ensayo y error que vivió en el entorno de trabajo
  • La documentación formal y la explicación técnica detallada se publicarán por separado más adelante

Recordando hace 1 año

  • Hace aproximadamente un año publicó un proyecto llamado no-defender, que aprovechaba la forma en que Windows Defender se desactiva a través de la API de WSC
  • Este proyecto consultaba código de terceros de un proveedor de antivirus para hacerle creer al sistema que había otro antivirus registrado
  • Tras su lanzamiento recibió mucha atención y obtuvo unas 1,500 estrellas, pero decidió borrar el código fuente y cerrar el proyecto debido a una solicitud de eliminación por DMCA de la empresa de antivirus relacionada

Motivo para iniciar el proyecto

  • Al momento de escribir el texto, se encuentra hospedado en un Airbnb en Seúl
  • Su entorno principal de desarrollo es una MacBook M4Pro, y no llevó aparte ningún equipo indispensable para hacer ingeniería inversa x86
  • Debido a un torneo de CTF y el itinerario del viaje, se encontró en la situación de tener que trabajar sin un dispositivo x86
  • Mientras evaluaba la posibilidad de una implementación “normal” del proyecto no-defender, empezó a explorar si era posible una implementación independiente sin depender de un AV

Investigación inicial (día 1)

  • Con ayuda de un amigo consiguió el binario de wsc e intentó reimplementar el registro en WSC con una estructura similar a la del proyecto anterior
  • Lo implementó usando la API COM de WSC, pero apareció un error de Access Denied
  • Identificó la causa del error en el proceso de verificación de firma y autenticación que WSC realiza sobre el proceso que invoca la API
  • Cuando intentó registrar el AV inyectando un módulo en un proceso del antivirus, el AV se registró correctamente

Sustitución del binario AV y experimentos adicionales (día 1)

  • Intentó ejecutar la herramienta mediante procesos del sistema firmados (cmd.exe, etc.), pero falló en la validación de PPL (Protected Process Light)
  • Decidió pausar temporalmente el trabajo y dejar para después el desensamblado detallado y el rastreo para el análisis

Preparación del entorno (día 2)

  • Debido a las limitaciones del entorno MacBook arm64, depurar Windows x86 era muy difícil
  • Usó de forma remota la PC de un amigo que vive en Estados Unidos (Parsec, AnyDesk, etc.) para realizar depuración y pruebas en un entorno de alta latencia
  • En el proceso, la compilación del código y la depuración de la VM se entrecruzaban de forma compleja, lo que le provocó lentitud y confusión

Depuración del servicio WSC (día 2)

  • Confirmó que el servicio WSC tiene una estructura de DLL ejecutada por svchost
  • Para quitar la protección PPL, aplicó un bypass con un controlador especial y confirmó con el depurador la entrada a la función
  • Identificó que dentro del servicio se estaba ejecutando una verificación del token SID de WinDefend
  • Formuló la teoría de que podía evadir el procedimiento de autenticación imitando un proceso con el SID de WinDefend

Imitación del SID de WinDefend (día 2)

  • Estudió más a fondo la estructura y el funcionamiento de los tokens de Windows
  • Tras implementar y ejecutar código para imitar el SID de WinDefend, observó que todas las llamadas COM devolvían SUCCESS, pero en la práctica el AV no quedaba registrado

Reconstrucción del algoritmo de validación (día 3)

  • Reanalizó cuidadosamente en el binario AV si la comprobación de SID realmente se superaba
  • Cuando la verificación de SID no se supera, el servicio además revisa el estado de elevación, la firma del binario y la bandera DllCharacteristics del PE (ForceIntegrity)
  • Reprodujo la función que realiza esa lógica y llevó a cabo experimentos aplicándola a binarios core del sistema

Uso del proceso Taskmgr (día 3)

  • Volvió a probar usando Taskmgr.exe como proceso objetivo, pero WSC rechazaba la solicitud por errores en el paso del nombre y un bug de IPC
  • Después de mejorar la inferencia de la ruta del archivo y la forma de pasar el nombre del AV, confirmó que funcionaba correctamente

Limpieza del código (día 3)

  • Ordenó las funciones e intentó implementar la ejecución automática (autorun)
  • Experimentó fallos intermitentes al gestionar la ejecución automática, y repitió la revisión del código y del entorno para descubrir la causa

Implementación de la ejecución automática (día 4)

  • Confirmó que la causa era una casilla de las opciones del Programador de tareas (Task Scheduler) que impedía ejecutar la tarea cuando la laptop no estaba conectada a corriente alterna (AC)
  • Tras desactivar esa opción, la ejecución automática funcionó normalmente
  • Para cerrar, realizó limpieza del código y pruebas

Conclusión

  • El trabajo de ingeniería inversa en un entorno limitado e incómodo fue una experiencia muy dura tanto mental como físicamente
  • Más adelante se publicará por separado una documentación más detallada sobre la implementación de WSC

Agradecimientos

  • Pindos: amigo que le prestó su PC por las noches para ayudarle con la depuración y además le calentó la habitación
  • MrBruh: colega que lo impulsó a empezar a explorar el proyecto y le dio ideas y retroalimentación
  • También agradece a las personas cercanas que estuvieron en contacto con él durante el proyecto y le dieron apoyo
  • Confiesa que ama el kimchi
  • También da las gracias al artista que dejó graffiti en su pared

1 comentarios

 
GN⁺ 2025-05-13
Comentarios de Hacker News
  • La forma más potente, aunque invasiva, de desactivar Defender es arrancar con un Linux USB en vivo, renombrar la carpeta C:\ProgramData\Microsoft\Windows Defender y luego crear un archivo vacío en su lugar
    • Como la política de grupo funciona demasiado bien, armé un entorno de dominio local con un controlador en mi homelab para cambiar automáticamente las políticas de Defender para todos los usuarios
    • Es raro que Windows no tenga un manifiesto firmado que detecte ese tipo de manipulación
    • De hecho, productos populares hacen básicamente eso, y una vez tumbaron cerca del 25% de todo Internet
  • El proyecto se volvió bastante popular y consiguió como 1.5k estrellas, pero después el desarrollador del antivirus que yo usaba envió una solicitud DMCA. No entiendo cuál es el “antivirus que yo usaba” ni por qué esta persona enviaría un DMCA. Supongo que el autor hizo ingeniería inversa de otro antivirus y lo metió en open source, o al menos está relacionado con imitar a WinDefend. Parece que hubo un tema de copyright
    • Según entiendo, parece que usó el cascarón de otra herramienta antivirus para saltarse los requisitos de firma. Puede considerarse transformativo y razonable (no soy experto legal), pero es una zona gris
    • Sí, copió parte de un antivirus existente y violó la ley de copyright. El párrafo justo arriba del citado también explica que el proyecto usó código de terceros de un antivirus existente para registrar el AV en WSC
  • Como referencia, WSC significa Windows Security Center
    • Gracias por la ayuda. De verdad desespera cuando una sigla aparece por primera vez sin explicación
  • Esto es realmente extraño: https://github.com/es3n1n/defendnot/… Si tienen curiosidad por lo que realmente pasa, vean esto: https://github.com/es3n1n/defendnot/…
    • Me pregunto si alguien que explique bien la magia de CPP puede explicar por qué este código es extraño
    • No veo qué tiene de raro. Yo uso bastante bien este patrón en varias partes del código. La firma es diferente en el sitio de llamada, pero eso es preferencia personal. Como referencia, D tiene sintaxis integrada que se dispara al salir del scope
    • Por falta de tiempo me dio flojera implementar directamente el patrón RAII para todos los componentes COM. Planeo cambiarlo en la próxima actualización
    • “El código es como tratas a tus colegas” - Michael Feather En resumen, no es IA El código sirve para diferir una llamada de función cuando termina el scope de un objeto. Usa macros de C para simplificar definiciones complejas de lambdas/funciones anónimas en C y la generación de nombres de variable únicos. Eso sí, como la macro no está en mayúsculas y parece una llamada de función, puede confundir a quien no esté familiarizado. Para algunas personas este patrón es lo bastante útil como para considerarlo idiomático. La explicación técnica puede verse en el enlace a otro comentario
  • El año pasado disfruté mucho mis vacaciones haciendo ingeniería inversa de los escritorios virtuales de Windows, y es un gran recuerdo. La ingeniería inversa es realmente divertida. Aprendí muchas cosas interesantes, por ejemplo que dentro de Windows RPC existe un mecanismo de mensajería no documentado: https://csandker.io/2022/05/24/Offensive-Windows-IPC-3-ALPC.html
  • Hace poco leí https://nostarch.com/windows-security-internals y eso hizo que este post me resultara todavía más cercano. Ya entendía más o menos cómo funcionaba el backend en Windows, pero el último capítulo de ese libro explica con tanto detalle como el autor cuestiones sobre tokens y SID
  • Me pregunto por qué alguien querría desactivar WSC
    • Podría ser por rendimiento, desarrollo de malware, hacking, etc.
    • Si fuera un actor de amenazas, quizá tenga suerte y no haya otro producto EDR (detección y respuesta en endpoints) instalado. Pero si lo hay, casi seguro lo bloqueará. Si fueras un vendor de EDR, esto podría usarse como una llamada ofuscada de API para desactivar el firewall de Windows. Productos como CrowdStrike también pueden usar su propio firewall o reemplazar el firewall de Windows
    • Todo software antivirus es al menos powervirus. No me gusta que alguien esté vigilando con cosas como que no se puede usar netcat.exe
    • Es mi hardware, así que lo voy a usar como yo quiera. Esa es la razón simple
    • Me pregunto por qué alguien querría meter deliberadamente un rootkit en su propio sistema
  • Lo peor para mí es que Check Point Harmony ni siquiera use la interfaz creada para Defender, y en cambio instruya a los usuarios mediante un artículo de su base de conocimiento a desactivar Defender manualmente
  • Por si alguien tenía la duda: WSC significa Windows Security Center. Yo también tuve que buscarlo
    • La frase “Todo esto es administrado por Windows Security Center-WSC” sí está incluida en el artículo
  • Sobre la frase “estoy trabajando desde una macbook arm64, así que actualmente no hay una forma realmente decente de emular Windows x86 en una macbook arm”, preguntan por UTM y mencionan que Parallels empezó hace poco a dar soporte para VM de Intel
    • Probé UTM y era inutilizable con Windows x86. Tal vez Linux por línea de comandos pueda ir a una velocidad aceptable, aunque lenta, pero en un entorno GUI es imposible. Windows arm64 sí corre bien, pero como no es Windows x86, no sirve para hacer ingeniería inversa de componentes del sistema x86
    • El sistema de recompilación dinámica de QEMU no es tan eficiente como los sistemas nativos de Windows o macOS (Rosetta 2). Windows x86 sí corre en UTM, pero el rendimiento es muy malo. En la práctica, siento que es mejor correr apps x86 dentro de una VM de Windows ARM usando el recompilador dinámico de Windows, o usar WINE, que emplea subsistemas basados en código nativo. Para tareas rápidas o improvisadas puede servir. Si para el OP “realmente decente” incluye rendimiento, se entiende su postura
    • Corríjanme si me equivoco, pero creo que la emulación de una CPU con MMU es inherentemente lenta y difícil de optimizar. Tecnologías como Rosetta de Apple y la equivalente de Microsoft son rápidas porque solo ejecutan código en espacio de usuario. Evitan la emulación completa del MMU de todo el sistema