Wie ich meinen Urlaub mit WSC-Reverse-Engineering ruiniert habe

• Erfahrungsbericht über die Entwicklung von defendnot, einem Tool, das Windows Defender durch direkte Nutzung der Windows Security Center (WSC) Service API deaktiviert
• Das Projekt begann im Prozess, die technischen Grenzen und rechtlichen Probleme des früheren Projekts no-defender zu überwinden
• Reverse Engineering und Debugging wurden trotz zahlreicher Hindernisse wie einer besonderen Umgebung (MacBook arm64, Remote-Debugging, hohe Latenz) durchgeführt
• Die Umgehung der Defender-Registrierung und die Mechanismen zur Prozessvalidierung wurden analysiert und nach vielen Fehlschlägen und Versuchen so verbessert, dass alles stabil funktionierte
• Am Ende wurde sogar eine Autorun-Funktion fertig implementiert, während zugleich offen geschildert wird, wie belastend der Projektverlauf war

---

Einführung

• Erfahrungsbericht über den Implementierungsweg des Tools defendnot, das Windows Defender deaktiviert
• Statt einer Erklärung der wichtigsten technischen Details liegt der Schwerpunkt auf den Problemen in der Praxis und den mühsamen Fehlversuchen
• Eine formale Dokumentation und technische Erklärung sollen später separat veröffentlicht werden

Rückblick auf vor einem Jahr

• Vor etwa einem Jahr wurde ein Projekt namens no-defender veröffentlicht, das die Struktur nutzte, bei der Windows Defender über die WSC-API deaktiviert wird
• Das Projekt bezog sich auf Third-Party-Code eines Antivirus-Anbieters und täuschte das System so, als wäre ein anderes Antivirus-Programm registriert
• Nach der Veröffentlichung erhielt es große Aufmerksamkeit und etwa 1.500 Stars, doch wegen einer DMCA-Löschaufforderung des betreffenden Antivirus-Unternehmens wurde entschieden, den Quellcode zu entfernen und das Projekt einzustellen

Anlass für den Projektbeginn

• Zum Zeitpunkt des Verfassens dieses Textes wird in einem Airbnb in Seoul gewohnt
• Die Hauptentwicklungsumgebung ist ein M4Pro MacBook, und es wurde kein separates Gerät für notwendiges x86-Reverse-Engineering mitgenommen
• Wegen eines CTF-Wettbewerbs und Reiseplans musste ohne x86-Gerät gearbeitet werden
• Parallel zur Prüfung, ob das no-defender-Projekt auf eine „saubere“ Weise implementiert werden kann, wurde untersucht, ob eine eigenständige Implementierung unabhängig von AV möglich ist

Erste Untersuchung (Tag 1)

• Mit Hilfe eines Freundes wurde ein WSC-Binary beschafft, und es wurde versucht, die WSC-Registrierung in einer dem früheren Projekt ähnlichen Struktur neu zu implementieren
• Die Implementierung erfolgte über die COM API von WSC, jedoch trat ein Access Denied-Fehler auf
• Als Ursache wurde ermittelt, dass WSC bei API-aufrufenden Prozessen eine Signaturprüfung und Authentifizierung durchführt
• Als versucht wurde, die Registrierung durch Injektion eines Moduls in einen AV-Prozess vorzunehmen, wurde der AV-Eintrag erfolgreich registriert

Austausch des AV-Binarys und weitere Experimente (Tag 1)

• Es wurde versucht, das Tool über signierte Systemprozesse (cmd.exe usw.) auszuführen, doch dies scheiterte an der PPL-Validierung (Protected Process Light)
• Für die Analyse wurde eine detaillierte Disassemblierung und Nachverfolgung in Aussicht gestellt und die Arbeit vorübergehend unterbrochen

Aufbau der Umgebung (Tag 2)

