Monitoring - Detektieren von Angriffen mittels MITRE ATT&CK

Monitoring

Detektieren von Angriffen mittels MITRE ATT&CK

Michael Schneider
von Michael Schneider
am 11. Juli 2019
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

Auf einem Windows 10 Client werden im normalen Betrieb täglich tausende Ereignisse protokolliert. Diese Ereignisse geben Auskunft über den Zustand und Aktivitäten des Systems und dessen Benutzer. Durch die Auswertung dieser Protokolle können viele verschiedene Informationen gewonnen werden, vom Arbeitsverhalten des Benutzers anhand An-/Abmelde-Vorgänge und Start/Herunterfahren des Geräts, über einen sich abzeichnenden Ausfall einer Festplatte aufgrund vieler unüblicher Schreibfehler, bis hin zu Angriffen auf das System.

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:

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

Michael Schneider

Michael Schneider arbeitet seit dem Jahr 2000 in der IT. Im Jahr 2010 hat er sich auf die Informationssicherheit spezialisiert. Zu seinen Aufgaben gehören das Penetration Testing, Hardening und das Aufspüren von Schwachstellen in Betriebssystemen. Er ist bekannt für eine Vielzahl in PowerShell geschrieber Tools zum Finden, Ausnutzen und Beheben von Schwachstellen. (ORCID 0000-0003-0772-9761)

Links

Sie wollen die Sicherheit Ihrer Firewall prüfen?

Unsere Spezialisten kontaktieren Sie gern!

×
HardeningKitty

HardeningKitty

Michael Schneider

KleptoKitty

KleptoKitty

Michael Schneider

Linux Hardening

Linux Hardening

Michael Schneider

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv