Skills Red Team: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Red Teaming wird oft auf Exploitation, Malware-Entwicklung oder spektakuläre Active-Directory-Kompromittierungen reduziert. In der Praxis ist das zu kurz gedacht. Ein belastbares Red Team arbeitet wie ein gegnerischer Operator mit klaren Zielen, sauberer Vorbereitung, kontrollierter Durchführung und nachvollziehbarer Auswertung. Technische Tiefe ist Pflicht, aber ohne Prozessdisziplin, OPSEC und präzise Kommunikation wird aus einem technisch starken Operator schnell ein Risiko für das Projekt.

Der Unterschied zwischen Pentest und Red Team liegt nicht nur im Umfang, sondern im Denkmodell. Ein Pentest sucht Schwachstellen systematisch und oft breit. Ein Red Team simuliert einen realistischen Angreifer mit Missionszielen, Zeitdruck, Restriktionen und der Notwendigkeit, unentdeckt zu bleiben. Daraus ergeben sich andere Skill-Schwerpunkte: Zielverständnis, Angriffspfad-Design, Priorisierung, Täuschung, Infrastrukturkontrolle, Detection Awareness und saubere Exit-Strategien.

Wer Red-Team-Skills aufbauen oder glaubwürdig darstellen will, muss technische Fähigkeiten in operative Kategorien übersetzen. Dazu gehören Recon, Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Exfiltration und Impact. Entscheidend ist aber nicht nur, ob einzelne Techniken bekannt sind, sondern ob sie in einer Kette unter realistischen Randbedingungen funktionieren.

Ein gutes Beispiel: Das Ausführen eines bekannten Kerberoasting-Workflows ist kein belastbarer Skill-Nachweis, wenn keine Aussage dazu möglich ist, wann der Angriff sinnvoll ist, welche Logquellen anschlagen, wie Service Accounts priorisiert werden, welche Passwortpolitik den Erfolg beeinflusst und wie die Aktivität in einen größeren Angriffspfad eingebettet wird. Red-Team-Kompetenz zeigt sich an der Qualität der Entscheidungen zwischen den Schritten, nicht nur an den Schritten selbst.

Deshalb werden starke Red-Team-Profile meist an drei Ebenen erkannt. Erstens an technischer Tiefe in Betriebssystemen, Netzwerken, Identitäten und Anwendungen. Zweitens an operativer Reife, also Planung, OPSEC, Infrastruktur und Dokumentation. Drittens an der Fähigkeit, Ergebnisse in verwertbare Erkenntnisse zu übersetzen. Wer diese Skills später in Unterlagen sauber abbilden will, findet ergänzende Orientierung bei Skills Pentester, Technische Skills Cybersecurity und Projekte Red Team.

Ein häufiger Fehler bei der Selbsteinschätzung ist die Verwechslung von Tool-Nutzung mit Kompetenz. Cobalt Strike, Sliver, Mythic, Impacket, BloodHound, Rubeus oder CrackMapExec sind Werkzeuge. Der eigentliche Skill liegt darin, sie kontrolliert, situationsgerecht und mit minimaler Signatur einzusetzen. Wer nur Standardbefehle reproduziert, scheitert schnell, sobald EDR-Regeln, Segmentierung, eingeschränkte Rechte oder unvollständige Sicht auf die Umgebung ins Spiel kommen.

Red-Team-Skills sind deshalb immer Kombinationen aus Wissen, Timing und Fehlerminimierung. Ein Operator muss wissen, welche Technik möglich ist, wann sie sinnvoll ist und welche Nebenwirkungen sie erzeugt. Genau diese Kombination trennt Laborwissen von einsatzfähiger Praxis.

Die technische Basis eines Red Teamers beginnt nicht bei Exploits, sondern bei Systemverständnis. Wer Windows intern nicht versteht, wird Active Directory nur oberflächlich angreifen. Wer Linux-Privilegienmodelle nicht beherrscht, verliert auf Unix-Systemen unnötig Zeit. Wer Netzwerke nur aus Sicht von Portscans betrachtet, erkennt weder Segmentierungsfehler noch Pivot-Möglichkeiten sauber. Und wer Webanwendungen nur auf OWASP-Top-10-Niveau betrachtet, übersieht häufig die Brücke zwischen Applikationsfehlern und Infrastrukturkompromittierung.