• Aufgrund der Grenzen der arm64-MacBook-Umgebung war x86-Windows-Debugging äußerst schwierig
• Über die Fernnutzung des PCs eines in den USA lebenden Freundes (Parsec, AnyDesk usw.) wurden Debugging und Experimente unter hoher Latenz durchgeführt
• Im komplizierten Wechselspiel aus Code-Builds und VM-Debugging wurden Verlangsamung und Verwirrung erlebt

Debugging des WSC-Dienstes (Tag 2)

• Es wurde bestätigt, dass der WSC-Dienst als von svchost ausgeführte DLL aufgebaut ist
• Zur Aufhebung des PPL-Schutzes wurde mit einem speziellen Treiber ein Bypass angewendet, und mit dem Debugger wurde der Funktionsaufruf bestätigt
• Es wurde festgestellt, dass innerhalb des Dienstes eine Prüfung des WinDefend-SID-Tokens stattfindet
• Daraus wurde die Theorie entwickelt, das Authentifizierungsverfahren durch das Nachahmen eines Prozesses mit WinDefend-SID umgehen zu können

Nachahmung der WinDefend-SID (Tag 2)

• Es wurde zusätzlich die Token-Struktur und Funktionsweise von Windows gelernt
• Nach Implementierung und Ausführung von Code zur Nachahmung der WinDefend-SID gaben zwar alle COM-Aufrufe SUCCESS zurück, tatsächlich wurde aber kein AV-Eintrag registriert

Rekonstruktion des Validierungsalgorithmus (Tag 3)

• Es wurde vorsichtig erneut analysiert, ob die SID-Prüfung im AV-Binary wirklich bestanden wird
• Falls die SID-Prüfung fehlschlägt, prüft der Dienst zusätzlich erhöhten Berechtigungsstatus, die Binärsignatur und das DllCharacteristics-Flag (ForceIntegrity) der PE-Datei
• Die Funktion, die diese Struktur ausführt, wurde nachgebildet und auf core-Binaries im System experimentell angewendet

Nutzung des Taskmgr-Prozesses (Tag 3)

• Es wurde mit Taskmgr.exe als Zielprozess erneut getestet, doch wegen eines Fehlers bei der Namensübergabe und eines IPC-Bugs lehnte WSC die Anfrage ab
• Nach Verbesserung der Dateipfad-Ableitung und der Methode zur Übergabe des AV-Namens wurde ein normaler Betrieb bestätigt

Aufräumen des Codes (Tag 3)

• Die Funktionen wurden bereinigt und die Implementierung einer Autorun-Funktion versucht
• Bei der Verwaltung des automatischen Starts kam es zu sporadischen Fehlschlägen, weshalb Code und Umgebung wiederholt überprüft wurden, um die Ursache zu finden

Implementierung des automatischen Starts (Tag 4)

• Es wurde festgestellt, dass in den Optionen des Aufgabenplaners (Task Scheduler) das Kontrollkästchen gesetzt war, das verhindert, dass der Task ausgeführt wird, wenn das Notebook nicht an das Stromnetz angeschlossen ist
• Nach Deaktivierung dieser Einstellung funktionierte der automatische Start normal
• Abschließend wurden Code-Cleanup und Tests durchgeführt

Fazit

• Reverse Engineering unter eingeschränkten und unbequemen Bedingungen war psychisch und physisch eine sehr harte Erfahrung
• Eine detailliertere Dokumentation zur WSC-Implementierung soll später separat veröffentlicht werden

Danksagung

• Pindos: Ein Freund, der nachts seinen PC zur Verfügung stellte, beim Debugging half und das Zimmer warm hielt
• MrBruh: Ein Kollege, der den Anstoß gab, das Projekt zu erkunden, und Feedback zu Ideen lieferte
• Dank auch an die Bekannten, die während des Projekts in Kontakt blieben und Rückhalt gaben
• Es wird gestanden, dass Kimchi geliebt wird
• Dank auch an den Künstler, der Graffiti an unserer Wand hinterlassen hat

