Ein Angriffsszenario beschreibt einen konkreten, plausiblen Ablauf, durch den ein Angreifer ein System kompromittieren, Daten entwenden oder Prozesse stören könnte – vom initialen Einstiegspunkt über die Vorgehensweise bis zum angestrebten Ziel. Angriffsszenarien denken aus der Perspektive des Angreifers: Was will er? Was braucht er dafür? Wie geht er vor? Diese Perspektive deckt Schwachstellen auf, die von innen heraus – durch defensives Denken – oft übersehen werden.
Angriffsszenarien sind das praktische Werkzeug der Bedrohungsmodellierung: Während STRIDE Bedrohungsklassen kategorisiert, beschreibt ein Angriffsszenario den konkreten Angriffspfad. Für Automatisierungsinfrastrukturen sind Angriffsszenarien besonders relevant, weil Automatisierungssysteme als „Masterkeys“ für viele angebundene Systeme wirken – wer die Automatisierungsplattform kompromittiert, hat potenziell Zugriff auf alle integrierten Systeme.
Typische Angriffsszenarien für Automatisierungsinfrastrukturen
Gestohlener API-Key
API-Key aus Git-Repository oder Log-Datei extrahiert. Angreifer ruft API-Endpunkte im Namen des Workflows auf – liest oder manipuliert Daten ohne Authentifizierungsbarriere.
Supply-Chain-Angriff
Kompromittiertes npm-Package oder Container-Image enthält Schadsoftware. Wird in die Build-Pipeline eingeschleust. Malware läuft mit den Rechten der Automatisierungsplattform.
Phishing → Workflow-Zugang
Mitarbeiter klickt Phishing-Link, gibt n8n-Passwort ein. Angreifer loggt sich ein, liest alle Workflow-Konfigurationen und darin enthaltene Credentials anderer Systeme.
Webhook-Injection
Angreifer sendet manipulierte Payloads an einen Webhook-Endpunkt ohne Signaturverifikation. Injektion von falschen Bestelldaten, Datenlöschungen oder Command-Injection.
Insider-Bedrohung
Mitarbeiter mit Workflow-Zugang exfiltriert Kundendaten oder sabotiert Workflows. Übermäßige Zugriffsrechte ohne Monitoring ermöglichen unbemerkte Aktivitäten.
Laterale Bewegung
Nach initialer Kompromittierung eines Hilfssystems (Monitoring, CI/CD) bewegt sich Angreifer lateral. Nutzt Netzwerkzugang und Service-Credentials, um die Hauptplattform zu erreichen.
Praxisbeispiel
Ein Automationsdienstleister analysiert das Angriffsszenario „Phishing → Workflow-Zugang → Credential-Harvesting“. Schritt 1: Mitarbeiter erhält E-Mail mit gefälschter n8n-Login-Seite (Phishing). Schritt 2: Gibt Credentials ein. Schritt 3: Angreifer loggt sich mit gestohlenen Credentials in n8n ein. Schritt 4: Liest alle 34 Workflow-Konfigurationen – darin sind im Klartext hinterlegt: CRM-API-Key, ERP-Zugangsdaten, E-Mail-Credentials, Datenbankpasswort. Schritt 5: Angreifer hat Zugang zu 7 verschiedenen Kundensystemen ohne weiteren Aufwand. Gegenmaßnahmen nach Analyse: MFA für n8n-Admin (unterbricht Angriff nach Schritt 2). Alle Credentials in AWS Secrets Manager ausgelagert, nicht mehr in Workflows sichtbar (reduziert Schaden von Schritt 4 auf null). Logging und Alerting bei ungewöhnlichen Login-Zeiten (Erkennung nach Schritt 3). Das Szenario zeigt, warum MFA + Secret-Manager zusammen wichtiger sind als jede einzelne Maßnahme allein.
