Cómo arruiné mis vacaciones haciendo ingeniería inversa de WSC

• defendnot, creado durante un viaje a Seúl, era una herramienta que intentaba desactivar Windows Defender llamando directamente a la API del servicio Windows Security Center (WSC), lo que terminó convirtiéndose en varios días de ingeniería inversa
• La herramienta anterior, no-defender, registraba en WSC la presencia de otro antivirus usando código de un antivirus existente; consiguió unas 1.5k estrellas en GitHub antes de ser eliminada por una solicitud de DMCA del fabricante del antivirus
• Al principio se reprodujeron las llamadas a la API COM de WSC en aproximadamente una hora, pero WSC validaba el proceso que hacía la llamada, así que el acceso era denegado desde procesos normales
• El análisis mostró que WSC comprobaba el SID de WinDefend, privilegios de administrador, firma y el flag ForceIntegrity dentro de DllCharacteristics del PE; en la implementación final se usó Taskmgr.exe
• En un entorno enredado con una MacBook arm64, una PC remota en Estados Unidos, 210 ms de latencia con Parsec y una VM de Shadow.tech, la implementación se terminó corrigiendo un error de ruta de ctx.bin y un problema con las condiciones de energía de autorun

---

Contexto de por qué hice defendnot

• defendnot es una herramienta que usa directamente la API del servicio Windows Security Center para desactivar Windows Defender
• La parte clave de la implementación no fue tanto la llamada a WSC en sí, sino ir sorteando una por una las condiciones de validación que lo bloqueaban y un entorno de trabajo muy incómodo
• Una documentación técnica más detallada sobre WSC será publicada más adelante por otra persona

no-defender y el DMCA hace un año

• no-defender, publicado hace alrededor de un año, usaba la API de Windows para antivirus con el fin de apagar Windows Defender
• Esa API estaba pensada para avisarle al sistema que “hay otro antivirus, así que no hace falta ejecutar los escaneos de Defender”
• El componente del sistema que administra esa parte es Windows Security Center (WSC)
• no-defender funcionaba forzando el registro en WSC de un antivirus existente usando código de terceros de ese antivirus
• A las pocas semanas de publicarse consiguió aproximadamente 1.5k stars, y cuando el fabricante del antivirus usado presentó una solicitud de retiro por DMCA, se vació el repositorio y ahí terminó todo

El análisis de WSC que volvió a arrancar durante un viaje a Seúl

• Mientras se hospedaba en un Airbnb en Seúl, recibió un mensaje de MrBruh, que había estado revisando no-defender y estaba investigando si era posible una implementación “limpia” sin binarios de antivirus
• Normalmente lleva una laptop x86 aparte para CTFs o trabajos de reversing en x86, pero en este viaje solo había llevado una MacBook M4Pro
• Aun con la desventaja de no tener equipo para reversing x86, empezó a analizar WSC aprovechando el tiempo antes de que sus amigos se despertaran

Día 1: reproducción de la API COM de WSC y primer acceso denegado

• MrBruh proporcionó los binarios más recientes de WSC, y se tomó como referencia la implementación de registro en WSC del antivirus que se había usado antes
• WSC tiene una API COM usada por los antivirus, y se reprodujeron en alrededor de una hora las llamadas que hacía ese antivirus existente
• Se hicieron pruebas arrancando Windows arm64 en Parallels, pero el resultado fue access denied
• Por experiencia previa ya se sabía que WSC validaba el proceso que invocaba la API, y al principio se sospechó que podía tratarse de una validación de firma
• Al inyectar código en el proceso que el antivirus existente usaba para sus operaciones con WSC, las llamadas COM para registrar un nuevo antivirus y actualizar su estado funcionaron correctamente

Intento de eliminar la dependencia de binarios de antivirus

• Para evitar que el nuevo proyecto volviera a enfrentar reclamos del fabricante del antivirus anterior, se intentó usar binarios provistos por el sistema en lugar de binarios del antivirus
• El primer proceso elegido fue cmd.exe, pero las llamadas a la API de WSC fueron rechazadas
• Al revisar wscsvc.dll, apareció código que comprobaba si el proceso llamador era PPL
• Un proceso creado simplemente con CreateProcessA no era un proceso protegido PPL, y esa madrugada ya no se pudo avanzar más

Día 2: montar un entorno incómodo de depuración remota

• En la MacBook arm64 era difícil trabajar bien con Windows x86, y se quería evitar tanto trabajar en arm64 como quedarse sin x64dbg
• Su amigo pindos permitió acceso a su PC y se conectó por Parsec
• Como la conexión era desde Corea a una PC ubicada en Estados Unidos, la latencia promedio era de unos 210 ms
• En ese momento el flujo de trabajo era extremadamente engorroso
  • Compilar el módulo con MSVC en Windows arm64 dentro de Parallels
  • Compartir los artefactos compilados con el host mediante una carpeta compartida
  • Copiar los artefactos a la VM sobre la PC de pindos usando AnyDesk
  • Depurar el servicio WSC con 210 ms de latencia por Parsec
• El entorno era lo bastante incómodo como para reducir mucho la velocidad de desarrollo y análisis

