MITRE ATT&CK - Kritik am Standard

MITRE ATT&CK

Kritik am Standard

Marc Ruef
Marc Ruef
Michael Schneider
Michael Schneider
am 04. Februar 2021
Lesezeit: 15 Minuten

Keypoints

Das sind die Schwächen von ATT&CK

  • MITRE ATT&CK bietet ein Framework zur Katalogisierung von Taktiken und Techniken durch Angreifer
  • Der Standard weist einige organisatorische und technische Mängel auf
  • Unter anderem fehlt es an einer nachvollziehbaren Linearität oder Hierarchie
  • Techniken und Sub-Techniken sind teilweise verteilt, unvollständig oder fehlerhaft
  • Die Nutzung des Standards wird dadurch unnötig aber massgeblich erschwert

In den vergangenen 20 Jahren hat eine löbliche Standardisierung im Cybersecurity-Bereich Einzug gehalten. Federführend ist dabei die US-amerikanische Non-Profit-Organisation MITRE. Diese wird durch verschiedene Abteilungen der US-amerikanischen Regierung unterstützt und konnte so Standards wie CVE (eindeutige Identifikation von Schwachstellen), CWE (Schwachstellenklassen) und CPE (normalisierte Identifikation von Produkten) ins Leben rufen. Eine eher junge Standardisierung ist ATT&CK, die Taktiken und Techniken von Angreifern dokumentiert. Dieser Beitrag setzt sich kritisch mit dem Ansatz des Standards auseinander.

Wir setzen ATT&CK im Rahmen unserer Penetration Tests ein, um unseren Kunden und Mitarbeitern ein Mittel in die Hand zu geben, um möglichst ohne Missverständnisse miteinander über Angriffsmethoden reden zu können. Diese beschreiben wir mit den entsprechenden eindeutigen Identifiern und stellen den Angriffsweg grafisch dar.

Ebenfalls wird seit Dezember 2020 durch die Verwundbarkeitsdatenbank VulDB ein Mapping mit ATT&CK möglich. Dessen Einführung haben wir begleitet. Unsere jahrelange Erfahrung mit verschiedenen Standards, deren Ansätze, Strukturen und Interoperabilitäten liessen uns relativ schnell potentielle Schwächen, Mängel und Probleme in ATT&CK ausmachen.

Wir haben versucht ein musterbasiertes Parsing umzusetzen, um anhand bestehender Beschreibungen von Schwachstellen die dazugehörigen ATT&CK-Techniken zu identifizieren. Kommt zum Beispiel in einem Text der Ausdruck Bruteforce vor, dann wird T1110 (Brute Force) zugewiesen. Ebenso haben wir ein Mapping von CWE auf ATT&CK-Techniken umgesetzt. Aus CWE-307 (Improper Restriction of Excessive Authentication Attempts) wird sodann ebenfalls T1110.

Keine echte Hierarchie

Das grundlegende Problem von ATT&CK ist, dass hierarchische Strukturen fehlen oder inkonsistent sind. Die Techniken können nicht ausschliesslich einzelnen Taktiken zugewiesen werden. Techniken können oftmals von mehreren Taktiken und über mehrere Phasen eines Angriffs hinweg verwendet werden.

Die Identifier sowohl der Taktiken als auch der Techniken sind ebenfalls nicht nachvollziehbar. Es fehlt ihnen eine Linearität, Gruppierung oder Hierarchie. Die Taktik Reconnaissance wird in der Regel zu Beginn eines Angriffs umgesetzt und erst danach folgt der Initial Access. Betrachtet man sich die Identifier, dann heissen diese TA0043 und TA0001. Sie sind (per Zufall) nicht absteigender Folge und auch keine Nachbarszahlen bzw. Nachbarsbereiche. Viel eher hätte sich TA0001 und TA0002 bzw. TA1000 und TA2000 angeboten.

Dies macht das Erarbeiten des Verständnisses für die Einträge und das Arbeiten mit diesen enorm schwierig. Ständig müssen Identifier gesucht und gegeneinander abgeglichen werden. CWE hat dieses Problem, mindestens in den tiefen Bereichen, weniger. So wird CWE-119 für Speicherschutzverletzungen verwendet, CWE-120 für klassische Pufferüberlauf-Schwachstellen, CWE-121 für stack-basierte und CWE-122 für heap-basierte Pufferüberlauf-Schwachstellen. Erst in höheren Regionen sind auch da inkonsistente Zahlenbereich, im Fall von Speicherproblemen sind dies zum Beispiel CWE-415 für Double-Free und CWE-416 für Use-after-Free, zu beobachten.

Inkonsistente Verteilung von Techniken

T1555 setzt sich mit Credentials from Password Stores auseinander. Die Beschreibung ist leicht verständlich:

Adversaries may search for common password storage locations to obtain user credentials. Passwords are stored in several places on a system, depending on the operating system or application holding the credentials.

Die Sub-Techniken beschränken sich dann jedoch auf Keychain (T1555.001), Securityd (T1555.002) und Credentials im Browser (T1555.003).

Hierbei ist keine Rede von /etc/passwd bzw. /etc/shadow, wie es bei unixoiden Systemen der Fall ist. Erst mit T1003.008 wird die entsprechende Sub-Technik eingeführt. Einen wirklichen Unterschied in Bezug auf das Konzept und die gezeigte Entkoppelung kann nicht nachvollzogen werden.

Ein ähnliches Problem zeigt sich, wenn man Cross Site Scripting als Schwachstelle zuweisen will. Einerseits bietet sich T1059.007 an, da es sich mit der Ausführung von Javascript auseinandersetzt. Andererseits handelt es sich auch immer um eine Drive-By Attacke, die hingegen in T1189 beschrieben ist und auch das Beispiel von XSS konkret nennt.

Missverständliche Definitionen

Die Aufgabe eines Standards ist es mitunter, eine einheitliche und nachvollziehbare Nomenklatur zu schaffen. Unglücklich verhält sich diesbezüglich T1498, das sich mit Network Denial of Service beschäftigt. In der Beschreibung wird diese Klasse wie folgt spezifiziert:

Network DoS can be performed by exhausting the network bandwidth services rely on. (…) A Network DoS will occur when the bandwidth capacity of the network connection to a system is exhausted due to the volume of malicious traffic directed at the resource or the network connections and network devices the resource relies on.

Dies fokussiert sich konkret auf die Überlastung der Bandbreite entweder durch eine hohe Anzahl an Zugriffen oder eine grosse Menge an Daten. Dadurch wird es nun aber schwierig netzwerkbasierte Angriffe zuzuweisen, die sich Eigenheiten in Netzwerkprotokollen zunutze machen. Dazu gehören korrupte IP-Fragmentierung (z.B. Ping of Death) und gespoofte Unreachable-Fehler mit ICMP Type 3, Code 1-3.

Überlappungen und Duplikate

In einem spezifischen Fall muss von einem Duplikat die Rede sein. T1537 beschreibt Transfer Data to Cloud Account mit den folgenden Worten:

Adversaries may exfiltrate data by transferring the data, including backups of cloud environments, to another cloud account they control on the same service to avoid typical file transfers/downloads and network-based exfiltration detection.

In ähnlicher Weise hält T1567.002 mit dem Titel Exfiltration Over Web Service: Exfiltration to Cloud Storage fest:

Adversaries may exfiltrate data to a cloud storage service rather than over their primary command and control channel. Cloud storage services allow for the storage, edit, and retrieval of data from a remote cloud storage server over the Internet.

Erst bei genauem Hinschauen wird im Text ersichtlich, dass in T1537 die kompromittierte Quelle auch schon ein Cloud-System sein muss. Als Data Sources werden dementsprechend AWS CloudTrail logs, Azure activity logs, Stackdriver logs festgehalten. Bei T1567.002 handelt es sich jedoch um Exfiltrationen über Webdienste, die vor allem Enduser-Plattformen wie Linux, Windows, macOS betreffen.

Spezifische aber unvollständige Sub-Techniken