[GN⁺]

Hacker-News-Kommentare

• Die stärkste, aber auch invasivste Methode, Defender zu deaktivieren, besteht darin, von einem Live-Linux-USB zu booten, den Ordner C:\ProgramData\Microsoft\Windows Defender umzubenennen und an seiner Stelle eine leere Datei anzulegen
  • Weil Gruppenrichtlinien so gut funktionieren, habe ich in meinem Homelab einen Controller aufgesetzt und eine lokale Domain-Umgebung eingerichtet, die die Defender-Richtlinien für alle Benutzer automatisch ändert
  • Es ist seltsam, dass Windows kein signiertes Manifest hat, das eine solche Manipulation erkennt
  • Beliebte Produkte machen das im Grunde auch so und haben damit schon einmal etwa 25 % des gesamten Internets lahmgelegt
• Das Projekt bekam viel Aufmerksamkeit und etwa 1,5k Stars, doch danach schickte der Entwickler des Antivirenprogramms, das ich verwendet habe, eine DMCA-Anfrage. Ich verstehe nicht, welches „Antivirenprogramm, das ich verwendet habe“ gemeint ist und warum diese Person eine DMCA schickt. Vermutlich hat der Autor ein anderes Antivirenprogramm rückentwickelt und in Open Source eingebaut oder zumindest etwas gemacht, das WinDefend nachahmt. Es scheint ein Urheberrechtsproblem gegeben zu haben
  • So wie ich es verstehe, wurde die Hülle eines anderen AV-Tools genutzt, um die Signaturanforderungen zu umgehen. Das ist transformativ und möglicherweise vertretbar (ich bin kein Rechtsexperte), aber eine Grauzone
  • Ja, es wurden Teile eines bestehenden Antivirenprogramms kopiert und damit das Urheberrecht verletzt. Schon der direkt darüber zitierte Absatz erklärt, dass das Projekt Drittanbieter-Code eines bestehenden Antivirenprogramms verwendet hat, um AV bei WSC zu registrieren
• Zur Info: WSC steht für Windows Security Center
  • Danke für die Hilfe. Es ist wirklich frustrierend, wenn ein Akronym beim ersten Auftreten nicht erklärt wird
• Das hier ist wirklich bizarr: https://github.com/es3n1n/defendnot/… Falls es dich interessiert, was tatsächlich passiert, schau hier nach: https://github.com/es3n1n/defendnot/…
  • Ich frage mich, ob jemand, der sich gut mit CPP-Magie auskennt, erklären kann, warum dieser Code bizarr sein soll
  • Ich verstehe nicht, was daran seltsam sein soll. Ich nutze dieses Muster an vielen Stellen im Code sehr gern. Am Aufrufort ist die Signatur zwar anders (persönliche Vorliebe). Zur Info: In der Sprache D gibt es eingebaute Syntax, die beim Verlassen des Scopes ausgelöst wird
  • Ich hatte keine Zeit und es war mir zu lästig, für alle COM-Komponenten direkt ein eigenes RAII-Muster zu implementieren. Im nächsten Update werde ich das ändern
  • „Code ist wie man Kollegen behandelt“ - Michael Feather Kurz gesagt: keine AI Der Code dient dazu, einen Funktionsaufruf zu verzögern, bis der Scope eines Objekts endet. Er nutzt C-Makros, um komplexe Definitionen von C-Lambdas/anonymen Funktionen und die Erzeugung eindeutiger Variablennamen zu vereinfachen. Allerdings sind die Makros nicht in Großbuchstaben geschrieben und sehen wie Funktionsaufrufe aus, was für Ungeübte verwirrend sein kann. Für manche ist dieses Muster nützlich genug, dass es als idiomatisch gilt. Eine technische Erklärung findet sich im Link in einem anderen Kommentar
