Skip to content
Tools/IR Playbooks/Edge Device Exploitation
/
static content
■ High IR Playbook

Edge Device Exploitation

Ausnutzung von Edge-Geräten

Response to exploited vulnerabilities in firewalls, VPN gateways, ADCs and file transfer systems: preserve evidence before patching, limit the attack surface, rotate secrets and investigate follow-on activity in the internal network.

Reaktion auf ausgenutzte Schwachstellen in Firewalls, VPN-Gateways, ADCs und Datei-Transfer-Systemen: Beweise vor dem Patch sichern, Angriffsfläche begrenzen, Geheimnisse rotieren und Folgeaktivität im internen Netz untersuchen.

Detect Contain Investigate Eradicate Recover Review
Erkennen Eindämmen Untersuchen Beseitigen Wiederanlauf Nachbereitung

Overview

Überblick

This playbook structures the response to suspected or confirmed exploitation of a vulnerability in a device at the network edge: firewall, VPN gateway, application delivery controller (ADC), load balancer, file transfer server, remote access solution or email gateway.

Edge devices are a common initial access point for ransomware groups and state actors. They are reachable from the internet, hold credentials and sessions of many users, often run without EDR and log only to a limited extent.

The core of this playbook: A patch ends the exploitation, not the compromise. Patching a possibly compromised edge device closes the door, but does not check who is already inside.

Dieses Playbook strukturiert die Reaktion auf die vermutete oder bestätigte Ausnutzung einer Schwachstelle in einem Gerät am Netzwerkrand: Firewall, VPN-Gateway, Application Delivery Controller (ADC), Load Balancer, Datei-Transfer-Server, Remote-Access-Lösung oder E-Mail-Gateway.

Edge-Geräte sind häufige Erstzugänge für Ransomware-Gruppen und staatliche Akteure. Sie sind aus dem Internet erreichbar, halten Zugangsdaten und Sitzungen vieler Benutzer, laufen oft ohne EDR und protokollieren begrenzt.

Der Kern dieses Playbooks: Ein Patch beendet die Ausnutzung, nicht die Kompromittierung. Wer ein möglicherweise kompromittiertes Edge-Gerät nur patcht, schließt die Tür, prüft aber nicht, wer bereits im Haus ist.

Scope & Severity

Anwendungsbereich & Schweregrad

Scope

Use this playbook if at least one of the following applies:

  • An actively exploited vulnerability is reported for an edge product you run, and the device was vulnerable and reachable during the exploitation window.
  • The vendor's integrity or IOC checking tool reports findings.
  • Unknown files, web shells, modified system files, new local accounts or unexplained configuration changes are found on the device.
  • The device behaves unusually: crashes, reboots, high load or outbound connections to unknown destinations.
  • Internal systems show access from the device's IP address or from the VPN address pool that does not match known users.
  • A vendor, service provider, CERT or authority reports the device as possibly compromised.

Boundaries:

  • If encryption is under way or spread is broad, the ransomware playbook additionally takes the lead.
  • If user accounts have been taken over, the identity compromise playbook runs in parallel.
  • A patch backlog without any sign of exploitation is vulnerability management, not an incident.

Severity

Default severity: High.

Raise to Critical if:

  • the vendor's checking tool confirms a compromise
  • web shells, implants or unknown persistence are found
  • credentials, sessions or configuration secrets have probably been exfiltrated
  • follow-on activity is visible in the internal network
  • central identity services or privileged service accounts are affected
  • the vulnerability allows unauthenticated execution and the device was exposed for a longer period

Anwendungsbereich

Verwenden Sie dieses Playbook, wenn mindestens einer der folgenden Punkte zutrifft:

  • Für ein eingesetztes Edge-Produkt wird eine aktiv ausgenutzte Schwachstelle gemeldet und das Gerät war im Ausnutzungszeitraum verwundbar sowie erreichbar.
  • Das Integritäts- oder IOC-Prüfwerkzeug des Herstellers meldet Auffälligkeiten.
  • Auf dem Gerät finden sich unbekannte Dateien, Webshells, geänderte Systemdateien, neue lokale Konten oder unerklärliche Konfigurationsänderungen.
  • Das Gerät zeigt ungewöhnliches Verhalten: Abstürze, Neustarts, hohe Last oder ausgehende Verbindungen zu unbekannten Zielen.
  • Interne Systeme zeigen Zugriffe von der IP-Adresse des Edge-Geräts oder aus dem VPN-Adresspool, die nicht zu bekannten Benutzern passen.
  • Ein Hersteller, Dienstleister, CERT oder eine Behörde meldet das Gerät als möglicherweise kompromittiert.

Abgrenzung:

  • Bei laufender Verschlüsselung oder breiter Ausbreitung führt zusätzlich das Ransomware-Playbook.
  • Bei übernommenen Benutzerkonten läuft parallel das Playbook zur Identitätskompromittierung.
  • Ein Patch-Rückstand ohne Hinweis auf Ausnutzung ist Schwachstellenmanagement, kein Incident.

Schweregrad

Standard-Schweregrad: Hoch.

Auf Kritisch anheben, wenn:

  • das Hersteller-Prüfwerkzeug eine Kompromittierung bestätigt
  • Webshells, Implantate oder unbekannte Persistenz gefunden werden
  • Zugangsdaten, Sitzungen oder Konfigurationsgeheimnisse wahrscheinlich abgeflossen sind
  • Folgeaktivität im internen Netz sichtbar ist
  • zentrale Identitätsdienste oder privilegierte Dienstkonten betroffen sind
  • die Schwachstelle unauthentisierte Ausführung ermöglicht und das Gerät über längere Zeit exponiert war

First 15 Minutes

Die ersten 15 Minuten

▶

▶ Act immediately

  • Name an incident lead and start the timeline and decision log.
  • Record product, exact version, build, serial number, location and reachability.
  • Check whether HA partners, secondary sites, test or legacy devices of the same type exist.
  • Read the vendor advisory: affected component, workaround, checking tool and published IOCs.
  • Do not reboot, patch or reset yet, unless active damage is occurring.
  • Apply an immediate, evidence-preserving interim measure: take the management interface off the internet, disable the affected feature, or restrict access to known source networks.
  • Preserve device, firewall, proxy, WAF, DNS and SIEM logs for the exploitation window.
  • Bring in network, identity and server owners.
  • Start a first search for follow-on activity from the VPN pool and the device IP.
  • Give management, legal and data protection an early warning if sessions, credentials or data may be affected.

▸ Contacts and Escalation

Pre-fill these for your organization and keep them available offline:

  • Incident lead on call
  • Network and firewall owners
  • IAM, AD, RADIUS and SAML owners
  • Vendor support and PSIRT
  • Reporting bodies: BSI (DE), competent CSIRT (AT), NCSC/BACS (CH)
  • External forensics and incident response providers
  • Cyber insurance
  • Management, legal, data protection and communications

▶ Sofort handeln

  • Incident-Lead benennen sowie Timeline und Entscheidungsprotokoll starten.
  • Produkt, exakte Version, Build, Seriennummer, Standort und Erreichbarkeit dokumentieren.
  • Prüfen, ob HA-Partner, Zweitstandorte, Test- oder Altgeräte desselben Typs existieren.
  • Herstellerhinweis lesen: betroffene Komponente, Workaround, Prüfwerkzeug und veröffentlichte IOCs.
  • Noch nicht neu starten, patchen oder zurücksetzen, sofern keine aktive Schadwirkung läuft.
  • Sofortige, beweisschonende Übergangsmaßnahme umsetzen: Management-Oberfläche vom Internet nehmen, betroffene Funktion deaktivieren oder Zugriff auf bekannte Quellnetze beschränken.
  • Geräte-, Firewall-, Proxy-, WAF-, DNS- und SIEM-Logs für den Ausnutzungszeitraum sichern.
  • Netzwerk-, Identitäts- und Server-Verantwortliche einbinden.
  • Eine erste Suche nach Folgeaktivität aus VPN-Pool und Geräte-IP starten.
  • Management, Legal und Datenschutz vorwarnen, wenn Sessions, Zugangsdaten oder Daten betroffen sein könnten.

▸ Kontakte und Eskalation

Diese Angaben organisationsspezifisch vorbelegen und offline verfügbar halten:

  • Incident-Lead on call
  • Netzwerk- und Firewall-Verantwortliche
  • IAM-, AD-, RADIUS- und SAML-Verantwortliche
  • Hersteller-Support und PSIRT
  • Meldestellen: BSI (DE), zuständiges CSIRT (AT), BACS (CH)
  • Externe Forensik und Incident-Response-Dienstleister
  • Cyberversicherung
  • Management, Legal, Datenschutz und Kommunikation

Objectives & Principles

Ziele & Prinzipien

▶

Purpose

  • Quickly establish whether a vulnerable edge device was actually exploited
  • Preserve evidence before a reboot, patch or log rotation destroys it
  • Effectively reduce the attack surface
  • Identify and invalidate credentials, sessions and secrets
  • Detect and stop spread into the internal network
  • Return the device to service in a demonstrably trustworthy state

Incident Objectives

  1. Establish whether and since when the device was exploited.
  2. Preserve volatile evidence before the device is changed.
  3. Interrupt further exploitation and attacker access.
  4. Invalidate affected credentials, sessions and secrets.
  5. Detect lateral movement and follow-on activity.
  6. Return the device to service only in a demonstrably trustworthy state.

Core Response Principles

  • Patching is necessary, but it is not proof of cleanliness. Persistence can survive a patch and a reboot.
  • Preserve first, then patch. A patch, reboot or factory reset can erase decisive traces.
  • Everything that passed through or was stored on the device is initially considered at risk. That includes user passwords, sessions, LDAP/RADIUS service accounts, certificates, private keys and API tokens.
  • The time window matters. What counts is the window from the first known exploitation until the device was secured.
  • The device is a starting point, not the target. The investigation does not end at the device.
  • Use vendor tools, but do not trust them blindly. A negative result reduces risk but does not rule out a compromise.
  • Sessions survive the patch. With "Citrix Bleed" (CVE-2023-4966), attackers read session tokens from memory and used them to take over sessions that had already passed MFA. Those who only patched, without terminating all sessions, left the attackers in the system.
  • Record time consistently. Document the device clock, time zone and any drift relative to SIEM, firewall and directory service at the start.
  • Keep a timeline and a decision log.

Zweck

  • Schnell klären, ob ein verwundbares Edge-Gerät tatsächlich ausgenutzt wurde
  • Beweise sichern, bevor Neustart, Patch oder Log-Rotation sie zerstören
  • Die Angriffsfläche wirksam verkleinern
  • Zugangsdaten, Sitzungen und Geheimnisse identifizieren und ungültig machen
  • Eine Ausbreitung ins interne Netz erkennen und stoppen
  • Das Gerät nachweisbar vertrauenswürdig wieder in Betrieb nehmen

