A configuration management database and its discovery tooling hold privileged scanning credentials for almost every host, a map of how your services connect, and the records that decide what gets patched, monitored and protected, so an attacker who controls it gains both a key ring and the power to make assets disappear from your defences. This playbook covers a compromise of the CMDB or asset inventory platform: its administrators, its discovery engines and their stored credentials, its integrations with scanners, endpoint and cloud tools, and the data itself. It sets out how the incident shows up, triage questions, containment in priority order, credential rotation, how to rebuild trust in the data, the evidence to keep and when notification rules apply. It is vendor-neutral and written for asset management owners, security operations and incident responders. Building and protecting the inventory before an incident is covered in the Asset Inventory and CMDB Security Guide and Securing the CMDB and asset inventory itself.
Key takeaways
- Discovery credentials come first. Domain accounts, SSH keys, SNMP community strings, hypervisor accounts and cloud read roles used for discovery reach most of the estate; treat every one the platform stored as exposed.
- The data is a target, not just a record. Deleting or editing configuration items can drop hosts out of vulnerability scanning, endpoint coverage checks and alert routing, which hides attacker infrastructure in plain sight.
- The map is reconnaissance. Service maps, network relationships and owner records tell an attacker where the crown jewels are and who to impersonate, so assume the next phase will be targeted.
- Rebuild trust from independent sources. Reconcile the CMDB against cloud provider APIs, endpoint agents, directory and network data rather than restoring a backup and hoping it is clean.
- Downstream automation inherits the poison. Patching scopes, firewall rule generation, access reviews and incident contacts that read from the CMDB must be paused or checked until the data is trusted.
Why a CMDB compromise is different
CIS Control 1 asks organisations to actively manage all enterprise assets so they know what to monitor and protect, and NIST SP 1800-5 describes IT asset management as a way to give security analysts visibility. That central role cuts both ways. A compromised inventory gives the attacker three capabilities:
| Capability | How the CMDB provides it | ATT&CK technique |
|---|---|---|
| Credential access | Stored discovery credentials and integration tokens | T1552.001 Credentials In Files, T1552.004 Private Keys, T1528 |
| Discovery without noise | Hosts, software, open ports, cloud resources and dependencies already collected | T1018 Remote System Discovery, T1046 Network Service Discovery, T1580 Cloud Infrastructure Discovery |
| Defence manipulation | Editing or retiring records that scanners, endpoint coverage reports and alert routing depend on | T1565.001 Stored Data Manipulation |
| Execution | Discovery engines that run commands or scripts on targets | T1072 Software Deployment Tools |
The CMDB often runs on the same platform as the service desk. If it does, run this playbook together with If your ITSM platform is compromised.
How the incident shows up
| Signal | Where it appears | What it suggests |
|---|---|---|
| Discovery credentials viewed, exported or edited, or new credentials added | Platform audit log | Credential harvesting or redirection of discovery |
| Discovery accounts authenticating from hosts that are not discovery servers, or outside schedule | Directory, SSH and hypervisor logs | Stolen discovery credentials in use (T1078 Valid Accounts) |
| Configuration items retired, reclassified or moved out of scanning or monitoring groups in bulk | Record history, scanner scope reports | Hiding assets from defences |
| Owner, support group or contact fields changed on critical services | Record history | Redirecting alerts or enabling impersonation |
| Bulk exports of service maps, relationships or network data | Platform transaction and API logs | Reconnaissance collection (T1213 Data from Information Repositories) |
| New discovery patterns, probes or scripts | Platform configuration history | Code execution on targets through discovery |
| Coverage gap appears between endpoint agent counts and CMDB counts | Reconciliation reports | Deleted or suppressed records |
Triage questions
- Which credentials did the platform hold? List every discovery and integration credential, its type, the targets it reaches and whether the platform stores it or retrieves it from a vault at run time.
- Were discovery credentials used elsewhere? Search directory, SSH, database and hypervisor logs for those accounts from sources other than the discovery servers.
- What changed in the data? Pull record history for deletions, retirements, classification and ownership changes in the window, focusing on servers, network devices, security tooling and critical services.
- Which systems consume the data? Vulnerability scanners, patching, endpoint coverage reporting, alert routing, access reviews, firewall automation, licence and cloud cost tools. Each is a downstream effect to check.
- Could discovery run commands? If discovery or orchestration engines execute scripts on targets, the targets are in scope as potential execution points.
- Which security tools trust CMDB tags? Exclusion lists, maintenance windows and suppression rules keyed on CMDB fields can silence alerts for any host the attacker re-tagged.
- Is personal data present? Owner and user records, device assignments and location data can be personal data and drive notification.
Containment priorities
- Preserve evidence: export the platform audit log, record history for all configuration item classes, discovery logs and the credential store metadata before changing anything.
- Suspend administrative and integration access that is suspected, and restrict platform admin to a named response group.
- Stop discovery: disable discovery schedules and stop discovery engines so stolen or modified probes stop running and the data stops changing.
- Disable discovery accounts at their targets: disable the domain, SSH, database and hypervisor accounts, and remove cloud role trust for discovery roles, rather than only changing them in the CMDB.
- Freeze downstream automation: pause jobs that generate scan scopes, patch targets, firewall rules or access review populations from the CMDB, and switch alert routing for critical services to a static list.
- Lock data changes: make the CMDB read-only for everyone except the response group while you assess integrity.
Credential rotation
| Credential type | Typical reach | Rotation action |
|---|---|---|
| Windows domain discovery accounts | Every domain-joined host via WMI or remote management | Reset, restrict logon rights, review group memberships, check for use elsewhere; see the Active Directory Domain Compromise Response Playbook if they held admin rights |
| SSH keys and Unix accounts | Linux and Unix servers, network appliances | Generate new key pairs, remove old public keys from every authorized_keys file, restrict sudo to discovery commands |
| SNMP community strings and SNMPv3 users | Routers, switches, firewalls | Replace community strings, move to SNMPv3 with authentication and privacy, check for write communities |
| Hypervisor and storage management accounts | Virtualisation clusters and arrays | Reset, reduce to read-only roles |
| Cloud discovery roles and keys | All accounts, subscriptions and projects in scope | Delete access keys, rebuild role trust, prefer federation; see the Cloud Access Key Leak Playbook |
| Database and application credentials | Databases and middleware | Reset and narrow to metadata queries |
| Integration tokens to scanners, endpoint and IdP tools | Connected security tools | Revoke and reissue with read-only scope |
Rotate at the target system first, then update the CMDB or vault, then confirm discovery succeeds only with the new credential. Track each item in the Secrets Rotation Runbook Template.
Rebuilding trust in the data
A restored backup may contain the attacker's edits if the compromise started before the backup. Treat the CMDB as a set of claims to check against independent sources.
- Pick a trusted baseline: choose a backup or export dated before the first attacker action and verify its integrity before use, as NIST CSF 2.0 RC.RP-03 expects for restoration assets.
- Reconcile against authoritative sources: cloud provider inventory APIs, endpoint agent consoles, directory computer objects, network access control and DHCP data, and hypervisor inventories.
- Restore security-relevant fields first: scan scope membership, criticality, monitoring and endpoint coverage flags, owner and support group for critical services.
- Re-run discovery with new credentials from rebuilt discovery servers, and compare results with the reconciled baseline.
- Resume downstream automation one consumer at a time, checking each output (scan scope, patch target list, alert routing) against expectation.
Rebuild or clean in place
- Rebuild discovery servers in all cases where they ran attacker probes or stored credentials locally; rebuild from trusted images, not cleaned in place.
- Clean the platform in place when it is SaaS, the provider confirms no platform breach, and record history covers the window.
- Rebuild the platform when it is self-hosted and the attacker reached the server or database.
- Small organisations often find it quicker to rebuild the inventory from endpoint and cloud tooling than to audit every record.
- Large estates should reconcile by class and criticality, starting with internet-facing and crown jewel services.
Roles and decisions
| Decision | Owner | Inputs |
|---|---|---|
| Stop discovery and disable discovery accounts at targets | Incident manager with the identity team | Credential list, evidence of use outside discovery servers |
| Freeze downstream automation | Incident manager with owners of scanning, patching and alert routing | List of CMDB consumers and their pause procedures |
| Choose the trusted baseline | CMDB owner with security operations | Backup dates, first attacker action, integrity check result |
| Resume alert routing from the CMDB | Security operations lead | Verified owner and support group for critical services |
| Rebuild versus clean the platform | CMDB owner with the platform provider | Hosting model, log coverage, provider statement |
Record each decision with the decision maker and time. The asset management team usually knows the data best but should not be the only group checking it: if an administrator account in that team was the entry point, pair every integrity check with a reviewer from security operations. Where operational technology assets are recorded in the same inventory, bring in the OT owners before stopping discovery, because active probing and credential changes on industrial devices can affect operations; the joint CISA asset inventory guidance for OT owners and operators is a useful reference for rebuilding that part of the record.
Detection and measurement
| Metric | Target |
|---|---|
| Discovery credentials rotated at target and confirmed invalid | 100 percent |
| Difference between endpoint agent count and CMDB active device count | Within an agreed tolerance, investigated daily during recovery |
| Critical services with verified owner and support group | 100 percent before alert routing resumes |
| Discovery account logons from non-discovery hosts | Zero, each alerted |
| Bulk retirements or deletions per day | Baseline with an alert threshold and approval |
| Discovery credentials stored in the platform rather than retrieved from a vault | Falling to zero |
Evidence to preserve
| Evidence | Why it matters |
|---|---|
| Platform audit and login logs | Who accessed credentials and changed data |
| Record history for configuration items and relationships | Exactly which records were altered and how |
| Credential store metadata and access history | Which credentials were viewed or changed |
| Discovery job logs and pattern definitions | Probes and scripts that ran on targets |
| Target-side authentication logs for discovery accounts | Use of stolen credentials across the estate |
| Downstream outputs (scan scopes, patch lists, alert routes) | Defensive gaps created by the attacker |
Hash exports and keep chain of custody; see the Evidence Handling and Chain of Custody Guide.
Notification triggers
- Personal data: GDPR Article 33 requires notification to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, unless it is unlikely to result in a risk; staff and device assignment records may qualify.
- Follow-on compromise: if discovery credentials were used against systems holding regulated data, those systems' notification rules apply.
- Other regimes: see the Breach Notification Laws by Country Guide.
Common failure patterns
- Changing the password in the CMDB but not at the target, leaving the stolen credential valid everywhere it works.
- Restoring a poisoned backup without reconciling against independent sources.
- Restarting automation too early, so a scan scope still missing attacker hosts is treated as complete.
- Forgetting downstream consumers, such as alert routing that now pages an attacker-chosen contact.
- Leaving rotation incomplete: the Cloudflare Thanksgiving Breach 2023 shows a nation-state attacker getting in through credentials left unrotated after a related incident.
Framework mapping
| Phase | NIST CSF 2.0 | NIST SP 800-53 Rev 5 | CIS Controls v8.1 |
|---|---|---|---|
| Detection and triage | DE.CM-03, RS.AN-03 | AU-6, IR-4 | Control 8 Audit Log Management |
| Containment and rotation | RS.MI-01, RS.MI-02, PR.AA-01 | AC-2, AC-6, IA-5 | Control 5 Account Management |
| Data integrity and rebuild | ID.AM-01, ID.AM-02, RC.RP-03 | CM-8, CM-8(3), SI-7 | Control 1 Inventory and Control of Enterprise Assets |
| Recovery | RC.RP-01, ID.AM-08 | CM-2, CM-3 | Control 2 Inventory and Control of Software Assets |
| Evidence and notification | RS.CO-02 | AU-9, AU-11, IR-6 | Control 17 Incident Response Management |
Where identity fits
Discovery accounts are among the most privileged and least watched non-human identities in an organisation: broad, always on and rarely owned by a named person. Vault them, scope them to read-only commands, restrict where they can log on from and alert on any other use. See the Non-Human Identity (NHI) Guide and the Privileged Access Management Guide.
Practitioner checklist
- Every discovery credential is listed with targets, owner and rotation steps at the target.
- Discovery credentials are retrieved from a vault at run time, not stored in the platform.
- Discovery accounts can only log on from discovery servers, and other use alerts.
- Bulk retirements, deletions and owner changes on critical classes need approval and alert.
- A daily reconciliation compares the CMDB with endpoint, cloud and directory sources.
- Downstream consumers of CMDB data are listed with a pause procedure.
- Record history and audit logs stream to a SIEM beyond platform retention.
- A verified pre-incident backup and a reconciliation runbook exist.
Standards and references
- CIS: Control 1 Inventory and Control of Enterprise Assets
- NIST: SP 1800-5 IT Asset Management
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- CISA and partners: Foundations for OT Cybersecurity, Asset Inventory Guidance for Owners and Operators
- GDPR: Article 33 Notification of a personal data breach to the supervisory authority
Related NHI Mgmt Group resources: Asset Inventory and CMDB Security Guide, If your ITSM platform is compromised, If your vulnerability scanner is compromised, Attack Surface Management Guide.