A compromised external attack surface management (EASM) platform hands an attacker your reconnaissance already done: every internet-facing asset, its weaknesses, any leaked credentials found for your staff and the keys the platform uses to read your cloud accounts and DNS. Unlike most security tools, the damage is less about privileged logons and more about what the attacker learns, what connector keys they can reuse, and what the platform can be made to do: probe systems, hide assets from monitoring or, if a DNS key can write, change records. This playbook covers how the incident shows up, triage, containment in priority order, a rotation plan for connector credentials, restoring scope and inventory, evidence, notification and measurement. It is vendor-neutral and written for exposure management leads, cloud and DNS owners and incident responders. Prevention is covered in Securing the external attack surface management (EASM) itself; this page assumes prevention has failed.
Key takeaways
- Assume the attacker has your exposure list. Every open finding on an internet-facing asset becomes an urgent fix, because the attacker no longer needs to find it.
- Revoke write-capable keys first. DNS provider keys, registrar access and any cloud role that can change resources matter more than read-only connectors; revoke them at the provider.
- Leaked credential findings are live credentials. Reset every account named in the platform's leaked credential data, not only the ones you had already triaged.
- Check scope, not just access. Removed seeds, new exclusions and changed attributions can hide assets from monitoring long after access is revoked.
- Active probing can reach third parties. If the attacker added seeds or ran validation, find out which addresses were probed and involve legal counsel.
What the attacker gains
The table is NHI Mgmt Group's view of a common EASM architecture; products name and split these components differently.
| Component | What it holds or can do | Attacker use |
|---|---|---|
| Asset inventory | Domains, subdomains, IP ranges, certificates, cloud endpoints, forgotten hosts | A complete perimeter map without active reconnaissance (T1590) |
| Exposure findings | Open admin panels, vulnerable versions, screenshots, validation evidence | A prioritised exploitation list |
| Leaked credential data | Staff usernames and sometimes passwords or tokens from breach and paste sources | Working credentials to try (T1589.001) |
| Cloud connectors | Read roles or keys in cloud accounts | Cloud discovery (T1580), key reuse (T1078.004) |
| DNS and registrar connectors | API keys for DNS providers, registrar data access | Zone enumeration; record changes if the key can write |
| Seeds, scope and exclusions | What the platform watches and probes | Hide assets from monitoring, or aim probing at third parties |
| Active validation engine | Sends probes and safe checks from the provider's addresses | Scanning (T1595.002) attributed to you |
| Outbound integrations | Ticketing, chat, SIEM and vulnerability management tokens | Close tickets, leak findings to new destinations, pivot |
How the incident shows up
- Console activity you cannot explain: new users or API keys, bulk exports of assets or findings, role changes, or sign-ins from new locations.
- Scope changes: seeds added or removed, business units restructured, new exclusions, or attributions confirmed without the scope administrator.
- Connector identities acting oddly at the source: the EASM cloud role or DNS key calling APIs it never used before, from addresses outside the provider's published ranges, or gaining new secrets (T1098.001).
- DNS changes: new records, changed name server or mail records, or zone transfers you did not initiate. If records changed, treat it as a DNS incident too and see the Domain Registrar Compromise Playbook.
- Complaints from third parties: abuse reports about scans coming from your EASM provider's addresses against systems you do not own.
- A vendor notice: a SaaS provider may report that its own environment was accessed. The Sumo Logic breach shows the pattern for security SaaS: customers were asked to rotate API keys and every credential they had given the platform for other systems.
Triage questions
- Was it your tenant or the provider? A misused user or API key in your tenant has a narrower scope than a provider-side compromise.
- Which connector credentials exist, and can any of them write? List cloud roles, DNS keys, registrar access and integration tokens, and check each one's permissions at the provider.
- What was exported or viewed? Use the platform audit log, ideally from a copy outside the platform, to find bulk exports, API pulls and views of leaked credential findings.
- Did scope change? Diff seeds, exclusions and attributions against the last trusted export or your asset register.
- Was active validation run? Find which targets were probed, with which checks, and whether any belonged to third parties.
- Are there signs of follow-on attacks? Check internet-facing systems listed in the findings for exploitation attempts, and identity provider logs for sign-ins by accounts named in leaked credential data.
Containment priorities
- Revoke write-capable connectors at the provider. Disable DNS provider keys, registrar access and any cloud role that can modify resources. Review recent changes in each DNS zone and cloud account.
- Pause active validation and scheduled discovery jobs so the platform stops probing, including any targets the attacker added.
- Lock down the tenant. Revoke sessions and API keys, remove unknown users, restrict access to a named response group through single sign-on with phishing-resistant MFA, and keep one verified break-glass account. See the Break-Glass Account Guide.
- Revoke read-only connectors and integration tokens at each cloud account, ticketing system and SIEM, then review what those identities did there.
- Reset leaked credentials. Force password resets and revoke sessions and tokens for every account in the platform's leaked credential data, and check that phishing-resistant MFA is enforced on them.
- Harden the exposed perimeter. Patch or restrict access to the highest-risk findings on internet-facing assets first, using the Emergency Out-of-Band Patching Playbook where needed.
Credential rotation plan
| Order | Credential | Rotate where | Replace with |
|---|---|---|---|
| 1 | DNS provider API keys | Each DNS provider account | Read-only key per account; DNS changes only through your own change process |
| 2 | Registrar access | Registrar account | Read-only export or API; registrar admin stays with the DNS owner. See the Authoritative DNS and Registrar Account Security Guide |
| 3 | Cloud connector keys and roles | Each cloud account or subscription | Inventory-only custom role through a cross-account role or federation, no static keys |
| 4 | Tenant API keys and admin accounts | EASM tenant and identity provider | Per-integration keys with scoped roles and expiry |
| 5 | Outbound integration tokens | Ticketing, chat, SIEM, vulnerability management | Service accounts with project-level rights |
| 6 | Accounts in leaked credential findings | Identity provider and affected applications | New passwords, revoked sessions, phishing-resistant MFA |
- Verify each revocation: confirm in the provider's audit log that the old key fails, and remove any extra secrets or certificates on connector app registrations.
- Rotate in one window: a connector left valid in one cloud account is enough for the attacker to keep reading. See Credential Rotation at Scale.
- Record ownership: each new connector identity gets an owner, scope and rotation date in your NHI inventory. See the External attack surface management (EASM) integration security guide.
Restoring scope and inventory
For a SaaS EASM, eradication mostly means restoring a trustworthy configuration. The decisions below are our guidance.
| Item | Keep when | Rebuild when |
|---|---|---|
| Seeds and scope | Matches a trusted export and the asset register | Any unexplained addition or removal; reverify every seed against registrar, internet registry and cloud records |
| Exclusions | Each has an owner, reason and expiry from before the incident | Added or extended during the exposure window |
| Attributions | Confirmed by a named owner before the incident | Confirmed or rejected during the exposure window |
| Findings status and risk acceptances | Closed with evidence of a fix | Closed or accepted during the exposure window; reopen and revalidate |
| Tenant | Tenant misuse only, provider unaffected | Provider cannot show the cause is fixed; consider moving and run a full rediscovery |
- Find and close the entry point: a stolen administrator credential, an exposed API key, a misused integration or a provider-side issue.
- Restore scope from your own asset register, then let discovery run and review new candidates before enabling active probing.
- Reopen and revalidate findings closed during the window; an attacker may have closed the ones they intended to use.
- Re-enable active validation gradually, confirmed assets only, starting with low-impact checks.
Recovery
- Compare discovery before and after: a full rediscovery should match the restored inventory; new assets that appear may be ones the attacker had hidden.
- Look for exploitation of exposed findings: review web, VPN and application logs on assets with high-risk findings from the start of the exposure window. NIST SP 800-53 RA-5(8) describes reviewing historic audit logs to see whether a vulnerability was exploited earlier.
- Watch for credential use: monitor sign-ins for accounts named in leaked credential data for at least the following weeks (our recommendation).
- Run the health check: use the External attack surface management (EASM) health check before declaring recovery.
Evidence to preserve
- Tenant audit log: sign-ins, role and user changes, API key creation and use, exports, scope and exclusion changes, validation jobs.
- A configuration and inventory export as found, before any restoration.
- Cloud, DNS provider and registrar audit logs for connector identities.
- DNS zone history, if the provider keeps it, or zone exports from before and after.
- Validation job history and target lists, and any third-party abuse reports.
- Provider advisories and support case records. NIST SP 800-61 Rev. 3, through CSF 2.0 outcome RS.AN-07, asks that incident data keeps its integrity and provenance. See the Evidence Handling and Chain of Custody Guide.
Notification triggers
- Personal data: leaked credential findings contain staff usernames and sometimes passwords. If they were accessed, assess GDPR Article 33: notify the supervisory authority without undue delay and, where feasible, within 72 hours, unless the breach is unlikely to result in a risk to individuals. A processor must tell the controller without undue delay.
- NIS2: if exposure led to disruption of an essential or important entity's services, assess Article 23 (early warning within 24 hours, notification within 72 hours, final report within one month).
- US listed companies: a material incident needs a Form 8-K Item 1.05 filing, generally within four business days of the materiality determination.
- Third parties: if your platform probed systems you do not own, involve legal counsel on informing those owners (our recommendation). See the Breach Notification Laws by Country Guide.
Adapting the playbook to your organisation
- Small teams with one EASM tenant: the critical steps are revoking DNS and cloud connector keys at the provider, resetting leaked credentials and patching the top internet-facing findings. Restoring scope can follow from your domain and address list within days.
- Large groups with many business units: scope by business unit makes triage harder, because an attacker with group-wide access read every unit's exposures. Split the response by business unit owner, and prioritise acquired companies whose seeds and attributions are newest and least verified.
- Managed EASM service: if a provider operates the platform for you, its analysts' accounts and its access to your connectors are in scope. Ask for its audit records under your contract, and revoke and reissue its access on your side. See the Third-Party Access Guide.
- EASM combined with a vulnerability scanner: where the same platform also runs internal authenticated scans, follow the vulnerability scanner playbook for the scan credentials as well, because they reach far further than external connectors.
Detection and measurement
- Connector identity activity outside expected API calls or source addresses, alerted in the cloud and DNS providers.
- Number of EASM connector credentials that can write DNS or cloud resources; target zero.
- Scope and exclusion changes without an approved ticket; target zero.
- Time to revoke every EASM connector credential at its provider in an exercise.
- Bulk exports of inventory or findings per month, each with a named requester.
- Time from a leaked credential finding to reset of the account.
Framework mapping
| Playbook step | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ATT&CK technique addressed |
|---|---|---|---|
| Triage of tenant and connector use | RS.AN-03 | IR-4, IR-5 | T1078.004 Cloud Accounts |
| Revoking connectors and tenant access | RS.MI-01 | AC-2, AC-6, IA-5 | T1098.001 Additional Cloud Credentials |
| Resetting leaked credentials | RS.MI-02 | IA-5 | T1589.001 Credentials |
| Restoring scope and inventory | ID.AM-01, RC.RP-01 | CM-8, RA-5 | T1590 Gather Victim Network Information |
| Look back for exploitation | ID.RA-01 | RA-5(8) | T1595.002 Vulnerability Scanning |
| Evidence, notification and provider coordination | RS.AN-07, RS.CO-02, RS.MA-01 | IR-6, SA-9 | T1199 Trusted Relationship |
Common failure patterns
- Revoking access in the EASM only: the DNS key or cloud credential remains valid at the provider.
- Treating the incident as "read-only": no fixes are expedited even though the attacker holds a ranked list of exposures.
- Ignoring removed seeds: assets dropped from scope stay unmonitored after the incident.
- Not resetting leaked credentials: findings marked as "already known" are left alone though the attacker can now read them.
- Write-capable DNS keys: a key granted edit rights during a proof of concept turns an EASM compromise into a DNS hijack risk.
- Treating a vendor rotation request as routine, as the Sumo Logic case shows for security SaaS.
Practitioner checklist
- Keep an inventory of every EASM connector credential, its permissions and where to revoke it.
- Make every DNS, registrar and cloud connector read-only, and alert at the provider on unusual use.
- Export the tenant audit log, scope and inventory regularly to storage outside the platform.
- Route leaked credential findings to automatic reset rather than manual triage.
- Keep seeds verified against your own asset register so scope can be restored without the platform.
- Know how to pause active validation in minutes, and who can do it.
- Rehearse revoking all connectors at their providers (our recommendation: at least annually).
- Agree in advance who decides on notifying third parties that were probed.
Standards and references
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- NCSC: Vulnerability scanning tools and services
- NCSC: Incident management
- CISA and FBI: Secure by Demand Guide
- Microsoft Learn: Enterprise access model
- EUR-Lex: Directive (EU) 2022/2555 (NIS2)
- GDPR: Article 33 Notification of a personal data breach
- SEC: Cybersecurity disclosure rules press release 2023-139
Related NHI Mgmt Group resources: Securing the external attack surface management (EASM) itself · Attack Surface Management Guide · DNS Security Guide · If your vulnerability scanner is compromised · If your SIEM is compromised