Incident-Ziele

  1. Feststellen, ob und seit wann das Gerät ausgenutzt wurde.
  2. Flüchtige Beweise vor Änderung des Geräts sichern.
  3. Weitere Ausnutzung und Angreiferzugang unterbrechen.
  4. Betroffene Zugangsdaten, Sitzungen und Geheimnisse ungültig machen.
  5. Laterale Bewegung und Folgeaktivität erkennen.
  6. Das Gerät nur in nachweisbar vertrauenswürdigem Zustand wieder in Betrieb nehmen.

Zentrale Reaktionsprinzipien

  • Patchen ist notwendig, aber kein Sauberkeitsnachweis. Persistenz kann Patch und Neustart überdauern.
  • Zuerst sichern, dann patchen. Patch, Neustart oder Factory Reset können entscheidende Spuren löschen.
  • Alles, was über das Gerät lief oder dort gespeichert war, gilt zunächst als gefährdet. Dazu gehören Benutzerpasswörter, Sitzungen, LDAP-/RADIUS-Dienstkonten, Zertifikate, private Schlüssel und API-Tokens.
  • Der Zeitraum zählt. Maßgeblich ist das Fenster von der ersten bekannten Ausnutzung bis zur Absicherung.
  • Das Gerät ist ein Ausgangspunkt, nicht das Ziel. Die Untersuchung endet nicht am Gerät.
  • Herstellerwerkzeuge nutzen, aber nicht blind vertrauen. Ein negatives Ergebnis reduziert Risiko, schließt eine Kompromittierung aber nicht aus.
  • Sitzungen überleben den Patch. Bei „Citrix Bleed“ (CVE-2023-4966) lasen Angreifer Sitzungstoken aus dem Speicher und übernahmen damit Sitzungen samt bestandener MFA. Wer nur patchte, ohne alle Sitzungen zu beenden, ließ die Angreifer im System.
  • Zeit konsistent erfassen. Geräteuhr, Zeitzone und mögliche Zeitabweichungen zu SIEM, Firewall und Verzeichnisdienst zu Beginn dokumentieren.
  • Timeline und Entscheidungsprotokoll führen.

Roles & Responsibilities

Rollen & Verantwortlichkeiten

▶

Incident lead

  • Steers the response and prioritizes actions.
  • Decides together with management on shutdown, restricted operation and return to service.
  • Keeps the timeline, situation picture and decision log.

Network and device owners

  • Preserve configuration, logs and diagnostic data.
  • Implement interim measures, patch, rebuild and hardening.
  • Stay in contact with vendor support and PSIRT.

Identity and access

  • Determine affected accounts, sessions and secrets.
  • Run password resets, session revocation, certificate and key rotation.

Forensics and threat hunting

  • Analyze device, network and directory service data.
  • Search for follow-on activity and assess vendor integrity checks.

Legal, data protection and communications

  • Assess reporting obligations.
  • Coordinate internal and external communication.
  • Check contractual and insurance obligations.

Incident-Lead

  • Steuert die Reaktion und priorisiert Maßnahmen.
  • Entscheidet gemeinsam mit Management über Abschaltung, eingeschränkten Weiterbetrieb und Wiederinbetriebnahme.
  • Führt Timeline, Lagebild und Entscheidungsprotokoll.

Netzwerk- und Geräteverantwortliche

  • Sichern Konfiguration, Logs und Diagnosedaten.
  • Setzen Übergangsmaßnahmen, Patch, Neuaufbau und Härtung um.
  • Halten Kontakt zu Hersteller-Support und PSIRT.

Identität und Zugriff

  • Bestimmen betroffene Konten, Sitzungen und Geheimnisse.
  • Steuern Passwort-Resets, Session-Widerruf, Zertifikats- und Schlüsselrotation.

Forensik und Threat Hunting

  • Werten Geräte-, Netzwerk- und Verzeichnisdienst-Daten aus.
  • Suchen nach Folgeaktivität und bewerten Hersteller-Integritätsprüfungen.

Legal, Datenschutz und Kommunikation

  • Bewerten Meldepflichten.
  • Koordinieren interne und externe Kommunikation.
  • Prüfen Vertrags- und Versicherungspflichten.

Decision Model

Entscheidungsmodell

▶

Rule 1: Just patch, or treat as an incident?

Apply the full playbook if all three criteria are met:

  1. The vulnerability is being actively exploited, or there are credible indications of it.
  2. The device ran a vulnerable version during the exploitation window.
  3. The vulnerable component was reachable from a network an attacker could reach.

Patching and documenting can be sufficient if at least one of these criteria is reliably not met. The justification must be recorded in the decision log.

Rule 2: Shut down or keep running with restrictions?

Disconnect immediately or disable the affected feature if

  • active attacker activity on or through the device is visible
  • no effective interim measure is available
  • the vendor check reports a compromise
  • unauthenticated code execution is possible and the device would remain exposed

Continued restricted operation is only justifiable if

  • the vulnerable feature has been effectively disabled or restricted
  • there are no active attacker indicators
  • a longer outage would seriously endanger business operations
  • the incident lead and accountable management approve the risk acceptance in writing

No patch available (zero-day): If there is neither a patch nor an effective vendor interim measure, disable the vulnerable feature or disconnect the device from the internet until a fix is available. Plan an alternative access path for the meantime, with a tightly limited user group and strong authentication. Continued operation without protection only with documented risk acceptance by management. As soon as the vendor publishes IOCs or a checking tool, check retrospectively from the earliest known exploitation date.

Rule 3: Patch, rebuild or replace?

Prefer a rebuild if:

  • compromise is confirmed or likely
  • unknown files, accounts or configuration changes were found
  • the vendor recommends a reset for compromised devices
  • firmware integrity cannot be verified

Patching may be sufficient if there is no sign of compromise, the vendor check comes back clean and the search for follow-on activity finds nothing.

Replace if the device is end of life or no longer receives security updates.

Rule 4: Which credentials must be renewed?

With confirmed or likely compromise:

  • Rotate the device's local admin accounts and management access
  • Rotate LDAP, AD and RADIUS service accounts
  • Terminate VPN and portal sessions
  • Replace API tokens, configuration secrets and deploy credentials
  • Replace TLS, SAML and other private keys and certificates unless exfiltration can be ruled out
  • Rotate site-to-site VPN pre-shared keys and partner connections
  • Reset user passwords for people who signed in during the exploitation window, if the vulnerability gave access to authentication data or session information

Regel 1: Nur patchen oder als Incident behandeln?

Das Playbook vollständig anwenden, wenn alle drei Kriterien erfüllt sind:

  1. Die Schwachstelle wird aktiv ausgenutzt oder es existieren belastbare Hinweise darauf.
  2. Das Gerät war im Ausnutzungszeitraum mit einer verwundbaren Version in Betrieb.
  3. Die verwundbare Komponente war aus einem für Angreifer erreichbaren Netz zugänglich.

Patchen und dokumentieren kann ausreichen, wenn mindestens eines dieser Kriterien sicher nicht erfüllt ist. Die Begründung muss im Entscheidungsprotokoll stehen.

Regel 2: Abschalten oder eingeschränkt weiterbetreiben?

Sofort trennen oder die betroffene Funktion abschalten, wenn

  • aktive Angreiferaktivität auf oder über das Gerät sichtbar ist
  • keine wirksame Übergangsmaßnahme verfügbar ist
  • Herstellerprüfung eine Kompromittierung meldet
  • unauthentisierte Code-Ausführung möglich ist und das Gerät weiter exponiert wäre

Eingeschränkt weiterbetreiben ist nur vertretbar, wenn

  • die verwundbare Funktion wirksam abgeschaltet oder begrenzt wurde
  • keine aktiven Angreiferindikatoren vorliegen
  • ein längerer Ausfall den Geschäftsbetrieb erheblich gefährdet
  • Incident-Lead und verantwortliches Management die Risikoübernahme dokumentiert freigeben

Kein Patch verfügbar (Zero-Day): Gibt es weder Patch noch wirksame Übergangsmaßnahme des Herstellers, die verwundbare Funktion abschalten oder das Gerät vom Internet trennen, bis eine Lösung vorliegt. Für die Zwischenzeit einen Ersatzweg mit eng begrenztem Benutzerkreis und starker Authentisierung planen. Weiterbetrieb ohne Schutz nur mit dokumentierter Risikoübernahme durch das Management. Sobald der Hersteller IOCs oder ein Prüfwerkzeug veröffentlicht, rückwirkend ab dem frühesten bekannten Ausnutzungszeitpunkt prüfen.

Regel 3: Patchen, neu aufbauen oder ersetzen?

Neuaufbau bevorzugen, wenn:

  • Kompromittierung bestätigt oder wahrscheinlich ist
  • unbekannte Dateien, Konten oder Konfigurationsänderungen gefunden wurden
  • der Hersteller für kompromittierte Geräte einen Reset empfiehlt
  • Firmware-Integrität nicht überprüfbar ist

Patchen kann ausreichen, wenn kein Hinweis auf Kompromittierung besteht, Herstellerprüfung unauffällig bleibt und die Suche nach Folgeaktivität ergebnislos ist.

Ersetzen, wenn das Gerät End of Life ist oder kein Sicherheitsupdate mehr bereitgestellt wird.

Regel 4: Welche Zugangsdaten müssen erneuert werden?

Bei bestätigter oder wahrscheinlicher Kompromittierung:

  • Lokale Admin-Konten und Management-Zugänge des Geräts rotieren
  • LDAP-, AD- und RADIUS-Dienstkonten rotieren
  • VPN- und Portal-Sitzungen beenden
  • API-Tokens, Konfigurationsgeheimnisse und Deploy-Credentials ersetzen
  • TLS-, SAML- und andere private Schlüssel sowie Zertifikate ersetzen, sofern Abfluss nicht ausgeschlossen ist
  • Site-to-Site-VPN-Pre-Shared Keys und Partner-Verbindungen rotieren
  • Benutzerpasswörter für während des Ausnutzungszeitraums angemeldete Personen zurücksetzen, wenn die Schwachstelle Zugriff auf Authentisierungsdaten oder Sitzungsinformationen ermöglicht hat

Situation and Action Matrix

Lage- und Maßnahmenmatrix

▶
SituationMinimum action
Vulnerable and reachable, no sign of exploitationMitigation or patch, log preservation, targeted validation
Actively exploited flaw, device exposedFull incident procedure, evidence preservation, vendor check and hunting
IOC, web shell or persistence foundTreat the device as compromised, rebuild, rotate secrets, widen the search
Identity services or privileged service accounts affectedActivate the identity playbook in parallel
Lateral movement or ransomware indicators visibleAdditionally activate the ransomware playbook
LagebildMindestmaßnahme
Verwundbar und erreichbar, keine AusnutzungshinweiseMitigation oder Patch, Log-Sicherung, gezielte Validierung
Aktiv ausgenutzte Lücke, Gerät exponiertVollständiges Incident-Verfahren, Beweissicherung, Herstellerprüfung und Hunting
IOC, Webshell oder Persistenz gefundenGerät als kompromittiert behandeln, neu aufbauen, Secrets rotieren, Suche ausweiten
Identitätsdienste oder privilegierte Dienstkonten betroffenIdentitäts-Playbook parallel aktivieren
Laterale Bewegung oder Ransomware-Indikatoren sichtbarRansomware-Playbook zusätzlich aktivieren

Rotation Order for Secrets

Rotationsreihenfolge für Geheimnisse

▶
  1. Terminate active VPN and portal sessions — the fastest step, it interrupts ongoing access. Only effective once the interim measure is in place; otherwise the attacker takes over new sessions.
  2. Break-glass and highly privileged admin access
  3. Local device administrators and management access
  4. LDAP, RADIUS, AD or SAML service accounts
  5. User passwords by risk group
  6. API tokens, private keys, certificates and pre-shared keys
  7. Site-to-site VPN and partner connections
  8. Non-critical technical integrations
  1. Aktive VPN- und Portal-Sitzungen beenden — der schnellste Schritt, er unterbricht einen laufenden Zugriff. Erst wirksam, wenn die Übergangsmaßnahme greift, sonst übernimmt der Angreifer neue Sitzungen.
  2. Break-Glass- und hochprivilegierte Admin-Zugänge
  3. Lokale Geräteadministratoren und Management-Zugänge
  4. LDAP-, RADIUS-, AD- oder SAML-Dienstkonten
  5. Benutzerpasswörter nach Risikogruppen
  6. API-Tokens, private Schlüssel, Zertifikate und Pre-Shared Keys
  7. Site-to-Site-VPN- und Partner-Verbindungen
  8. Nicht kritische technische Integrationen

What Makes Edge Devices Different

Besonderheiten von Edge-Geräten

▶
  • Edge devices often have no EDR integration, limited local logs and restricted forensic options.
  • They hold secrets: sessions, credentials, directory service accounts and certificates.
  • Traffic from the device and from VPN pools is often trusted more internally than external traffic.
  • HA and cluster partners can take over a compromised configuration.
  • Configuration backups from the exploitation window may already contain manipulated settings.
  • Edge-Geräte haben häufig keine EDR-Integration, begrenzte lokale Logs und eingeschränkte forensische Möglichkeiten.
  • Sie sind Geheimnisträger für Sitzungen, Zugangsdaten, Verzeichnisdienst-Konten und Zertifikate.
  • Verkehr vom Gerät und aus VPN-Pools wird intern oft stärker vertraut als externer Verkehr.
  • HA- und Cluster-Partner können kompromittierte Konfigurationen übernehmen.
  • Konfigurationsbackups aus dem Ausnutzungszeitraum können bereits manipulierte Einstellungen enthalten.

1 · Detect and Triage

1 · Erkennen und Triage

▶
Assess exploitation and its likely start Preserve volatile evidence before a patch, reset or log rotation
  • Record version, build, patch history, uptime and configuration.
  • Compare the running configuration with the last known good version.
  • Generate diagnostic and support bundles as specified by the vendor.
  • Run the vendor's integrity or IOC checking tool.
  • Export local system, admin, VPN and portal logs.
  • Preserve firewall, NetFlow, proxy, WAF, DNS and SIEM data.
  • Search for exploit paths, suspicious user agents, source IP addresses and outbound connections from the device.
  • If virtualized, take a snapshot including memory where technically possible.
  • Determine the exploitation window from vendor, CERT and threat intelligence data.

▸ Initial classification

  • Vulnerable, no indications: the device was exposed and vulnerable, checks so far clean
  • Exploitation attempt: exploit requests visible, but no evidence of successful execution
  • Exploited: indications of successful execution, files, accounts or configuration changes
  • Exploited with follow-on activity: additionally internal access, scans, remote execution or data exfiltration

Exit criteria

  • Preliminary classification documented
  • Configuration, logs, diagnostic data and check results preserved
  • Exploitation window determined
  • First hypotheses on secrets and follow-on activity documented
Ausnutzung und möglichen Beginn bewerten Flüchtige Beweise vor Patch, Reset oder Log-Rotation sichern
  • Version, Build, Patch-Historie, Uptime und Konfiguration erfassen.
  • Laufende Konfiguration gegen die letzte bekannte gute Version vergleichen.
  • Diagnose- und Supportpakete nach Herstellervorgabe erzeugen.
  • Hersteller-Integritäts- oder IOC-Prüfwerkzeug nutzen.
  • Lokale System-, Admin-, VPN- und Portal-Logs exportieren.
  • Firewall-, NetFlow-, Proxy-, WAF-, DNS- und SIEM-Daten sichern.
  • Nach Exploit-Pfaden, verdächtigen User-Agents, Quell-IP-Adressen und ausgehenden Verbindungen des Geräts suchen.
  • Bei Virtualisierung Snapshot inklusive Speicher erstellen, wenn technisch möglich.
  • Ausnutzungszeitraum anhand Hersteller-, CERT- und Threat-Intelligence-Daten bestimmen.

▸ Erste Klassifizierung

  • Verwundbar, keine Hinweise: Gerät war exponiert und verwundbar, Prüfungen bislang unauffällig
  • Ausnutzungsversuch: Exploit-Anfragen sichtbar, aber kein Beleg erfolgreicher Ausführung
  • Ausgenutzt: Hinweise auf erfolgreiche Ausführung, Dateien, Konten oder Konfigurationsänderungen
  • Ausgenutzt mit Folgeaktivität: Zusätzlich interne Zugriffe, Scans, Remote-Ausführung oder Datenabfluss

Exit-Kriterien

  • Vorläufige Klassifizierung dokumentiert
  • Konfiguration, Logs, Diagnosedaten und Prüfergebnisse gesichert
  • Ausnutzungszeitraum bestimmt
  • Erste Hypothesen zu Geheimnissen und Folgeaktivität dokumentiert

2 · Contain

2 · Eindämmen

▶
Stop further exploitation and attacker access Limit internal spread
  • Apply the vendor mitigation or disable the affected feature.
  • Allow management access only from a dedicated admin network.
  • If compromise is suspected, terminate all VPN and portal sessions.
  • Rotate the device's service accounts and check them for unusual sign-ins.
  • Limit access from the VPN pool and the device IP to the destinations that are needed.
  • Block admin protocols such as RDP, SMB, WinRM and SSH from the VPN pool into sensitive segments, or limit them to named groups.
  • Block known malicious IP addresses and domains where the attribution is reliable.
  • Include HA partners and identical systems in the measures.
  • Provide a limited alternative remote access path with strong authentication if needed.

Do not

  • Do not just patch the device and close the incident. The patch ends the known exploitation, but removes neither persistence nor access that has already been stolen.
  • Do not reboot before volatile evidence has been preserved, or its loss has been accepted deliberately and documented.
  • Do not assume the patch automatically invalidates existing sessions.
  • Do not reset all user passwords without a coordinated IAM, helpdesk and communication plan.
  • Do not restore configuration backups from the exploitation window without checking them.
  • Do not treat a negative vendor check as the sole proof of cleanliness.

Exit criteria

  • Vulnerable component no longer reachable or exploitable
  • Sessions and prioritized secrets handled according to the rotation plan
  • Internal access from the device and VPN context restricted and monitored
Weitere Ausnutzung und Angreiferzugang stoppen Interne Ausbreitung begrenzen
  • Hersteller-Mitigationsmaßnahme umsetzen oder betroffene Funktion deaktivieren.
  • Management-Zugang nur aus einem dedizierten Admin-Netz erlauben.
  • Bei Kompromittierungsverdacht alle VPN- und Portal-Sitzungen beenden.
  • Dienstkonten des Geräts rotieren und auf ungewöhnliche Anmeldungen prüfen.
  • Zugriffe aus VPN-Pool und Geräte-IP auf notwendige Ziele begrenzen.
  • Admin-Protokolle wie RDP, SMB, WinRM und SSH aus dem VPN-Pool in sensible Segmente sperren oder auf benannte Gruppen begrenzen.
  • Bekannte bösartige IP-Adressen und Domains blockieren, sofern die Zuordnung belastbar ist.
  • HA-Partner und baugleiche Systeme in die Maßnahmen einbeziehen.
  • Für Fernzugriff einen begrenzten Ersatzweg mit starker Authentisierung bereitstellen, wenn nötig.

Nicht tun

  • Das Gerät nicht nur patchen und den Incident damit schließen. Der Patch beendet die bekannte Ausnutzung, beseitigt aber weder Persistenz noch bereits gestohlene Zugänge.
  • Nicht neu starten, bevor flüchtige Beweise gesichert oder ihr Verlust bewusst und dokumentiert in Kauf genommen wurde.
  • Nicht annehmen, dass der Patch bestehende Sessions automatisch ungültig macht.
  • Nicht alle Benutzerpasswörter ohne abgestimmten IAM-, Helpdesk- und Kommunikationsplan zurücksetzen.
  • Konfigurationsbackups aus dem Ausnutzungszeitraum nicht ungeprüft wiederherstellen.
  • Ein negatives Hersteller-Prüfwerkzeug nicht als alleinigen Sauberkeitsnachweis werten.

Exit-Kriterien

  • Verwundbare Komponente nicht mehr erreichbar oder ausnutzbar
  • Sitzungen und priorisierte Geheimnisse nach Rotationsplan behandelt
  • Interne Zugriffe aus Geräte- und VPN-Kontext eingeschränkt und überwacht

3 · Investigate

3 · Untersuchen

▶
Reconstruct the actions on the device Determine affected secrets and internal follow-on activity
  • Analyze device and network data with the vendor or external forensics.
  • Analyze sign-ins from the device IP and the VPN pool in the directory service.
  • Check in particular whether LDAP or RADIUS service accounts were used from other sources or interactively.
  • Examine new accounts, group memberships and group policies in the relevant period.
  • Check VPN sessions for plausible source IP, time, device and behavior.
  • Search for AD reconnaissance, remote execution, new administration tools, access to hypervisors, backup systems, and data exfiltration.
  • Check whether configuration files or key material could have been read.

Exit criteria

  • A plausible picture of device activity and affected secrets
  • Follow-on activity classified as none, limited or extensive
  • Handover to the identity, data breach or ransomware playbook completed where required
Handlungen auf dem Gerät rekonstruieren Betroffene Geheimnisse und interne Folgeaktivität bestimmen
  • Geräte- und Netzwerkdaten mit Hersteller oder externer Forensik auswerten.
  • Anmeldungen aus Geräte-IP und VPN-Pool im Verzeichnisdienst analysieren.
  • Besonders prüfen, ob LDAP- oder RADIUS-Dienstkonten von anderen Quellen oder interaktiv genutzt wurden.
  • Neue Konten, Gruppenmitgliedschaften und Gruppenrichtlinien im relevanten Zeitraum untersuchen.
  • VPN-Sitzungen auf plausible Quell-IP, Zeit, Gerätebezug und Verhalten prüfen.
  • Nach AD-Erkundung, Remote-Ausführung, neuen Administrationstools, Zugriff auf Hypervisoren, Backup-Systeme und Datenabfluss suchen.
  • Prüfen, ob Konfigurationsdateien oder Schlüsselmaterial ausgelesen werden konnten.

Exit-Kriterien

  • Plausibles Bild der Geräteaktivität und betroffenen Geheimnisse
  • Folgeaktivität als keine, begrenzt oder umfangreich klassifiziert
  • Übergabe an Identitäts-, Datenpannen- oder Ransomware-Playbook erfolgt, falls erforderlich

4 · Eradicate

4 · Beseitigen

▶
Completely remove persistence and attacker access Return the device to a trustworthy state
  • With confirmed or likely compromise, factory reset or reinstall with current, verified vendor firmware.
  • Take the configuration from a state before the exploitation window, or rebuild it deliberately.
  • Do not blindly restore a full configuration backup from the compromised period.
  • Renew local accounts, service accounts, keys, certificates and pre-shared keys according to the rotation plan.
  • Remove unknown accounts, rules and internal follow-on changes.
  • Restrict management to a dedicated admin network, disable features that are not needed, enable MFA and central logging.
  • Repeat the integrity check after the rebuild.

Exit criteria

  • Device up to date, rebuilt or demonstrably clean
  • Relevant secrets rotated
  • Persistence and follow-on artifacts removed
  • Hardening measures implemented
Persistenz und Angreiferzugang vollständig entfernen Gerät in vertrauenswürdigen Zustand zurückführen
  • Bei bestätigter oder wahrscheinlicher Kompromittierung Factory Reset oder Neuinstallation mit aktueller, geprüfter Hersteller-Firmware.
  • Konfiguration aus einem Stand vor dem Ausnutzungszeitraum übernehmen oder gezielt neu erstellen.
  • Keine vollständige Konfigurationssicherung aus dem kompromittierten Zeitraum blind zurückspielen.
  • Lokale Konten, Dienstkonten, Schlüssel, Zertifikate und Pre-Shared Keys gemäß Rotationsplan erneuern.
  • Unbekannte Konten, Regeln und interne Folgeänderungen entfernen.
  • Management auf dediziertes Admin-Netz beschränken, nicht benötigte Funktionen deaktivieren, MFA und zentrales Logging aktivieren.
  • Integritätsprüfung nach Neuaufbau wiederholen.

Exit-Kriterien

  • Gerät aktuell, neu aufgebaut oder nachweislich sauber
  • Relevante Geheimnisse rotiert
  • Persistenz und Folgeartefakte entfernt
  • Härtungsmaßnahmen umgesetzt

5 · Recover

5 · Wiederanlauf

▶
Restore operations in a controlled way Detect recurrence early
  • Release features step by step, starting with test or pilot groups.
  • Lift restrictions on the VPN pool only after review.
  • Keep enhanced monitoring in place for at least 30 days: admin sign-ins, configuration changes, outbound connections, VPN anomalies and access into sensitive networks.
  • Inform users where needed about password changes, signing in again or MFA registration.

Exit criteria

  • Stable operations
  • Monitoring without new anomalies
  • Residual risks documented and assigned
Betrieb kontrolliert wiederherstellen Wiederauftreten früh erkennen
  • Funktionen stufenweise freigeben, zunächst für Test- oder Pilotgruppen.
  • Einschränkungen für VPN-Pool nur nach Prüfung zurücknehmen.
  • Erhöhtes Monitoring mindestens 30 Tage aufrechterhalten: Admin-Anmeldungen, Konfigurationsänderungen, ausgehende Verbindungen, VPN-Auffälligkeiten und Zugriffe in sensible Netze.
  • Benutzer bei Bedarf über Passwortwechsel, Session-Neuanmeldung oder MFA-Registrierung informieren.

Exit-Kriterien

  • Stabiler Betrieb
  • Monitoring ohne neue Auffälligkeiten
  • Restrisiken dokumentiert und zugewiesen

6 · Review

6 · Nachbereitung

▶
  • Hold the post-incident review within ten business days.
  • Assess the time from disclosure of the vulnerability to effective protection.
  • Correct the edge inventory, ownership, reachability and version levels.
  • Improve the emergency patch process for actively exploited vulnerabilities.
  • Ensure central logging and an adequate retention period.
  • Assess dependence on single remote access solutions and plan alternatives.
  • Nachbesprechung innerhalb von zehn Geschäftstagen durchführen.
  • Zeit vom Bekanntwerden der Schwachstelle bis zur wirksamen Absicherung bewerten.
  • Edge-Inventar, Verantwortlichkeiten, Erreichbarkeit und Versionsstände korrigieren.
  • Notfall-Patchprozess für aktiv ausgenutzte Schwachstellen verbessern.
  • Zentrales Logging und angemessene Aufbewahrungsdauer sicherstellen.
  • Abhängigkeit von einzelnen Fernzugangslösungen bewerten und Ersatzwege planen.

Evidence & Communication

Beweise & Kommunikation

▶

Evidence to Preserve

  • Version, build, serial number, uptime and patch history
  • Running configuration and last known good configuration
  • Vendor diagnostic and support bundles
  • Results of integrity and IOC checking tools
  • System, admin, VPN and portal logs
  • Firewall, NetFlow, WAF, proxy, DNS and SIEM data
  • Directory service logs for sign-ins from the VPN pool and device IP
  • Snapshot including memory, if virtualized
  • List of affected users and sessions
  • Timeline and decision log