T1021 setzt sich mit Remote Services auseinander, die genutzt werden können, um Fernzugriffe umsetzen zu können. So wird dann auch als Subtechnik RDP (T1021.001), SSH (T1021.004) und VNC (T1021.005) angeboten.

Diese Liste ist aber bei weitem nicht vollständig. Hier fehlt klassischerweise das unverschlüsselte Telnet oder gar noch rlogin. Das gleiche Problem ist auch andernorts, zum Beispiel bei T1213 (es fehlen z.B. Wikis oder Ticketing-Systeme) zu finden.

Inkonsistente Sub-Techniken

Zuvor wurde am Beispiel von T1021 aufgezeigt, dass Listen von Sub-Techniken unvollständig sein können.

Hinzu kommt, dass die Liste in diesem spezifischen Fall ebenso inkonsistent ist. RDP, SSH und VNC sind tatsächlich klassische Mechanismen für die Fernwartung. SMB/Windows Admin Shares (T1021.002) und Distributed Component Object Model (T1021.003) funktionieren hingegen anders. SMB ist viel eher mit NFS vergleichbar und DCOM mit RPC gleichzusetzen.

Viel eher müssten hier freie und kommerzielle Lösungen wie TeamViewer und Chrome Remote Desktop ihre Erwähnung finden, da sie vom Konzept her besser passen.

Ebenfalls ist dies bei T1499 zu beobachten, das sogenannte Endpoint Denial of Service dokumentiert. In den Sub-Kategorien sind in erster Linie Flooding-Techniken genannt (T1499.001 gegen Betriebssystem, T1499.002 gegen Dienste, T1499.003 gegen Applikationen). Erst T1499.004 führt auch eine andere DoS-Technik ein, die jedoch dann im Gegensatz zu den zuvor genannten in Bezug auf Betriebssystem und Applikationen konsolidiert wird.

Zu eng definierte Sub-Techniken

In T1037.001 werden automatisch gestartete Skripte, die beim Bootvorgang oder Login ausgeführt werden, beschrieben. Sub-Technik T1037.001 beschäftigt sich mit Windows und T1037.002 mit Mac. Wir betrachten in diesem Fall den Windows-Aspekt genauer. In der Beschreibung ist zu finden:

Adversaries may use Windows logon scripts automatically executed at logon initialization to establish persistence. Windows allows logon scripts to be run whenever a specific user or group of users log into a system. This is done via adding a path to a script to the HKCU\Environment\UserInitMprLogonScript Registry key.

Diese Definition greift viel zu kurz. In der Geschichte von MS-DOS und Windows gibt es rund ein Dutzend Möglichkeiten, wie beim Bootvorgang oder einem Login automatisiert Komponenten gestartet werden können. Bei MS-DOS waren dies typischerweise autoexec.bat und config.sys. Und seit Windows NT konnten zusätzliche Registry-Schlüssel für das automatische Ausführen erschlossen werden.

Registry-Schlüssel Berechtigung Ausführbar
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run jeder alle
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce Server-Operatoren alle
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx jeder alle
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug jeder Debugger
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon Server-Operatoren Userinit

T1037.001 zeigt damit, dass es zu eingeschränkt ist und historische Aspekte gänzlich ausser Acht lässt. Es mag darüber gestritten werden, ob Techniken auf Betriebssystem von vor mehr als 20 Jahren noch eine hohe Wichtigkeit beigemessen bekommen soll. Erfahrungsgemäss sind es aber oftmals hochgradig kritische Komponenten, die eben genau noch mit derartig archaischer Software betrieben werden.

Zu kurze Sub-Techniken

T1052 bespricht das Exfiltrieren von Daten über ein physisches Medium. In der Beschreibung werden verschiedene Medien in einer nicht abschliessenden Liste aufgezählt:

Such media could be an external hard drive, USB drive, cellular phone, MP3 player, or other removable storage and processing device.

Jedoch existiert für diese Technik mit T1052.001 nur eine spezifische Sub-Technik, die sich auf USB als Trägermedium beschränkt. Die zuvor genannten Medien sind nicht dediziert als Sub-Technik vorhanden.