Depuración del servicio WSC y el SID de WinDefend

• El servicio WSC es una DLL ejecutada por svchost, y el principal obstáculo para adjuntar el depurador era la protección PPL
• En la VM se activó el modo de prueba y se usó un driver que, con unas pocas líneas de código en modo kernel, quitaba el PPL del proceso objetivo
• El punto donde fallaba cmd.exe al intentar registrar un antivirus en WSC era WscServiceUtils::CreateExternalBaseFromCaller
• Esa función se hacía pasar por el cliente RPC y luego comprobaba si el token del proceso llamador contenía el SID de WinDefend
• Como en ese momento no se conocía bien el funcionamiento de los tokens de Windows, se concluyó que bastaba con hacerse pasar por WinDefend para superar la verificación
• Por falta de sueño, también se interpretó erróneamente que el binario del antivirus existente pasaba esa comprobación de IsMember

Intento de suplantar a WinDefend y fracaso

• Después de pasar varias horas aprendiendo sobre tokens de Windows, se implementó la idea de ejecutar el código con un token que incluyera el SID de WinDefend para pasar la verificación de WSC
• Se probó ejecutar el código con cmd adjuntándole el SID de WinDefend, pero aunque la llamada COM devolvía STATUS_SUCCESS, en la práctica no se registraba ningún antivirus nuevo
• Al final este enfoque no sirvió de mucho y hubo que volver a validarlo al día siguiente

Día 3: reconstrucción del algoritmo real de validación

• Al revisar de nuevo, se confirmó que el binario del antivirus existente no pasaba la comprobación del SID de WinDefend
• Pasar esa verificación llevaba a manipular el objeto WSC de Windows Defender, pero no servía porque no permitía desactivar Defender directamente solo con llamadas a WSC
• Se eliminó el código de suplantación de WinDefend y se analizó la otra rama de la condición
• En esa rama se comprobaba lo siguiente sobre el binario llamador
  • Si el proceso estaba elevated
  • Si la firma del binario era válida
  • Si había un flag específico en DllCharacteristics del PE
• El flag de DllCharacteristics que se comprobaba en CSecurityVerificationManager::CreateExternalBaseFromPESettings era ForceIntegrity
• Se creó en el repositorio de defendnot código que reproducía la validación binaria de WSC, dentro de la carpeta wsc-binary-check, y se probó con binarios de System32

Uso de Taskmgr.exe y el bug de ctx.bin

• Como el amigo necesitaba volver a usar su PC, se pasó a conectarse directamente a la VM por Parsec, pero con codificación por software el entorno se volvió todavía más lento
• Se usó Taskmgr.exe en lugar de cmd.exe, pero seguían apareciendo errores de RPC
• Por la latencia y los problemas de entrada ya era difícil depurar en esa misma VM, así que, por recomendación, se pagaron $30 por una suscripción a shadow.tech
• La VM de Shadow.tech tenía una versión más antigua de Windows, por lo que el código de wscsvc no tenía tantas funciones inline como en la versión más reciente, y el resultado de la decompilación también era más fácil de leer
• La causa real del error era que el nombre del AV enviado a WSC era incorrecto
  • defendnot-loader usaba un ctx.bin con parámetros serializados para pasar datos a defendnot.dll
  • Aunque ya se había implementado IPC aparte para seguimiento de estado, seguía quedando el método de ctx.bin para pasar configuración, como residuo del viejo código de no-defender
  • La función que buscaba la ruta de ctx.bin tomaba como base la carpeta del módulo Taskmgr.exe, no la de nodefend.dll
  • Como resultado, se enviaba un byte nulo como nombre del AV y WSC rechazaba ese buffer
• Después de corregir el problema de ruta, la prueba funcionó

Limpieza del código y problema con autorun

• Ese mismo día se siguió hasta las 8 a. m. limpiando el código e implementando funciones adicionales para terminar todo
• Entre esas funciones adicionales estaba la posibilidad de agregarse a autorun
• A las 8 a. m., lo único que todavía no funcionaba bien era autorun, y tras probar varios métodos sin éxito, se fue a dormir
• Al revisar de nuevo al día siguiente, se descubrió que el problema eran dos casillas relacionadas con energía en la creación de la tarea del programador
• Como la laptop no estaba conectada a corriente alterna, la tarea no se ejecutaba; al desactivar esos flags, autorun empezó a funcionar
• Después de unas horas más de limpieza de código, el trabajo quedó terminado

Cierre

• El trabajo en sí fue divertido, pero los problemas de entorno repetidos durante varios días y el flujo de depuración remota fueron una experiencia que no querría repetir
• En particular, la combinación de una MacBook arm64, una VM x86 remota, alta latencia, codificación lenta y un bug de ruta de archivo descubierto tarde elevó mucho la dificultad de la implementación
• Más adelante se publicará por separado documentación más técnica sobre WSC

[GN⁺]

Opiniones de Hacker News

• La forma más invasiva pero efectiva que encontré para desactivar Defender fue arrancar con un USB live de Linux, renombrar C:\ProgramData\Microsoft\Windows Defender y luego crear un archivo vacío en su lugar

  • Las políticas de grupo siguen funcionando muy bien, así que en mi homelab tengo un controlador de dominio local que solo cambia automáticamente las políticas de Defender para todos los usuarios
  • Un producto popular funcionaba casi de la misma manera y terminó tumbando más o menos el 25% de todo Internet junto con eso
  • Es raro que Windows no detecte esos cambios mediante un manifiesto firmado

• Como referencia, WSC significa Windows Security Center

• Me confundió bastante la expresión the antivirus I was using. No entendía por qué esa empresa de antivirus tendría motivos para enviarle al autor una solicitud de baja por DMCA
  Probablemente quiso decir que el autor hizo ingeniería inversa de otro antivirus y metió parte de eso en un proyecto open source. Pero también vi títulos como Impersonating WinDefend, así que al final me pregunto si el autor violó de alguna forma la ley de copyright

  • Según entiendo, parece que usó la carcasa de otra herramienta antivirus para saltarse los requisitos de firma. Entiendo que es una zona gris, y creo que también podría haber margen para verlo como un uso transformativo, pero no soy abogado
  • Correcto. Copió parte de un programa antivirus existente y violó la ley de copyright
    Justo antes del párrafo citado se explica que “el proyecto usó código de terceros de un antivirus que ya existía, y forzó a que ese antivirus se registrara en WSC como antivirus”

• Este código se siente maldito:
  https://github.com/es3n1n/defendnot/blob/master/defendnot-lo...
  Si quieren ver qué está pasando realmente, es acá:
  https://github.com/es3n1n/defendnot/blob/master/cxx-shared/s...

  • ¿Alguien con dominio de la magia de C++ puede explicar qué está pasando y por qué dicen que está maldito?
  • Por limitaciones de tiempo, no quería implementar RAII a mano para los objetos relacionados con COM. Igual planeo cambiarlo en la próxima actualización
  • No entiendo qué tiene de maldito. La firma en el sitio de llamada difiere un poco de mi preferencia personal, pero uso este patrón por todos lados en mi propio código
    Por ejemplo, el lenguaje D trae incorporado el concepto de una sentencia que se ejecuta al final del scope
  • “El código es cómo tratas a tus colegas” - Michael Feather, https://x.com/mfeathers/status/1031176879577780224
    En resumen, no lo escribió una IA. Este código difiere la llamada a una función hasta el momento en que el objeto sale de scope. La implementación crea, mediante macros de C, una sintaxis más corta que omite parte de la definición necesaria de una lambda/función anónima de C, y genera un nombre de variable único para administrar la llamada diferida
    Sin embargo, la sintaxis resultante evita la convención habitual de escribir en mayúsculas lo que representa una macro de C y, a primera vista, parece una llamada a función sobre un puntero a objeto. Si no estás familiarizado con este patrón o esperas que las macros se indiquen de otra forma, puede resultar confuso
    Para algunas personas es lo bastante común y útil como para considerarlo casi un modismo en ciertos contextos. La explicación técnica en https://news.ycombinator.com/item?id=43959403#43960905 desglosa bien cómo funciona la macro

• Durante unas vacaciones hice ingeniería inversa de los escritorios virtuales de Windows, y eso mejoró muchísimo mis vacaciones. Mi mejor recuerdo del año pasado fue darme cuenta de que la ingeniería inversa es realmente divertida
  También aprendí muchas cosas interesantes; por debajo de RPC en Windows hay una capa de mensajería no documentada: https://csandker.io/2022/05/24/Offensive-Windows-IPC-3-ALPC....

• Cada vez confirmo que, si la foto de perfil es un personaje de anime, el post va a ser bueno. Lo guardo para cuando en el futuro tenga que volver a un entorno Windows bastante malo

• Para quien tenga curiosidad: WSC significa Windows Security Center. Yo también tuve que buscarlo

  • En el artículo dice: “La parte del sistema que gestiona este desastre se llama Windows Security Center, o WSC para abreviar”

• ¿Por qué alguien querría desactivar WSC?

  • Podría ser por rendimiento, o por desarrollo de malware o hacking
  • Si eres atacante, podrías apuntar a un caso afortunado en el que no haya instalado otro producto de detección y respuesta en endpoints. Si lo hay, casi seguro lo interceptará
    Si eres un proveedor de EDR, esto es una llamada de API ofuscada que puede usarse para suprimir o desactivar Windows Firewall. Por ejemplo, supongo que CrowdStrike puede tanto usar Windows Firewall como usar su propia implementación
  • Es mi hardware, así que hago lo que quiero con él
  • Todo software antivirus es, como mínimo, un powervirus. No quiero que alguien se meta como niñera a decirme que netcat.exe no se puede
  • Porque no hay razón para querer instalarte a propósito un rootkit a ti mismo

• Hace poco leí https://nostarch.com/windows-security-internals, y este artículo hizo que me cerrara mucho más
  Ya tenía una idea general de cómo funcionan estas cosas por detrás en Windows, pero llegó en el momento justo. El último capítulo de ese libro también profundiza bastante en tokens y SID, tal como lo trató el autor de este artículo