Communication Checklist

Internal

  • Inform management about the situation, risks and expected restrictions.
  • Prepare operations and the helpdesk for dropped sessions, password changes and support volume.
  • Guide users only through known internal channels.

External

  • Involve vendor support or PSIRT through a known contact path.
  • Inform partners with site-to-site connections about renewed keys and maintenance windows.
  • Involve insurance and external forensics according to contract.
  • Check reporting obligations.

▸ Template: VPN notice

As a security measure, we have terminated active VPN sessions. Please sign in again through the usual access point. If a password change is required, you will be told so only through our known internal channels. Do not enter your password via links in unexpected emails. Support: [helpdesk contact].

Zu sichernde Beweise

  • Version, Build, Seriennummer, Uptime und Patch-Historie
  • Laufende Konfiguration und letzte bekannte gute Konfiguration
  • Hersteller-Diagnose- und Supportpakete
  • Ergebnisse der Integritäts- und IOC-Prüfwerkzeuge
  • System-, Admin-, VPN- und Portal-Logs
  • Firewall-, NetFlow-, WAF-, Proxy-, DNS- und SIEM-Daten
  • Verzeichnisdienst-Logs zu Anmeldungen aus VPN-Pool und Geräte-IP
  • Snapshot inklusive Speicher, falls virtualisiert
  • Liste betroffener Benutzer und Sessions
  • Timeline und Entscheidungsprotokoll

Kommunikations-Checkliste

Intern

  • Management über Lagebild, Risiken und erwartete Einschränkungen informieren.
  • Betrieb und Helpdesk auf Sitzungsabbrüche, Passwortwechsel und Supportaufkommen vorbereiten.
  • Benutzer nur über bekannte interne Kanäle anleiten.

Extern

  • Hersteller-Support oder PSIRT über einen bekannten Kontaktweg einbinden.
  • Partner mit Site-to-Site-Verbindungen über erneuerte Schlüssel und Wartungsfenster informieren.
  • Versicherung und externe Forensik nach Vertrag einbinden.
  • Meldepflichten prüfen.

▸ Vorlage: VPN-Information

Aufgrund einer Sicherheitsmaßnahme haben wir aktive VPN-Sitzungen beendet. Bitte melden Sie sich erneut über den bekannten Zugang an. Falls ein Passwortwechsel erforderlich ist, erhalten Sie dazu eine Mitteilung ausschließlich über unsere bekannten internen Kanäle. Geben Sie Ihr Passwort nicht über Links in unerwarteten E-Mails ein. Unterstützung: [Helpdesk-Kontakt].

Quick Response Checklist

Quick-Response-Checkliste

▶

Immediately

Assessment

Containment and eradication

Afterwards

Sofort

Bewertung

Eindämmung und Beseitigung

Danach

Prevention & References

Prävention & Referenzen

▶

Preventive Controls

  • Complete edge inventory with version, reachability, owners and criticality
  • Subscribe to vendor security advisories and match them against actively exploited vulnerabilities
  • Emergency patch process with clear decision authority
  • No management interfaces reachable from the internet
  • MFA for VPN and administration
  • Central logging with sufficient retention
  • Segmented VPN access following least privilege
  • Minimal rights for directory service and technical service accounts
  • Regular vendor integrity checks
  • Independent emergency access for administrators

References

  • NIST SP 800-61 Rev. 3
  • CISA Known Exploited Vulnerabilities Catalog
  • Vendor security advisories and integrity checking tools
  • BSI warnings on perimeter and remote access systems
  • MITRE ATT&CK: T1190, T1133, T1505.003

Disclaimer

This playbook is a practical community resource. It does not replace legal advice, forensic expertise, vendor guidance, cyber insurance requirements or organization-specific incident response planning.

Präventive Kontrollen

  • Vollständiges Edge-Inventar mit Version, Erreichbarkeit, Verantwortlichen und Kritikalität
  • Hersteller-Sicherheitswarnungen abonnieren und gegen aktiv ausgenutzte Schwachstellen abgleichen
  • Notfall-Patchprozess mit klarer Entscheidungsbefugnis
  • Keine aus dem Internet erreichbaren Management-Oberflächen
  • MFA für VPN und Administration
  • Zentrales Logging mit ausreichender Aufbewahrung
  • Segmentierter VPN-Zugang nach Least Privilege
  • Minimale Rechte für Verzeichnisdienst- und technische Dienstkonten
  • Regelmäßige Hersteller-Integritätsprüfungen
  • Unabhängiger Notfallzugang für Administratoren

Referenzen

  • NIST SP 800-61 Rev. 3
  • CISA Known Exploited Vulnerabilities Catalog
  • Hersteller-Sicherheitswarnungen und Integritätsprüfwerkzeuge
  • BSI-Warnungen zu Perimeter- und Fernzugangssystemen
  • MITRE ATT&CK: T1190, T1133, T1505.003

Disclaimer

Dieses Playbook ist eine praktische Community-Ressource. Es ersetzt keine Rechtsberatung, forensische Expertise, Herstellervorgaben, Cyberversicherungsanforderungen oder organisationsspezifische Incident-Response-Planung.

Threat Sentinel IR Playbook Library  ·  CC BY 4.0

github.com/threat-sentinel/playbooks  ·  threat-sentinel.com

Public OSINT dashboard · no account, no tracking │ loaded Privacy │ press / to search