Windows ist in vielen Unternehmensumgebungen der zentrale Angriffsraum. Relevante Skills sind unter anderem Authentifizierungsmechanismen wie NTLM, Kerberos, SPNs, Tickets, Delegation, LSASS, DPAPI, SAM, LSA Secrets, GPOs, Scheduled Tasks, Services, WMI, WinRM, PowerShell, AMSI, ETW und Defender-Interaktionen. Ohne dieses Fundament bleiben viele Angriffe reine Befehlsrezepte. Mit diesem Fundament wird klar, warum bestimmte Techniken funktionieren, wann sie scheitern und welche Artefakte sie hinterlassen.

Im Linux-Umfeld geht es nicht nur um sudo-Missbrauch oder SUID-Binaries. Wichtiger ist das Verständnis von PAM, SSH-Agent-Weiterleitung, Cron, systemd, Namespaces, Container-Runtimes, Dateirechten, Capabilities, Kernel-Angriffsfläche und typischen Fehlkonfigurationen in Automatisierungs- und Deployment-Prozessen. Gerade in hybriden Umgebungen entstehen Angriffspfade oft an den Übergängen zwischen Linux-Servern, CI/CD-Systemen, Secrets und Cloud-Identitäten.

Netzwerkverständnis ist für Red Teams elementar. Dazu gehören Routing, NAT, VLANs, ACLs, Proxying, DNS, SMB, LDAP, RDP, WinRM, HTTP/S, mTLS, VPN-Technologien und typische Egress-Kontrollen. Ein Operator muss erkennen, welche Kommunikationspfade realistisch sind, wie Beaconing unauffällig gestaltet wird und welche Protokolle in einer Umgebung normal wirken. Wer nur auf direkte TCP-Verbindungen setzt, fällt in restriktiven Netzen schnell aus.

• Windows- und Linux-Internals verstehen, nicht nur Befehle auswendig lernen
• Authentifizierung, Autorisierung und Identitätsbeziehungen analysieren können
• Netzwerkpfade, Segmentierung und Egress-Beschränkungen praktisch auswerten
• Web-, API- und Infrastrukturfehler zu vollständigen Angriffspfaden verknüpfen

Bei Anwendungen reicht es nicht, SQL Injection oder XSS zu kennen. Relevant ist die Frage, wie aus einem Applikationsfehler operativer Mehrwert entsteht. Ein SSRF kann Cloud-Metadaten offenlegen. Ein schwach geschütztes Admin-Panel kann Zugang zu Secrets liefern. Ein Dateiupload kann in RCE enden. Ein IDOR kann interne Benutzerstrukturen offenlegen, die später für Password Spraying oder Social Engineering genutzt werden. Red-Team-Skills zeigen sich dort, wo technische Domänen miteinander verbunden werden.

Wer diese Grundlagen aufbaut, sollte sie nicht isoliert betrachten. Ein starkes Profil entsteht aus der Verbindung von Host-, Netzwerk- und Identitätswissen. Ergänzend dazu lohnt der Blick auf Skills Blue Team, weil Detection-Logik, Telemetrie und Incident-Response-Denken die Qualität offensiver Entscheidungen deutlich verbessern.

Viele Red-Team-Operationen scheitern nicht an Privilege Escalation oder Lateral Movement, sondern bereits in der Anfangsphase. Recon und Initial Access werden oft unterschätzt, weil sie weniger spektakulär wirken als Post-Exploitation. Tatsächlich entscheidet sich hier, ob eine Operation realistisch, kontrolliert und unauffällig startet oder schon früh unnötige Aufmerksamkeit erzeugt.

Recon bedeutet nicht nur OSINT-Sammlung. Es geht um Hypothesenbildung. Welche Tochtergesellschaften existieren? Welche Domains, Subdomains, Mail-Gateways, VPN-Endpunkte, Cloud-Tenants und Drittanbieter sind sichtbar? Welche Technologien werden eingesetzt? Welche Rollen und Namenskonventionen lassen sich ableiten? Welche externen Systeme liefern Hinweise auf interne Identitätsstrukturen? Gute Recon-Arbeit reduziert späteres Raten und erhöht die Präzision von Angriffspfaden.

Initial Access kann technisch, sozial oder kombiniert erfolgen. Dazu gehören externe Schwachstellen, Passwortangriffe, Token-Missbrauch, Fehlkonfigurationen in Cloud-Diensten, exposed Management Interfaces, Lieferkettenpfade oder Phishing. Entscheidend ist die Auswahl des Pfads mit dem besten Verhältnis aus Erfolgschance, Realismus und Detektionsrisiko. Ein lauter Exploit gegen ein gepatchtes Gateway ist schlechter als ein präziser Angriff auf schwache MFA-Ausnahmen oder ein schlecht segmentiertes Partnerportal.

Ein typischer Anfängerfehler ist zu frühes aktives Scanning. Breite Nmap-Scans, aggressive Directory Enumeration oder unkontrollierte Passwortversuche erzeugen Signale, bevor überhaupt klar ist, welche Ziele priorisiert werden sollen. In realen Operationen ist Zurückhaltung oft wirksamer als Geschwindigkeit. Erst wenn die Hypothese steht, wird aktiv geprüft. Nicht umgekehrt.

Auch Phishing wird häufig falsch verstanden. Der Skill liegt nicht im Versand einer Mail, sondern in Zielgruppenauswahl, Vorwand, Infrastruktur, Payload-Entscheidung, Telemetrie-Minimierung und Follow-up. Ein glaubwürdiger Pretext ohne saubere Domänenhygiene, SPF/DKIM/DMARC-Abstimmung oder Redirect-Plan ist operativ schwach. Ebenso schwach ist ein technisch perfekter Mailflow ohne realistischen Kontext für die Zielperson.

Ein robuster Initial-Access-Workflow beginnt mit Zieldefinition, Annahmen und Abbruchkriterien. Danach folgt die Auswahl der Methode, die Vorbereitung der Infrastruktur, die Testphase gegen eigene Kontrollsysteme und erst dann die Durchführung. Jeder Schritt muss dokumentiert werden, damit später nachvollziehbar bleibt, warum ein Pfad gewählt wurde und welche Alternativen verworfen wurden.

Wer Initial Access glaubwürdig trainieren will, sollte eigene Szenarien aufbauen: extern erreichbare Webanwendung, VPN mit MFA-Ausnahmen, O365-ähnliche Identitätsumgebung, Mailflow, Proxy und Logging. Solche Umgebungen lassen sich im Homelab Cybersecurity vorbereiten und als belastbare Nachweise in Portfolio Cybersecurity oder Github Cybersecurity Bewerbung dokumentieren, sofern keine sensiblen Inhalte offengelegt werden.

Nach dem ersten Zugriff beginnt die Phase, in der technische Tiefe sichtbar wird. Post-Exploitation ist kein wahlloses Ausführen bekannter Tools, sondern kontrolliertes Arbeiten entlang eines Angriffspfads. Das Ziel ist nicht, möglichst viele Hosts zu berühren, sondern mit minimaler Exposition die für die Mission relevanten Rechte, Systeme und Daten zu erreichen.

Privilege Escalation muss immer kontextbezogen erfolgen. Lokal auf Windows können schwache Service Permissions, unquoted service paths, Token-Impersonation, fehlerhafte ACLs, AlwaysInstallElevated, Treiberprobleme oder EDR-Lücken relevant sein. In Linux-Umgebungen sind sudo-Regeln, Dateirechte, Container-Escapes, Kernel-Schwachstellen oder falsch delegierte Automatisierungsrechte typische Pfade. Entscheidend ist die Bewertung: Welche Methode ist stabil, welche ist laut, welche hinterlässt Artefakte, welche ist reversibel?

Credential Access ist einer der sensibelsten Bereiche. Das Auslesen von LSASS, SAM, Browser-Secrets, DPAPI-Material, Kerberos-Tickets oder Cloud-Tokens kann operativ wertvoll sein, ist aber oft stark überwacht. Gute Operatoren prüfen zuerst, ob weniger invasive Wege existieren: gespeicherte Konfigurationen, Service-Accounts, Deployment-Secrets, Session-Artefakte, API-Tokens, Passwort-Manager-Integrationen oder Zugriff über delegierte Rechte. Nicht jede Umgebung erfordert sofort Mimikatz-ähnliche Ansätze.

Lateral Movement ist ebenfalls mehr als PsExec oder WMI. Die Wahl des Protokolls hängt von Rechten, Segmentierung, Logging und Normalverhalten ab. WinRM kann in Admin-Umgebungen normal wirken, in anderen Netzen aber sofort auffallen. RDP erzeugt andere Artefakte als SMB-basierte Ausführung. Scheduled Tasks, Services, DCOM, Remote Registry oder Remote PowerShell haben jeweils eigene Vor- und Nachteile. Ein sauberer Operator kennt diese Unterschiede und wählt nicht nach Bequemlichkeit.

Besonders in Active Directory ist Pfadlogik entscheidend. Ein kompromittierter Benutzer ist nicht automatisch wertvoll. Relevant sind Gruppenmitgliedschaften, lokale Admin-Rechte, Session-Standorte, Delegationsbeziehungen, ACL-Missbrauch, Zertifikatsdienste, Backup-Systeme, Management-Server und Tiering-Brüche. BloodHound-Daten sind nur dann nützlich, wenn sie mit realen Betriebsabläufen abgeglichen werden. Ein theoretischer Pfad über fünf Systeme ist operativ schlechter als ein unauffälliger Pfad über ein schlecht gehärtetes Jump-System.

Ein häufiger Fehler ist das Sammeln von Rechten ohne Zielbezug. Wer Domain Admin erreicht, aber dabei unnötig viele Systeme berührt, hohe Telemetrie erzeugt und keine saubere Begründung für den Pfad liefern kann, arbeitet ineffizient. In vielen Übungen ist ein begrenzter, realistischer Zugriff mit sauberer Nachvollziehbarkeit wertvoller als maximale Eskalation.

Praxisreife zeigt sich auch im Umgang mit Fehlschlägen. Wenn ein Dump blockiert wird, muss klar sein, welche Alternativen bestehen. Wenn WinRM nicht erreichbar ist, muss ein anderer Kanal vorbereitet sein. Wenn ein Host EDR-seitig aggressiv reagiert, darf die Operation nicht in hektisches Trial-and-Error kippen. Genau hier trennt sich reproduzierbares Handwerk von improvisierter Tool-Nutzung.

OPSEC ist kein Zusatzthema, sondern Kernkompetenz. Viele technisch gute Angriffe scheitern an schlechter Infrastruktur, wiederverwendeten Artefakten, unpassenden Kommunikationsmustern oder unnötig auffälligem Verhalten. Wer Red Teaming ernsthaft betreibt, muss verstehen, dass jede Aktion eine Signatur erzeugt: im Netzwerk, auf dem Host, in Identity-Systemen, in E-Mail-Gateways und im Verhalten der Zielpersonen.

Zur Infrastruktur gehören Domains, Redirectors, C2-Server, Zertifikate, Hosting-Provider, DNS-Konfiguration, Traffic-Profiles, Payload-Delivery, Logging auf eigener Seite und Trennung von Rollen. Ein häufiger Anfängerfehler ist die direkte Kommunikation zwischen Implantat und Teamserver. Redirectors, Domain Fronting-Alternativen, Header-Anpassungen, Sleep/Jitter-Strategien, Kill-Switches und saubere Rotation von Artefakten sind Standardüberlegungen, keine Kür.

Auch die Wahl des C2-Frameworks ist nur ein Teil des Bildes. Wichtiger ist, wie Profile angepasst werden, welche Module wirklich benötigt werden und welche Standardartefakte entfernt oder ersetzt werden. Default-Konfigurationen sind in vielen Umgebungen schnell erkennbar. Wer bekannte User-Agents, Standard-URIs, typische Sleep-Werte oder unveränderte Loader nutzt, liefert Detection-Teams unnötig einfache Treffer.

• Infrastruktur strikt trennen: Delivery, Redirect, C2, Kollaboration und Datenspeicherung nicht vermischen
• Standardprofile und Default-Artefakte konsequent vermeiden
• Kommunikationsmuster an normales Zielverhalten anpassen statt maximale Interaktivität zu erzwingen
• Für jeden Schritt Exit- und Containment-Optionen vorbereiten

OPSEC betrifft aber nicht nur Technik. Auch Teamverhalten zählt. Unsaubere Benennung von Dateien, wiederverwendete Skripte, fehlende Zeitstempel, unklare Zuständigkeiten oder spontane Änderungen ohne Dokumentation führen schnell zu Kontrollverlust. In längeren Operationen ist das besonders kritisch, weil mehrere Operatoren parallel arbeiten und Fehler sich gegenseitig verstärken können.

Ein weiterer Punkt ist Artefaktmanagement. Welche Dateien wurden abgelegt? Welche Registry-Keys verändert? Welche Tasks erstellt? Welche Benutzerkonten angelegt? Welche Zertifikate importiert? Welche Logs auf eigener Infrastruktur enthalten sensible Daten? Ohne präzise Erfassung wird Cleanup unsauber und das Abschlussbild unzuverlässig. Professionelle Teams behandeln jede Änderung am Zielsystem wie eine kontrollierte Operation mit Rückbauplan.

Wer OPSEC trainieren will, sollte nicht nur offensive Tools üben, sondern parallel Detection-Sicht aufbauen. Eigene Angriffe gegen ein Lab mit Sysmon, Windows Event Forwarding, Defender, Zeek, Suricata oder SIEM-Parsing zeigen schnell, welche Aktionen unnötig laut sind. Genau deshalb ist die Verbindung zu Skills Blue Team und Skills Soc Analyst für Red-Team-Reife so wertvoll.

Red-Team-Skills werden oft an technischen Einzelaktionen gemessen. In realen Projekten ist jedoch der Workflow mindestens genauso wichtig. Ein sauberer Workflow reduziert Fehler, verhindert unnötige Risiken und macht Ergebnisse reproduzierbar. Ohne diese Struktur wird selbst eine erfolgreiche Operation schwer auswertbar.

Am Anfang steht die Missionsdefinition. Welche Ziele sind erlaubt? Welche Systeme sind tabu? Welche Nachweise gelten als Erfolg? Welche Kommunikationswege existieren bei kritischen Ereignissen? Welche Zeitfenster sind freigegeben? Welche Sicherheitsmechanismen dürfen bewusst getestet werden und welche nicht? Diese Fragen sind nicht administrativ, sondern operativ. Sie bestimmen, welche Techniken vertretbar sind.

Danach folgt die Hypothesenphase. Statt blind zu scannen oder sofort Payloads zu platzieren, wird ein wahrscheinlicher Angriffspfad modelliert. Beispiel: Externe Webanwendung liefert Benutzerstruktur, daraus folgt Passwort-Spraying gegen O365-Ausnahmen, daraus ein Benutzerkontext, daraus Zugriff auf SharePoint-Dokumente, daraus VPN-Konfigurationen, daraus interner Zugang, daraus Discovery und Privilege Escalation. Ein solcher Pfad ist besser steuerbar als ungeplantes Vorgehen.

Dokumentation muss parallel zur Operation laufen. Nicht am Ende. Jeder Host, jedes Credential, jede Session, jede Änderung, jede Hypothese und jeder Fehlschlag gehört in eine strukturierte Erfassung. Das ist nicht nur für Reporting wichtig, sondern für Teamkoordination und Fehlervermeidung. Wenn unklar ist, welcher Operator welche Rechte auf welchem Host hat, entstehen doppelte Aktionen, Kollisionen und unnötige Detektion.

Deconfliction ist besonders in größeren Übungen kritisch. Mehrere Operatoren dürfen sich nicht gegenseitig Sessions zerstören, Artefakte überschreiben oder denselben Host mit unterschiedlichen Methoden bearbeiten, ohne voneinander zu wissen. Gute Teams arbeiten mit klaren Besitzregeln für Systeme, Zeitfenstern für riskante Aktionen und einem gemeinsamen Lagebild.

Ein praxistauglicher Workflow enthält typischerweise Zieldefinition, Recon, Hypothesenbildung, Infrastrukturvorbereitung, kontrollierte Durchführung, laufende Dokumentation, Zwischenbewertung, Cleanup und Reporting. Dabei ist jeder Schritt mit Entscheidungspunkten verbunden. Wenn eine Annahme nicht bestätigt wird, wird nicht hektisch eskaliert, sondern der Pfad angepasst.

Beispiel für eine einfache Operations-Logik

1. Ziel: Zugriff auf sensibles internes Dokumentensystem nachweisen
2. Annahme: Externe Identitätsfläche bietet realistischen Einstieg
3. Recon: Benutzerformat, SSO-Endpunkte, MFA-Ausnahmen, Mailflow
4. Initial Access: kontrollierter Test gegen freigegebene Identitäten
5. Post-Access: minimale Discovery, nur zielbezogene Systeme
6. Escalation: nur wenn für Missionsziel erforderlich
7. Nachweis: Zugriff dokumentieren, keine unnötige Datenentnahme
8. Cleanup: Artefakte entfernen, Sessions schließen, Infrastruktur rotieren
9. Reporting: Pfad, Ursachen, Detection-Lücken, Prioritäten

Wer diese Arbeitsweise in Projekten oder Bewerbungsunterlagen glaubwürdig zeigen will, sollte nicht nur Tools nennen, sondern Entscheidungslogik und Ergebnisqualität belegen. Dafür sind strukturierte Nachweise in Portfolio Cybersecurity, Projekte Pentester oder Lebenslauf Red Team deutlich aussagekräftiger als reine Tool-Listen.

Die meisten Red-Team-Fehler sind keine exotischen Technikprobleme, sondern Folge schlechter Entscheidungen. Ein klassischer Fehler ist Aktionismus. Sobald erster Zugriff vorhanden ist, werden zu viele Befehle ausgeführt, zu viele Hosts gescannt und zu viele Tools getestet. Das erzeugt Telemetrie, ohne den Angriffspfad wirklich zu verbessern.

Ein zweiter Fehler ist fehlende Zielbindung. Wenn das Missionsziel der Nachweis eines bestimmten Zugriffs ist, braucht es nicht automatisch Domain Admin. Viele Operatoren eskalieren weiter, weil es technisch möglich ist, nicht weil es operativ nötig wäre. Das erhöht Risiko, Komplexität und Cleanup-Aufwand.

Ein dritter Fehler ist unzureichende Dokumentation. Gerade unter Zeitdruck werden Sessions, Credentials, Hostnamen, Änderungen und Zeitpunkte nicht sauber festgehalten. Später fehlen dann Belege für den Pfad, Cleanup wird unsicher und Reporting bleibt vage. In professionellen Umgebungen ist das nicht akzeptabel.

Ebenso problematisch ist die unkritische Übernahme öffentlicher Tradecraft-Beispiele. Was in einem Blogpost oder Conference-Talk funktioniert, kann in einer produktiven Umgebung sofort auffallen. Standard-Loader, bekannte AMSI-Bypässe, unveränderte C2-Profile oder laute Enumeration sind oft bereits abgedeckt. Red-Team-Skills zeigen sich darin, bekannte Techniken an die Zielumgebung anzupassen oder bewusst zu verwerfen.

Auch fehlendes Blue-Team-Verständnis ist ein häufiger Schwachpunkt. Wer nicht weiß, welche Events erzeugt werden, welche Korrelationen üblich sind und wie Analysten denken, trifft schlechte Entscheidungen. Ein Operator muss nicht nur wissen, wie etwas funktioniert, sondern auch, wie es gesehen wird.

• Zu frühes oder zu breites Scanning ohne klare Hypothese
• Werkzeugwahl nach Bequemlichkeit statt nach Signatur und Kontext
• Unnötige Eskalation über das Missionsziel hinaus
• Schwache Dokumentation, fehlende Artefaktkontrolle und unsauberes Cleanup

Ein weiterer Fehler ist die Überschätzung einzelner Zertifikate oder CTF-Erfolge. Solche Nachweise können hilfreich sein, ersetzen aber keine operative Reife. Wer nur Challenge-Logik kennt, hat oft Schwierigkeiten mit instabilen Zielsystemen, unvollständiger Sicht, restriktiven Freigaben und der Notwendigkeit, Risiken aktiv zu begrenzen. Ergänzende Orientierung dazu liefern Zertifikate Red Team, Ctf Bewerbung Cybersecurity und Eigene Projekte Cybersecurity.

Der vielleicht teuerste Fehler ist fehlende Selbstdisziplin. Nicht jede Idee muss sofort getestet werden. Nicht jede Session muss interaktiv genutzt werden. Nicht jeder Fund muss maximal ausgereizt werden. Gute Red Teams arbeiten kontrolliert, nicht impulsiv.

Ein realistisches Beispiel verdeutlicht, wie Red-Team-Skills zusammenspielen. Ausgangslage ist ein Unternehmen mit Microsoft-365-Anbindung, externem VPN, mehreren Webanwendungen und klassischem Active Directory im Backend. Ziel ist der Nachweis, dass ein Angreifer auf ein internes Dokumentensystem mit sensiblen Projektunterlagen zugreifen kann.

Phase eins ist passive Recon. Öffentliche Dokumente, Stellenanzeigen, Zertifikatstransparenz, DNS-Einträge und Login-Portale liefern Hinweise auf Namenskonventionen, eingesetzte Produkte und mögliche Identitätsendpunkte. Dabei fällt auf, dass ein altes Partnerportal noch aktiv ist und Benutzerkennungen im Format vorname.nachname verwendet.

Phase zwei ist Hypothesenbildung. Statt breit gegen O365 zu sprühen, wird geprüft, ob das Partnerportal andere Authentifizierungsregeln hat. Ein kontrollierter Test mit freigegebenen Konten zeigt, dass dort keine moderne MFA erzwungen wird. Über ein schwaches Passwort eines Testkontos entsteht ein erster Benutzerkontext. Von dort aus werden nur die unmittelbar relevanten Ressourcen geprüft: Gruppenmitgliedschaften, zugängliche Portale, Dokumente und gespeicherte Konfigurationen.

Phase drei ist zielgerichtete Discovery. In einem internen Wiki findet sich eine VPN-Anleitung mit Hostnamen, Split-Tunnel-Hinweisen und Support-Kontakten. In einem freigegebenen Skript-Repository liegen veraltete Automatisierungsdateien mit Service-Account-Bezügen. Statt sofort Credentials zu dumpen, wird geprüft, ob diese Konten noch aktiv sind und wo sie Berechtigungen besitzen.

Phase vier ist kontrollierte Ausweitung. Ein Service-Konto hat lokale Admin-Rechte auf einem Management-Server. Über diesen Server lassen sich Sessions und administrative Werkzeuge beobachten. Dort wird ein privilegierter Benutzerkontext identifiziert, der Zugriff auf das gesuchte Dokumentensystem besitzt. Erst jetzt wird eine begrenzte Lateral-Movement-Technik gewählt, die in dieser Umgebung normal wirkt und keine unnötigen Zusatzhosts berührt.

Phase fünf ist Nachweis und Rückbau. Es werden keine Massendaten entnommen, sondern nur der Zugriff auf definierte Testdokumente belegt. Alle temporären Artefakte werden erfasst und entfernt. Im Reporting wird nicht nur der technische Pfad beschrieben, sondern auch die organisatorische Ursache: veraltetes Partnerportal, inkonsistente MFA-Durchsetzung, überprivilegiertes Service-Konto, schwache Trennung von Dokumentation und Betriebsgeheimnissen.

Dieses Beispiel zeigt, dass Erfolg selten aus einem einzelnen Exploit entsteht. Entscheidend sind präzise Recon, Zurückhaltung, Kontextverständnis und die Fähigkeit, kleine Signale zu einem belastbaren Angriffspfad zu verbinden. Genau diese Qualität sollte auch in eigenen Nachweisen sichtbar werden, etwa über Projekte Red Team oder Wie Portfolio Cybersecurity.

Red-Team-Skills wirken nur dann überzeugend, wenn sie konkret belegt werden. Reine Schlagwörter wie Active Directory, C2, Privilege Escalation oder OPSEC sind austauschbar. Aussagekräftig wird ein Profil erst, wenn sichtbar ist, in welchem Kontext diese Fähigkeiten angewendet wurden, welche Entscheidungen getroffen wurden und welche Ergebnisse daraus entstanden sind.

Am stärksten sind eigene Projekte mit klarer Problemstellung. Ein gutes Projekt beschreibt Zielumgebung, Annahmen, Angriffspfad, eingesetzte Techniken, Detection-Aspekte, Fehler, Lessons Learned und Cleanup. Das kann ein AD-Lab mit Tiering-Brüchen sein, eine simulierte Phishing-Kette mit Mail-Infrastruktur, ein Cloud-Identitätsszenario mit Token-Missbrauch oder ein hybrider Pfad über Webanwendung und internes Netzwerk. Wichtig ist, dass das Projekt nicht nur Erfolg zeigt, sondern auch Entscheidungslogik.

Zertifikate können hilfreich sein, wenn sie technische Tiefe und praktische Prüfung enthalten. Sie sind aber nur ein Baustein. Ein Zertifikat ohne eigene Projekte wirkt oft theoretisch. Umgekehrt können starke Projekte fehlende Zertifikate teilweise kompensieren, wenn sie sauber dokumentiert und nachvollziehbar sind. Eine sinnvolle Ergänzung bieten Zertifikate Pentester, Welche Zertifikate Cybersecurity und Cybersecurity Zertifikate Einstieg.

Für die Darstellung in Unterlagen zählt Präzision. Statt nur Tools aufzulisten, sollten Kompetenzen in Form von Tätigkeiten beschrieben werden: Angriffspfade in AD-Umgebungen modelliert, C2-Profile für restriktive Egress-Szenarien angepasst, Detection-Artefakte eigener Tradecraft gegen Sysmon und Defender validiert, privilegierte Identitätsbeziehungen in hybriden Umgebungen analysiert, Cleanup und Artefaktmanagement dokumentiert. Solche Formulierungen zeigen Anwendung statt Vokabular.

Auch Einsteiger können belastbare Nachweise liefern, wenn die Projekte sauber aufgebaut sind. Ein kleines, aber gut dokumentiertes Lab mit klaren Zielen ist wertvoller als zehn unscharfe CTF-Writeups. Wer den Einstieg plant, kann ergänzend auf Skills Cybersecurity Bewerbung, Bewerbung Red Team und Anschreiben Red Team zurückgreifen, um technische Inhalte präzise in Bewerbungsunterlagen zu übertragen.

Ein starkes Profil zeigt außerdem Lernkurve. Welche Fehler wurden anfangs gemacht? Welche Detection-Signaturen wurden ausgelöst? Wie wurde Tradecraft angepasst? Welche Annahmen haben sich als falsch erwiesen? Solche Punkte wirken glaubwürdig, weil sie reale Arbeit widerspiegeln. Perfekte Erfolgsgeschichten ohne Reibung wirken dagegen oft konstruiert.

Einsatzreife entsteht nicht durch das Sammeln isolierter Techniken, sondern durch systematischen Aufbau. Der erste Schritt ist ein stabiles Fundament in Betriebssystemen, Netzwerken, Identitäten und Anwendungen. Darauf folgt die Fähigkeit, Angriffstechniken in vollständige Pfade zu übersetzen. Danach kommen OPSEC, Infrastruktur, Dokumentation und Reporting. Viele versuchen die Reihenfolge umzudrehen und starten direkt mit C2-Frameworks oder Evasion. Das führt fast immer zu Lücken.

Ein sinnvoller Aufbau beginnt mit reproduzierbaren Labs. Zuerst einfache Windows- und Linux-Szenarien, dann Active Directory mit mehreren Rollen, anschließend Logging und Detection, danach externe Angriffsflächen, Mailflow und Cloud-Identitäten. Jede Stufe sollte nicht nur technische Erfolge, sondern auch Fehlversuche und Gegenmaßnahmen enthalten. So entsteht ein realistisches Verständnis dafür, warum manche Techniken im Labor leicht, in echten Umgebungen aber unzuverlässig sind.

Danach folgt die Arbeit an Workflows. Für jedes Szenario sollte ein klarer Ablauf definiert werden: Ziel, Annahmen, Recon, Initial Access, Discovery, Escalation, Nachweis, Cleanup, Reporting. Wer diese Struktur konsequent trainiert, entwickelt automatisch bessere Entscheidungslogik. Genau das macht später den Unterschied in Projekten und Interviews.

Wichtig ist außerdem die Verbindung zu defensiven Perspektiven. Wer eigene Angriffe gegen Logging und Detection testet, lernt schneller als durch reine Offensivübungen. Dadurch wird sichtbar, welche Befehle unnötig laut sind, welche Protokolle auffallen, welche Artefakte zurückbleiben und wie Analysten Ketten rekonstruieren. Diese Rückkopplung verbessert Tradecraft massiv.

Langfristig sollte jedes Training auf drei Fragen hinauslaufen: Was war das Ziel? Warum wurde genau dieser Pfad gewählt? Welche Spuren und Risiken entstanden dabei? Wenn diese Fragen präzise beantwortet werden können, ist aus technischem Wissen operative Kompetenz geworden.

Wer den nächsten Schritt plant, sollte Projekte, Zertifikate und Unterlagen aufeinander abstimmen. Ein Red-Team-Profil wirkt dann stimmig, wenn Skills, praktische Nachweise und Darstellung dieselbe Sprache sprechen. Dafür sind unter anderem Lebenslauf Pentester, Bewerbung Penetration Tester und Vorstellungsgespraech Pentester sinnvolle Ergänzungen.

Am Ende zählt nicht, wie viele Tools bekannt sind, sondern wie kontrolliert, nachvollziehbar und zielgerichtet gearbeitet wird. Genau darin liegt die eigentliche Red-Team-Skill-Reife.