dickicht · kiefergruen.com
Strukturierte Wissensbasis für Spezialisten — Themenbereiche, technische Begriffe, Use-Case-Szenarien und operative FAQ. Kein Onboarding-Material, keine Oberflächlichkeit.
Themenbereiche
Dreizehn operative Themenfelder der Cyber-Abwehr — von Detection Engineering über forensische Analyse bis zu Fraud Analytics und Disinformation.
Detektion von Betrugsketten über Device-Fingerprint-Anomalien, Session-Replay-Indikatoren, Velocity-/Geo-Pattern, Mule-Account-Clustering und transaktionsnahes Graph-Correlation-Scoring; flankierend Analyse von Desinformationssignalen über koordinierte Inauthentic-Behavior-Muster, Sockpuppet-Netze und narrative Amplification-Pfade.
Proaktives Aufspüren persistenter Angreifer mit IOC-Validierung, Hypothesen-getriebenem Hunting und MITRE ATT&CK-orientiertem TTP-Mapping.
Erkennung von Low-and-Slow-Mustern, DNS-Tunneling und periodischem C2-Traffic durch Baseline-Drift-Analyse, Zeitreihen-Korrelation und Entropie-basierte Heuristik.
Strukturierte Incident Response mit forensischer Nachvollziehbarkeit, kontrolliertem Containment, abgestimmten Eskalationspfaden und klaren RTO-/RPO-Leitplanken.
Technische und strategische Unterstützung in Ransomware-Szenarien: forensische Triage, isolierte Wiederanlaufpfade, Network Segmentation, Schlüsselentscheidungen auf Basis belastbarer Artefakte.
Schutz exponierter Personen und sensibler Funktionen mit hardening-orientierter Architektur, Asset-Kritikalitätsmodell, Attack-Surface-Reduktion und kontinuierlichem Monitoring auf Anomalien.
Aufbau und kontinuierliche Verbesserung von SIEM-Use-Cases, Sigma-Regeln, UEBA-Signalen und belastbaren Runbooks mit Test- und Tuning-Zyklen.
Kombination aus OSINT, HUMINT und interner Telemetrie zur Priorisierung adversary-spezifischer Risiken, inklusive Campaign-Clustering und IAB/IOA-Abgleich.
Reduktion von Identity-Risiken über Least-Privilege-Modelle, ASR-Policies, Credential Hygiene, Pass-the-Hash-Mitigationen und kontrollierte Admin-Tiering-Strategien.
Aufbau von Detection Coverage für hybride Infrastrukturen mit Fokus auf IAM-Missbrauch, API-Anomalien, lateral movement zwischen On-Prem und Cloud sowie CSPM-gestützter Gap-Analyse.
Analyse von Angriffspfaden über HTTP/2-, GraphQL- und REST-Interfaces inklusive IDOR/BOLA, SSRF, Insecure Deserialization, desync-basierten Request-Smuggling-Mustern, OAuth/OIDC-Token-Missbrauch, JWT-Fehlkonfigurationen, CSP-Bypass, DOM-XSS und WAF-Evasion-Telemetrie.
Artefakt- und Timeline-Analyse zur sauberen Rekonstruktion von Initial Access, Privilege Escalation und Impact-Phase; ergänzt durch Memory Forensics. Ergebnisse fließen direkt in Härtung und Detection Backlog.
Operationalisierung von Incident-Workflows mit SOAR, Emulation realistischer Angriffssequenzen per BAS sowie Fokus auf LOLBAS-Muster zur Schließung detection-relevanter Blind Spots.
Wissensbasis
Alle Begriffe, Use Cases und FAQ-Einträge auf einen Blick — als direkte Sprungmarken.
Use-Case Matrix
Typische Incident-Szenarien mit zugeordneten Arbeitsschwerpunkten, relevanten Konzepten und kritischen Artefakten für die erste technische Priorisierung.
| Szenario | Primäre Priorität | Relevante Begriffe | Kritische Artefakte |
|---|---|---|---|
| Ransomware mit Domänenbezug | Containment, Tier-Isolation, Recovery-Pfad absichern | Ransomware, Containment, Network Segmentation, Runbook | AD-Events, Backup-Status, EDR-Telemetrie, Encryption-Indicators |
| BEC / Account Takeover | Identity-Sicherung, Token-Invalidierung, Mailflow-Analyse | UEBA, SIEM, Threat Intelligence, ASR | Sign-in Logs, Conditional Access Events, Mail Trace, OAuth Grants |
| Stealthy C2-Beaconing | Egress-Kontrolle, Beacon-Intervall-Korrelation, Scope-Expansion | Beaconing, C2, DNS-Tunneling, Domain Fronting | DNS/Proxy Logs, NetFlow, JA3/JA4, Process-Commandline |
| LOLBAS-basierter Initial Access | Execution-Path-Härtung, Rule-Tuning, schnellere Triage | LOLBAS, Detection Engineering, Sigma-Regeln, BAS | ScriptBlock Logs, AMSI Events, Sysmon Event IDs, Parent-Child Chains |
| Cloud IAM Missbrauch | Privilegienrückbau, Session-Termination, API-Monitoring | XDR, EASM, CSPM, Incident Response | Cloud Audit Trail, IAM Policy Diffs, API Calls, Token Lifetimes |
| Persistenter APT-Dwell-Time-Fall | Forensische Rekonstruktion, Campaign-Clustering, Langzeit-Monitoring | APT, MITRE ATT&CK, Digitale Forensik, Purple Team | Timeline Artefakte, Persistence Keys, Lateral Movement Traces, Exfil Indicators |
| Insider Threat (privilegierter Missbrauch) | Privilegienentzug, Session-Containment, Nachweisführung | UEBA, SIEM, Digitale Forensik, Runbook | DLP-Events, Datei-/Objektzugriffe, Admin-Aktivitäten, Audit Trails |
| Supply-Chain Compromise | Blast-Radius-Analyse, Vertrauenskette prüfen, kontrollierter Rollback | Threat Intelligence, Incident Response, TTP-Mapping, XDR | Build-/Deploy-Logs, SBOM-Diffs, Signatur-/Hash-Integrität, Paket-Repositories |
| Kerberoasting / AD Credential Attack | Service-Account-Härtung, Offline-Cracking-Fenster schließen, Detektionslücke beseitigen | Kerberoasting, DCSync, Golden Ticket, Pass-the-Hash | TGS-Request-Volumen (Event 4769), SPN-Inventory, Passwort-Alter Service Accounts, KDC-Logs |
| Fileless / Memory-resident Malware | Speicheranalyse, Injection-Pfad rekonstruieren, Persistenz-Mechanismus identifizieren | Memory Forensics, LSASS Dumping, EDR, LOLBAS | VAD-Tree-Anomalien, injizierte Threads, anomale Netzwerkverbindungen aus Systemprozessen, Hollow Process Indicators |
| Cloud SSRF → Metadata-Exploitation | IMDS-Exposition bewerten, temporäre Credentials invalidieren, IAM-Scope einschränken | CSPM, EASM, Zero Trust, Threat Hunting | IMDS v1 Requests, IAM Assumed-Role Calls, Outbound Requests an 169.254.169.254, kurze Token-Lebenszeit-Anomalien |
FAQ
Technisch präzise Antworten auf häufige Fragen aus dem Incident-Response- und Detection-Alltag — für Spezialisten, nicht für Einsteiger.
Wie priorisiere ich Artefakte in den ersten 30 Minuten eines Ransomware-Incidents?
Die Triage folgt einer klaren Sequenz: Zuerst Backup-Integrität und Snapshot-Status sicherstellen — Shadow Copy Deletion (vssadmin, wmic) als Early Warning ist oft der früheste sichtbare Indicator. Dann AD-Tier-Status bewerten: KRBTGT-Anomalien, Domain-Admin-Sessions, unerwartete Replikationsevents (DCSync-Signatur). Danach EDR-Telemetrie auf Encryption-Binaries, Staging-Verzeichnisse und laterale SMB-Verbindungen auswerten. Kritische Entscheidung so früh wie möglich: Isolation vs. kontrollierte Beobachtung — falsche Wahl kostet Recovery-Wochen. Faustregel: Wenn das Backup-Fabric kompromittiert ist, ändert sich der gesamte Recovery-Plan.
Was sind verlässliche Detektionssignale für LOLBAS-Missbrauch?
ScriptBlock Logs (PowerShell Event 4104) mit verdächtiger Encoding-Nutzung oder bekannten Bypass-Fragmenten. AMSI-Events bei aktiver Bypass-Suche. Sysmon Event ID 1 mit anomalen Parent-Child-Ketten (z.B. winword.exe → cmd.exe → powershell.exe). Event ID 3 für Netzwerkverbindungen aus unerwarteten Elternprozessen. Konkrete LOLBAS-Kandidaten mit hohem Missbrauchspotenzial: certutil (-urlcache -split -f), mshta, regsvr32 (Squiblydoo), rundll32, wscript/cscript, msiexec. Kernprinzip: Detektion über die Kombination von Parent-Process, Command-Line-Argument und nachgelagertem Netzwerkverhalten — kein einzelnes Signal ist verlässlich genug.
Wie unterscheidet man echtes C2-Beaconing von legitimem Traffic?
Vier Analyseachsen: (1) Zeitreihen-Regelmäßigkeit — echter Beacon hat geringe Zeitvariation (Jitter unter 10–15 %), legitimer Traffic schwankt stärker; Spektralanalyse des Intervalls trennt periodisch von organisch. (2) Payload-Größen-Konsistenz — C2-Heartbeats zeigen charakteristisch kleine, stabile Paketgrößen; Upload-Spitzen deuten auf Exfil-Phasen. (3) Destination-Qualität — neu registrierte Domains (unter 30 Tage), selten genutzte ASN, DGA-Muster (Entropie der Domain), Zertifikats-Alter. (4) TLS-Fingerprinting — JA3/JA4-Hashes bekannter C2-Frameworks (Cobalt Strike, Havoc, Sliver) sind dokumentiert und vergleichbar; Abweichung vom Browser-Fingerprint bei vermeintlichem Browser-Traffic ist starkes Signal.
Welche initialen Schritte sind bei Verdacht auf APT-Dwell-Time — und warum nicht sofort containen?
Kontra-intuitiv, aber kritisch: Nicht sofort isolieren. Erste Phase ist stille Observation — passive Log-Collection aus SIEM, EDR, DNS, Proxy und NetFlow über einen definierten Zeitraum, um Scope und Persistenz vollständig zu verstehen. Parallele Aufgaben: Persistenz-Mechanismen kartieren (Scheduled Tasks, Registry Run Keys, WMI Subscriptions, Services, Boot-Kits), C2-Infrastruktur identifizieren und Sinkholing vorbereiten, betroffene Konten vollständig auflisten ohne Alarm auszulösen. Erst mit vollständigem Bild koordiniertes Containment — sonst Risiko, dass Angreifer mit aktivierter Backup-Persistenz oder Wiper-Logik reagiert. Ausnahme: wenn aktive Exfiltration läuft oder kritische Infrastruktur unmittelbar gefährdet ist.
Wie strukturiert man ein Detection-Engineering-Backlog belastbar?
Priorisierung nach vier Faktoren: (1) Threat-Intel-Aktualität — aktive Kampagnen gegen die eigene Branche oder Technologie-Stack haben höchste Priorität. (2) ATT&CK-Coverage-Gap — welche Techniken haben keine korrespondierende Detection Rule; Heatmap visualisiert Lücken. (3) Blast Radius — wie hoch ist das Schadenpotenzial bei unbemerktem Durchlaufen der Technik. (4) Detection Confidence — Rule-Qualität messbar durch Precision/Recall gegen historische True-Positives und BAS-Outputs. Operativ: Sigma als Detection-as-Code, versioniert in Git, CI/CD-Validation gegen Eventlog-Fixtures. Jede Rule braucht dokumentierten Testfall, definierten Schwellenwert und zugehörigen Runbook-Eintrag.
Wie bewertet man die operative Qualität eines SIEM-Use-Cases?
Vier Kennzahlen: (1) False Positive Rate (FPR) — Anteil harmloser Events an allen Alarmen; Ziel unter 5–10 % für High-Fidelity-Rules. (2) True Positive Rate / Detection Rate — wie viele echte Incidents werden erkannt; messbar durch BAS-Durchläufe. (3) Mean Time to Detect (MTTD) — Zeitspanne zwischen Incident-Beginn und erstem validen Alarm; je früher in der Kill Chain, desto besser. (4) ATT&CK-Coverage-Score — Anteil abgedeckter Techniken in relevanten Taktiken. Mindestanforderung für produktive Rules: dokumentierte Testmethode, definierter Trigger-Datensatz, klarer Response-Playbook-Eintrag und regelmäßiger Tuning-Zyklus.
Glossar
58 Begriffe mit Definition und Praxisbeispiel aus Incident Response, Forensik und Fraud Analysis — technisch präzise, ohne Vereinfachung.
Advanced Persistent Threat beschreibt langfristig angelegte, zielgerichtete Angriffe mit hoher Ressourcenbasis und klaren strategischen Zielen.
Praxisbeispiel aus Incident Response: Nach Initial Access über kompromittiertes VPN-Konto wurden über Wochen Living-off-the-Land-Techniken genutzt; IR priorisiert Credential Rotation, Host Isolation und ATT&CK-basierte Scope-Expansion.
↑ InhaltsverzeichnisHypothesenbasierte Suche nach Angreiferaktivität in Telemetrie, Logs und Endpunktdaten – unabhängig von klassischen Alarmen.
Praxisbeispiel aus Incident Response: Hunt-Query auf Parent-Child-Prozessketten identifiziert ungewöhnliches PowerShell-Encoding; daraus entstehen neue Detection Rules und Retro-Hunt über 90 Tage.
↑ InhaltsverzeichnisIndicators of Compromise sind technische Artefakte wie Hashes, Domains oder IPs, die auf potenzielle Kompromittierung hindeuten.
Praxisbeispiel aus Incident Response: Gefundene C2-Domain wird in EDR, Proxy und DNS-Sinkhole geblockt; parallel erfolgt IOC-Pivoting auf Zertifikats- und JA3-Fingerprints.
↑ InhaltsverzeichnisWissensbasis zur Kategorisierung realer Angreifertechniken, die Teams für Detection-Design, Gap-Analyse und Priorisierung nutzen.
Praxisbeispiel aus Incident Response: Beobachtete Techniken T1059 und T1027 markieren unzureichende Script-Telemetrie; Incident-Team ergänzt Logging und baut gezielte ATT&CK-Coverage-Metriken auf.
↑ InhaltsverzeichnisZuordnung beobachteter Taktiken, Techniken und Prozeduren zu bekannten Angriffsmustern, um Lagebild und Reaktion zu schärfen.
Praxisbeispiel aus Incident Response: Sequenz aus Credential Dumping, Lateral Movement und Datastaging wird als konsistente TTP-Kette erfasst und als priorisierter Countermeasure-Backlog übergeben.
↑ InhaltsverzeichnisModell zur Darstellung von Angriffsphasen von Initial Access bis Actions on Objectives, hilfreich für präventive Kontrollen.
Praxisbeispiel aus Incident Response: Für jede Kill-Chain-Phase werden vorhandene Kontrollen bewertet; Schwachstellen in Delivery und Exploitation führen zu E-Mail-Sandboxing- und Patch-SLA-Anpassungen.
↑ InhaltsverzeichnisAnalyse von Abweichungen gegenüber Normalverhalten in Netzwerk-, Benutzer- und Systemaktivitäten.
Praxisbeispiel aus Incident Response: Abweichende Service-Account-Logons außerhalb Maintenance Window lösen Incident-Playbook aus, inklusive Session-Termination und Privilege Review.
↑ InhaltsverzeichnisVorgehen, bei dem Angriffe bewusst langsam und unauffällig ausgeführt werden, um Schwellenwerte zu unterlaufen.
Praxisbeispiel aus Incident Response: Datenexfiltration in kleinen HTTPS-Batches über mehrere Wochen wird erst durch Langzeit-Baseline und Beacon-Intervall-Korrelation sichtbar.
↑ InhaltsverzeichnisRegelmäßige, oft periodische Kommunikation eines kompromittierten Systems mit externer Infrastruktur.
Praxisbeispiel aus Incident Response: 300-Sekunden-Heartbeat zu selten genutzter ASN führt zu Host-Isolation, Memory Capture und nachgelagerter Malware-Familienklassifikation.
↑ InhaltsverzeichnisSteuerkanal zwischen Angreifer und kompromittiertem Host zur Befehlsausführung und Datenexfiltration.
Praxisbeispiel aus Incident Response: Nach C2-Nachweis werden Egress Policies gehärtet, Domain Fronting geprüft und alle betroffenen Tokens sofort invalidiert.
↑ InhaltsverzeichnisMissbrauch von DNS-Anfragen zum verdeckten Transport von Daten und Befehlen über erlaubte Protokolle.
Praxisbeispiel aus Incident Response: Auffällige TXT-Requests mit hoher Entropie führen zur Blockade verdächtiger Resolver und zur Implementierung von DNS-Response-Policy-Zones.
↑ InhaltsverzeichnisC2-Verschleierungstechnik, bei der Traffic über legitime CDN/Cloud-Infrastruktur geleitet wird, sodass der äußerlich sichtbare Hostname (SNI) zu einer vertrauenswürdigen Domain gehört, während der HTTP-Host-Header auf die tatsächliche C2-Infrastruktur zeigt.
Praxisbeispiel aus Incident Response: JA3/JA4-TLS-Fingerprinting, CDN-spezifische Header-Inspektion (X-Forwarded-Host) und Korrelation von SNI vs. HTTP-Host auf Proxy-Ebene ermöglichen Erkennung; viele CDN-Anbieter haben Domain Fronting inzwischen technisch unterbunden — Angreifer weichen auf alternativen Missbrauch aus.
↑ InhaltsverzeichnisSecurity Information and Event Management sammelt und korreliert Ereignisse, um sicherheitsrelevante Muster erkennbar zu machen.
Praxisbeispiel aus Incident Response: Korrelationsregel kombiniert Impossible Travel, MFA Fatigue und Privilege Escalation; daraus entsteht ein High-Fidelity-Use-Case mit reduziertem False-Positive-Anteil.
↑ InhaltsverzeichnisUser and Entity Behavior Analytics bewertet Verhaltensprofile, um riskante Abweichungen datenbasiert zu markieren.
Praxisbeispiel aus Incident Response: UEBA markiert atypischen Datenzugriff eines Service Accounts; IR verifiziert Missbrauch, sperrt Entitlements und führt gezieltes Access Recertification durch.
↑ InhaltsverzeichnisEndpoint Detection and Response erfasst kontinuierlich Telemetrie von Endpunkten — Prozesse, Netzwerkverbindungen, Registry, Dateisystem — und ermöglicht reaktive Untersuchung und Eindämmung direkt am Host. Entscheidend ist die Qualität der Telemetrie-Tiefe, nicht nur das Alarmvolumen.
Praxisbeispiel aus Incident Response: EDR-Telemetrie liefert die vollständige Process-Tree-Ansicht von einer Office-Makro-Ausführung bis zur finalen PowerShell-Payload; ohne diese Sicht wäre der laterale Bewegungspfad über drei Hosts nicht rekonstruierbar gewesen.
↑ InhaltsverzeichnisNetwork Detection and Response analysiert Netzwerkverkehr auf Protokollebene, extrahiert Metadaten und erkennt Anomalien ohne Endpoint-Sicht — besonders wertvoll für unkontrollierte Segmente, OT/IoT und blinde Flecken des EDR.
Praxisbeispiel aus Incident Response: NDR identifiziert anomale SMB-Verbindungen zwischen Workstations außerhalb der Geschäftszeiten in einem Segment ohne EDR-Abdeckung; der laterale Bewegungspfad wäre andernfalls vollständig unsichtbar geblieben.
↑ InhaltsverzeichnisExtended Detection and Response korreliert Signale aus Endpoint, Netzwerk, E-Mail und Cloud, um kontextreiche Alarmketten statt isolierter Einzelereignisse zu erzeugen.
Praxisbeispiel aus Incident Response: XDR korreliert Mail-Phishing, Endpoint-Payload und verdächtigen API-Call; Incident-Team erhält eine zusammenhängende Attack Story mit priorisiertem Scope.
↑ InhaltsverzeichnisSecurity Orchestration, Automation and Response automatisiert wiederkehrende Analyseschritte und standardisiert Reaktionsabläufe über Playbooks.
Praxisbeispiel aus Incident Response: SOAR-Playbook führt automatische IOC-Enrichment, Ticket-Erstellung, Host-Isolation und Stakeholder-Benachrichtigung in definierten Sequenzen aus.
↑ InhaltsverzeichnisStrukturierter Prozess zur Erkennung, Analyse, Eindämmung, Beseitigung und Nachbereitung von Sicherheitsvorfällen.
Praxisbeispiel aus Incident Response: P1-Vorfall wird in Triage, Containment, Eradication, Recovery und Lessons Learned geführt; jede Phase hat klare Owner, SLA und Evidenzanforderungen.
↑ InhaltsverzeichnisGezielte Begrenzung eines Vorfalls, um Ausbreitung, Datenverlust und operative Auswirkungen zu minimieren.
Praxisbeispiel aus Incident Response: Segmentweise Isolation statt Full Shutdown hält kritische Dienste online, während kompromittierte Endpunkte aus dem Produktionsnetz entfernt werden.
↑ InhaltsverzeichnisBeweissichere Analyse digitaler Spuren zur Rekonstruktion von Angriffspfaden und belastbarer Ursachenbewertung.
Praxisbeispiel aus Incident Response: Prefetch-, Amcache- und Eventlog-Korrelation rekonstruiert die Ausführungskette; Timeline belegt Zeitpunkt und Mechanismus der Privilege Escalation.
↑ InhaltsverzeichnisAnalyse eines RAM-Abbilds zur Untersuchung laufender Prozesse, Netzwerkverbindungen, geladener Module, Verschlüsselungsschlüssel und injizierten Codes — unverzichtbar bei dateilosen Angriffen, wo keine Disk-Artefakte entstehen.
Praxisbeispiel aus Incident Response: Volatility-Analyse des Memory Dumps extrahiert injizierte Shellcode-Fragmente aus einem legitimen svchost-Prozess; eine anomal gemappte, ausführbare Memory-Region ohne Disk-Pendant (VAD-Tree-Analyse) identifiziert den Injection-Punkt und ermöglicht die Malware-Familienklassifikation.
↑ InhaltsverzeichnisErpressung durch Verschlüsselung oder Datenexfiltration mit Druckaufbau über Verfügbarkeit, Integrität oder Vertraulichkeit.
Praxisbeispiel aus Incident Response: Vor Verschlüsselungsphase werden Shadow Copies gelöscht; IR stoppt Ausbreitung via AD-Tier-Separation, isoliert Backup-Fabric und startet Clean-Restore-Workflow.
↑ InhaltsverzeichnisAufteilung von Netzen in kontrollierte Zonen, um laterale Bewegung von Angreifern wirksam einzuschränken.
Praxisbeispiel aus Incident Response: East-West-Firewall-Regeln verhindern SMB-Lateral-Movement aus User-VLAN in Server-Zonen; Blast Radius sinkt signifikant.
↑ InhaltsverzeichnisArchitekturprinzip, das keinen impliziten Vertrauensvorschuss für Identitäten, Geräte oder Netzzugänge gewährt — jede Anfrage wird kontextbasiert authentisiert und autorisiert, unabhängig von ihrer Herkunft. Kernprinzipien: Verify Explicitly, Use Least Privilege, Assume Breach.
Praxisbeispiel aus Incident Response: Nach Kompromittierung eines VPN-Kontos zeigt die Analyse, dass Zero-Trust-Enforcement mit per-Request-Re-Authentisierung und Micro-Segmentation den Blast Radius auf einen einzigen Dienst begrenzt hätte — im Gegensatz zur impliziten Vertrauenszone hinter dem VPN-Perimeter.
↑ InhaltsverzeichnisOpen Source Intelligence nutzt öffentlich verfügbare Informationen für Lagebild, Kontext und Risikobewertung.
Praxisbeispiel aus Incident Response: Leak-Forum-Monitoring liefert frühe Hinweise auf kompromittierte Zugangsdaten; Passwort-Reset und MFA-Rebind werden präventiv ausgelöst.
↑ InhaltsverzeichnisHuman Intelligence basiert auf menschenbezogenen Quellen und ergänzt technische Informationsgewinnung.
Praxisbeispiel aus Incident Response: Hinweise aus internen Meldestrukturen präzisieren den Initial-Phishing-Vektor und verkürzen die Root-Cause-Analyse signifikant.
↑ InhaltsverzeichnisKontextualisierte Bedrohungsinformationen für priorisierte Schutzmaßnahmen, Detection-Optimierung und Entscheidungsfähigkeit.
Praxisbeispiel aus Incident Response: CTI-Feed liefert aktuelle Infrastructure-of-Interest; daraus werden Blocklisten, Detection Queries und Executive Risk Notes abgeleitet.
↑ InhaltsverzeichnisAkteur, der sich auf den Erstzugang zu Zielnetzwerken spezialisiert und diese Zugänge an andere Bedrohungsakteure — typischerweise Ransomware-Gruppen — weiterverkauft. Listings auf Cybercrime-Foren enthalten oft Branche, Umsatzgröße und Zugangsmethode.
Praxisbeispiel aus Threat Intelligence: Aktive IAB-Listings für Unternehmen der eigenen Branche triggern proaktives Access-Review, Credential-Reset für exponierte Accounts und erhöhtes SIEM-Monitoring auf externe Authentisierungsanomalien — noch bevor ein Incident eingetreten ist.
↑ InhaltsverzeichnisEntwicklung und Pflege belastbarer Detektionslogik inklusive Testing, Tuning und Coverage-Betrachtung.
Praxisbeispiel aus Incident Response: Nach Incident werden neue Rules als Detection-as-Code versioniert, gegen historische Daten getestet und mit Precision/Recall-Kennzahlen bewertet.
↑ InhaltsverzeichnisHerstellerunabhängiges Format für SIEM-Detektionen, das Regeln portable und wartbar macht.
Praxisbeispiel aus Incident Response: Eine Sigma-Regel für suspicious scheduled tasks wird in mehrere SIEM-Backends kompiliert und in CI/CD mit Unit-Events validiert.
↑ InhaltsverzeichnisStandardisierte Handlungsanleitung für Vorfälle und Routineprozesse, um Qualität und Tempo im Einsatz zu sichern.
Praxisbeispiel aus Incident Response: Das Runbook für kompromittierte Admin-Konten definiert Entscheidungspunkte, Kommunikationsmatrix, Artefaktsammlung und technische Sofortmaßnahmen.
↑ InhaltsverzeichnisBreach and Attack Simulation prüft Sicherheitskontrollen kontinuierlich durch kontrollierte, wiederholbare Angriffssimulationen mit messbarer Erfolgsquote.
Praxisbeispiel aus Incident Response: BAS-Job simuliert Credential Dumping und lateral movement; fehlende Alarme werden als priorisierte Detection-Gaps in den Sprint übernommen.
↑ InhaltsverzeichnisPurple Teaming verbindet Red- und Blue-Team-Ziele in iterativen Zyklen, um Detection Coverage und Response-Reife messbar zu erhöhen.
Praxisbeispiel aus Incident Response: Nach realem Vorfall wird der Angriffspfad kontrolliert nachgestellt; Blue Team validiert neue Regeln direkt gegen die emulierten TTPs.
↑ InhaltsverzeichnisExternal Attack Surface Management identifiziert exponierte Assets, Fehlkonfigurationen und unbeabsichtigt veröffentlichte Dienste aus externer Angreiferperspektive.
Praxisbeispiel aus Incident Response: EASM entdeckt vergessene Subdomain mit veralteter Admin-Konsole; Sofortmaßnahme umfasst De-Publishing, Patch und Credential Reset.
↑ InhaltsverzeichnisCloud Security Posture Management bewertet kontinuierlich die Konfiguration von Cloud-Ressourcen gegen Sicherheits-Baselines (CIS Benchmarks, NIST, eigene Policies) und identifiziert Fehlkonfigurationen, Drift und Compliance-Abweichungen.
Praxisbeispiel aus Incident Response: CSPM meldet öffentlich zugänglichen Storage Bucket mit sensitiven Artefakten; automatisches Remediation-Playbook setzt Bucket auf private, erstellt Incident-Ticket und triggert Datenexpositions-Bewertung nach DSGVO Art. 33.
↑ InhaltsverzeichnisAttack Surface Reduction umfasst technische Richtlinien zur Reduktion ausnutzbarer Ausführungswege, etwa bei Makros, Scripts und Office-Child-Prozessen.
Praxisbeispiel aus Incident Response: ASR blockiert nach Incident das Starten von Child-Prozessen durch Office; beobachtete Initial-Access-Kette wird nachhaltig unterbunden.
↑ InhaltsverzeichnisLiving Off The Land Binaries And Scripts beschreibt den Missbrauch legitimer Systemwerkzeuge für Tarnung, Persistenz und Ausführung ohne zusätzliche Malware-Dateien.
Praxisbeispiel aus Incident Response: Missbrauch von certutil und mshta zur Payload-Nachladung wird erkannt; Countermeasure umfasst Command-Line-Telemetrie, Block-Regeln und restriktive Allowlisting-Policies.
↑ InhaltsverzeichnisOffline-Angriff auf das Kerberos-Protokoll: Ein authentisierter Domänennutzer fordert Service-Tickets für SPNs an, die mit dem Passwort-Hash des Service Accounts verschlüsselt sind, und crackt diesen lokal ohne weitere Netzwerk-Interaktion. Kein Alarm ohne gezieltes Monitoring — der Angriffsschritt ist legitimes Protokollverhalten.
Praxisbeispiel aus Incident Response: Anomales TGS-Request-Volumen für selten genutzte SPNs außerhalb der Servicezeiten (Event 4769, Encryption Type 0x17) wird als Kerberoasting-Signal erkannt. Sofortmaßnahme: Service-Account-Passwort-Reset auf 25+ Zeichen, AES-Erzwingung (RC4-Deaktivierung), Monitoring auf Offline-Cracking-Indikatoren in nachgelagerten Logon-Events.
↑ InhaltsverzeichnisMissbrauch der Directory Replication Service (DRS) API, um Passwort-Hashes aller Domänenkonten direkt vom Domain Controller abzurufen — ohne physischen Zugriff auf den DC, aber mit delegierten Replikationsrechten (Domain Admins, Enterprise Admins oder explizit delegiert). Ermöglicht direkten Zugriff auf KRBTGT-Hash für Golden-Ticket-Erstellung.
Praxisbeispiel aus Incident Response: Security Event 4662 mit den Rechten-GUIDs {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2} und {1131f6ab-9c07-11d1-f79f-00c04fc2dcd2} markiert DCSync-Anfragen aus einem Nicht-DC-Host. Im Incident war der Auslöser ein Service Account mit fälschlicherweise delegierten Replikationsrechten aus einer veralteten Automatisierungslösung.
↑ InhaltsverzeichnisGefälschtes Kerberos-Ticket-Granting-Ticket (TGT), erstellt mit dem KRBTGT-Account-Hash. Ermöglicht dauerhafte, von Standard-Passwort-Rotationen unabhängige Domänenzugriffe mit beliebigen Berechtigungen. Tickets können auf bis zu 10 Jahre Gültigkeit ausgestellt werden und überleben normale Incident-Response-Maßnahmen.
Praxisbeispiel aus Incident Response: Nach DCSync-Nachweis wird KRBTGT-Passwort zweimal innerhalb kurzer Zeit rotiert (erforderlich wegen Kerberos-Ticket-Lifetime-Overlap von 10 Stunden); alle aktiven Sessions werden invalidiert, anschließend vollständige Suche nach Persistence-Artefakten in Scheduled Tasks, WMI-Subscriptions und Registry.
↑ InhaltsverzeichnisVerwendung eines erbeuteten NTLM-Passwort-Hashes zur Authentisierung ohne Kenntnis des Klartextpassworts — möglich überall, wo NTLM akzeptiert wird. Klassische Lateral-Movement-Technik in Windows-Umgebungen, die ohne Klartextpasswort auskommt.
Praxisbeispiel aus Incident Response: Lateral Movement via PtH über SMB wird durch drei kombinierte Maßnahmen eingedämmt: Credential Guard (Isolierung von LSA-Secrets in VSM), konsequente SMB-Signing-Enforcement (verhindert Relay-Angriffe) und Monitoring auf NTLM-Authentisierungen von Workstation zu Workstation (Event 4776 auf DCs, NTLM-Audit-Policies).
↑ InhaltsverzeichnisAuslesen des Local Security Authority Subsystem Service (LSASS) Prozessspeichers zur Extraktion von Klartext-Credentials, NTLM-Hashes, Kerberos-Tickets und DPAPI-Master-Keys. Angriffstools reichen von Mimikatz und Procdump bis zu Task-Manager-Dumps und direktem NTDS.dit-Zugriff.
Praxisbeispiel aus Incident Response: Sysmon Event ID 10 (ProcessAccess auf lsass.exe mit GrantedAccess 0x1010 oder 0x1410) ist die primäre Detektionsquelle; Schutzmaßnahmen umfassen PPL (Protected Process Light, RunAsPPL Registry Key), Microsoft Credential Guard (Hyper-V-Isolation) und ASR-Regel "Block credential stealing from the Windows local security authority subsystem" (GUID: 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b0).
↑ InhaltsverzeichnisAngriffsmethode, bei der ein Angreifer mit gültigen Credentials massenhaft Push-Benachrichtigungen an das MFA-Gerät des Opfers sendet, bis dieses die Anfrage aus Versehen, Frustration oder sozialer Manipulation bestätigt. Auch als MFA Bombing oder Push Spam bezeichnet.
Praxisbeispiel aus Incident Response: Gegenmaßnahmen umfassen Number Matching (Nutzer muss angezeigte Zahl im Authenticator bestätigen), Additional Context (Anzeige von IP und Standort im Push), Rate Limiting für Push-Anfragen und Conditional-Access-Policies, die nach Schwellenwert-Überschreitung den Sign-in blockieren und einen Incident-Alert auslösen.
↑ InhaltsverzeichnisÜbernahme legitimer Benutzerkonten durch Credential Stuffing, Phishing, MFA-Fatigue oder Token-Diebstahl mit anschließendem Missbrauch privilegierter Zugriffe.
Praxisbeispiel aus Fraud Response: Mehrere erfolgreiche Logins aus atypischen ASN/Geo-Kombinationen führen zu Session-Invalidierung, Step-up-Auth und erzwungener Credential-Rotation.
↑ InhaltsverzeichnisGezielte Kompromittierung oder Imitation geschäftlicher E-Mail-Kommunikation zur Manipulation von Zahlungsanweisungen, Lieferkettenprozessen oder Freigabeworkflows.
Praxisbeispiel aus Fraud Response: Inbound-Regelmanipulation und Reply-Chain-Hijacking werden in M365-Audit-Logs erkannt; Auszahlungen werden gestoppt und Freigabeprozesse mit Vier-Augen-Kontrolle verschärft.
↑ InhaltsverzeichnisMissbrauch von Zahlungs- und Checkout-APIs durch Bot-Traffic, Parameter-Tampering, Replay-Attacken oder Logikfehler in Risk-/Limit-Prüfungen.
Praxisbeispiel aus Fraud Response: Anomal erhöhte Refund-Requests mit identischen Device- und Header-Profilen triggern adaptive Rate Limits, Signatur-Checks und temporäre Endpoint-Isolation.
↑ InhaltsverzeichnisMissbrauch gestohlener oder synthetischer Identitäten zur Kontoeröffnung, Transaktionsausführung oder Umgehung von KYC/KYB-Kontrollen.
Praxisbeispiel aus Fraud Response: KYC-Daten zeigen wiederholte Nutzung korrelierter Merkmale über mehrere Neukonten; Onboarding wird blockiert und die Fälle in ein Link-Analysis-Cluster überführt.
↑ InhaltsverzeichnisAbweichungen in Browser-, OS-, Netzwerk- und Sensor-Merkmalen, die auf Emulatoren, Automatisierung oder Identitätswechsel hindeuten.
Praxisbeispiel aus Fraud Response: Ein Konto wechselt innerhalb kurzer Zeit zwischen widersprüchlichen Fingerprints; Risk Engine erhöht den Score und fordert Strong Re-Authentication.
↑ InhaltsverzeichnisSignale für wiederverwendete Session-Artefakte, z. B. Token-Reuse, inkonsistente Client-Telemetrie oder zeitlich unplausible Request-Folgen.
Praxisbeispiel aus Fraud Response: Gleiches Refresh-Token erscheint parallel aus verschiedenen Netzen; Sessions werden global beendet und betroffene OAuth-Clients neu registriert.
↑ InhaltsverzeichnisBewertung von Ereignisdichte, Sequenzgeschwindigkeit und geographischer Plausibilität zur Erkennung automatisierter oder orchestrierter Betrugsaktivitäten.
Praxisbeispiel aus Fraud Response: Binnen Minuten erfolgen Transaktionen aus nicht plausiblen Länderfolgen; Regelwerk setzt Hold-Status und initiiert manuelle Verifikation.
↑ InhaltsverzeichnisGraphbasierte Gruppierung von Konten mit gemeinsamen technischen und finanziellen Merkmalen zur Identifikation von Geldwäsche- und Ausleitungspfaden.
Praxisbeispiel aus Fraud Response: Mehrere Empfängerkonten teilen Device-, IP- und Zahlungsvektoren; Cluster wird als Mule-Ring markiert und regulatorisch reportet.
↑ InhaltsverzeichnisRisikobewertung über Beziehungsgraphen zwischen Konten, Geräten, Zahlungsinstrumenten und Kommunikationsknoten statt isolierter Einzelereignisse.
Praxisbeispiel aus Fraud Response: Neue Konten mit hoher Nachbarschaft zu bekannten Fraud-Knoten erhalten dynamisch erhöhte Prüfintensität und verzögerte Auszahlung.
↑ InhaltsverzeichnisKoordinierte, nicht-authentische Aktivität mehrerer Konten zur künstlichen Verstärkung von Narrativen, Reichweite oder vermeintlicher Glaubwürdigkeit.
Praxisbeispiel aus Disinformation Analysis: Zeitlich synchronisierte Post-Sequenzen mit überlappenden Metadaten weisen auf gesteuerte Kampagnen hin; betroffene Assets werden in Monitoring-Listen überführt.
↑ InhaltsverzeichnisVerbund scheinbar unabhängiger, aber zentral gesteuerter Accounts zur Manipulation von Diskursen, Reputation oder Entscheidungswahrnehmung.
Praxisbeispiel aus Disinformation Analysis: Mehrere Profile mit identischen Verhaltenssignaturen und Infrastrukturbezug pushen gleichlautende Claims; Netz wird attributiert und dokumentiert.
↑ InhaltsverzeichnisSystematische Verstärkung ausgewählter Botschaften durch koordinierte Cross-Channel-Verteilung, Timing-Steuerung und algorithmische Reichweitenoptimierung.
Praxisbeispiel aus Disinformation Analysis: Ein Desinformationsnarrativ wird über Foren, Social-Media-Cluster und Kommentar-Spikes orchestriert; Korrelationsanalyse zeigt den gemeinsamen Initial-Seed.
↑ InhaltsverzeichnisLeichtgewichtiger Trip-Wire — z. B. ein präpariertes Dokument, eine URL, ein DNS-Record oder eine Fake-Credential-Datei — der beim Öffnen oder Zugriff eine Out-of-Band-Benachrichtigung auslöst und so frühe Aufklärungsaktivität von Angreifern signalisiert, lange bevor klassische Alarme ansprechen.
Praxisbeispiel aus Incident Response: Canary-Token-Dateien (präparierte Word-Dokumente mit HTTP-Callback) in Share-Verzeichnissen und einem fake credentials.txt triggern einen Alert beim ersten Zugriff; der Alert kommt 48 Stunden vor dem ersten EDR-Signal und ermöglicht eine vollständige Scope-Analyse während der Angreifer noch in der Reconnaissance-Phase ist.
↑ InhaltsverzeichnisSchwachstelle, für die zum Zeitpunkt der Ausnutzung kein Patch existiert. Hochwertig im Exploit-Handel und bei APT-Gruppen. Da signaturbasierte Erkennung per Definition zu spät kommt, muss die Detection auf Verhaltensanomalien, Post-Exploitation-Aktivitäten und anomale Prozess-/Netzwerkmuster abzielen.
Praxisbeispiel aus Incident Response: Zero-Day in einem Edge-Gerät wird erst durch anomale ausgehende Verbindungen und unerklärliche Konfigurations-Drifts sichtbar — kein Signatur-Alert, kein Patch verfügbar. Nach Vendor-Disclosure beschleunigt ein präziser Asset-Inventory-Query die Exposure-Bewertung auf Minuten; bis dahin greift Netzwerk-Segmentierung und erhöhtes Egress-Monitoring als Übergangskontrolle.
↑ Inhaltsverzeichnis