Aus dem Tagebuch eines Red Teams – Teil 12

The End

Ein Jahr mit vielen Erzählungen aus unseren Red-Teaming-Projekten ist vergangen. Mit diesem Artikel endet die Serie „Aus dem Tagebuch eines Red Teams“ – aber nicht, ohne einen Blick zurückzuwerfen und einen Ausblick zu geben!

Rückblick

In „Bitte, bitte NICHT updaten!“ bangten wir (ausnahmsweise!), dass unser Kunde nicht zu schnell Sicherheitsupdates einspielen würde, um eine aktuelle Schwachstelle zu unseren Gunsten im Projekt ausnutzen zu können.

Noch Adrenalin-lastiger wurde es für uns bei unseren „Einbrüchen“ in Gebäude. In „Schiebetüre öffne dich – nachts im Gebäude“ sind wir – ohne Einschlagen von Scheiben – durch eine eigentlich verschlossene Schiebetüre ins Gebäude eingedrungen. Und es schien, trotz Überwachungskameras, niemanden gestört zu haben. In „Die beste Firewall hilft nichts, wenn Türen offenstehen“ war der Protagonist ebenso eine Türe und wir erzählten, wie ein kleines Stückchen Styropor die Sicherheitsmechanismen einer Firewall aushebeln kann.

Davon, dass Sicherheitsdienste leider häufig wortwörtlich kommen und gehen, haben wir in „Die (Un-)Wirksamkeit von Sicherheitsdiensten“ berichtet. Dass manchmal auch am helllichten Tag niemand Verdacht schöpft, was hier eigentlich passiert, wurde in „Warum wir vor Warnwesten warnen“ deutlich, wo wir stundenlang an einem Kartenlesegerät rumbastelten. Aber wir lernten schnell: „Alles ist gut, solange du eine gelbe Warnweste trägst!“.

Im Artikel „Erfolgreich dank Passwort in Datei auf Desktop“ kämpften wir mit einer verschlüsselten Passwortmanager-Datei, bis wir bemerkten, dass wir den Wald vor lauter Bäumen nicht sahen und das in diesem Projekt heißbegehrte Datenbank-Passwort einfach „daneben“ in einer Textdatei auf dem Desktop herumlag.

Wie unerlässlich es ist, die Effektivität etablierter Abwehrmechanismen zu testen, wurde in den Erzählungen „Wie der späte Phisher ein Passwort fing“, „Das aufmerksame, unaufmerksame Blue Team“ und „Wenn die Katze die Maus nur halb erwischt“ ersichtlich. Zwar wurden wir in allen drei Fällen erkannt, konnten dabei aber Schwächen und Lücken in der Verteidigung aufdecken, durch die (echte) Angriffe hätten erfolgreich fortgesetzt werden können.

Schließlich schlossen wir die Serie in den vergangen beiden Artikeln mit einem tiefen Einblick in ein Projekt ab. Der Kunde selbst schrieb uns „Die Anleitung zum Erfolg (Teil 1 & Teil 2)“, die uns half, von außen in das interne Firmennetz einzudringen und dort die gesamte Infrastruktur zu kompromittieren.

Schneidern eines Red-Teaming-Projekts

So vielfältig die Geschichten sind, so vielfältig und verschieden sind in Red-Teaming-Projekten auch die Ziele und Schwerpunkte. Ein Red-Teaming-Projekt gleicht selten dem anderen und wird stets auf die Anforderungen und Bedürfnisse des Kunden zugeschnitten.

Im Wesentlichen sind wir in den Anekdoten aus den Blogartikeln aus folgenden Ausgangssituationen in die Projekte gestartet:

1. Aus der „realen“ Welt, um in Gebäude hineinzugelangen (Artikel 2, 3, 5 und 8)
2. Aus dem Blickwinkel eines Angreifers aus dem Internet (Artikel 6, 9, 10 und 11)
3. Aus dem Blickwinkel eines Angreifers, der sich bereits im internen Firmennetz befindet, auch Assumed-Breach-Szenario genannt (Artikel 1, 4 und 7)

Für alle Ansätze gibt es gute Gründe. Der Ausgangspunkt des Red Teams muss vor allem mit den Zielen, die im Projekt verfolgt werden, sinnvoll abgestimmt werden. Hierbei spielt nicht zuletzt der zur Verfügung stehende Zeitraum eine wichtige Rolle.

Das Festlegen der Rules of Engagement (RoE), der Spielregeln fürs Red Team, geschieht vor dem Start des Projekts in enger Abstimmung mit dem White Team, also dem kleinen Kreis eingeweihter Personen auf Kundenseite. Darin werden alle Rahmenbedingungen, beginnend mit dem Ausgangspunkt des Red Teams bis hin zu den Projektzielen, festgelegt. Ziele für das Red Team können beispielsweise sein:

• Zugriff auf das interne Netzwerk erlangen
• Identifizieren und Kompromittieren von bestimmten, für das Unternehmen wichtigen Systemen, wie der Backup-Infrastruktur, Datenbank-Server oder Produktionsmaschinen

Außerdem werden Kontaktinformationen zu Ansprechpartnern ausgetauscht und Zeiten abgestimmt. Falls im Projekt relevant, erhält jedes Mitglied des Red Teams zudem einen sogenannten „Get out of Jail“-Brief, der, sofern man ertappt wird, zum Nachweisen der Legitimität des durchgeführten Einbruchsversuchs hilft.

Weiterhin werden in den Rules of Engagement der „Scope“ sowie die erlaubten „Tactics, Techniques and Procedures“ festgelegt:

Klären der erlaubten Angriffsoberfläche („Scope“)

Welche Bestandteile des Unternehmens dürfen während des Projekts durch das Red Team angegriffen werden? Welche werden explizit ausgeschlossen? Beispiele hierfür sind Gebäude, über das Internet erreichbare Systeme und Mitarbeitende (beispielsweise im Rahmen von Phishing-Simulationen).

Tactics, Techniques and Procedures (TTP)

Welche Methodiken und Aktionen sind bei der Projektdurchführung erlaubt? Welche werden explizit ausgeschlossen? Beispiele hierfür sind:

• das Enumerieren der Angriffsoberfläche des Unternehmens über öffentlich verfügbare Informationen, auch OSINT genannt
• sogenanntes Lockpicking, um Schlösser von Türen zu öffnen
• das Ausnutzen technischer Schwachstellen
• das Kontaktieren von Mitarbeitenden in Phishing-Kampagnen

Und was sich für uns von selbst versteht: Moralisch verwerfliche Aktionen setzen wir nie ein. Genauso wenig führen wir beabsichtigt destruktive Aktionen durch.

Weitere Absprachen

Über diese Standard-Regeln hinaus lassen sich individuell natürlich weitere Regeln festlegen, letztlich ist hier nichts in Stein gemeißelt.

Eine gängige Absprache ist, dass das Red Team dem White Team gezielte Fragen stellen darf, sofern dadurch eine Effizienzsteigerung des Projekts erreicht wird. Dies ist beispielsweise dann sinnvoll, wenn das Red Team bestimmte Informationen durch aufwändige Recherchen zwar selbst sammeln könnte, dies aber zeitlich in keinem Verhältnis zur Projektdauer stehen würde.

Ausblick: Wie es weitergehen kann

Wir freuen uns über Feedback zu dieser Serie – egal ob per Mail, über LinkedIn oder telefonisch!

Falls Sie Interesse haben, ein Red-Teaming-Projekt durchzuführen oder eine erste Beratung zu diesem Thema wünschen, zögern Sie nicht, uns zu kontaktieren!

Telefon: +49 731 20 589-26
E-Mail: pentests@it-sec.de

Nina Wagner im Namen des Red Teams der it.sec
Senior IT-Security Consultant / Penetration Testing