zhoucc-cpu/cve-2023-23397-detection-labForschungslabor für Erkennung und Eindämmung von CVE-2023-23397 mithilfe von Netzwerk- und Endpoint-Sicherheitstelemetrie.
Dieses Projekt ist ein defensives Cybersicherheits-Forschungslabor, das sich auf das Netzwerkverhalten im Zusammenhang mit CVE-2023-23397 konzentriert.
Das Projekt untersucht verdächtige ausgehende SMB- und NTLM-Authentifizierung von einem Windows-Endpunkt und demonstriert einen vollständigen defensiven Workflow:
Baseline
-> Netzwerkbeobachtung
-> NTLM-Erkennung
-> Alarmgenerierung
-> Gateway-Mitigation
-> Host-Mitigation
-> Validierung
Das Labor ist vollständig isoliert und verwendet ausschließlich Systeme, die für autorisierte Sicherheitstests im Eigentum stehen und kontrolliert werden.
Dieses Repository ist als reproduzierbare defensive Sicherheitsstudie organisiert und nicht als Exploit-Demonstration. Seine zentrale Forschungsfrage lautet:
Können SMB/NTLM-Protokollsemantik und Netzwerkvertrauensgrenzen anomales ausgehendes Authentifizierungsverhalten im Zusammenhang mit CVE-2023-23397 erkennen, und wie unterscheiden sich hostseitige und gatewayseitige Mitigationen hinsichtlich Blockierungsverhalten und Sensor-Sichtbarkeit?
Die Studie bewertet vier Fragen:
Das Projekt validiert erzwungenes ausgehendes SMB/NTLM-Verhalten im Zusammenhang mit CVE-2023-23397 sowie die entsprechenden Erkennungs- und Mitigationskontrollen. Es beweist nicht, dass Outlook eine bösartige MAPI-Nachricht verarbeitet hat oder dass CVE-2023-23397 ausgenutzt wurde.
| Dokument | Zweck |
|---|---|
report/project-report.md | Hauptforschungsbericht mit Fragen, Design, Ergebnissen, Diskussion und Einschränkungen |
docs/literature-review.md | Überprüfung maßgeblicher Arbeiten zu Schwachstelle, Forced Authentication, NTLM, Zeek und Firewall-Kontrollen |
docs/research-methodology.md | Topologie, Variablen, Kontrollen, Verfahren, Evidenzquellen und Gültigkeitsgrenzen |
docs/live-validation-2026-09-11.md | Genaue Beobachtungen der Live-Validierung und finaler Laborzustand |
evidence/validation-20260911/ | PCAPs, Logs, Integritätsmanifest und maschinenlesbare Verifikationszusammenfassung |
scripts/verify_validation_evidence.py | Schreibgeschützte automatisierte Konsistenzprüfungen der Evidenz |
Die primären Ziele dieses Projekts sind:
Das Labor enthält drei virtuelle Maschinen.
| System | Rolle | Adresse |
|---|---|---|
| Windows-Victim | Geschützter Windows-Endpunkt | 10.10.20.10/24 |
| Ubuntu-Sensor | Router und Zeek-Sicherheitssensor | 10.10.20.1/24, 10.10.30.1/24 |
| Kali-Adversary | Kontrolliertes SMB-Ziel | 10.10.30.10/24 |
Logischer Datenverkehrspfad:
Windows-Victim
10.10.20.10
|
| VICTIM_NET
|
Ubuntu-Sensor
10.10.20.1 / 10.10.30.1
|
| ATTACK_NET
|
Kali-Adversary
10.10.30.10
Die Opfer- und Angreifernetze sind voneinander isoliert.
Der Datenverkehr zwischen ihnen muss Ubuntu-Sensor durchlaufen, damit der Sensor die Kommunikation beobachten und kontrollieren kann.
Ein separates VMware-Managementnetz wird für den administrativen SSH-Zugriff auf Ubuntu-Sensor verwendet.
Weitere Informationen:
lab/network-plan.md
CVE-2023-23397 steht im Zusammenhang mit erzwungenem ausgehendem Authentifizierungsverhalten bei Microsoft Outlook.
Das sicherheitsrelevante Verhalten ist ein Windows-System, das versucht, sich gegenüber einer vom Angreifer kontrollierten Netzwerkressource zu authentifizieren.
Dieses Labor konzentriert sich auf das beobachtbare Netzwerkverhalten:
Windows endpoint
-> outbound TCP/445
-> SMB negotiation
-> NTLM authentication
-> network detection
Das Labor erhebt nicht den Anspruch, dass jedes erzeugte SMB-Ereignis eine Ausnutzung der Outlook-Schwachstelle darstellt.
Stattdessen wird kontrollierter SMB- und NTLM-Datenverkehr genutzt, um defensive Erkennungslogik sicher zu entwickeln und zu validieren.
Detaillierte Analyse:
docs/attack-flow.md
Primäre Technik:
T1187 - Forced Authentication
Primäre Taktik:
Credential Access
Das Projekt konzentriert sich auf die Erkennung und Verhinderung verdächtiger ausgehender Authentifizierung von einer geschützten Workstation zu einem nicht vertrauenswürdigen Ziel.
Die erste Phase etablierte normale geroutete Kommunikation zwischen dem Windows-Opfer und dem kontrollierten Angreifer.
Baseline-Paketmitschnitte und Zeek-Verbindungsprotokolle wurden erfasst, bevor die Erkennungslogik eingeführt wurde.
Dies lieferte einen Referenzpunkt für spätere Vergleiche.
Analyse:
docs/baseline-traffic-analysis.md
Ein kontrollierter SMB-Server wurde auf Kali-Adversary gehostet.
Windows-Victim griff erfolgreich zu:
\\10.10.30.10\SHARE
Zeek hat erfolgreich geparst:
Die Baseline zeigte, dass der Sensor den vollständigen Authentifizierungspfad beobachten konnte, bevor benutzerdefinierte Erkennungslogik eingeführt wurde.
Analyse:
docs/smb-baseline-analysis.md
Ein benutzerdefinierter Zeek-Detektor wurde entwickelt:
detections/zeek/cve_2023_23397_ntlm.zeek
Der Detektor erzeugt:
CVE23397::Suspicious_Outbound_NTLM
Die Regel wertet vier Hauptbedingungen aus:
Dies liefert mehr Kontext als eine reine Alarmierung auf TCP/445.
Erkennungslogik:
Victim network
+
Untrusted destination
+
TCP/445
+
NTLM Authenticate
=
Suspicious outbound NTLM notice
Ein Unterdrückungsintervall von fünf Minuten wird verwendet, um doppelte Benachrichtigungen bei wiederholter Authentifizierung gegenüber demselben Ziel zu reduzieren.
Der benutzerdefinierte Detektor wurde erfolgreich mit kontrolliertem SMB- und NTLM-Datenverkehr validiert.
Das validierte Ereignis zeigte die Korrelation zwischen:
Eine validierte Warnung enthielt:
CVE23397::Suspicious_Outbound_NTLM
Die Erkennungsanalyse und die integritätsgeprüften Beweise sind dokumentiert in:
docs/ntlm-detection-analysis.md
Die erste Mitigation wurde auf Ubuntu-Sensor angewendet.
Das Gateway blockierte weitergeleiteten TCP/445-Verkehr von:
10.10.20.10
zu:
10.10.30.10:445
Nachdem die Regel aktiviert wurde: