Vermutete Lücke: Die Entwicklung der offensiven Sicherheit...

Der Zweck dieses Blogbeitrags ist einzigartig: Er soll Sie (den unschuldigen Leser, Kunden oder Konkurrenten) darüber informieren, wie TrustedSec versucht, den im Laufe der Zeit gewachsenen spezifischen Bedarf der Branche an Tests auf mutmaßliche Eindringlinge zu erfüllen. In unserer kleinen Infosec-Welt, in der der hochtechnische Informationsfluss allgegenwärtig und unaufhörlich ist, schlägt dieser Beitrag bis zu seinem Schluss einen eher besinnlichen und hoffentlich humorvollen Weg ein. Keine GPT-Füllung, nicht einmal Memes, nur ein abgewogener, shenanigan-gefärbter Rückblick auf die Offensivindustrie von einem Typen vom Land mit einer übermäßig schnellen Internetverbindung und einer Vorliebe für mentale Kreisel.

Ich empfehle, ihn bei Ihrem Lieblingsgetränk zu lesen, aber für Ungeduldige gehe ich im Abschnitt "Szenarien" auf die Besonderheiten unseres Modells für den Test auf mutmaßliche Verstöße ein.

Ein salziger Spaziergang auf dem Weg der Erinnerungen

Seit einiger Zeit wird das Netzwerk-Pentesting weitgehend in zwei Hauptkategorien unterteilt: extern und intern. Externe Tests sind in der Regel auf die IP-Adresse/den Hostnamen beschränkt und werden in einer Blackbox durchgeführt (keine Akkreditierung, kein Fernzugriff, finden Sie es selbst heraus), und interne Tests werden in der Regel von einem Netzwerkimplementiergerät aus durchgeführt, das an den Kunden geliefert wird. Dieses Gerät besteht in der Regel aus einer Linux-Distro, z. B. Kali, Ubuntu oder BlackArch, und baut einen umgekehrten SSH-Tunnel zur Zentrale auf, den der Tester nutzt, um sich anzumelden und den Test durchzuführen.

Diese Konzepte sind ausgetretene Pfade, mit denen sich die meisten Organisationen im Jahr 2024 einigermaßen wohlfühlen. Die Angst vor größeren Ausfällen hat sich kaum bewahrheitet, obwohl es hin und wieder eine Menge gesperrter Konten gibt und jemand dumm genug ist, am Configuration NC im Active Directory herumzufummeln, aber insgesamt sind der größte Schatten auf dem Bild der offensiven Sicherheitsindustrie die Testfirmen, die überhaupt nicht testen, sondern einfach die Ergebnisse von nmap/Nessus in einem Bericht ausdrucken. Ich höre immer noch davon, und es ist heute genauso schockierend wie vor zehn Jahren. Man muss diesen Unternehmen eine zusätzliche Portion Abscheu entgegenbringen, denn vor dem Aufkommen verhaltensbasierter Kontrollen war Pentesting nicht nur einfach für diejenigen, die sich in den dunklen Künsten auskannten. glorreiche.

Jahrelang hatten sich die Offensivteams auf DA-by-lunch-Techniken wie Responder, Mimikatz und PowerSploit verlassen. In allen Vorträgen, die von Mitgliedern des Roten Teams gehalten wurden, wurde betont, dass die "Grundprinzipien" eingehalten werden müssten (möglichst wenig Zugriff, gepatchte Systeme, gute Sicherheitsgrundlagen usw.). ad nauseumso sehr, dass sie die Verteidiger mit Schlagzeilen-Tweets wie "Wir sind nicht einmal in der Lage, uns an die Grundregeln zu halten, wie sollen wir das dann tun? ??' Die Verteidiger wurden von Tränen und Schuldgefühlen überschwemmt, zu endlosen Schwachstellenoffenbarungen, Urlaubsalpträumen und "McAfee LOL"-Spott von Team Rot verurteilt, während ein ununterbrochener Strom von Hashdumps in einem Nebel von Shellibrations, die mit Red Bull infundiert wurden, über den Bildschirm flimmerte. Der Jubel sollte jedoch nur von kurzer Dauer sein.

Um nicht zurückzustehen, tat die Verteidigung das, was sie immer tut, und manchmal auch gut: Sie passte sich an. Als wären sie aus der Schüchternheit der Pubertät herausgewachsen, erkannten die Verteidiger, dass die VA sie nicht retten würde, und begannen, massenhaft interne Zeitungen zu schlucken, entschlossen, die Sichtbarkeit dort zu erhöhen, wo es wichtig war (damals waren das die Endpunkte). Die Branche wachte auf in Masse zu wichtigen Ereigniscodes wie 4688, 4662 und 5145 und erfuhren so, dass die wertvollen Daten, nach denen sie die ganze Zeit gesucht hatten, nur auf das richtige GPO warteten, um sie zu aktivieren.

Gigabytes und mehr Protokolle wurden generiert, alle gut verstaut in Open-Source- und kommerziellen SIEMs wie Splunk, Graylog und ELK Stack. Die Verpflichtungen des Purple Teams traten auf den Plan, verbesserten und verfeinerten die Erkennung und legten dem SOC zum ersten Mal hochwertige Dashboards für Warnmeldungen in die Hände. Und die SOCs, zumindest diejenigen, die diese Dashboards nicht abschafften, weil sie nie etwas unternommen hatten, genossen einen ruhigeren Schlaf.

Aber nicht nur die internen Verteidigungsteams wurden aufmerksam. Auch die Anbieter hatten festgestellt, dass die vorhandenen Sicherheitstools ineffizient waren, wenn es darum ging, ... nun ja, so ziemlich alles zu stoppen, was eine Lücke auf dem Markt für Tools hinterließ, die wirklich funktionierten, um echte Angriffe zu erkennen und zu verhindern (und nicht nur, um "Mimikatz zu stoppen" lol). Neue Produkte wurden auf den Markt gebracht, die zum ersten Mal in der Geschichte den ultimativen Traum der Unternehmen von der Infosicherheit zu verwirklichen schienen: gute Sicherheit, die man kaufen konnte. EDR kam mit unglaublicher Kraft auf den Markt und wurde in nur wenigen Jahren begeistert angenommen. Die große Mehrheit der Kunden, gegen die wir rote Teams führen, verwendet heute im Wesentlichen eines der beiden Endpunktkontrollsysteme: CrowdStrike oder Microsoft. Beide sind effektiv. Schließlich haben die Verteidiger erkannt, was schon immer wahr war: Das Schlachtfeld gehört ihnen.

Das rote Team, das seit Jahren daran gewöhnt war, dass ihm die Passwörter ausgehändigt wurden (im Fall des CCDC wortwörtlich, was unserem Ego nicht gut tat), wurde in die Ecke gedrängt und begann ungeschickt, die Kunst der Neugier neu zu erlernen, nachdem es angesichts der unaufhörlichen Versorgung der Anrufbeantworter mit Protokollen lethargisch geworden war. Da sie es nicht gewohnt war, entdeckt zu werden, führte Team Rot das "Geisterprotokoll" ein und begann, die TTPs in den sozialen Medien zu verschleiern. Die Simulation von Gegnern ("AdSim") und die Verpflichtungen des roten Teams rückten in den Vordergrund und gaben dem roten Team mehr Zeit, sich an die Abwehr anzupassen und nach neuen Angriffsmethoden zu suchen. Obwohl sie für das Ego verletzend waren, zwangen die massiven Verbesserungen der Abwehrmaßnahmen die führenden roten Teams dazu, erhebliche Investitionen in ihr internes Know-how und ihre Tools zu tätigen und diese folglich dazu zu nutzen, die Abwehrmaßnahmen ihrer Kunden auf sehr effektive Weise zu verbessern. Organisationen, die diese Situation für sich nutzten, profitierten von einer erheblichen Verbesserung ihrer Sicherheitsposition.

