Da Unternehmen weiterhin rund um die Uhr Opfer von Angriffen werden, versuchen IT- und Sicherheitsteams ständig, ihre Abwehrmaßnahmen zu verbessern – in der Hoffnung, Angreifer aus ihren Netzwerken zu vertreiben. Die (mehr oder weniger) gute Nachricht ist, dass Anbieter von Sicherheitssoftware und -hardware mit Produkt- und Serviceangeboten überlaufen, die Ihnen helfen sollen. Viele versprechen sogar, die bösen Jungs und Mädels 24 Stunden am Tag, 7 Tage die Woche von Ihren Systemen fernzuhalten!
Sie müssen also nur Ihre Kreditkarte zücken, eines dieser Produkte installieren und ruhig schlafen, richtig? Leider stellen wir bei den Penetrationstests, die wir für Kunden im ganzen Land durchführen, immer wieder fest, dass diese teuren Sicherheitslösungen erhebliche blinde Flecken haben. Viele erkennen nicht einmal die einfachsten Angriffe vollständig. Außerdem müssen Sicherheitsprodukte für Ihre Umgebung feinabgestimmt werden; die Standardeinstellungen decken nicht alle für Ihre Umgebung spezifischen Probleme ab.
In diesem Artikel zeigen wir Ihnen, wie Sie einige dieser „niedrig hängenden Früchte“ für Hacker ausführen können, um die Wirksamkeit der Sicherheitsdienste Ihres Unternehmens zu testen. Damit wir ein echtes kommerzielles Tool für diese Angriffe zur Verfügung hatten, entschieden wir uns für die Sicherheitslösung InsightIDR von Rapid7, die wir in unserer Laborumgebung installierten.
InsightIDR hat SIEM als Grundlage und lässt sich im Kern zu einer XDR-Lösung skalieren, die Endpunkte, Netzwerkverkehrsanalyse, UEBA, Incident Response und mehr abdeckt. Bei unseren Tests stießen wir auf eine Reihe von Problemen, die bei SIEM-Systemen häufig vorkommen. Die gute Nachricht ist, dass Anbieter auf diese Probleme reagieren – sie hören davon lieber von „White Hats“ und Kunden als von den Angreifern – und wir standen während unserer Arbeit in Kontakt mit Rapid7. Rapid7 erwies sich als reaktionsschnell und unkompliziert in der Zusammenarbeit – ein gutes Zeichen für den Anwendersupport und von entscheidender Bedeutung für die Cybersicherheit. Rapid7 arbeitet an mehreren Korrekturen für unsere Ergebnisse – einige davon waren bekannte Probleme, von denen das Unternehmen bereits wusste. Daher werden wir diesen Artikel in einigen Monaten aktualisieren, um den Abschluss dieser Arbeiten widerzuspiegeln. Außerdem haben wir an mehreren Stellen die Kommentare von Rapid7 aufgenommen.
Unseres Wissens ist dies eines der wenigen Male, dass Testergebnisse zu einem Cybersicherheitsprodukt dieser Größenordnung veröffentlicht wurden; unser Ziel ist daher vor allem die Wissensvermittlung. Wir empfehlen Ihnen, diesen Artikel als Leitfaden zu verwenden, um eigene interne Tests von Sicherheitslösungen durchzuführen. Wir haben uns auf mehrere erkennbare „Warnschüsse“ konzentriert, die während eines Angriffs (oder eines Pentests) auftreten können und Ihnen zeigen, dass sich hinter den Kulissen etwas Unheilvolles zusammenbraut. Werden einer oder mehrere dieser Angriffe nicht erkannt, fordern Sie Ihre Anbieter auf, dafür eine Signatur zu schreiben. Das Ergebnis ist ein stärkeres Produkt für die gesamte Nutzerbasis.
Wir haben außerdem einen separaten Leitfaden für die ersten Schritte mit Rapid7 InsightIDR erstellt, in dem wir unsere Eindrücke von der Benutzerfreundlichkeit und Funktionalität des Produkts festhalten. Wir fanden, dass sich das Produkt innerhalb weniger Stunden einfach installieren und konfigurieren ließ, und erhielten sofort Benachrichtigungen über wichtige Sicherheitsereignisse. In diesem Artikel konzentrieren wir uns auf häufige Angriffe, die wir bei Penetrationstests durchführen, und darauf, wie das InsightIDR-System von Rapid7 darauf reagierte.
Die Fähigkeit von InsightIDR testen, Angriffe zu erkennen
- Aufzählung von Active Directory
- Passwort-Spraying
- Kerberoasting
- AS-REP-Roasting
- Manipulation des Netzwerkverkehrs
- Hashes von Domänencontrollern auslesen
- Pass-the-Hash-Angriffe (PTH)
- Fazit
Nachdem der Agent auf allen Systemen in unserer Testumgebung installiert war, konnten wir die Aktionen simulieren, die ein Angreifer oder Ransomware-Betreiber ausführen würde, um zu sehen, welche Arten von Sicherheitsbedrohungen erkannt werden. (Hinweis: Viele der folgenden Angriffe stammen aus Light Pentest LITE: eBook Edition, einem praxisorientierten, schrittweisen Leitfaden für Penetrationstests in internen Netzwerken.)
Aufzählung von Active Directory
Eines der ersten Dinge, die wir bei einem Penetrationstest tun, ist, mehr über die Active-Directory-Umgebung des Kunden zu erfahren. Active-Directory-Konfigurationen, insbesondere solche, die seit mehreren Jahren produktiv eingesetzt werden, sind oft voller Angriffspfade, die nur schwer zu erkennen sind, wenn man nicht genauer unter die Haube schaut.
Eines der Tools, die wir für die Aufzählung von Active Directory verwenden, ist SharpHound. Es sammelt Informationen über alle Objekte im Verzeichnis und darüber, wie sie aus sicherheitstechnischer Sicht miteinander in Beziehung stehen. SharpHound bietet zahlreiche Konfigurationseinstellungen, mit denen sich die Datenerfassung unauffälliger gestalten lässt; normalerweise führen wir es jedoch einfach „mit offenen Karten“ wie folgt aus:
sharphound.exe -d pwn.town -c all
Das -d pwn.town gibt unsere Domäne an, und -c all weist SharpHound an, alle Daten über die Active-Directory-Umgebung zu sammeln.
InsightIDR erkannte nicht, dass SharpHound ausgeführt wurde. Das ist allerdings nicht überraschend, da wir bisher noch keine Sicherheitslösung gesehen haben, die das Tool erkennt.
Die gute Nachricht ist, dass InsightIDR diesen Angriff bald erkennen können wird. Rapid7 teilte uns mit: „Wir arbeiten an einer Erkennung für die Aufzählung von Active Directory mithilfe von SharpHound, die unserer Ansicht nach anhand von Windows-Logereignissen möglich ist. Sie wird voraussichtlich bis zum Jahresende verfügbar sein.“
Passwort-Spraying
Zu Beginn eines Penetrationstests möchten wir herausfinden, ob wir Zugriff auf weitere Active-Directory-Benutzerkonten erhalten können. Eine beliebte und relativ unauffällige Methode dafür ist Passwort-Spraying. Dabei versuchen wir, uns bei jedem Konto einmal mit einem Passwort anzumelden, von dem wir wissen, dass Menschen es mit hoher Wahrscheinlichkeit verwenden. Aus unserer Erfahrung wissen wir, dass Menschen saisonale Kombinationen aus Jahreszeit und Jahr geradezu lieben. Daher luden wir Rubeus herunter und versuchten, uns mit der folgenden Syntax bei jedem Benutzerkonto anzumelden:
rubeus.exe spray /password:Spring2022! /outfile:pwned.txt
Der spray-Schalter teilt Rubeus mit, dass wir ein Passwort-Spraying durchführen; /password:Spring2022! gibt das Passwort an, mit dem wir das Spraying durchführen, und /outfile:pwned.txt speichert gültige Zugangsdaten in einer Textdatei namens pwned.txt.
InsightIDR erkannte unsere Passwort-Spraying-Versuche nicht. Wir stellen fest, dass Sicherheitslösungen sehr gut darin sind, Sie zu benachrichtigen, wenn ein Konto gesperrt wird. In diesem Fall versuchen wir jedoch nur einmal, uns bei jedem Konto anzumelden, sodass die Konten aktiv bleiben.
Rapid7 teilte uns mit, dass ein nicht von uns konfigurierter Honeypot geholfen hätte. Die Antwort des Unternehmens: „Für Passwort-Spraying haben wir zwei Erkennungen: Die erste ist der Honey User, den Sie während des Tests nicht konfiguriert haben, und die zweite ist eine Brute-Force-Erkennung, die nach einer Häufung fehlgeschlagener Authentifizierungen von einem einzelnen Host sucht. Unser Schwellenwert liegt bei mindestens 100 verschiedenen Benutzern (unsere kleinsten Kunden haben etwa 500 Benutzer). Wir überprüfen diesen Schwellenwert derzeit neu.“
Kerberoasting
Kerberoasting gehört zu unseren Lieblingsangriffen. Die technische Erklärung kann etwas komplex ausfallen; für eine ausführlichere Betrachtung empfehlen wir diesen Artikel von Black Hills Information Security. Wenn wir jedoch über Kerberoasting sprechen, sitzen wir meist in einem Raum voller Manager und Führungskräfte, die einfach nur eine leicht verständliche Erklärung des Angriffs und seiner Bedeutung möchten. Wir sagen dann etwa Folgendes:
„Im Grunde kann sich jedes Active-Directory-Konto an Active Directory wenden und sagen: ‚Hey Active Directory, könntest du mir bitte die Hashes aller Dienstkonten geben, die beispielsweise mit IIS und SQL verknüpft sind?‘ Und die Active-Directory-Umgebung antwortet bereitwillig: ‚Kein Problem, Bri-Guy, HIER BITTE!‘“
Dieser Angriff wird verständlicher, wenn man ihn in Aktion sieht. Um zu prüfen, ob eine Umgebung für den Kerberoasting-Angriff anfällig ist, können wir Rubeus erneut mit der folgenden Syntax verwenden:
rubeus.exe kerberoast
Wie wir hier sehen, ist das Ray -Benutzerkonto in unserem Labor für Kerberoasting anfällig. Wir können also den Kontohash auf eine leistungsstarke Passwort-Cracking-Maschine übertragen und möglicherweise das Klartextpasswort ermitteln. In Produktivumgebungen gehören die von uns gefundenen kerberoastbaren Konten häufig zur Gruppe der Domänenadministratoren, und die Passwörter werden nicht regelmäßig geändert. Das bedeutet: Wenn wir diese Konten knacken, könnten wir noch vor der Frühstückspause die vollständige Kontrolle über die Domäne haben!
InsightIDR erkannte den Kerberoasting-Versuch nicht. Das ist allerdings nicht völlig überraschend, da wir bisher nur wenige Sicherheitslösungen gesehen haben, die für diesen speziellen Angriff einen Alarm auslösen. Lösungen wie Blumira haben jedoch eine Erkennung dafür entwickelt und stellen sogar ihren Code für ein Kerberoast-Honey-Credential öffentlich zur Verfügung.
Antwort von Rapid7: „Mehrere unserer Kunden sind wegen Kerberoasting besorgt, und wir arbeiten aktiv an einer Erkennung für diese Art von Aktivität, die voraussichtlich bis zum Ende des Sommers live gehen wird. Unsere größte Sorge besteht derzeit darin, dies so umzusetzen, dass die Zahl der Fehlalarme begrenzt wird.“
AS-REP-Roasting
Ähnlich wie Kerberoasting ist AS-REP-Roasting etwas, das jedes Active-Directory-Konto durchführen kann, um Zugriff auf Passwort-Hashes von Konten zu erhalten. Einen sehr guten technischen Überblick über die Einzelheiten dieses Angriffs bietet dieser Artikel von Stealthbits. In einer Runde mit technisch versierten und weniger technikaffinen Teilnehmern erklären wir den Angriff jedoch folgendermaßen:
Beim AS-REP-Roasting-Angriff kann jeder Benutzer in Active Directory im Grunde sagen: „Hey Active Directory, falls Benutzerkonten so eingestellt sind, dass sie keine Kerberos-Vorauthentifizierung benötigen, gib mir bitte ein paar verschlüsselte Daten über diesen Benutzer, die ich offline mitnehmen und knacken kann!“
Um anfällige Benutzer in Active Directory zu finden, können Sie den folgenden PowerShell-Befehl verwenden:
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $True} -Properties DoesNotRequirePreAuth
Bei allen Benutzern, die dieser Befehl zurückgibt, können Sie die Benutzer im Tool „Active Directory-Benutzer und -Computer“ öffnen und auf die Registerkarte „Konto“ klicken, um die anfällige Konfiguration zu sehen:
Da wir die anfälligen Benutzer und ihre Hashes sehen möchten, verwenden wir erneut Rubeus:
rubeus.exe asreproast
InsightIDR erkannte den AS-REP-Roasting-Versuch nicht. Ähnlich wie beim Kerberoasting haben wir bisher nur sehr wenige Sicherheitslösungen gesehen, die bei diesem Angriff einen Alarm auslösen. Auch hier können Benutzer wahrscheinlich in naher Zukunft mit einer Erkennung durch Rapid7 rechnen.
Manipulation des Netzwerkverkehrs
Wenn wir mit Passwort-Spraying, Kerberoasting und AS-REP-Roasting nicht weiterkommen, werden wir verschiedene Tools verwenden, um bestimmten anfälligen Netzwerkverkehr zu manipulieren – etwa NBT-NS (NetBIOS Name Service), LLMNR (Link-Local Multicast Name Resolution) und mDNS (Multicast-DNS).
Um diesen Angriff zu veranschaulichen, stellen Sie sich folgendes Szenario vor: Die Benutzerin Sally öffnet den Windows Explorer und versucht, zum PT-APP01-Server zu navigieren, vertippt sich jedoch beim Servernamen, fügt eine zusätzliche Null ein und gibt \\pt-app001 ein. Nach wenigen Augenblicken erhält sie eine Fehlermeldung mit dem Hinweis: „Windows kann nicht auf \\pt-app001 zugreifen.“ Kein großes Problem, oder? Tatsächlich könnte im Hintergrund jedoch etwas viel Unheimlicheres vor sich gehen!
Wenn wir als Angreifer Netzwerkvergiftungstools wie Inveigh einsetzen, können wir tatsächlich darauf lauschen, ob Sally solche Tippfehler macht, und diese dann abfangen. Sehen Sie sich diese Darstellung an, um einen Eindruck davon zu bekommen, wie das aussieht:
Im Grunde fragt Sallys Rechner den DNS-Server, wo \\pt-app001 zu finden ist. Wenn der DNS-Server den Rechner nicht finden kann, sendet Sallys Rechner über unsichere Protokolle (NBT-NS, LLMNR und mDNS) Rufe an den Rest des Netzwerks. Sobald das passiert – BOOM! – bringen wir Sallys Rechner dazu, uns Sallys Benutzernamen und Passwort-Hash zu senden.
Um diesen Angriff auf den Netzwerkverkehr zu starten, können wir Inveigh verwenden:
inveigh.exe -nbns y -llmnr y -mdns y
Diese Syntax weist Inveigh an, zu starten und den unsicheren NBT-NS-, LLMNR- und mDNS-Verkehr zu vergiften.
Nach einer Weile sehen wir hoffentlich Einträge im Inveigh-Protokoll, die folgendermaßen aussehen:
Wir können nun den Hash für den Benutzer Beverly nehmen und versuchen, ihn zu knacken.
InsightIDR erkannte die Netzwerkvergiftung nicht. Da InsightIDR jedoch ein endpointbasiertes Tool ist, hatten wir das auch nicht erwartet. Wenn Ihre Sicherheitslösungen zusätzlich zur Endpunktaktivität den gesamten Netzwerkverkehr überwachen, empfehlen wir, Inveigh auszuführen und zu prüfen, ob dadurch Alarme ausgelöst werden. Alternativ gibt es ein hervorragendes kostenloses Tool zur Erkennung von Netzwerkvergiftungsangriffen namens CanaryPi.
Auch hier gibt es gute Nachrichten: Laut Rapid7 ist eine Lösung in Arbeit: „Wir verfügen über eine Erkennung dafür, die wir in der Vergangenheit mit einem Tool namens Responder getestet haben und bei der ein Alarm ausgelöst wurde. Wir haben sie auch mit dem von Ihnen verwendeten Tool (Inveigh) ausprobiert, konnten sie jedoch nicht auslösen. Wir untersuchen derzeit den Grund dafür, werden sie aber bald zum Laufen bringen.“
Hashes von Domänencontrollern auslesen
Wenn wir Zugangsdaten eines Mitglieds der Gruppe der Domänenadministratoren erfassen und knacken können, werden wir als Nächstes alle Benutzernamen und Passwort-Hashes aus Active Directory auslesen. Das mimikatz-Tool eignet sich dafür perfekt:
lsadump::dcsync /domain:pwn.town /all /csv
Diese Syntax weist Mimikatz an, eine Liste aller Benutzer der Domäne pwn.town und ihrer Hashes in einem übersichtlichen CSV-Format auszugeben:
Unserer Ansicht nach ist dieser spezielle Angriff das Schlimmste, was Ihrer Active-Directory-Umgebung passieren kann. Warum? Wenn der Angreifer über diese Informationen verfügt und sich weiterhin in Ihrem Netzwerk befindet, kann er Pass-the-Hash-Angriffe (PTH) durchführen, um in Active Directory als beliebiger gewünschter Benutzer zu agieren! Und selbst wenn Sie den Zugriff der Angreifer auf Ihre Umgebung beseitigen, können sie möglicherweise einige dieser Hashes knacken und anschließend über E-Mail, VPN, VDI usw. direkt wieder in Ihr Netzwerk gelangen.
InsightIDR hat tatsächlich das Vorhandensein der mimikatz.exe-Datei auf Endpunkten erkannt, auf denen der InsightIDR-Agent installiert war. Als wir jedoch die Active-Directory-Hashes von einem nicht überwachten Endpunkt mit impacket auslasen, löste InsightIDR keinen Alarm aus. Traditionell beobachten wir, dass Sicherheitslösungen beim Auslesen von Hashes einen Alarm auslösen. Das sind zwar gute Nachrichten, aber auch etwas frustrierend, denn im Grunde hat die Lösung den „Finishing Move“ des Angreifers in Active Directory erkannt.
Pass-the-Hash-Angriffe (PTH)
Mit den aus Active Directory ausgelesenen Hashes können wir ein Tool wie CrackMapExec verwenden, um den Hash im Netzwerk an andere Systeme weiterzureichen:
cme smb 10.0.7.0/24 -u brian -H PASSWORD-HASH-FOR-BRIAN
In dieser Syntax ruft cme CrackMapExec auf, smb gibt das zu verwendende Protokoll an, 10.0.7.0/24 gibt das Subnetz der Systeme an, an die wir den Hash „sprühen“ werden, -u brian gibt den Benutzer Brian an, und -H PASSWORD-HASH-FOR-BRIAN ist Brians Passwort-Hash:
Wie Sie sehen, haben wir diesen Hash über das gesamte Subnetz 10.0.7.0/24 „gesprüht“ und festgestellt, dass nicht nur die Kombination aus Benutzer und Hash gültig ist, sondern dass es sich auf vielen Systemen um ein Konto mit hohen Berechtigungen handelt (angezeigt durch Pwn3d!).
InsightIDR erkannte die Pass-the-Hash-Angriffe nicht. Allgemein beobachten wir, dass EDR-Tools (Endpoint Detection and Response) zum Schutz von Unternehmensendpunkten Alarme auslösen, wenn sie Pass-the-Hash-Verhalten erkennen.
Testen Ihrer Umgebung auf die Erkennung von „Warnschüssen“
Es ist wichtig zu beachten, dass solche blinden Flecken bei vielen SIEMs üblich sind. In einer perfekten Welt könnten wir mit einem Zauberstab wedeln und eine Kombination von Sicherheitslösungen finden, die Ihr Netzwerk unangreifbar macht. Bis dahin sind wir jedoch der Meinung, dass es gibt viele erkennbare „Warnschüsse“, die während eines Angriffs (oder eines Pentests) auftreten können und Sie darauf hinweisen, dass sich hinter den Kulissen etwas Unheilvolles zusammenbraut. Wir empfehlen Ihnen, diesen Artikel als Leitfaden für eigene Tests von Sicherheitslösungen im Unternehmen zu verwenden. Wenn einer oder mehrere dieser Angriffe nicht erkannt werden, fordern Sie Ihre Anbieter auf, dafür eine Signatur zu erstellen. Wenn Sie außerdem auf der Suche nach einer neuen Lösung für Monitoring und Protokollierung sind, sehen Sie sich unseren SIEMple-SIEM-Fragebogen an. Er enthält eine Liste von Fragen, die Sie vor dem Kauf stellen können, um besser zu verstehen, was die Lösung leistet und was nicht, sowie zusätzliche technische Tests, mit denen Sie feststellen können, ob die Lösung Bedrohungen wirksam erkennt und/oder stoppt.
Weitere führende SIEM-Lösungen entdecken
Weiterlesen: