Bericht und Dokumentation
Michael Schneider
Monitoring
Detektieren von Angriffen mittels MITRE ATT&CK
Lesezeit: 10 Minuten
Keypoints
So können Sie Angriffe mittels MITRE ATT&CK erkennen
- Wissen über Angriffstechniken hilft, diese zu detektieren
- MITRE ATT&CK Enterprise Matrix beinhaltet reelle Angriffstaktiken und -techniken
- Die Windows-Audit-Einstellungen sollten ausgebaut werden
- Durch Korrelierung von Ereignissen können Angriffe erkannt werden
Es gibt unzählige Techniken wie ein Windows-System angegriffen werden kann. Für das erfolgreiche Detektieren von Angriffen muss einerseits die eingesetzte Technik bekannt und andererseits das System so konfiguriert sein, dass relevante Ereignisse überhaupt aufgezeichnet werden. Aus all den Daten müssen danach die passenden Ereignisse zur jeweiligen Technik gefunden werden.
MITRE ATT&CK Enterprise Matrix
Die MITRE ATT&CK Enterprise Matrix ist eine Sammlung von Taktiken und Techniken, bestehend aus Daten von realen Angriffen. ATT&CK ist öffentlich verfügbar und kann kostenlos eingesetzt werden. Die Version April 2019 der ATT&CK Enterprise Matrix umfasst 12 Taktiken und 244 Techniken. Als Beispiel umfasst die Taktik Credential Access Techniken zum Erlangen von Zugangsdaten, dazu gehören Brute Force, Credential Dumping und Forced Authentication. Jede Technik beinhaltet eine Beschreibung, eine Liste von Examples, wie die Technik eingesetzt wird, sowie mögliche Gegenmassnahmen jeweils aufgeteilt in Mitigation und Detection.
Die ATT&CK Enterprise Matrix eignet sich unter anderem als Basis für die Erkennung von Angriffen. Die empfohlenen Massnahmen sind, je nach Technik, spezifisch formuliert. So wird im Falle von Kerberoasting empfohlen im Event-Log der Kerberos Service Ticket Operations auf Accounts zu achten, die innert wenigen Minuten viele Anfragen stellen, besonders wenn der Ticket-Request den Verschlüsselungsalgorithmus RC4 (Type 0×17) beinhaltet. Bei der Technik Credential Dumping sind die Empfehlungen dafür allgemeiner gehalten. Es wird unter anderem empfohlen zu prüfen, dass LSASS als Protected Process gestartet wird und dass Zugriffe auf den Prozess LSASS überwacht werden. Zudem sollte die Ausführung von Anwendungen und Skripte auf verdächtiges Verhalten untersucht werden. Als eines der bekanntesten Beispiele für Credential Dumping gilt das Tool Mimikatz. Mimikatz wird neben Security-Researchern auch von vielen Gruppen in realen Angriffen eingesetzt. Daher versuchen wir ein Testsystem so zu konfigurieren, dass mittels Windows-Bordmitteln ein Angriff mit Mimikatz detektiert werden kann.
Konfiguration Audit-Einstellungen
Im Artikel Windows 10 Client Hardening sind bereits einige Zusatzeinstellungen für die Audit-Konfiguration erwähnt. Die neuste Version der Hardening Checkliste verfügt über weitere Einstellungen und sie wurde auf den Stand von Windows 10 Build 1903 aktualisiert. Um die Ausführung von Mimikatz zu erkennen, ist es nötig die Audit-Einstellungen von Windows zu erweitern. Dies umfasst einige der nachfolgenden Einstellungen, welche jedoch auch für das Erkennen von weiteren Angriffstechniken genutzt werden können:
- Audit Policy nach Windows Security Baseline konfigurieren
- Advanced Audit Policy Configuration nach Windows Security Baseline konfigurieren
- Audit-Einstellungen für ein- und ausgehenden NTLM-Verkehr aktiveren
- Audit-Einstellungen für die Regeln zur Attack Surface Reduction aktivieren
- Log-Einstellungen der Windows Firewall aktiveren
- Nutzung von Credential Guard aktivieren (ist je nach System nicht möglich)
- LSA Audit Mode und aktivieren als Protected Process konfigurieren
- PowerShell Monitoring aktivieren
- Installation von Sysmon, als Vorlage dient die Konfiguration von SwiftOnSecurity
Monitoring von Mimikatz
Auf dem Windows-Client läuft der LSASS-Prozess im Protected Mode. Dies lässt sich beim Start des Betriebssystems im System-Event-Log verifizieren. Der Event der Quelle Wininit mit der Event-ID 12 lautet: LSASS.exe was started as a protected process with level: 4. Wenn nun mit Mimikatz versucht wird die Zugangsdaten der angemeldeten Benutzern auszulesen, schlägt der Vorgang fehl:
mimikatz # privilege::debug Privilege '20' OK mimikatz # sekurlsa::logonpasswords ERROR kuhl_m_sekurlsa_acquireLSA ; Handle on memory (0x00000005)
Mit Sysmon kann der Start von Mimikatz detektiert werden, unter anderem mit dem Event Process Create. Falls eine modifizierte Version von Mimikatz eingesetzt wird, und der Name, die Beschreibung und weitere Merkmale der Applikation getarnt wurden, ist dieser Event nur bedingt zuverlässig. Beim Starten von Mimikatz wird zudem im Security-Event-Log der Task Sensitive Privilege Use mit der Event-ID 4673 als Failed registriert. Es wird versucht die Privilegien für SeTcbPrivilege zu erlangen. Falls es sich bei der Prozess-ID um dieselbe ID wie beim Sysmon-Event handelt, stellt dies ein Indiz für eine verdächtige Aktivität dar.
Im nächsten Schritt wird der Mimikatz-Treiber geladen, um den Protected Mode des LSASS-Prozesses im Memory des Systems zu entfernen.
mimikatz # !+ [*] 'mimidrv' service not present [+] 'mimidrv' service successfully registered [+] 'mimidrv' service ACL to everyone [+] 'mimidrv' service started mimikatz # privilege::debug Privilege '20' OK mimikatz # !processprotect /remove /process:lsass.exe Process : lsass.exe PID 652 -> 00/00 [0-0-0]
Dieser Vorgang kann mit Sysmon und dem Event Driver loaded nachvollzogen werden. Zusätzlich ist im System-Event-Log unter der Quelle Service Control Manager und der Event-ID 7045 ebenfalls ein Eintrag zum Laden des Treibers vorhanden. Die Installation eines Treibers wird auch im Security-Event-Log unter der Event-ID 4697 festgehalten.
Nachdem der LSASS-Prozess nun nicht mehr geschützt ist, können die Zugangsdaten der Benutzer aus dem Speicher des Prozesses ausgelesen werden.
mimikatz # sekurlsa::logonpasswords Authentication Id : 0 ; 2496472 (00000000:002617d8) Session : Interactive from 1 User Name : admin Domain : W10 Logon Server : W10 Logon Time : 31/02/2019 08:10:41 SID : S-1-5-21-2094461431-2471580941-81854671-1002 ...
Das Auslesen der Zugangsdaten generiert im Security-Event-Log den Event An attempt was made to access an object. der Kategorie Kernel Object mit der Event-ID 4663. Dabei wurde von einer Anwendung auf das Objekt LSASS-Prozess erfolgreich zugegriffen.
Durch die Erweiterung der Sysmon-Config um die folgende Einstellung kann die Erkennung von Zugriffen auf den LSASS-Prozess noch verbessert werden:
<!--SYSMON EVENT ID 10 : INTER-PROCESS ACCESS-->
<!--DATA: UtcTime, SourceProcessGuid, SourceProcessId, SourceThreadId, SourceImage, TargetProcessGuid, TargetProcessId, TargetImage, GrantedAccess, CallTrace-->
<ProcessAccess onmatch="include">
<TargetImage condition="contains">lsass.exe</TargetImage>
</ProcessAccess>Mit diesen Erkenntnissen der Analyse der Ausführung von Mimikatz ist es nun möglich den Angriff zu detektieren. Im einfachsten Fall kann auf die Ausführung von mimikatz.exe sowie das Laden des Treibers mimidrv.sys geachtet werden. Durch die Korrelierung der Ereignisse Process Create, Driver loaded und Zugriffe auf den LSASS-Prozess kann zudem auch eine getarnte Version von Mimikatz oder eine Anwendung, die nach einem ähnlichen Prinzip vorgeht, detektiert werden.
Wie weiter
Das Detektieren von Mimikatz ist nur ein erster Schritt auf dem Weg alle Angriffstechniken der ATT&CK Enterprise Matrix detektieren zu können. Die dokumentierten Techniken bieten jedoch eine Hilfestellung und somit einen guten Anhaltspunkt zum Aufbau eines Detektion-Frameworks. Eine weitere Hilfe stellt die Sammlung von Event-Log-IDs von Andrea Fortuna dar. Zudem können die Mechanismen zur Erkennung von verdächtigen Vorgängen meist für mehr als nur eine Technik verwendet werden. Es ist demzufolge auch nicht nötig für jede einzelne Technik eine eigene Detektierungsregel zu bauen. Darüber hinaus darf nicht vergessen werden, dass es andere Angriffe und Aktivitäten ausserhalb von MITRE ATT&CK gibt, die auch beachtet werden sollten.
Die Identifikation von Angriffen kann einerseits bereits auf dem Client-System erfolgen mit einem anschliessenden Alarm an die zentrale Infrastruktur, oder es findet im zentralen Monitoringsystem eine entsprechende Analyse statt. Bei zentralen Auswertungen können zudem die Daten anderer Systeme zugezogen werden, was gegebenenfalls auch weitere Anhaltspunkte liefern kann. Ebenfalls sollte die Historie der letzten Tage beigezogen werden, da sich ein Angriff über mehrere Tage oder gar Wochen erstrecken kann.
Über den Autor
Links
- https://attack.mitre.org/
- https://attack.mitre.org/software/S0002/
- https://attack.mitre.org/tactics/TA0006/
- https://attack.mitre.org/techniques/T1003/
- https://attack.mitre.org/techniques/T1110/
- https://attack.mitre.org/techniques/T1187/
- https://attack.mitre.org/techniques/T1208/
- https://blogs.technet.microsoft.com/secguide/2019/05/23/security-baseline-final-for-windows-10-v1903-and-windows-server-v1903/
- https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/
- https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-exploit-guard/attack-surface-reduction-exploit-guard
- https://github.com/0×6d69636b/windows_hardening/
- https://github.com/SwiftOnSecurity/sysmon-config
- https://github.com/gentilkiwi/mimikatz/
- https://www.andreafortuna.org/2019/06/12/windows-security-event-logs-my-own-cheatsheet/
Sie wollen die Sicherheit Ihrer Firewall prüfen?
Unsere Spezialisten kontaktieren Sie gern!
×
Einführung von CVSS v4.0
Michael Schneider
Rogue Device
Michael Schneider
Windows LAPS
Michael Schneider
Sie brauchen Unterstützung bei einem solchen Projekt?
Unsere Spezialisten kontaktieren Sie gern!