Trotz allem, was über OST gesagt wird, und trotz der kleinlichen, aber urkomischen Debatten über C2 und Begriffe wie "Bypass" hat sich die rot/blaue Methodik immer wieder bewährt. Verbessere das rote Team und du wirst das blaue Team verbessern. Fast gleichzeitig erkannten die Verteidiger, dass dem roten Team wirklich ihr Interesse am Herzen lag und dass die fabrizierte Gegnerschaft wirklich eine gute Sache war. Die roten Teams kamen zu dem richtigen Schluss, dass eine gute Verteidigung unglaublich ist (vielleicht sogar ein wenig... lustig...), und dass die Verteidiger, wenn sie darauf achten, dem roten Team helfen werden, neue Techniken zu entwickeln. Wie kann dieser Verbesserungszyklus fortgesetzt werden?

Um mit der scheinbar täglich besser werdenden Verteidigung Schritt zu halten, haben die roten Teams mit der ersten logischen Maßnahme reagiert: mehr Einsatzzeit. Das funktioniert bis zu einem gewissen Grad, und einige Kunden würden sich gerne für einen mehrmonatigen Einsatz des roten Teams verpflichten, da sie vor allem Wert auf Realismus und Stealth legen. Aber Stealth erfordert Zeit, und nicht jeder kann sich die niedrigsten und langsamsten Bewegungen eines Netzwerks leisten. Der Zeitvorteil wird weiterhin durch verhaltensbasierte Erkennung ausgehöhlt, die die Benutzeraktivität nun in Wochen und Monaten bewertet. Rote Teams brauchten eine Möglichkeit, gezielten Wert zu liefern, ohne sich zu ruinieren.

In die vermeintliche Lücke stoßen

Bewertungen von mutmaßlichen Verstößen (Predicted Breach, PB) sollen ein Bedrohungsszenario nachahmen, in dem sich ein Angreifer bereits auf die eine oder andere Weise Zugang zum internen Netzwerk verschafft hat. Aber von welchen Szenarien sprechen wir hier? Tut dies nicht bereits ein interner Pentest? Ja, in gewisser Weise schon. Das nächstliegende Bedrohungsszenario, das von einem standardmäßigen internen Pentest nachgeahmt wird, ist ein physisches Eindringen, aber selbst in diesem Fall liegt der Schwerpunkt auf der Abdeckung. Mit anderen Worten: Es geht darum, wie viele verwundbare Eskalationspfade entdeckt werden können und welche Schwachstellen auf dem Weg dokumentiert wurden, die diese Pfade beenden können, wenn sie behoben werden. Tun Sie all dies so schnell wie möglich, nehmen Sie so viele Systeme wie möglich ins Visier und liefern Sie die Ergebnisse dann präzise und professionell.

Die Sicherheitshaltung eines Unternehmens kann von weit weg, und viele haben das auch getan, indem sie einfach die Ergebnisse ihres Pentests korrigiert haben. Ironischerweise unterschätzen die meisten großen Pentester, die ich kenne, ihre eigenen Fähigkeiten gravierend. Das ist vielleicht auch gut so (zumindest in geringem Maße), denn die Leistung eines Pentests in Verbindung mit einer unkontrollierten Moral kann leicht in kriminelle Aktivitäten umschlagen, wie der Anführer von LockBit bei einem Treffen im Jahr 2022 andeutete interview mit vx-underground.

Ich entschuldige mich für diesen Exkurs. Worin besteht also der materielle Unterschied zwischen AB und Pentesting? Kurz gesagt, und ich habe bereits darauf hingewiesen, ist Pentesting Deckung-Emissionen, während AB auf Deckung beruht Szenario-Emissionen auf der Grundlage eines Szenarios. Sind ABs eine "Weiterentwicklung" der Pentests? Nicht ganz richtig. Penetrationstests werden weiterhin nützlich sein, solange es Unternehmensumgebungen gibt. Wie bereits erwähnt, haben sich die Kontrollen jedoch erheblich verbessert, was offensive Shops dazu zwingt, ihre Dienste anzupassen. Selbst Unternehmen, die noch Nicht-IT-Benutzer mit lokalen Administratorrechten haben, können einen EDR kaufen und von einer sofortigen Verbesserung der Sicherheit ihrer Zugangspunkte profitieren, was wiederum zu Frustration bei Red Teams führt. Das bedeutet einfach, dass Red Teams das Intrusion Goal, d. h. szenariobasierte Tests, für reife Organisationen einschränken sollten.

