Warum beide Perspektiven wichtig sind
Kapitel 1: Grundlagen & Einführung → Was ist Security & Ethical Hacking?
Einführung
IT-Sicherheit ist kein Entweder-oder zwischen Angriff und Verteidigung – es ist ein dynamisches Zusammenspiel beider Seiten. Wer nur verteidigt, ohne die Angreifer-Perspektive zu verstehen, baut Mauern mit blinden Flecken. Wer nur angreift, ohne defensive Maßnahmen zu kennen, versteht nicht, wie effektiver Schutz aussieht.
💡 Kerngedanke: "Man kann kein guter Verteidiger sein, ohne zu wissen, wie Angreifer denken – und man kann kein effektiver Angreifer sein, ohne zu verstehen, was Verteidiger übersehen."
Diese Seite erklärt, warum die Kombination beider Perspektiven der Schlüssel zu echter IT-Sicherheit ist.
Das Katz-und-Maus-Spiel
IT-Sicherheit ist ein ständiges Wettrüsten zwischen Angreifern und Verteidigern. Beide Seiten entwickeln sich kontinuierlich weiter:
┌─────────────────────────────────────────────────────────────────┐
│ EVOLUTION DER SICHERHEIT │
└─────────────────────────────────────────────────────────────────┘
ANGREIFER VERTEIDIGER
────────── ───────────
│ │
Einfache Viren ──────────────────────▶ Antivirus-Software
│ │
Polymorphe Malware ──────────────────▶ Heuristische Erkennung
│ │
Fileless Malware ────────────────────▶ EDR & Behavior Analysis
│ │
Living-off-the-Land ─────────────────▶ UEBA & Anomaly Detection
│ │
AI-gestützte Angriffe ───────────────▶ AI-gestützte Defense
│ │
▼ ▼
┌─────────────────────────────────────────────────┐
│ Das Spiel endet nie – beide Seiten lernen │
│ voneinander und entwickeln sich weiter │
└─────────────────────────────────────────────────┘
Was das für dich bedeutet
Wenn du nur eine Seite verstehst, hinkt dein Wissen immer hinterher:
| Nur Offensive | Nur Defensive |
|---|---|
| Du findest Lücken, weißt aber nicht, wie man sie nachhaltig schließt | Du implementierst Kontrollen, die ein erfahrener Angreifer leicht umgeht |
| Du verstehst nicht, welche Angriffe priorisiert werden sollten | Du erkennst nicht, welche Logs wirklich relevant sind |
| Du kannst Schwachstellen nicht im Kontext der Verteidigung bewerten | Du baust Detection Rules ohne zu wissen, wie Angreifer sie umgehen |
Die Blindspots einer einseitigen Perspektive
Wenn nur das Blue Team arbeitet
┌─────────────────────────────────────────────────────────────────┐
│ SZENARIO: Blue Team ohne offensive Erfahrung │
└─────────────────────────────────────────────────────────────────┘
Blue Team implementiert:
✅ Firewall mit Standard-Regeln
✅ Antivirus auf allen Endpoints
✅ SIEM mit Default-Rules
✅ Jährliche Vulnerability Scans
Gefühl: "Wir sind sicher!"
─────────────────────────────────────────────────────────────────
Realität (was ein Red Team finden würde):
❌ Firewall: Ausgehende Verbindungen nicht gefiltert
→ C2-Kommunikation möglich
❌ Antivirus: Erkennt nur bekannte Signaturen
→ Custom Payloads werden nicht erkannt
❌ SIEM: Default-Rules erzeugen Alert-Fatigue
→ Echte Angriffe gehen im Rauschen unter
❌ Vuln-Scans: Nur extern, nicht authentifiziert
→ Interne Schwachstellen bleiben unentdeckt
❌ Kein Monitoring von: PowerShell, WMI, Scheduled Tasks
→ Living-off-the-Land-Angriffe unsichtbar
Wenn nur das Red Team arbeitet
┌─────────────────────────────────────────────────────────────────┐
│ SZENARIO: Red Team ohne defensive Integration │
└─────────────────────────────────────────────────────────────────┘
Red Team liefert:
✅ 47-seitigen Pentest-Report
✅ 23 kritische Findings
✅ Proof-of-Concept für jeden Exploit
✅ CVSS-Scores und Risikobewertung
Was passiert danach:
❌ Report landet in der Schublade
→ "Zu technisch für das Management"
❌ Findings werden isoliert betrachtet
→ Symptome behandelt, nicht Ursachen
❌ Keine Validierung der Fixes
→ Gleiche Schwachstellen im nächsten Test
❌ Keine Detection für gefundene Techniken
→ Echte Angreifer nutzen dieselben Methoden unbemerkt
❌ Kein Wissenstransfer zum Blue Team
→ Lerneffekt geht verloren
Die Vorteile der dualen Perspektive
Für Security Professionals
┌─────────────────────────────────────────────────────────────────┐
│ KOMPETENZMATRIX: DUAL-SKILLED │
└─────────────────────────────────────────────────────────────────┘
┌──────────────────────┬──────────────────────────────────────────┐
│ OFFENSIVE SKILLS │ WIE SIE DEFENSIVE ARBEIT VERBESSERN │
├──────────────────────┼──────────────────────────────────────────┤
│ Exploitation │ Verstehen, welche Vulns wirklich │
│ │ ausnutzbar sind (Priorisierung) │
├──────────────────────┼──────────────────────────────────────────┤
│ Post-Exploitation │ Wissen, welche Artefakte Angreifer │
│ │ hinterlassen (Detection Engineering) │
├──────────────────────┼──────────────────────────────────────────┤
│ Evasion Techniques │ Detection Rules bauen, die auch │
│ │ Umgehungsversuche erkennen │
├──────────────────────┼──────────────────────────────────────────┤
│ Social Engineering │ Effektive Awareness-Trainings │
│ │ entwickeln (aus Angreifer-Sicht) │
└──────────────────────┴──────────────────────────────────────────┘
┌──────────────────────┬──────────────────────────────────────────┐
│ DEFENSIVE SKILLS │ WIE SIE OFFENSIVE ARBEIT VERBESSERN │
├──────────────────────┼──────────────────────────────────────────┤
│ Log Analysis │ Verstehen, welche Spuren man │
│ │ vermeiden muss (OPSEC) │
├──────────────────────┼──────────────────────────────────────────┤
│ Detection Rules │ Wissen, was erkannt wird und was │
│ │ nicht (gezieltes Evasion) │
├──────────────────────┼──────────────────────────────────────────┤
│ Incident Response │ Realistische Szenarien entwickeln, │
│ │ die IR-Prozesse wirklich testen │
├──────────────────────┼──────────────────────────────────────────┤
│ Hardening │ Schwachstellen finden, die trotz │
│ │ Härtung existieren (Edge Cases) │
└──────────────────────┴──────────────────────────────────────────┘
Für Unternehmen
| Aspekt | Nur eine Perspektive | Beide Perspektiven |
|---|---|---|
| Risikobewertung | Theoretisch, basierend auf CVSS | Praktisch, basierend auf realer Ausnutzbarkeit |
| Budget-Allokation | Nach Bauchgefühl oder Compliance | Datengetrieben nach echtem Risiko |
| Detection-Qualität | Hohe False-Positive-Rate | Präzise, getestet gegen echte Angriffe |
| Security Posture | Checkbox-Security | Echte Widerstandsfähigkeit |
| Incident Response | Ungetestet, theoretisch | Validiert durch Übungen |
| ROI von Security | Schwer messbar | Nachweisbar durch verhinderte Angriffe |
Praktische Beispiele
Beispiel 1: Detection Rule ohne offensive Erfahrung
┌─────────────────────────────────────────────────────────────────┐
│ SZENARIO: Erkennung von Mimikatz │
└─────────────────────────────────────────────────────────────────┘
BLUE TEAM (ohne offensive Erfahrung) erstellt:
──────────────────────────────────────────────
Regel: Alert wenn "mimikatz.exe" ausgeführt wird
detection:
process_name: "mimikatz.exe"
Problem: Jeder Angreifer benennt die Datei um!
─────────────────────────────────────────────────────────────────
BLUE TEAM (mit offensiver Erfahrung) erstellt:
──────────────────────────────────────────────
Regel: Alert bei LSASS Memory Access Patterns
detection:
# Erkennt jedes Tool, das Credentials dumpt
EventID: 10 # Process Access
TargetImage|endswith: '\lsass.exe'
GrantedAccess|contains:
- '0x1010' # PROCESS_QUERY_LIMITED_INFO + VM_READ
- '0x1410' # Mit PROCESS_QUERY_INFO
- '0x1fffff' # PROCESS_ALL_ACCESS
SourceImage|not|endswith:
- '\wmiprvse.exe' # Whitelist legitimer Prozesse
- '\svchost.exe'
Ergebnis: Erkennt Mimikatz, ProcDump, Comsvcs und unbekannte Tools!
Beispiel 2: Pentest-Finding ohne defensive Kontextualisierung
┌─────────────────────────────────────────────────────────────────┐
│ SZENARIO: SQL Injection in Legacy-Anwendung │
└─────────────────────────────────────────────────────────────────┘
RED TEAM (ohne defensive Erfahrung) reportet:
──────────────────────────────────────────────
Finding: SQL Injection in /search.php
CVSS: 9.8 (Critical)
Empfehlung: "Prepared Statements implementieren"
Problem: Legacy-App kann nicht kurzfristig gepatcht werden!
─────────────────────────────────────────────────────────────────
RED TEAM (mit defensiver Erfahrung) reportet:
──────────────────────────────────────────────
Finding: SQL Injection in /search.php
CVSS: 9.8 (Critical)
Kurzfristige Mitigations (sofort umsetzbar):
├── WAF-Rule für SQLi-Patterns aktivieren
├── Input-Validation auf Netzwerk-Ebene
├── Database-User Permissions einschränken
└── Monitoring für verdächtige Queries
Mittelfristige Maßnahmen (1-3 Monate):
├── Prepared Statements implementieren
└── Code-Review für ähnliche Patterns
Detection:
└── SIEM-Rule für SQL-Error-Strings in Logs
Ergebnis: Sofortiger Schutz + nachhaltiger Fix + Monitoring!
Beispiel 3: Incident Response ohne Angreifer-Verständnis
┌─────────────────────────────────────────────────────────────────┐
│ SZENARIO: Ransomware-Angriff │
└─────────────────────────────────────────────────────────────────┘
IR TEAM (ohne offensive Erfahrung):
────────────────────────────────────
1. Ransomware auf Server X entdeckt
2. Server X isoliert und neu aufgesetzt
3. Backup eingespielt
4. "Incident behoben"
Realität:
❌ Initialer Angriffsvektor nicht identifiziert
❌ Lateral Movement nicht untersucht
❌ Andere kompromittierte Systeme übersehen
❌ Persistence-Mechanismen nicht entfernt
→ Angreifer kehrt 2 Wochen später zurück
─────────────────────────────────────────────────────────────────
IR TEAM (mit offensiver Erfahrung):
────────────────────────────────────
1. Ransomware auf Server X entdeckt
2. Dwell-Time-Analyse: Wie lange war Angreifer im Netzwerk?
3. Hunting nach bekannten Ransomware-TTPs:
├── Initiale Kompromittierung (Phishing? RDP?)
├── Credential Harvesting (DC-Logs prüfen)
├── Lateral Movement (SMB-Connections analysieren)
└── Staging (Wo wurden Tools hochgeladen?)
4. Alle betroffenen Systeme identifiziert
5. Persistence-Mechanismen entfernt
6. Root Cause behoben (MFA für VPN eingeführt)
7. Detection Rules für beobachtete TTPs erstellt
→ Angreifer kann nicht zurückkehren + zukünftige Erkennung
Der Feedback-Loop
Die wahre Stärke liegt im kontinuierlichen Feedback zwischen beiden Perspektiven:
┌─────────────────────────────────────────────────────────────────┐
│ CONTINUOUS IMPROVEMENT LOOP │
└─────────────────────────────────────────────────────────────────┘
┌───────────────────────────────────────┐
│ THREAT INTELLIGENCE │
│ Was machen echte Angreifer gerade? │
└───────────────────┬───────────────────┘
│
▼
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ │ │ │ │ │
│ RED TEAM │───▶│ PURPLE TEAM │───▶│ BLUE TEAM │
│ │ │ │ │ │
│ Simuliert │ │ Analysiert │ │ Implementiert │
│ neue TTPs │ │ gemeinsam │ │ Verbesserungen │
│ │ │ │ │ │
└────────┬────────┘ └─────────────────┘ └────────┬────────┘
│ │
│ ┌─────────────────┐ │
│ │ │ │
└────────▶│ VALIDATION │◀────────────────┘
│ │
│ Wurden die │
│ Lücken wirklich│
│ geschlossen? │
│ │
└────────┬────────┘
│
▼
┌─────────────────┐
│ NÄCHSTE RUNDE │
│ (Repeat) │
└─────────────────┘
Der Loop in der Praxis
| Phase | Red Team Beitrag | Blue Team Beitrag | Ergebnis |
|---|---|---|---|
| 1. Threat Intel | Welche TTPs sind relevant? | Welche Assets sind kritisch? | Priorisierte Testszenarien |
| 2. Simulation | Führt Angriff durch | Beobachtet Detection | Erkenntnisse über Gaps |
| 3. Analyse | Erklärt Techniken | Teilt Detection-Logik | Gemeinsames Verständnis |
| 4. Verbesserung | Vorschläge für Evasion-Tests | Neue Detection Rules | Verbesserte Sicherheit |
| 5. Validation | Re-Test der Fixes | Monitoring der neuen Rules | Bestätigung der Wirksamkeit |
Argumente für Management und Budget
Business Case: Warum beide Perspektiven finanzieren?
┌─────────────────────────────────────────────────────────────────┐
│ KOSTEN-NUTZEN-ANALYSE │
└─────────────────────────────────────────────────────────────────┘
SZENARIO A: Nur Defensive Security
───────────────────────────────────
Budget: €200.000/Jahr
Ausgaben:
├── SIEM-Lizenz: €50.000
├── Firewall/IDS: €40.000
├── SOC-Personal (2 FTE): €110.000
└── Gesamt: €200.000
Ergebnis nach 1 Jahr:
• Viele Alerts, aber unklare Priorisierung
• Keine Validierung der Sicherheitsmaßnahmen
• Unbekannte Blindspots
─────────────────────────────────────────────────────────────────
SZENARIO B: Offensive + Defensive kombiniert
─────────────────────────────────────────────
Budget: €200.000/Jahr
Ausgaben:
├── SIEM-Lizenz: €50.000
├── Firewall/IDS: €40.000
├── SOC-Personal (1,5 FTE):€85.000
├── Externer Pentest: €15.000
└── Purple Team Exercises: €10.000
└── Gesamt: €200.000
Ergebnis nach 1 Jahr:
• Validierte Security Controls
• Getestete Detection Rules
• Bekannte und priorisierte Risiken
• Messbare Verbesserung der Security Posture
ROI-Metriken
| Metrik | Nur Defensive | Kombinierter Ansatz |
|---|---|---|
| Detection Coverage | Unbekannt | 78% der ATT&CK-Techniken |
| MTTD | ~14 Tage (Branchenschnitt) | ~2 Stunden (validiert) |
| False Positive Rate | ~85% | ~15% (getunt) |
| Patch-Priorisierung | Nach CVSS | Nach realer Ausnutzbarkeit |
| Compliance-Audit | Bestanden | Bestanden + nachweislich sicher |
Für verschiedene Zielgruppen
Für Homelab-Betreiber
┌─────────────────────────────────────────────────────────────────┐
│ WARUM DU BEIDE SEITEN LERNEN SOLLTEST │
└─────────────────────────────────────────────────────────────────┘
Als Homelab-Betreiber bist du:
• Sysadmin (Infrastruktur aufbauen)
• Blue Team (Monitoring, Hardening)
• Red Team (Testen, ob es sicher ist)
• IR Team (Wenn etwas schiefgeht)
→ Du MUSST beide Perspektiven verstehen!
─────────────────────────────────────────────────────────────────
PRAKTISCHES BEISPIEL: Dein öffentlich erreichbarer Dienst
1. Du setzt einen Dienst auf (Sysadmin)
2. Du härtest das System (Blue Team)
├── Firewall-Regeln
├── fail2ban
└── TLS-Konfiguration
3. Du testest die Härtung (Red Team)
├── Nmap-Scan von außen
├── SSL-Test (testssl.sh)
└── Directory-Bruteforce
4. Du findest Schwachstellen (Purple Team)
├── TLS 1.0 noch aktiv → deaktivieren
└── .git-Verzeichnis öffentlich → blockieren
5. Du richtest Monitoring ein (Blue Team)
└── Alert wenn jemand die Lücken versucht
→ Kompletter Security-Lifecycle durch eine Person!
Für angehende Security Professionals
┌─────────────────────────────────────────────────────────────────┐
│ KARRIERE-VORTEILE DER DUALEN EXPERTISE │
└─────────────────────────────────────────────────────────────────┘
T-SHAPED SKILLS: Breit aufgestellt, tief in einem Bereich
┌─────────────────────────┐
│ Breites Grundwissen │
│ (Beide Perspektiven) │
└───────────┬─────────────┘
│
┌───────────▼───────────┐
│ │
│ Tiefe Expertise │
│ (Spezialisierung) │
│ │
│ z.B. Malware- │
│ Analyse, Cloud │
│ Security, AppSec │
│ │
└───────────────────────┘
─────────────────────────────────────────────────────────────────
GEFRAGTE ROLLEN, DIE BEIDE SEITEN ERFORDERN:
• Security Architect
→ Muss wissen, wie Angreifer denken UND wie man verteidigt
• Threat Hunter
→ Sucht proaktiv nach Angreifern (offensive Denkweise)
→ In defensiver Infrastruktur (SIEM, EDR)
• Detection Engineer
→ Schreibt Rules, die echte Angriffe erkennen
→ Muss Angriffstechniken kennen
• Security Consultant
→ Berät Kunden zu beiden Aspekten
→ Pentest + Härtung + Strategie
• CISO / Security Manager
→ Muss beide Teams verstehen und koordinieren
Für IT-Administratoren mit Security-Verantwortung
┌─────────────────────────────────────────────────────────────────┐
│ DU BIST SCHON BLUE TEAM – WARUM AUCH OFFENSIVE SKILLS? │
└─────────────────────────────────────────────────────────────────┘
Als Admin machst du bereits:
✅ Patching und Updates
✅ Firewall-Konfiguration
✅ Berechtigungsmanagement
✅ Backup und Recovery
Was dir fehlt ohne offensive Perspektive:
❓ Sind meine Patches wirklich wirksam?
❓ Sind meine Firewall-Regeln umgehbar?
❓ Gibt es Privilege-Escalation-Pfade?
❓ Kann ein Angreifer meine Backups löschen?
─────────────────────────────────────────────────────────────────
QUICK WINS: Offensive Skills für Admins
1. Lerne Nmap
→ Scanne deine eigene Infrastruktur regelmäßig
→ Finde offene Ports, die nicht offen sein sollten
2. Verstehe Privilege Escalation
→ GTFOBins (Linux) / LOLBAS (Windows)
→ Prüfe deine Systeme auf diese Vektoren
3. Teste deine Passwörter
→ Cracke deine eigenen Hashes (wo erlaubt)
→ Erkenne schwache Passwörter vor Angreifern
4. Simuliere Phishing
→ Teste, ob Anhänge ausgeführt werden können
→ Prüfe Mail-Filter-Konfiguration
5. Überprüfe deine Backups
→ Kann ein Admin (oder Angreifer) sie löschen?
→ Teste Recovery-Prozeduren
Mindset-Shift: Vom Silo zum Teamwork
Das alte Modell (ineffektiv)
┌─────────────────────────────────────────────────────────────────┐
│ SILO-MENTALITÄT │
└─────────────────────────────────────────────────────────────────┘
┌──────────────┐ ┌──────────────┐
│ RED TEAM │ │ BLUE TEAM │
│──────────────│ 🚧 │──────────────│
│ │ Barriere │ │
│ "Wir finden │◀─────────────────────▶│ "Wir sind │
│ die Lücken" │ Kein Austausch │ die Guten" │
│ │ │ │
│ Report am │ │ Defensive │
│ Projektende │ │ Haltung │
└──────────────┘ └──────────────┘
Probleme:
• "Wir gegen die"-Mentalität
• Wissen wird nicht geteilt
• Ego statt Zusammenarbeit
• Verbesserungen dauern Monate
Das neue Modell (effektiv)
┌─────────────────────────────────────────────────────────────────┐
│ KOLLABORATIVES MODELL │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────┐
│ GEMEINSAMES ZIEL: │
│ DIE ORGANISATION SICHERER MACHEN │
└───────────────────┬─────────────────────┘
│
┌──────────────┼──────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ OFFENSIVE│◀─▶│ PURPLE │◀─▶│ DEFENSIVE│
│ SKILLS │ │ MINDSET │ │ SKILLS │
└──────────┘ └──────────┘ └──────────┘
│ │ │
└──────────────┼──────────────┘
▼
┌─────────────────┐
│ KONTINUIERLICHE │
│ VERBESSERUNG │
└─────────────────┘
Vorteile:
• Gemeinsames Ziel verbindet
• Wissen fließt in beide Richtungen
• Schnelle Iteration und Verbesserung
• Respekt für beide Perspektiven
Zusammenfassung
Die 5 Kernargumente
┌─────────────────────────────────────────────────────────────────┐
│ 1. VOLLSTÄNDIGES BILD │
│ Nur wer beide Seiten kennt, versteht das Gesamtbild. │
│ Angriff und Verteidigung sind zwei Seiten derselben │
│ Medaille. │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ 2. EFFEKTIVERE MASSNAHMEN │
│ Defensive Maßnahmen, die gegen echte Angriffe getestet │
│ wurden, sind nachweislich wirksam. │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ 3. BESSERE PRIORISIERUNG │
│ Wer weiß, welche Schwachstellen wirklich ausgenutzt │
│ werden können, fokussiert die richtigen Risiken. │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ 4. KONTINUIERLICHE VERBESSERUNG │
│ Der Purple-Team-Ansatz ermöglicht schnelle Iteration │
│ und messbare Fortschritte. │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ 5. KARRIEREVORTEIL │
│ Dual-Skilled Security Professionals sind gefragt und │
│ können flexibel eingesetzt werden. │
└─────────────────────────────────────────────────────────────────┘
Fazit
🎯 Die Quintessenz: Offensive und defensive Security sind keine Gegensätze, sondern Partner. Wer nur eine Seite beherrscht, arbeitet mit einem blinden Auge. Erst die Kombination beider Perspektiven ermöglicht echte, nachhaltige IT-Sicherheit.
Dieses Buch folgt genau diesem Prinzip: Du lernst sowohl Angriffstechniken (um Schwachstellen zu finden) als auch Verteidigungsmaßnahmen (um sie zu schließen und zu überwachen). Jedes Kapitel beleuchtet beide Seiten, damit du am Ende ein vollständiger Security Professional bist – egal ob du später als Red Teamer, Blue Teamer oder in einer hybriden Rolle arbeitest.
Nächste Schritte
Jetzt, da du verstehst, warum beide Perspektiven wichtig sind, geht es im nächsten Kapitel um die praktische Umsetzung:
- Legale & Ethische Aspekte: Wie du legal und ethisch korrekt testest
- Lab-Setup: Deine eigene sichere Trainingsumgebung aufbauen
- Security-Frameworks: Die Standards, die beide Seiten verbinden