If your vulnerability scanner is compromised: contain it, rotate scan credentials and rebuild

A compromised vulnerability scanner gives an attacker the credentials that log into almost every host you own and a ranked list of the weaknesses on each one. Authenticated scanning needs accounts with administrative or broad read rights on Windows, Linux, databases, network devices and cloud accounts, and the scanner stores those credentials alongside its results. Agents on every endpoint and appliances with firewall paths into every network segment add further reach. This playbook covers how the incident shows up, triage, containment in priority order, a rotation plan for scan credentials, rebuilding the scanner and its agents, evidence, notification and the measurements that would catch the next one sooner. It is vendor-neutral and written for vulnerability management leads, Windows and Linux administrators and incident responders. Prevention belongs to Securing the vulnerability scanner itself; this page assumes prevention has failed.

Key takeaways

• Disable the scan accounts first. The Windows domain scan account, Linux scan users and SSH keys, database and network device credentials are the fastest route to lateral movement, so disable them in the directory and on the targets before anything else.
• The results are an exploitation list. Treat every unremediated finding the scanner held as known to the attacker, and reprioritise patching on that basis.
• Agents are a deployment channel. If the console or update path was controlled, scan agents on every host are a potential way to run code; verify their integrity before trusting them.
• Hunt for scan account use from anywhere other than the scanner. Logons by scan identities from unexpected sources are the clearest sign the credentials were reused.
• Rotate in one window, then prove the old credentials fail. A scan credential missed in one policy is enough for the attacker to return.

What the attacker gains

NIST SP 800-53 RA-5(5) asks organisations to implement privileged access authorisation for vulnerability scanning, because authenticated scans need privileged access. The NCSC guidance on vulnerability scanning tools notes that authenticated checks, such as logging into Windows hosts, reveal issues otherwise invisible, and that a hosted scanner means the vendor stores your vulnerability results. Both points describe what a compromise exposes. The table is NHI Mgmt Group's view of a common architecture.

One further risk is specific to Windows authenticated scanning: if a scan account authenticates with NTLM to a host the attacker controls, its credential material can be captured or relayed (T1557.001). Kerberos-only scan accounts reduce that exposure. See the NTLM Relay Guide.

How the incident shows up

• Scan account logons from the wrong place: Windows event 4624 for the scan account where the source address is not a scanner engine, or interactive and remote desktop logons (logon types 2 and 10) for an account that should only log on over the network.
• Privileged use outside scan windows: event 4672 (special privileges assigned) for the scan account outside the schedule, or sudo use by the Linux scan user that runs commands no scan check would run.
• Console changes: new users or API keys, credentials exported or viewed, new scan policies, exclusions added for particular hosts, or schedules changed without a ticket.
• Agent anomalies: agents re-linked to an unknown console, unexpected agent updates, or agents spawning processes outside their normal set.
• Results tampering: findings closed or accepted as risk in bulk, or ticket integrations closing issues without a fix.
• A supply chain advisory: security tooling itself can be the vector. In the Trivy supply chain attack, a malicious release and repointed version tags delivered a stealer to CI pipelines that ran the scanner, and every secret available to those pipelines had to be treated as stolen.

Triage questions

1. Which part was reached? A console user, the credential store, an engine or appliance, the agent channel, or the vendor's hosted platform.
2. Which credentials were stored, and with what rights? List every credential in every scan policy, including old policies that are no longer scheduled.
3. Have the scan identities been used elsewhere? Query domain controllers, Linux authentication logs, database audit logs and cloud audit logs for scan identities, filtered to sources that are not scanner engines.
4. Could the attacker push code to agents? Check console audit records for agent updates, plugin changes and remediation scripts, if the product can run them.
5. What did the attacker learn? Export the current open findings for internet-facing and critical systems; these are the attacker's likely next targets.
6. Were scope or results changed? Compare scan policies, exclusions and accepted risks against the last known-good configuration.

Containment priorities

1. Disable scan identities at the target systems. Disable the domain scan account and any secondary scan accounts in the directory, lock Linux scan users and remove their keys from authorized_keys, and disable database and network device scan logins. Doing this at the target stops reuse even if the attacker copied the credentials.
2. Stop all scheduled and running scans. This prevents disruptive checks and stops the console from using any credential it still holds.
3. Isolate engines and appliances. Remove the firewall rules that let scanner engines reach internal segments, or move them to a quarantine network while you image them.
4. Freeze the agent channel. Block agent communication to the console or vendor at the firewall or proxy if agent integrity is in doubt, and stop agent auto-update. Keep endpoint detection running so you still see agent behaviour.
5. Lock down the console. Revoke sessions and API keys, remove unknown users, and restrict access to a named response group through single sign-on with phishing-resistant MFA.
6. Revoke cloud and integration credentials in each cloud account, ticketing system and SIEM, and review what those identities did.
7. Raise patch priority. Treat critical open findings on internet-facing systems as known to the attacker and use the Emergency Out-of-Band Patching Playbook where needed.