Ein ähnliches Problem ist bei T1222 zu finden, das sich mit Rechten von Dateien und Verzeichnissen beschäftigt. Dort werden als Sub-Techniken die beiden Betriebssystem-Familien Windows (T1222.001) und Linux/Mac (T1222.002) gelistet. Alternative Betriebssysteme werden nicht genannt. In diesem spezifischen Fall ist generell fragwürdig, ob hier wirklich nach Betriebssystem und nicht stattdessen nach Dateisystem oder Anwendungstypen (z.B. Webserver, FTP-Server, Dateiserver) unterschieden werden sollte.

Nur verifizierte Attacken

Wir haben im April 2019 einen Vorschlag für die Technik NAC Bypass in der Taktik Defense Evasion eingereicht. Die Technik stützt auf den Vortrag von Alva Lease Skip Duckwall IV an der Defcon 19, und verweist auf das Tool NACKered sowie unsere Weiterentwicklung nac_bypass.

Bei der Aufnahme von neuen Techniken ist eine der Kriterien das Vorhandensein von Daten von verifizierten Incidents. Die NAC-Bypass wird meist von internen Angreifern und im Rahmen von Penetration Tests bzw. Red Team Assessments verwendet, worüber es nur selten öffentliche Berichte gibt. Die Technik wurde mit dem Vermerk, dass es noch keine verifizierten Incidents gibt, leider noch nicht in das Framework aufgenommen.

Dies führt dazu, dass das Framework eben nicht alle Techniken zusammenführt, sondern diese eigentlich nur im historischen Rückblick zusammenfasst. Durch dieses reaktive Verhalten werden interessierte Leser daran gehindert, potenzielle, absehbare und zukunftsgerichtete Gefahren auch als solche wahrzunehmen. Denn erst wenn ein erster Zwischenfall bekannt wird, werden auch Informationen zu den angewendeten Techniken dokumentiert.

Fazit

ATT&CK ist ein interessanter und auch wichtiger Standard. Er hilft dabei verschiedene Taktiken und Techniken zu katalogisieren. Dies ist jedoch in vielen Punkten nicht immer gelungen.

Die in diesem Beitrag beschriebenen Mängel machen es sehr schwierig, sich das Verständnis für den Standard anzueignen und mit diesem natürlich umgehen zu können. Techniken und Sub-Techniken sind teilweise schwierig zu finden, können nicht nachvollzogen werden, sind nicht vollständig oder fehlerhaft.

Die Maturität von ATT&CK ist nicht mit derjenigen anderer MITRE-Projekte, wie zum Beispiel CWE oder CPE zu vergleichen. Hier muss dringend nachgebessert werden, um ein solides und nachhaltiges Konstrukt, das positiven Einfluss auf die Cybersecurity-Branche entfalten kann, erarbeiten zu können.

Wir haben die in diesem Beitrag zusammengefassten Punkte dem Projektteam mitgeteilt und hoffen, dass diese in zukünftigen Entscheidungen und Entwicklungen berücksichtigt werden.

Über die Autoren

Marc Ruef

Marc Ruef ist seit Ende der 1990er Jahre im Cybersecurity-Bereich aktiv. Er hat vor allem im deutschsprachigen Raum aufgrund der Vielzahl durch ihn veröffentlichten Fachpublikationen und Bücher – dazu gehört besonders Die Kunst des Penetration Testing – Bekanntheit erlangt. Er ist Dozent an verschiedenen Fakultäten, darunter ETH, HWZ, HSLU und IKF. (ORCID 0000-0002-1328-6357)

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 geschriebener 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!

×
Konkrete Kritik an CVSS4

Konkrete Kritik an CVSS4

Marc Ruef

Bericht und Dokumentation

Bericht und Dokumentation

Michael Schneider

scip Cybersecurity Forecast

scip Cybersecurity Forecast

Marc Ruef

Einführung von CVSS v4.0

Einführung von CVSS v4.0

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