Das Defender-Dilemma ist wohl allen bekannt, es besagt, dass Angreifer nur eine Sicherheitslücke in einem IT-Unternehmen ausnutzen müssen. Wobei ein Verteidiger alle Lücken schliessen muss, was eher unwahrscheinlich ist. Diese negative Perspektive ist nicht förderlich, um ein kreatives Defenders-Mindset aufbauen zu können. In diesem Beitrag wollen wir daher den Fokus auf das Dilemma der Angreifer richten und wie dieses am Beispiel von Honeytokens ausgenutzt werden kann.

Ein Angreifer betritt das Spielfeld eines Defender, sobald eine Kompromittierung, meist eines Endpunktes, durch eine Angriffsvariante stattgefunden hatte. Die Angreifer haben nun verschiedene Möglichkeiten das Spielfeld zu erkunden, vorstellbar wie beim Game Minesweeper welches wahrscheinlich nur noch die ältere Generation unter euch kennt.

Die Aufgabe als Defender besteht darin die Angreifer so schnell wie möglich zu erkennen und zu blockieren, bevor diese auf kritische Daten zugreifen können. Um das zu erreichen, setzen wir heutzutage meistens eine Vielzahl an Sicherheitstools ein, welche unter anderem Logs von unseren Endpunkten sammeln. Anhand von unseren durchgeführten Red Teams können wir jedoch sagen, dass zwar unsere Aktionen meistens aufgezeichnet wurden, jedoch im Datenlärm untergangen sind. Woran kann das liegen? Ein Grund könnte sein, dass wir als Defender dazu tendieren zu wenig kreativ zu sein. Wir arbeiten Listen ab, um unsere Systeme sicherer zu machen, achten aber zu wenig auf das Spielfeld, auf welchem sich ein Angreifer bewegt. Passend dazu ist auch John Lambert’s (2015) Zitat:

Defenders think in lists. Attackers think in graphs. As long as this is true, attackers win.

Wie können wir nun das Spielfeld für Angreifer schwieriger gestalten? Angreifer versuchen in einem ersten Schritt meistens weitere Informationen über unsere IT-Umgebung zu sammeln. Diese Aktion findet entweder auf dem Endpunkt oder über das Netzwerk zu Diensten wie zum Beispiel Active Directory, File Server oder andere Umsysteme statt. Da wollen wir nun mit einer möglichen Methode genannt Honeytokens ansetzen, um aufzuzeigen, dass wir mit dieser effektiven Art in der Lage sein können, frühzeitig auf ein erstes Indiz reagieren zu können. Dafür legen wir auf unserem Spielfeld gezielt Fallen aus, vorstellbar wie bei Minesweeper die Minen.

Es ist wichtig bei der Platzierung der Honeytokens sich in die Denkweise der Angreifer zu versetzen. Umso kreativer wir diese Fallen stellen umso eher werden diese durch die Angreifer ausgelöst. Bei einer Aktivierung haben wir nun den Vorteil durch unsere zahlreichen Tools festzustellen von welcher Komponente (z.B. User, IP-Adresse, Hostname) ein Angriff ausgegangen ist. Nun liegt es an uns so schnell wie möglich zu reagieren, um die Angreifer von unserem Spielfeld zu vertreiben.

Honeytokens gibt es in verschiedenen Variationen. Im nachfolgenden Kapitel beschreiben wir ein Beispiel anhand von einem Active Directory Honeytoken.

Honeytoken Idee für Active Directory

Active Directory ist für Angreifer ein idealer Ort, um Informationen über die IT-Umgebung zu sammeln. Vergleichbar mit Google Maps, wir suchen nach einem guten Restaurant oder Sehenswürdigkeiten, Angreifer suchen im Active Directory nach einem einfachen Pfad, um an privilegierte Objekte heranzukommen. Um Active Directory auszulesen, existieren viele Tools wie zum Beispiel dsquery.exe, dsa.msc, SharpHound, ADExplorer, PowerView und viele mehr auf welche wir in diesem Artikel jedoch nicht speziell eingehen werden. Wir sind nämlich eher interessiert an der Abfrage selbst welche über LDAP stattfindet und welche wir mit Hilfe von System Access Control Lists (SACL) auf einem Domain Controller aufzeichnen können. SACL werden im Vergleich zu Discretionary Access Control List (DACL) zu wenig verwendet. Anders als eine DACL welche über SIDs den Zugriff auf ein Objekt kontrolliert, ermöglicht die SACL den Zugriff auf die Audit ACE eines Objektes. Eine Audit ACE beschreibt, ob eine gewisse Aktion auf ein Objekt erfolgreich war oder nicht. Zu empfehlen für eine tiefere Recherche zum Thema ACL ist das An ACE Up the Sleeve Dokument, welches von der Firma SpecterOps veröffentlicht wurde.

Für unseren Active Directory Honeytoken werden wir von den zwei SACL Kategorien Object Read und Object Write nur das Object Read verwenden. Wir können damit aufzeichnen, ob Active Directory ausgelesen wird. Die Vorgehensweise sieht wie folgt aus:

1. In einem ersten Schritt erstellen wir einen neuen Benutzer mit einem komplexen Kennwort in Active Directory. Die Namenskonvention sollte sich an die bereits vorhandene Objekte richten, um zu vermeiden, dass ein Angreifer das Konto schnell als Honeytoken identifizieren kann. Des Weiteren gilt bereits zu überlegen nach was für einem Namen oder Prefix ein Angreifer in einem Active Directory suchen würde wie zum Beispiel nach adm*, admin* oder svc*
   
2. Nun sollten wir uns in den nächsten Tagen mehrmals mit dem erstellten Honeytoken anmelden um die LastLogon-Attribute in Active Directory zu befüllen. Angreifer versuchen nämlich Honeytokens zu erkennen indem sie Konten herausfiltern, die sich nie angemeldet haben oder deren Kennwort am selben Tag wie die LastLogon-Attribute festgelegt wurden.
3. Nun fügen wir eine neuen SACL über das Security Tab -> Advanced -> Auditing hinzu:
   • Principal: Everyone
   • Applies to: The object only
   • Permissions: Read all properties
     
4. Damit die Domain Controller einen Event durch unsere SACLs Einstellung erzeugen können, müssen wir die Advanced Audit Policy wie folgt konfigurieren:
   • DS Access – Audit Directory Service Access: Success (Mindestens Success)
   • Vorteilhaft wird diese Einstellung über GPOs vorgenommen und muss auf alle Domain Controller appliziert werden.
     
5. Nun können wir unseren Honeytoken testen in dem wir eine LDAP-Abfrage auf den erstellten Honeytoken ausführen. In unserem Beispiel haben wir dsquery und SharpHound verwendet.
   • Abfrage mit dsquery nach allen AD Benutzern welche mit adm beginnen
     
   • Diese Abfrage erzeugt zwei Security Eventlog Einträge auf dem Domain Controller mit der Event ID: 4662.
     
   • Die Abfrage mit SharpHound erzeugt mit unserer Read All Properties SACL-Einstellung vier Einträge, da SharpHound mehrere Properties abfragt.
     
6. Als letzter Schritt muss nun der Event 4462 von der verwendeten Sicherheitslösung eingesammelt und ein Alarm ausgelöst werden.

Von nun an können wir feststellen, ob Angreifer das gesamte Active Directory auslesen oder in unserem Beispiel spezifisch nach adm Accounts suchen. Zu beachten gilt das False-Positives auftreten können, falls der erstellte Honeytoken in einer OU angelegt wurde in welchen legitime Administratoren oft Abfragen tätigen oder durch 3rd Party Applikationen wie zum Beispiel ein Identity Management System. Ausnahmen können daher erforderlich sein, um False-Positives zu vermeiden.

Weitere Honeytoken-Ideen für SACLs

In Windows gibt es eine Vielzahl an Securable Objects wie zum Beispiel:

• Network Shares
• Registry Keys
• Dateien und Verzeichnisse auf dem NTFS-Dateisystem
• Printers
• Processes
• Active Directory Objects

Auf alle diese Objekte können SACLs gesetzt werden. Dateien auf Shares oder auch auf Clients sind hervorragend geeignet für Honeytokens und erzeugen wie am Beispiel Active Directory auch ein Event mit der ID 4462. Vorausgesetzt die Advanced Audit Policy ist korrekt konfiguriert. Der Kreativität ist schlussendlich kein Ende gesetzt. Als Start für die Dateinamen kann man sich an der PowerView Funktion Find-InterestingDomainShareFile orientieren welche von Angreifern gerne verwendet wird. Die Funktion sucht standardmässig nach Namen wie pass, sensitive, secret, admin, login oder unattend*.xml.

