Red Teaming Fallstudie: Verborgene Risiken aufdecken
Braucht unsere Organisation Red Teaming?
Stellen Sie sich ein großes Unternehmen mit tausenden Mitarbeitenden vor, das regelmäßig in Sicherheit investiert. Dennoch blieb die Frage: Was passiert, wenn ein entschlossener, gut organisierter Angreifer uns gezielt ins Visier nimmt? Innerhalb von acht Wochen simulierte unser Red Team einen realen Angriff ohne enge Einschränkungen. Wir führten eine Phishing‑Kampagne über eine eigene Domain durch (Ergebnis: 260 Zugangsdaten), nutzten OSINT, um Kontrollen zu umgehen, setzten Pretexting, Kartenduplikation und ein „Rogue‑Gerät“ ein und missbrauchten schließlich eine fehlkonfigurierte Zertifizierungsstelle (CA) in der Domäne, um Domain‑Admin‑Rechte zu erlangen. Der Test deckte kritische menschliche, technische und physische Schwachstellen auf – und zeigte: Nur umfassendes Red Teaming legt verborgene Risiken offen.
Was ist Red Teaming?
Red Teaming bewertet den Sicherheitszustand einer Organisation ganzheitlich – vom digitalen Perimeter bis zum menschlichen Verhalten. Es simuliert, wie ein motivierter Angreifer oder eine APT‑Gruppe vorgehen würde, wenn Ihre Firma ohne Zeit‑ und Ressourcenlimit zum Ziel wird.
Wie führt Haxoris solche Tests durch?
Wir investieren viel in Planung und Durchführung und orientieren uns an Red‑Teaming‑Methodiken: Identifikation von Schwachstellen, Risikobewertung und Wirksamkeitsprüfung bestehender Maßnahmen. Die Bewertung gliedern wir in mehrere verbundene Phasen:
- Informationsgewinnung aus offenen Quellen (OSINT)
- Tests externer Infrastruktur
- Penetrationstests des internen Netzes (zwei Szenarien)
- Physischer Zutritt an mehreren Standorten des Kunden
- Gezielte Phishing‑Kampagne
Wir haben unseren Kunden gehackt!
Gezieltes Red Teaming startet mit EXTERNEN TESTS – allem, was aus dem Internet erreichbar ist. Wir prüften Web‑Applikationen, VPN‑Gateways, Mail‑Server und weitere Dienste: veraltete Software, Fehlkonfigurationen, Code‑Fehler. Der Kunde war gut aufgestellt: aktuelle Server, keine bekannten CVEs, korrekt konfigurierte Firewalls, und IDS/IPS überwachten den Traffic ohne erkennbare Lücken. Auch beim WLAN scheiterten wir – Zugang nur mit Client‑Zertifikaten und MFA.
OSINT zeigte seine Stärke, als wir möglichst viele Informationen über das Unternehmen zusammenführten: Organisationsstrukturen, Namenslisten, IP‑Adressen, Subdomains, Hinweise zu Partnerschaften und Verträgen. Obwohl nur wenige Mitarbeitende die Zugehörigkeit auf LinkedIn angaben, fanden wir über die Unternehmensgröße genügend Profile. Wir kombinierten LinkedIn mit alten Leak‑Daten und validierten E‑Mail‑Adressen. Der Schlüsselmoment: Wir identifizierten das genaue E‑Mail‑Format ([email protected]) durch einen Fehler in einem internen System.
Wir versuchten, den PHYSISCHEN PERIMETER an mehreren Standorten zu überwinden. Beim ersten Besuch kartierten wir Eingänge, Notausgänge, Patrouillenwege der Security und tote Kamerawinkel. Ein Fahrzeug der Feuerinspektion vor dem Gebäude lieferte den Pretext: Nach kurzem OSINT traten wir als „Feuerlöscher‑Inspektion“ auf – Uniformen mit Logo einer echten Firma, Schreiben mit Auftrag – Zugang gewährt. So gelangten wir unkontrolliert in einen Besprechungsraum, fanden hinter dem TV einen versteckten RJ45‑Port, installierten binnen Minuten ein eigenes 4G‑Rogue‑Gerät, versteckten es und verließen unauffällig das Gebäude – ein dauerhafter, leiser Zugang ins interne Netz für die nächste Phase.
Obwohl wir bereits im Netz waren, brauchten wir gültige Domänenzugänge. Auf Basis verifizierter OSINT‑E‑Mails starteten wir eine gezielte PHISHING‑KAMPAGNE – keine Massenmails, sondern personalisierte Angriffe über eine ähnliche Domain. Eine gefälschte Intranet‑Loginseite (getarnt als „neues Prämien‑System“) erfasste die Anmeldedaten; anschließend beendeten wir die Kampagne, um Erkennung zu vermeiden. Die neuen Domänenzugänge öffneten den Weg zu tieferer interner Exposition und anschließender Rechteeskalation.
INTERNE TESTS umfassten ein gestohlenes Gerät imitiert und interne Netztests. In der Zertifizierungsstelle fanden wir die Schwachstelle ESC8: Zertifikate für beliebige AD‑Services anfordern – sogar für den Domain Controller (DC). Wir bestätigten dies mit Certipy, erzwangen mit Netexec (Modul Coerce_Plus) eine Authentisierung des DC gegenüber unserem Relay‑Server und relayten die Aufnahme via NTLMRelayX. Die CA stellte ein DC‑Zertifikat aus – effektiv erhielten wir Domain‑Admin‑Rechte. DA‑Besitz bedeutet die vollständige Kompromittierung von AD – Zugriff auf alle Dienste und sensiblen Daten.
Ergebnisse und zentrale Erkenntnisse
- KOMPROMITTIERTE ANMELDEDATEN: Zielgerichtetes Phishing brachte 260 valide Accounts – Schwächen bei Filtern und Awareness.
- PHYSISCHER ZUGANG ERLANGT: „Falscher“ Inspektor umging Empfang, klonte RFID‑Karten und platzierte ein Rogue‑Gerät – Zugang zum internen Netz.
- RECHTEESKALATION ZUM DOMAIN‑ADMIN: Fehlkonfiguration der CA (ESC8) ausgenutzt → vertrauenswürdiges Zertifikat → volle Admin‑Kontrolle, unentdeckt.
- KEINE ERKENNUNG: Perimeter, IDS/IPS und Logging erfassten unsere Aktivitäten nicht – deutliche Sichtbarkeitslücken.
Unsere Empfehlungen
- Physische Sicherheit und Besuchsprozesse stärken: Barrieren gegen Tailgating, konsequente ID‑ und Besucher‑Kontrollen.
- Regelmäßige Audits aller Vektoren: Perimeter, interne Systeme, externe Dienste, CA und Netz‑Infrastruktur.
- Mitarbeitende zu Phishing und Social Engineering schulen: szenariobasierte Übungen für anhaltende Wachsamkeit.
- Interne Geräte und Verhalten in Echtzeit überwachen: schnelle Erkennung nicht autorisierter Hardware und Netz‑Anomalien.
Cybersicherheit ist nicht nur Technologie – sie ist das Zusammenspiel von Menschen, Prozessen und Werkzeugen. Kontinuierliches Testen, Lernen und Resilienzaufbau sind essenziell, denn Angreifer suchen stets den schwächsten Punkt. Echte Sicherheit beginnt im Bewusstsein und Handeln der Mitarbeitenden.