yamato-security/enablewindowslogsettingsDokumentation und Skripte zur ordnungsgemäßen Aktivierung von Windows-Ereignisprotokollen.
Dies ist ein weiterer Leitfaden zur ordnungsgemäßen Konfiguration und Überwachung von Windows-Ereignisprotokollen mit dem Schwerpunkt auf der Protokollierung für Sigma-Regeln.
Dies ist ein Work in Progress. Schauen Sie bitte regelmäßig nach Aktualisierungen vorbei.
Zach Mathis (@yamatosecurity). Da ich weitere Forschung und Tests durchführe, habe ich vor, dies regelmäßig zu aktualisieren, da es viel Raum für Verbesserungen gibt (sowohl in der Dokumentation als auch bei der Erstellung weiterer Erkennungsregeln). PRs sind willkommen, und ich nehme Sie gerne als Mitwirkenden auf. Wenn Sie Fehler in dieser Dokumentation finden, lassen Sie es mich bitte wissen, und ich werde sie so schnell wie möglich beheben.
Wenn Sie etwas davon nützlich finden, geben Sie dem Repository bitte einen Stern auf GitHub, da mich das wahrscheinlich motivieren wird, dies weiter zu aktualisieren.
Der Großteil der Informationen stammt aus Microsofts Advanced security auditing FAQ, den sigma-Regeln, dem ACSC Event Logging Guide sowie meiner eigenen Forschung und meinen Tests. Ich möchte insbesondere der sigma-Community danken, dass sie die Erkennung von Bedrohungen Open Source und kostenlos zum Nutzen aller Verteidiger gemacht hat.
Standardmäßig protokolliert Windows viele Ereignisse nicht, die zum Erkennen bösartiger Aktivitäten und für forensische Untersuchungen erforderlich sind.
Außerdem beträgt die standardmäßige maximale Größe für Ereignisdateien nur 20 MB für die klassischen Ereignisprotokolle (Security, System, Application), 15 MB für PowrShell und nur 1 MB für fast alle anderen Protokolle, sodass eine gute Chance besteht, dass Beweise im Laufe der Zeit überschrieben werden.
In diesem Repository wird ein einfaches Batch-Skript bereitgestellt, mit dem Systemadministratoren ihre Windows-Rechner einfach konfigurieren können, sodass sie bei einem Vorfall über die Protokolle verfügen, die sie benötigen. Für große Netzwerke sollten Sie dieses Dokument wahrscheinlich als Referenz verwenden und Ihre Endpunkte mit Gruppenrichtlinien und/oder InTune konfigurieren.
Ich empfehle nachdrücklich, die standardmäßigen Windows-Ereignisprotokoll-Einstellungen zu verbessern, und gebe mein Bestes, um die genauesten Informationen bereitzustellen. Ich übernehme jedoch keinerlei Verantwortung für nachteilige Auswirkungen einer übermäßigen Protokollierung oder für die Richtigkeit der Inhalte dieses Repositorys. Es liegt in Ihrer Verantwortung, alle Änderungen, die Sie an Ihren Systemen vornehmen, zu verstehen und auf Testmaschinen zu testen, bevor Sie sie in der Produktion ausrollen. Ich empfehle, auf Testmaschinen, die Ihre Umgebung nachbilden, mindestens eine Woche lang so viel Protokollierung wie möglich zu aktivieren und dann zu prüfen, ob es Ereignisse gibt, die zu viel Rauschen erzeugen, oder ob es Ereignisse gibt, die Sie möchten, aber nicht erzeugt werden.
Sie können die Gesamtzahl und den Prozentsatz der Ereignis-IDs in einer evtx-Datei mit dem Befehl für Ereignis-ID-Metriken von Hayabusa anzeigen.
Beispiel: hayabusa.exe eid-metrics -f path/to/Security.evtx
Process Creation (Prozesserstellung), das nachverfolgt, welche Prozesse auf einem System ausgeführt werden.
Derzeit stützt sich etwa die Hälfte der Erkennungsregeln von Sigma auf dieses Ereignis.
Dies kann durch die Installation von Sysmon (Ereignis-ID 1) oder durch die Aktivierung der integrierten Security-Protokoll-Ereignis-ID 4688 erreicht werden.
Sysmon 1 liefert detaillierte Informationen wie Hashes und Metadaten der ausführbaren Datei und ist daher ideal. Falls Sysmon jedoch nicht installiert werden kann, ist es möglich, die integrierten Security 4688-Protokolle zu verwenden. Es ist jedoch wichtig, dass auch die Befehlszeilenprotokollierung aktiviert ist, da viele Erkennungsregeln darauf angewiesen sind. Leider liefert Security 4688 nicht so detaillierte Informationen wie die Sysmon-Prozesserstellungsprotokolle, sodass nicht alle Process Creation-Regeln mit Security 4688 funktionieren.
Nur etwa 10~20 % der Sigma-Regeln können mit den standardmäßigen Windows-Überwachungseinstellungen verwendet werden!
Dies ist im großen Maßstab nicht praktikabel, aber der einfachste Weg, Protokolle zu aktivieren/deaktivieren und ihre maximale Dateigröße zu prüfen und/oder zu konfigurieren, ist ein Rechtsklick auf das Protokoll in der Ereignisanzeige und das Öffnen von Properties.
Sie können den integrierten wevtutil-Befehl verwenden.
Beispiel: wevtutil sl Security /ms:1073741824, um die maximale Dateigröße für das Security-Protokoll auf 1 GB zu erhöhen.
Beispiel:```powershell $sysmon = Get-WinEvent -ListLog Microsoft-Windows-Sysmon/Operational $sysmon.MaximumSizeInBytes = 2048000000 #2GB $sysmon.SaveChanges()
## Option 4: Gruppenrichtlinie
Es ist unkompliziert, die maximale Dateigröße für die klassischen Ereignisprotokolle wie `Security`, `System` und `Application` zu erhöhen, jedoch müssen Sie leider Administrative Vorlagen installieren und/oder die Registry direkt ändern, um die maximale Dateigröße für die anderen Protokolle zu ändern. Es könnte einfacher sein, die Dateigröße mit einem Batch- oder PowerShell-Skript beim Start zu erhöhen.
# Konfigurationsskript
Ein Skript zum Erhöhen der maximalen Dateigröße und zum Aktivieren der richtigen Protokolle finden Sie hier: [YamatoSecurityConfigureWinEventLogs.bat](https://github.com/yamato-security/enablewindowslogsettings/blob/main/YamatoSecurityConfigureWinEventLogs.bat)
# Konfigurieren der Protokolleinstellungen
## Sysmon-Protokoll (1382 Sigma-Regeln)
Datei: `Microsoft-Windows-Sysmon%4Operational.evtx`
Standard: `Nicht installiert`
Die Installation und Konfiguration von Sysmon ist das Beste, was Sie tun können, um Ihre Sichtbarkeit auf Windows-Endpunkten zu erhöhen, aber es erfordert Planung, Tests und Wartung.
Das ist ein eigenes großes Thema, daher fällt es derzeit aus dem Rahmen dieses Dokuments.
Schauen Sie sich bitte die folgenden Ressourcen an:
* [TrustedSec Sysmon Community Guide](https://github.com/trustedsec/SysmonCommunityGuide)
* [Sysmon Modular](https://github.com/olafhartong/sysmon-modular)
* [Florian Roth's updated fork of the Swift On Security's sysmon config file](https://github.com/Neo23x0/sysmon-config)
* [Ion-storm's updated fork of the Swift On Security's sysmon config file](https://github.com/ion-storm/sysmon-config)
* [Cyb3rWard0g's sysmon config file](https://github.com/OTRF/Blacksmith/blob/master/resources/configs/sysmon/sysmon.xml)
## Sicherheitsprotokoll (1045 Sigma-Regeln (903 Prozesserstellungsregeln + 142 andere Regeln))
Datei: `Security.evtx`
Standard: `Teilweise aktiviert`
Das Sicherheitsprotokoll ist am komplexesten zu konfigurieren, daher habe ich ein separates Dokument dafür erstellt: [ConfiguringSecurityLogAuditPolicies.md](https://github.com/yamato-security/enablewindowslogsettings/blob/main/ConfiguringSecurityLogAuditPolicies.md)
## PowerShell-Protokolle (175 Sigma-Regeln)
Datei: `Microsoft-Windows-PowerShell%4Operational.evtx`
### Modulprotokollierung (30 Sigma-Regeln)
Das Aktivieren der Modulprotokollierung aktiviert die Ereignis-ID `4103`.
Die Modulprotokollierung hat den Vorteil, dass sie auf älteren Betriebssystemen und PowerShell-Versionen ausgeführt werden kann: PowerShell 3.0 (Win 7+).
Ein weiterer Vorteil ist, dass sowohl der ausgeführte PowerShell-Befehl als auch die Ergebnisse protokolliert werden.
Der Nachteil ist, dass eine extrem hohe Anzahl von Ereignissen erzeugt wird.
Wenn ein Angreifer zum Beispiel Mimikatz ausführt, erzeugt es 7 MB Protokolle mit über 2000 Ereignissen!
#### Aktivieren der Modulprotokollierung
Standard: `Keine Überwachung`
##### Option 1: Aktivieren über die Gruppenrichtlinie
Öffnen Sie im Gruppenrichtlinien-Editor (`gpedit.msc`) den Pfad `Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell` und aktivieren Sie `Turn on Module Logging`.
Klicken Sie im Bereich `Options` auf die Schaltfläche `Show...`, um zu konfigurieren, welche Module protokolliert werden sollen.
Geben Sie `*` in das Textfeld `Value` ein, um alle Module aufzuzeichnen.
##### Option 2: Aktivieren über die Registry```
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging → EnableModuleLogging = 1
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging\ModuleNames → * = *
Standard-Einstellungen: On Win 10/2016+, if a PowerShell script is flagged as suspicious by AMSI, it will be logged with a level of Warning.
Das Aktivieren der Script-Block-Protokollierung aktiviert die Ereignis-ID 4104. Wenn Sie Log script block invocation start / stop events aktivieren, werden auch die EIDs 4105 und 4106 aktiviert, was jedoch nicht empfehlenswert ist, da dadurch nur Rauschen erzeugt wird.
Script-Block-Protokollierung wird standardmäßig in PowerShell 5.0+ (Win 10+) unterstützt, Sie können sie jedoch auf älteren Betriebssystemen (Win 7+) aktivieren, wenn Sie .NET 4.5 und WMF 4.0+ installieren.
Leider beträgt die maximale Größe eines einzelnen Windows-Ereignisprotokolls 32 KB, sodass alle PowerShell-Skripte, die größer sind, in 32-KB-Blöcke fragmentiert werden.
Wenn Sie die ursprüngliche Datei PowerShell Operational.evtx haben, können Sie das Tool block-parser verwenden, um diese Protokolle in eine einzige leicht lesbare Textdatei zu entfragmentieren.
Ein Vorteil der Script-Block-Protokollierung ist, dass selbst wenn ein bösartiges Skript mit XOR, Base 64, ROT13 usw. verschleiert wird, das decodierte Skript protokolliert wird, was die Analyse erheblich erleichtert.
Die Protokolle sind einfacher zu handhaben als die Modulprotokollierung, da bei der Ausführung von Mimikatz durch einen Angreifer nur 5 MB und 100 Ereignisse erzeugt werden, verglichen mit 7 MB und über 2000 Ereignissen.
Allerdings werden die Ausgaben der Befehle bei der Script-Block-Protokollierung nicht aufgezeichnet.
Öffnen Sie im Gruppenrichtlinien-Editor Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell und aktivieren Sie Turn on PowerShell Script Block Logging.
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1
Standard-Einstellungen: No Auditing
Mit Transkriptionsprotokollen ist es auch möglich, PowerShell-Protokolle als Textdateien auf dem lokalen Computer zu speichern. Obwohl ein Angreifer die Transkriptionsprotokolle für Anti-Forensik in der Regel leicht löschen kann, gibt es Szenarien, in denen der Angreifer alle Ereignisprotokolle löscht, aber nicht nach Transkriptionsprotokollen sucht, die gelöscht werden könnten. Daher wird empfohlen, wenn möglich ebenfalls Transkriptionsprotokolle zu aktivieren. Standardmäßig werden sie im Dokumentenordner des Benutzers gespeichert. Idealerweise sollten Transkriptionsprotokolle in einer Nur-Schreib-Netzwerkfreigabe gespeichert werden, was in der Praxis jedoch schwer umzusetzen sein kann. Ein Vorteil von Transkriptionsprotokollen ist, dass sie den Zeitstempel und Metadaten für jeden Befehl enthalten und sehr speichereffizient sind: Weniger als 6 KB für die Ausführung von Mimikatz. Der Nachteil ist, dass die Transkriptionsprotokolle nur das aufzeichnen, was im PowerShell-Terminal angezeigt wird.
Öffnen Sie im Gruppenrichtlinien-Editor Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell und aktivieren Sie Turn on PowerShell Transcription.
Geben Sie dann das Ausgabeverzeichnis an.
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → EnableTranscripting = 1 HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → EnableInvocationHeader = 1 HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → OutputDirectory = “” (Enter path. Empty = default)
### Referenzen
* [Mandiant Blog: Mehr Sichtbarkeit durch PowerShell-Protokollierung](https://www.mandiant.com/resources/blog/greater-visibilityt)
## Systemprotokoll (55 Sigma-Regeln)
Datei: `System.evtx`
Standardeinstellungen: `Aktiviert. 20 MB`
Empfohlene Einstellungen: `Aktiviert. 128 MB+`
Malware installiert häufig Dienste für Persistenz, lokale Rechteausweitung usw., die in diesem Protokoll gefunden werden können.
Es ist auch möglich, hier die Ausnutzung verschiedener Sicherheitslücken zu erkennen.
> **Hinweis: Eine Sache, auf die Sie beim Systemprotokoll achten sollten, ist, dass Parameter in Feldern manchmal in die lokale Sprache übersetzt werden, sodass Signaturen, die nur Englisch verwenden, auf nicht-englischen Systemen möglicherweise nicht erkennen. Beispielsweise wird auf einem englischen System in den Parametern für EID 7045 `Enabled` aufgezeichnet, während auf Japanisch möglicherweise `有効` aufgezeichnet wird.**
> **Hinweis: Ebenso wie beim `Application`-Protokoll verwenden mehrere Anbieter dieselbe Ereignis-ID, sodass Sie möglicherweise sowohl nach dem Anbieternamen als auch nach dem Kanal filtern müssen. Ein Beispiel ist die Ereignis-ID `1`, die von verschiedenen Anbietern für unterschiedliche Ereignisse verwendet wird.**
Wichtige Ereignis-IDs:
| Ereignis-ID | Beschreibung | Sigma-Regeln | Hayabusa-Regeln | Stufe | Hinweise |
| :---: | :---: | :---: | :---: | :---: | :---: |
| 1 | System-Standby/Ruhezustand | 0 | Noch nicht. | Info | Anbieter: `Power-Troubleshooter` |
| 1 | Systemzeit geändert | 0 | Noch nicht. | Info | Anbieter: `Kernel-General` |
| 12 | Systemstart | 0 | Noch nicht. | Info | |
| 13 | Systemherunterfahren | 0 | Noch nicht. | Info | |
| 16 | Registry-Hive-Zugriffsverlauf gelöscht | 2 | Noch nicht. | High~Crit | Passwort-Dumper können den Zugriffsverlauf löschen, nachdem sie Passwort-Hashes aus dem SAM-Registrierungsschlüssel ausgelesen haben. Dies passiert aber auch normalerweise, daher müssen Fehlalarme herausgefiltert werden. |
| 55 | NTFS-Dateisystem beschädigt | 1 | Nein | High | Kann Angriffe gegen NTFS-Sicherheitslücken erkennen. |
| 104 | Systemereignisprotokoll gelöscht | 1 | Ja | Med | |
| 6005 | Ereignisprotokoll-Dienst gestartet | 0 | Ja | Info | |
| 6006 | Ereignisprotokoll-Dienst beendet | 0 | Ja | Info | |
| 6008 | Unerwartetes Herunterfahren | 0 | Ja | Info | |
| 6038 | NTLMv1 wurde verwendet | 1 | Nein | Low | |
| 7031 | Dienst abgestürzt | 0 | Ja | Low | |
| 7034 | Dienst abgestürzt | 0 | Ja | Low | |
| 7036 | Dienst gestartet/beendet | 2 | Ja | Info~High | Kann verwendet werden, um zu erkennen, wenn jemand Defender stoppt usw. |
| 7040 | Starttyp des Dienstes geändert | 0 | Ja | Info | Kann darauf hindeuten, dass ein Angreifer einen Dienst deaktiviert hat. |
| 7045 | Dienstinstallation | 37 | Ja | Info~Crit | Dies ist die wichtigste System-Ereignis-ID, da sich Malware häufig selbst als Dienst installiert oder Dienste missbraucht. |
| 20001 | Neues PNP-Gerät | 0 | Ja | Info~? | Die Stufe hängt davon ab, ob USB-Geräte erlaubt sind oder nicht. Protokolliert nur das erste Mal, wenn ein Gerät angeschlossen wurde. Nicht-USB-PNP-Geräteereignisse erzeugen sehr viel Rauschen und sollten wahrscheinlich herausgefiltert werden. |
## Anwendungsprotokoll (16 Sigma-Regeln)
Dieses Protokoll besteht größtenteils aus Rauschen, aber Sie können hier möglicherweise wichtige Beweise finden.
Einige Antivirenprogramme von Drittanbietern protokollieren hier.
Beim Anwendungsprotokoll ist zu beachten, dass verschiedene Anbieter dieselben Ereignis-IDs für unterschiedliche Ereignisse verwenden. Sie sollten daher nicht nur nach Ereignis-IDs, sondern auch nach Anbieternamen filtern.
Datei: `Application.evtx`
Standardeinstellungen: `Aktiviert. 20 MB`
Empfohlene Einstellungen: `Aktiviert. 128 MB+`
Wichtige Ereignis-IDs:
| Ereignis-ID | Anbieter | Beschreibung | Sigma-Regeln | Hayabusa-Regeln | Stufe | Hinweise |
| :---: | :---: | :---: | :---: | :---: | :---: | :---: |
| 1 | `Audit-CVE`, `Microsoft-Windows-Audit-CVE` | Exploit-Versuch einer bekannten Sicherheitslücke (CVE) | 1 | Nein | Critical | Erkennt Ereignisse, die von Benutzermodus-Anwendungen erzeugt werden, wenn sie die CveEventWrite-API aufrufen, während versucht wird, eine bekannte Sicherheitslücke auszunutzen. Microsoft begann 2020/01 mit CVE-2020-0601 (einer Windows-CryptoAPI-Sicherheitslücke) mit der Verwendung dieses Protokolls. Leider ist das so ziemlich der einzige Fall, in dem CVEs in dieses Protokoll geschrieben werden. |
| 325 | `ESENT` | ESE-DB erstellt | 2 | Nein | Info~Crit | Erkennt, wenn ein Prozess eine ESE-Datenbank erstellt. Diese wird für verschiedene Dinge verwendet, z. B. für Exchange, AD, Zertifikatdienste, SRUM usw. Die wichtigste ESE-DB für die Sicherheit ist NTDS.dit, die Datei mit den Passwort-Hashes aller Domänenbenutzer auf Domänencontrollern. Es gibt zwei Sigma-Regeln zur Erkennung des Auslesens von NTDS.dit; es kann jedoch zu einem Fehlalarm kommen, wenn ein Administrator ntdsutil für Backups verwendet oder wenn Schattenkopien erstellt werden. |
| 326 | `ESENT` | ESE-DB angehängt | 1 | Nein | Info~Crit | Kann möglicherweise den Zugriff auf NTDS.dit erkennen. |
| 1000, 1001 | `Application Error`, `Windows Error Reporting` | Anwendungsfehler | 1 | Nein | Info~High | |
| 1034, 11724 | `MsiInstaller` | Anwendung deinstalliert | 1 | Nein | Info~Low | |
| 1040 | `MsiInstaller` | Anwendungsinstallation | 1 | Nein | Info~Med | |
| 33205 | `MSSQLSERVER` | SQL-Überwachungsereignis | 6 | Nein | Info~High | Kann MSSQL-Hintertüren, SQL-/Befehlsinjektion usw. erkennen. |
## Windows Defender-Betriebsprotokoll (10 Sigma-Regeln)
Datei: `Microsoft-Windows-Windows Defender%4Operational.evtx`
Standardeinstellungen: `Aktiviert. 1 MB`
Empfohlene Einstellungen: `Aktiviert. 128 MB+`
Sie können nicht nur Windows Defender-Warnungen erkennen (die wichtig zu überwachen sind), sondern auch hinzugefügte Ausschlüsse, deaktivierten Manipulationsschutz, gelöschten Verlauf usw.
## Bits-Client-Betriebsprotokoll (6 Sigma-Regeln)
Datei: `Microsoft-Windows-Bits-Client%4Operational.evtx`
Standardeinstellungen: `Aktiviert. 1 MB`
Empfohlene Einstellungen: `Aktiviert. 128 MB+`
Bitsadmin.exe ist ein beliebtes [lolbin](https://lolbas-project.github.io/lolbas/Binaries/Bitsadmin/), das Angreifer zum Herunterladen und Ausführen von Malware missbrauchen.
Sie können hier möglicherweise Hinweise darauf finden, obwohl es viele Fehlalarme zu beachten gibt.
## Firewall-Protokoll (6 Sigma-Regeln)
Datei: `Microsoft-Windows-Windows Firewall With Advanced Security%4Firewall.evtx`
Standardeinstellungen: `Aktiviert? 1 MB`
Empfohlene Einstellungen: `Aktiviert. 256 MB+`
Hier finden Sie Hinweise auf hinzugefügte/geänderte/gelöschte Firewallregeln.
Malware fügt häufig Firewallregeln hinzu, um sicherzustellen, dass sie mit ihrem C2-Server kommunizieren kann, fügt Proxyregeln für seitliche Bewegungen hinzu usw.
## NTLM-Betriebsprotokoll (3 Sigma-Regeln)
Datei: `Microsoft-Windows-NTLM%4Operational.evtx`
Standardeinstellungen: `Aktiviert, aber Überwachung ist deaktiviert. 1 MB`
Dieses Protokoll sollte aktiviert werden, wenn Sie die NTLM-Authentifizierung deaktivieren möchten.
Das Deaktivieren von NTLM wird höchstwahrscheinlich einige Kommunikationen unterbrechen. Sie können dieses Protokoll auf den DCs und anderen Servern überwachen, um zu sehen, wer NTLM weiterhin verwendet, und NTLM schrittweise für diese Benutzer deaktivieren, bevor Sie es global deaktivieren.
Es ist möglich, die NTLM-Nutzung für eingehende Verbindungen in Anmeldeereignissen wie 4624 zu erkennen, aber Sie müssen dieses Protokoll aktivieren, wenn Sie überwachen möchten, wer ausgehende NTLM-Verbindungen herstellt.
Zum Aktivieren der Überwachung öffnen Sie in der Gruppenrichtlinie `Computerkonfiguration > Richtlinien > Windows-Einstellungen > Sicherheitseinstellungen > Lokale Richtlinien > Sicherheitsoptionen` und konfigurieren Sie die entsprechenden verschiedenen `Netzwerksicherheit: NTLM einschränken:`-Einstellungen.
Referenz: [Farewell NTLM](https://www.scip.ch/en/?labs.20210909)
## Security-Mitigations KernelMode- und UserMode-Protokolle (2 Sigma-Regeln)
Dateien: `Microsoft-Windows-Security-Mitigations%4KernelMode.evtx`, `Microsoft-Windows-Security-Mitigations%4UserMode.evtx`
Standardeinstellungen: `Aktiviert. 1 MB`
Empfohlene Einstellungen: `Aktiviert. 128 MB+`
Derzeit gibt es nur 2 Sigma-Regeln für diese Protokolle, aber Sie sollten wahrscheinlich alle Protokolle für Exploit-Schutz, Netzwerkschutz, kontrollierten Ordnerzugriff und Angriffsflächenverkleinerung erfassen und überwachen (ca. 40+ Ereignis-IDs).
Leider sind die Protokolle zur Angriffsflächenverkleinerung (früher WDEG (Windows Defender Exploit Guard) und EMET) auf mehrere Protokolle verteilt und erfordern komplexe XML-Abfragen, um sie zu durchsuchen.
Details: [Grundlegendes zu den Funktionen zur Angriffsflächenverkleinerung und deren Verwendung](https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/overview-attack-surface-reduction?view=o365-worldwide)
## PrintService-Protokolle (2 Sigma-Regeln)
Es wird empfohlen, auch das Betriebsprotokoll zu aktivieren, um Angriffe auf den Druckspooler zu erkennen. (z. B. PrintNightmare usw.)
### Admin (1 Sigma-Regel)
Datei: `Microsoft-Windows-PrintService%4Admin.evtx`
Standardeinstellungen: `Aktiviert. 1 MB`
Empfohlene Einstellungen: `Aktiviert. 128 MB+`
### Operational (1 Sigma-Regel)
Datei: `Microsoft-Windows-PrintService%4Operational.evtx`
Standardeinstellungen: `Deaktiviert. 1 MB`
Empfohlene Einstellungen: `Aktiviert. 128 MB+`
## SMBClient-Sicherheitsprotokoll (2 Sigma-Regeln)
Datei: `Microsoft-Windows-SmbClient%4Security.evtx`
Standardeinstellungen: `Aktiviert. 8 MB`
Empfohlene Einstellungen: `Aktiviert. 128 MB+`
Wird verwendet, um zu versuchen, PrintNightmare (verdächtige abgelehnte SMB-Gastanmeldung von IP) und Benutzer zu erkennen, die versteckte Freigaben einbinden.
## AppLocker-Protokolle (1 Sigma-Regel)
Dateien: `Microsoft-Windows-AppLocker%4MSI and Script.evtx`, `Microsoft-Windows-AppLocker%4EXE and DLL.evtx`, `Microsoft-Windows-AppLocker%4Packaged app-Deployment.evtx`, `Microsoft-Windows-AppLocker%4Packaged app-Execution.evtx`
Standardeinstellungen: `Aktiviert, wenn AppLocker aktiviert ist? 1 MB`
Empfohlene Einstellungen: `Aktiviert. 256 MB+`
Es ist wichtig, sicherzustellen, dass dies aktiviert und überwacht wird, wenn Sie AppLocker verwenden.
## CodeIntegrity-Betriebsprotokoll (1 Sigma-Regel)
Datei: `Microsoft-Windows-CodeIntegrity%4Operational.evtx`
Standardeinstellungen: `Aktiviert. 1 MB`
Empfohlene Einstellungen: `Aktiviert. 128 MB+`
Überprüfen Sie dieses Protokoll, um Treiberladeereignisse zu erkennen, die von Windows-Codeintegritätsprüfungen blockiert werden; dies kann auf einen schädlichen Treiber hinweisen, der nicht geladen werden konnte.
## Diagnosis-Scripted-Betriebsprotokoll (1 Sigma-Regel)
Datei: `Microsoft-Windows-Diagnosis-Scripted%4Operational.evtx`
Standardeinstellungen: `Aktiviert. 1 MB`
Empfohlene Einstellungen: `Aktiviert. 128 MB+`
Hier finden sich möglicherweise Hinweise darauf, dass diagcab-Pakete für Exploitation verwendet werden.
## DriverFrameworks-UserMode-Betriebsprotokoll (1 Sigma-Regel)
Dateien: `Microsoft-Windows-DriverFrameworks-UserMode%4Operational.evtx`
Standardeinstellungen: `Keine Überwachung. 1 MB`
Empfohlene Einstellungen: `Aktiviert. 128 MB+`
Erkennt angeschlossene USB-Geräte.
## WMI-Activity-Betriebsprotokoll (1 Sigma-Regel)
Datei: `Microsoft-Windows-WMI-Activity%4Operational.evtx`
Standardeinstellungen: `Aktiviert auf Win10/2016+. 1 MB`
Empfohlene Einstellungen: `Aktiviert. 128 MB+`
Dies ist wichtig zu überwachen, da Angreifer WMI häufig für Persistenz und seitliche Bewegungen ausnutzen.
## TerminalServices-LocalSessionManager-Betriebsprotokoll (1 Sigma-Regel)
Datei: `Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx`
Standardeinstellungen: `Aktiviert. 1 MB`
Empfohlene Einstellungen: `Aktiviert. 128 MB+`
Erkennt, wenn ngrok, ein Reverse-Proxy-Tool, Datenverkehr an den lokalen RDP-Port weiterleitet, um Firewalls zu umgehen.
Link: [Umgehung von Netzwerkbeschränkungen durch RDP-Tunneling](https://www.mandiant.com/resources/blog/bypassing-network-restrictions-through-rdp-tunneling)
## TaskScheduler-Betriebsprotokoll (1 Sigma-Regel)
Datei: `Microsoft-Windows-TaskScheduler%4Operational.evtx`
Standardeinstellungen: `Deaktiviert. 1 MB`
Empfohlene Einstellungen: `Aktiviert. 128 MB+`
Angreifer missbrauchen häufig Aufgaben für Persistenz und seitliche Bewegungen, daher sollte dies aktiviert werden.