Weitere Honeytoken-Ideen

Zahlreiche Webseiten beschreiben verschiedene Arten von Honeytoken-Implementierung. Nachfolgend präsentieren wir einige Links:

• Canary Tokens oder Canary Tools bieten eine automatisierte Möglichkeit, Honeytokens zur Simulation von Netzwerkdiensten einzusetzen. Wenn Angreifer das Netzwerk nach interessanten Diensten wie File-Servern oder Webdiensten durchsuchen, wird ein Alarm ausgelöst
• Microsoft beschreibt, wie man ein Azure Key Vault Honeytoken erstellt, indem ein Alarm ausgelöst wird, wenn ein Angreifer versucht, Schlüsselmaterial auszulesen
• Rene Feingruber beschreibt in seinem Blogbeitrag verschiedene Arten von Honeytokens. Besonders kreativ sind die Honeytoken-Ideen zu den Tools BloodHound, PowerView und Responder, die von Angreifern häufig verwendet werden
• Nikhil Mittal beschreibt in seinem Blogbeitrag, wie Angreifer Honeytokens identifizieren können. Wie bereits erwähnt sollten wir uns in die Lage eines Angreifers versetzen um realistische Fallen auslegen zu können. Was würde daher ein Attacker als Täuschung ansehen und ignorieren?
• Sean Metcalf beschreibt detailliert, wie man ein normal aussehender Honeytoken in Active Directory erstellt

Fazit

Das Erstellen effektiver Honeytokens in IT-Umgebungen erfordert sowohl die Denkweise eines Angreifers als auch Kreativität. Wie wir gelernt haben, können Honeytokens für nahezu jedes Szenario entwickelt werden und kann helfen einen Angreifer in der Frühphase eines Angriffs zu enttarnen. Dadurch kann der Incident möglicherweise schneller bearbeiten und gestoppt werden. Es sollten mehrere Honytokens in einer IT-Umgebung erstellt werden, welche anhand der Angriffsstadien ausgelegt werden sollten. Zu beachten gilt, dass Honeytokens die IT-Umgebung nicht gefährden sollten. Daher empfehlen wir keine privilegierten Zugriffsrechte an Honeytokens zuzuweisen. Wie bei allem in der IT sollten die Honeytokens getestet werden, ob sie wie erwartet funktionieren. Und schliesslich sollten man sich nicht nur auf Honeytokens verlassen. Sie sind jedoch eine wirksame Technik, die Defender einsetzen können, um das Dilemma des Angreifers zu vergrössern.

Über den Autor

Marius Elmiger hat seit den frühen 2000er Jahren Erfahrung in verschiedenen Rollen als Administrator, Engineer, Architekt und Consultant gesammelt. Sein Fokus lag hauptsächlich in der Implementierung von komplexen IT-Infrastruktur Projekten, Umsetzung von Sicherheitskonzepten und Compromise Recoveries. Später wechselte er zur offensiven Seite, um sein Wissen weiter auszubauen. Als Grundlage neben zahlreichen Zertifikaten absolvierte Marius ein MSc in Advanced Security & Digital Forensics an der Edinburgh Napier University. (ORCID 0000-0002-2580-5636)

Links

• https://apt29a.blogspot.com/2019/11/deploying-honeytokens-in-active.html
• https://bloodhound.readthedocs.io/en/latest/data-collection/sharphound.html
• https://canary.tools
• https://canarytokens.org
• https://docs.microsoft.com/en-us/azure/sentinel/monitor-key-vault-honeytokens?tabs=deploy-at-scale
• https://docs.microsoft.com/en-us/sysinternals/downloads/adexplorer
• https://github.com/PowerShellMafia/PowerSploit/tree/master/Recon
• https://www.hub.trimarcsecurity.com/post/the-art-of-the-honeypot-account-making-the-unusual-look-normal
• https://www.labofapenetrationtester.com/2018/10/deploy-deception.html
• https://www.specterops.io/assets/resources/an_ace_up_the_sleeve.pdf