Bei TrustedSec haben wir mehrere Bedrohungsszenarien identifiziert:

• Verletzung des Umfangs
• Unzufriedener Arbeitnehmer/böswilliger Eingeweihter
• Erfolgreicher Social-Engineering-Angriff
• Missbrauch von Vertrauen
• Physischer Diebstahl oder Verlust eines internen Geräts
• Physische Intrusion

Es handelt sich natürlich um hochrangige Kategorien der Kompromittierung und sie sollen es auch sein. Sie überschneiden sich auch. Beispielsweise ist es leicht, sich einen erfolgreichen Social-Engineering-Angriff vorzustellen, der zu einem Missbrauch von Anmeldeinformationen führt. Die Red Teams machen das ständig. Abgesehen davon mussten einige Linien gezogen werden, und wir haben versucht, dies so sauber wie möglich zu tun.

Wie sieht es mit Ransomware aus? Ich höre die Frage deutlich und Kunden haben mir oft ähnliche Fragen gestellt. Ist Ransomware kein valides Bedrohungsszenario? Die direkte Antwort lautet: Nicht ganz. Ja, Ransomware stellt eine Bedrohung mit großen Auswirkungen dar. Ergebnis eines Kompromisses, aber er ist nicht die kompromittiert selbst. Der Verlust von Daten ist ebenfalls ein mögliches Ergebnis, stellt aber kein Bedrohungsszenario dar. Es ist wichtig, unsere Begriffe und das, was wir darunter verstehen, klar zu kategorisieren. Darüber hinaus ähneln die Voraussetzungen für den Einsatz von Ransomware den standardmäßigen Erhöhungszielen im Rahmen einer AB- oder Red-Team-Übung. Bevor eine Ransomware im großen Stil eingesetzt werden kann, muss der Angreifer über hohe Privilegien auf den Zielhosts verfügen. Kurz gesagt: Korrigieren Sie die bei einer AB-Übung entdeckten Eskalationspfade, und Sie werden die "Explosion" eines Ransomware-Einsatzes "eindämmen". Bitten Sie Ihren freundlichen Red Teamer, die mit den Sicherungssystemen verbundenen Pfade zu entdecken. xD

Szenarien

TrustedSec hat sieben AB-Szenarien entwickelt, die diese Bedrohungsszenarien abdecken sollen. Wenn Sie sich die Tabelle unten ansehen, könnten Sie denken, dass einige Szenarien nicht zu Ihrem Bedrohungsmodell gehören. Dies ist völlig normal (oder sogar fragwürdig), da das Ziel darin besteht, verschiedene Arten von gezielten Tests bereitzustellen, die sich mit Ihrem Bedrohungsmodell überschneiden.

1) Kompromiss der einheitlichen Unterschrift

• Bedrohungsszenario(s): Unzufriedener Arbeitnehmer, erfolgreicher Social Engineering (SE)-Angriff, Identitätsmissbrauch
• Beschreibung: Die Kompromittierung eines O365-Kontos simulierend, wird TrustedSec versuchen, auf die an den O365-Tenant angehängten Dienste von Drittanbietern zuzugreifen, indem es das SSO verwendet, die zugänglichen Informationen exfiltriert und analysiert. Eine Analyse des internen Netzwerks wird, wenn überhaupt, nicht durchgeführt.
• Mindestdauer: 1 Woche
• Anforderungen des Kunden :
  • Informationen über das SSO-Portal (Okta, Ping, O365), auf das Sie abzielen.
  • Gültige Anmeldeinformationen, die einen kompromittierten Benutzer repräsentieren. Für einen maximalen Wert empfiehlt TrustedSec, einen (vorzugsweise) aktiven Mitarbeiter oder ein kürzlich gekündigtes Konto mit intakten Zugriffsrechten zu verwenden.
  • Kontaktstelle, die bei Bedarf einen MFA-Zugang bereitstellt.

2) Dreh- und Angelpunkt des Netzwerks

• Bedrohungsszenario(s): Erfolgreiche Verletzung des Netzwerkperimeters, unzufriedener Arbeitnehmer, erfolgreicher Angriff auf ES, Missbrauch von Befugnissen
• BeschreibungTrustedSec wird mit einem vom Kunden bereitgestellten Mitarbeiter zusammenarbeiten, um die Kompromittierung zu simulieren, die durch einen erfolgreichen Social-Engineering-Angriff erreicht werden kann. Mithilfe einer autorisierten Infrastruktur und Nutzlasten wird der C2 des Rechners eines Benutzers aufgebaut und dazu verwendet, das Netzwerk in der gezielten Verfolgung eines einzigen Nachnutzungsziels anzugreifen. Der Schwerpunkt der Mission liegt auf den Nachbetriebsaktivitäten und der Aufdeckung, nicht auf ausweichenden Endpunktkontrolltests.
• Mindestdauer: 2 Wochen
• Anforderungen des Klienten:
  • Eines der folgenden Elemente:
    • Ein interner Mitarbeiter (vorzugsweise kein IT-Spezialist), der als kompromittierter Endpunkt fungiert. TrustedSec wird mit dem Mitarbeiter zusammenarbeiten, um einen nicht aufdringlichen C2 einzurichten.
    • Ein Laptop und/oder ein Citrix VDI-Image mit Domänenkennungen (Benutzername/Passwort) mit einem Zugang, der eine bestehende berufliche Rolle widerspiegelt.
  • TrustedSec wird vorab die Details der Nutzlast und der Infrastruktur für autorisierte Benutzer einreichen.

3) Kompromittierung und Drehen der Endpunkte

• Bedrohungsszenario(s): Erfolgreiche Verletzung des Netzwerkperimeters, unzufriedener Arbeitnehmer, erfolgreicher Angriff auf ES, Missbrauch von Befugnissen
• Beschreibung: TrustedSec wird mit einem vom Kunden bereitgestellten Mitarbeiter zusammenarbeiten, um die Kompromittierung zu simulieren, die durch einen erfolgreichen Social-Engineering-Angriff erreicht werden kann. Mithilfe einer angepassten Infrastruktur und ausweichenden Payloads wird der C2 der Maschine des Benutzers aufgebaut und dazu verwendet, das Netzwerk heimlich und gezielt anzugreifen, um Ziele nach dem Betrieb zu erreichen.
• Mindestdauer: 3 Wochen
• Anforderungen des Klienten:
  • Ein interner Mitarbeiter (vorzugsweise kein Informatiker) wird die Rolle des kompromittierten Endpunkts übernehmen. *TrustedSec wird mit dem Mitarbeiter zusammenarbeiten, um eine nicht-intrusive C2 einzurichten.
  • Der Client kann zwei Ziele auswählen (Anwendung, Server, IP-Adresse, Zugriffsebene).

*Hinweis: Ein "Reserve-Laptop" oder "ein goldenes Bild" mit generischen Domänenkennungen wird für diese Bewertung nicht unterstützt, da sich die Angreifer bei der Kenntnis der Situation stark auf die tägliche Nutzung verlassen.

4) Kompromittierung des Umfangs