Credential rotation plan

• Check for persistence created with scan rights: new local accounts, scheduled tasks, services and SSH keys on hosts where the scan account logged on unexpectedly.
• Verify: attempt authentication with each old credential from a test host and record the failure. The Incomplete rotation breaches guide explains why this step matters.
• Use a vault: where the scanner supports retrieving credentials from a privileged access or secrets vault at scan time, use it, so the scanner no longer stores long-lived credentials. See the Vulnerability scanner integration security guide.

Eradication and rebuild

1. Find the entry point and close it: a console vulnerability, a stolen administrator credential, an exposed API key or a compromised update.
2. Rebuild scope from the asset register, not from the scanner's own policies, and review every exclusion. The NCSC advises recording excluded assets and keeping fragile-host exclusions short.
3. Restore results history from a trusted export or rescan; do not rely on risk acceptances and closures made during the exposure window.
4. Re-onboard credentials with the new designs from the rotation table, using vault retrieval where possible.

Recovery

• Rescan before trusting: run full authenticated scans of critical and internet-facing systems with the new credentials and compare with pre-incident results.
• Look back: NIST SP 800-53 RA-5(8) describes reviewing historic audit logs to see whether a vulnerability was exploited before it was found. Apply it to the findings the attacker could see.
• Reopen network paths gradually: restore firewall rules for engines one segment at a time and document each change, as the NCSC recommends for scanner network changes.
• Re-enable agents in rings: a pilot group, then the wider estate, watching endpoint detection for unusual agent behaviour.

Evidence to preserve

• Console audit log: logins, credential views or exports, policy and exclusion changes, agent updates, API key use.
• Configuration export of policies, credentials metadata (not secrets) and integrations as found.
• Domain controller, Linux, database and cloud logs showing scan identity activity.
• Disk and memory images of self-hosted consoles and engines. See the Disk Imaging and Forensic Acquisition Guide.
• Agent version and hash inventory across the estate at the time of discovery.
• Vendor 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.

Notification triggers

• Personal data: scan results rarely hold personal data, but web application scans and credentialed checks can capture it. If personal data was accessed, GDPR Article 33 applies: 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.
• NIS2: if scan credentials were used to move through systems supporting an essential or important entity's services, assess whether it is a significant incident under 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.
• Hosted scanner provider: the provider's own breach obligations do not replace yours. See the Breach Notification Laws by Country Guide.

Detection and measurement

• Scan identity logons from non-scanner sources, alerted in real time; target zero unexplained.
• Percentage of scan credentials retrieved from a vault at scan time rather than stored in the scanner.
• Number of scan accounts with domain-wide administrative rights; target zero.
• Policy, exclusion and risk acceptance changes without a ticket; target zero.
• Time to disable every scan identity across directory, Linux, database and network devices in an exercise.
• Percentage of agents matching a published vendor version and signature.

Framework mapping

Common failure patterns

• Changing the password in the scanner only: the old scan account stays enabled in the directory, so copied credentials still work.
• Forgetting old policies: unscheduled policies still hold credentials for systems nobody remembers.
• Domain Admins for scanning: a scan account in a domain-wide admin group turns a scanner compromise into a domain compromise. See the Active Directory Domain Compromise Response Playbook.
• Trusting agents without checking: agents are reconnected to the rebuilt console without confirming their version and signatures.
• Ignoring what the attacker read: patch priorities stay unchanged although the attacker has the full list of open findings.
• Incomplete rotation in tooling pipelines: as the Trivy case shows, credentials that survive a first rotation let the attacker return.

Practitioner checklist

• Inventory every credential held by every scan policy, with where it must be disabled and rotated.
• Make scan accounts Kerberos-only, deny interactive logon and keep them out of domain-wide admin groups.
• Alert on scan identity logons from any source other than registered scanner engines.
• Export scanner configuration and audit logs to storage the scanner administrators cannot alter.
• Prefer vault retrieval of scan credentials at scan time.
• Keep an agent version and hash baseline, and a tested way to block agent communication.
• Rehearse disabling all scan identities and measure how long it takes (our recommendation: at least annually).
• Pre-agree how open findings are reprioritised if the results are exposed.

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
• Microsoft Learn: Enterprise access model
• CISA and FBI: Secure by Demand Guide
• 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 vulnerability scanner itself · Authenticated vs Unauthenticated Scanning Guide · Vulnerability Management Guide · Service Account Security Guide · If your SIEM is compromised