• Ich habe letztes Jahr beim Reverse Engineering der virtuellen Desktops von Windows meinen Urlaub großartig verbracht, und das ist eine tolle Erinnerung. Reverse Engineering macht wirklich Spaß. Ich habe viele interessante Dinge gelernt, zum Beispiel dass es innerhalb von Windows RPC eine undokumentierte Nachrichtenkommunikationsmethode gibt: https://csandker.io/2022/05/24/Offensive-Windows-IPC-3-ALPC.html
• Ich habe kürzlich https://nostarch.com/windows-security-internals gelesen, und das macht diesen Beitrag noch nachvollziehbarer. Ich wusste schon ungefähr, wie das Backend unter Windows funktioniert, aber das letzte Kapitel des Buches erklärt Token und SIDs so detailliert, wie der Autor sie behandelt hat
• Ich frage mich, warum man WSC deaktivieren möchte
  • Vermutlich aus Gründen der Performance oder für Malware-Entwicklung, Hacking und Ähnliches
  • Wenn man ein Threat Actor ist, hat man vielleicht Glück und es ist kein anderes EDR-Produkt installiert. Falls doch, wird man aber fast sicher blockiert. Als EDR-Anbieter könnte man das als verschleierten API-Aufruf verwenden, um die Windows-Firewall zu deaktivieren. Produkte wie CrowdStrike nutzen auch ihre eigene Firewall oder können die Windows-Firewall ersetzen
  • Jede Antivirensoftware ist zumindest Powervirus. Ich mag es nicht, wenn jemand überwacht, ob ich netcat.exe benutzen darf oder nicht
  • Es ist meine Hardware, also nutze ich sie so, wie ich will. So einfach ist das
  • Ich frage mich, warum man sich absichtlich ein Rootkit ins eigene System pflanzen möchte
• Für mich ist noch schlimmer, dass Check Point Harmony die eigentlich für Defender geschaffene Schnittstelle überhaupt nicht nutzt, sondern die Nutzer in einem Knowledge-Base-Artikel anweist, Defender direkt zu deaktivieren
• Falls es jemanden interessiert: WSC steht für Windows Security Center. Ich musste es auch erst nachschlagen
  • Die Formulierung „All dies wird vom Windows Security Center-WSC verwaltet“ steht im Artikel
• Zu der Aussage „Ich arbeite auf einem arm64 MacBook, daher gibt es derzeit keine vernünftige Möglichkeit, x86-Windows auf einem ARM-MacBook zu emulieren“ wurde gefragt, wie es mit UTM aussieht, und erwähnt, dass Parallels vor Kurzem Unterstützung für Intel-VMs eingeführt hat
  • Ich habe UTM ausprobiert, aber für x86-Windows war es unbenutzbar. Eine Kommandozeilen-Linux-Umgebung könnte mit akzeptabler Geschwindigkeit gerade noch gehen, aber mit GUI ist es unmöglich. arm64-Windows läuft gut, aber das ist eben kein x86-Windows und daher für Reverse Engineering von x86-Systemkomponenten nutzlos
  • Das Dynamic-Recompilation-System von QEMU ist nicht so effizient wie die nativen Systeme unter Windows oder macOS (Rosetta 2). x86-Windows läuft in UTM zwar, aber die Performance ist sehr schlecht. In der Praxis scheint es besser zu sein, x86-Apps in einer ARM-Windows-VM über den Dynamic Recompiler von Windows laufen zu lassen oder WINE zu verwenden, das auf nativen Code-Subsystemen basiert. Für schnelle, einfache Arbeiten mag es reichen. Wenn der OP mit „vernünftig“ auch Performance meint, ist diese Haltung nachvollziehbar
  • Korrigiert mich, wenn ich falsch liege, aber die Emulation einer CPU mit MMU ist grundsätzlich langsam und schwer zu optimieren. Apples Rosetta und Microsofts entsprechende Technik sind schnell, weil sie nur User-Space-Code ausführen. Die MMU-Emulation eines kompletten Systems wird dabei vermieden