• Bedrohungsszenario(s): Erfolgreiche Verletzung des Netzwerkperimeters, erfolgreicher SE-Angriff
• BeschreibungTrustedSec simuliert die Kompromittierung einer externen Webanwendung, erwirbt C2 von einem designierten Web- oder Datenbankserver (erfolgreicher SQL-Injection-Angriff) und versucht, von einer Vielzahl von Standpunkten aus eine Lücke in einer Zielanwendung oder Netzwerkumgebung zu öffnen. Dies kann verschiedene Formen annehmen, wie z. B. eine Webshell oder einen kompletten C2.
• Mindestdauer: 3 Wochen
• Anforderungen des Klienten:
  • Die Ausführung eines Implantats auf einem Webserver oder einem Datenbankserver, der im Kontext des Anwendungskontos ausgewählt wurde.
  • Je nach den Regeln der Firewall kann eine Ausnahmegenehmigung erforderlich sein, um den erforderlichen ausgehenden Datenverkehr zuzulassen.

5) DevOps

• Bedrohungsszenario(s): Unzufriedener Arbeitnehmer, Vertrauensmissbrauch
• Beschreibung: Mithilfe eines vom Kunden bereitgestellten Laptops verbindet sich TrustedSec mit dem internen Netzwerk und sucht nach Schwachstellen im Zusammenhang mit Entwicklungsvorgängen, z. B. Repo-Privilegien, hartcodierte Anmeldeinformationen und unangemessener Zugriff auf die Infrastruktur. Die Angriffe sind sehr gezielt auf die DevOps-Umgebung des Kunden und die entsprechende Infrastruktur gerichtet.
• Mindestdauer: 3 Wochen
• Anforderungen des Klienten:
  • Ein Konto mit Entwicklerrechten
  • Laptop mit der Standard-Entwicklerversion
  • Fernzugriff auf die DevOps-Umgebung

6) Kompromittierung von Arbeitsplätzen

• Bedrohungsszenario(s): Unzufriedener Arbeitnehmer, physischer Diebstahl oder Verlust eines Geräts
• Beschreibung: TrustedSec testet eine physische Workstation oder ein Citrix VDI-Abbild auf eine Vielzahl von falschen Sicherheitskonfigurationen, einschließlich Hardware- und Software-Schwachstellen, falls vorhanden. Der Betrieb ist in der Regel auf den lokalen Rechner beschränkt und überschreitet nicht die Netzwerkgrenzen. Jegliche bereitgestellte Hardware kann nach Ermessen von TrustedSec disassembliert werden.
• Mindestdauer: 2 Wochen
• Anforderungen des Klienten:
  • Laptop mit Standard- und/oder Citrix VDI-Zugang
  • Anmeldekennungen für Nicht-Administratoren
  • (Optional) Fernzugriff auf das Unternehmensnetzwerk

7) Physische Vergewaltigung

• Bedrohungsszenario(s): Unzufriedener Arbeitnehmer, erfolgreiche physische Intrusion
• BeschreibungTrustedSec simuliert eine erfolgreiche physische Kompromittierung, indem es ein spezielles Gerät sendet, das den meisten NAC-Systemen entgehen kann und keine Befreiung von ausgehenden Firewalls erfordert. Als echtes Stealth-Gerät gedacht, wird TrustedSec die entsprechende Verbindung nutzen, um das Netzwerk mithilfe von Standardtechniken zu kompromittieren.
• Mindestdauer: 2 Wochen
• Anforderungen des Klienten:
  • Ein physischer Rechner mit anhaltender interner Netzwerkkonnektivität
  • Nähe zu einem zellularen LTE-Dienst

Schlussfolgerung

Ich hoffe, dieser Artikel hat Sie zum Nachdenken über Ihr eigenes Bedrohungsmodell angeregt und darüber, wie es auf Ihre nächsten offensiven Testrunden angewendet werden könnte, und wenn ich Sie dabei zum Lächeln gebracht habe, ist das ein glücklicher Bonus. Wenn Sie Teil eines internen Teams sind, können Sie diese Szenarien zu Ihrem Vorteil biegen und anpassen, da Sie zweifellos über mehr Zeit und Fähigkeiten verfügen als ein Dritter.

Und wenn Sie mir so lange gefolgt sind, verdienen Sie einen Spaziergang oder einen Schluck, ganz wie Sie wollen.

Auf Ihr Wohl!