# Playbook: Edge Device Exploitation ## Summary 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. ## 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 ## 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 ## 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.** ## 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 ## First 15 Minutes - 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. ## Roles and Responsibilities ### 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. ## Decision Model ### 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 ## Situation and Action Matrix | Situation | Minimum action | |---|---| | Vulnerable and reachable, no sign of exploitation | Mitigation or patch, log preservation, targeted validation | | Actively exploited flaw, device exposed | Full incident procedure, evidence preservation, vendor check and hunting | | IOC, web shell or persistence found | Treat the device as compromised, rebuild, rotate secrets, widen the search | | Identity services or privileged service accounts affected | Activate the identity playbook in parallel | | Lateral movement or ransomware indicators visible | Additionally activate the ransomware playbook | ## Rotation Order for Secrets 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 ## What Makes Edge Devices Different - 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. ## Phase 1: Detect and Triage ### Objectives - Assess exploitation and its likely start. - Preserve volatile evidence before a patch, reset or log rotation. ### Actions - 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 ## Phase 2: Contain ### Objectives - Stop further exploitation and attacker access. - Limit internal spread. ### Actions - 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 ## Phase 3: Investigate ### Objectives - Reconstruct the actions on the device. - Determine affected secrets and internal follow-on activity. ### Actions - 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 ## Phase 4: Eradicate ### Objectives - Completely remove persistence and attacker access. - Return the device to a trustworthy state. ### Actions - 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 ## Phase 5: Recover ### Objectives - Restore operations in a controlled way. - Detect recurrence early. ### Actions - 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 ## Phase 6: Review ### Actions - 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. ## 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]. ## Legal and Regulatory Considerations Guidance, not legal advice (as of October 2026). Whether an obligation applies depends on the country, sector, size and role of the organization. Deadlines, reporting channels and contacts should be set in advance and confirmed with legal and data protection when an incident happens. **Reporting obligations for cybersecurity incidents** - **Germany — NIS2 (§ 32 BSIG, since 6 December 2025):** Particularly important and important entities report significant security incidents to the BSI: early warning within 24 hours, notification within 72 hours, final report within one month. - **Austria — NISG 2026 (since 1 October 2026):** Essential and important entities report significant security incidents to the competent CSIRT: early warning within 24 hours, notification within 72 hours. - **Switzerland — Information Security Act (ISA, since 1 April 2025):** Operators of critical infrastructure report cyberattacks to the Federal Office for Cybersecurity (NCSC/BACS) within 24 hours. **Data protection** - **Germany and Austria — GDPR Art. 33/34:** Report personal data breaches to the supervisory authority within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to the individuals; if the risk is high, notify the individuals as well. - **Switzerland — FADP Art. 24:** Report to the FDPIC as soon as possible if the breach is likely to result in a high risk for the individuals. All deadlines run from awareness of the incident, not from the end of the technical investigation. An incomplete early warning within the deadline is better than a complete report after it. **For this scenario** - A confirmed compromise of a central remote access or authentication system is often a significant security incident under NIS2 and the ISA. - Credentials and sessions of employees, partners or customers pass through the device, so personal data is regularly affected. - Contracts with customers, partners (site-to-site connections) and the cyber insurer often contain their own reporting deadlines. ## Quick Response Checklist ### Immediately - [ ] Incident lead, timeline and decision log started - [ ] Product, version, reachability and identical devices recorded - [ ] Vendor advisory, IOCs and interim measures reviewed - [ ] Configuration, logs and diagnostic data preserved before patch or reboot - [ ] Interim measure applied ### Assessment - [ ] Integrity or IOC check performed - [ ] Exploitation window determined - [ ] Classification set - [ ] Search for follow-on activity from the VPN pool and device IP started ### Containment and eradication - [ ] Sessions terminated - [ ] Secrets renewed according to the rotation order - [ ] Device patched, rebuilt or replaced - [ ] Integrity check repeated after restoration ### Afterwards - [ ] Enhanced monitoring for at least 30 days - [ ] Reporting obligations assessed - [ ] Edge inventory and emergency patch process updated ## 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 ## At a Glance This block is not a shortened replacement playbook. It is a quick way in; all sections of this document apply when handling the incident. **Edge Device Exploitation** 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. **Core phases:** Detect, Contain, Investigate, Eradicate, Recover, Review. ## 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.