How to Conduct a Post-Incident Vulnerability Scan

A post-incident vulnerability scan is a controlled investigation carried out after an attack, suspected compromise, or serious security event. Its purpose is broader than checking whether software has missing patches. The scan should help security teams identify the original weakness, discover persistence mechanisms, find systems that may have been affected, and verify that remediation has closed the route used by the attacker.

For Australian organisations, this work often spans cloud services, remote staff, managed service providers, operational technology, and offices distributed between Sydney, Melbourne, Brisbane, Perth, and regional locations. A useful process combines vulnerability management with incident response, digital forensics, asset intelligence, and clear executive decision-making. Scanning too early or too aggressively can destroy evidence, interrupt critical services, or cause an already unstable environment to fail.

Establish Safety And Scope Before Scanning

The first step is to confirm that the incident is sufficiently contained for scanning to begin. If an attacker may still have active access, a conventional authenticated scan could expose credentials, alter logs, or alert the intruder. The incident commander should decide whether the immediate priority is isolation, evidence preservation, eradication, or validation of a suspected entry point.

Create a written scope that identifies in-scope IP ranges, cloud subscriptions, endpoints, servers, applications, network devices, identities, and third-party connections. Include assets that are difficult to scan, such as medical devices, warehouse controllers, point-of-sale systems, and industrial equipment. In Australia, organisations may rely on outsourced IT providers or national managed security services, so ownership and approval boundaries need to be explicit before probes are sent.

Classify systems according to business impact and operational sensitivity. A vulnerability scan against a payroll server can usually be scheduled differently from one against a hospital system or a mining site with limited connectivity. Record exclusions, maintenance windows, rate limits, and emergency contacts. The goal is to obtain reliable security information without creating a second incident.

Preserve Evidence And Build An Accurate Asset Picture

Before changing systems, preserve relevant logs, endpoint telemetry, firewall records, identity events, cloud audit trails, and forensic images where appropriate. Record the time zone used by each source, since Australian environments may include Australian Eastern, Central, and Western time zones as well as overseas cloud regions. Accurate timestamps are essential when matching scan results with authentication events, malware execution, and data access.

A post-breach scan is only as effective as its asset inventory. Compare the known asset register with network discovery, cloud-native inventories, endpoint management platforms, vulnerability scanners, and identity directories. Look for unmanaged laptops, forgotten virtual machines, exposed development systems, stale administrator accounts, and internet-facing services that were not included in the original register.

Separate confirmed assets from suspected assets and unknown devices. A system that cannot be identified should not be treated as harmless simply because it is absent from the register. Tag each device with its owner, business function, location, operating system, data classification, and connectivity. This makes it easier to prioritise the systems most likely to have been exploited or used for lateral movement.

Where an organisation handles controlled information for overseas customers or government-linked programmes, its scanning and evidence process may need to align with contractual security obligations as well as Australian requirements. Guidance on CMMC Level 3 requirements can be relevant when Australian suppliers support US defence or aerospace partners and must demonstrate mature protection of sensitive information.

Design A Scan That Answers Incident Questions

Do not begin with a generic scan of every address range. Translate the incident narrative into testable questions. If phishing was suspected, examine mail gateways, endpoint execution, browser versions, identity controls, and remote access paths. If an internet-facing application was exploited, focus on its framework, dependencies, authentication, web server, API endpoints, container images, and adjacent database systems.

Use several scan types in a deliberate sequence. External scanning shows what attackers can see from the internet. Internal network scanning identifies exposed services, weak protocols, and unexpected routes between segments. Authenticated host scans provide more accurate patch and configuration data. Cloud configuration reviews can reveal public storage, excessive permissions, insecure security groups, disabled logging, and vulnerable images that a traditional network scan may miss.

Credentialed scanning should use tightly controlled service accounts with the minimum permissions needed. Never reuse a personal administrator account or place scan credentials in scripts or shared documents. Test the scanner against a small group of representative systems first, then expand gradually. Rate-limit checks on fragile systems and coordinate with application owners, especially where legacy software is common.

Scan for indicators associated with the incident as well as general vulnerabilities. This may include known malicious files, suspicious scheduled tasks, unauthorised services, weak remote management protocols, exposed secrets, unsafe PowerShell settings, outdated VPN appliances, and persistence in cloud identities. Vulnerability data should be combined with endpoint detection, threat intelligence, configuration baselines, and attack-path analysis rather than interpreted in isolation.

Analyse Findings Against The Attack Path

A scanner will usually produce a long list of findings, but severity alone does not establish priority. A medium-rated flaw on an isolated test server may be less urgent than a high-confidence weakness on an internet-facing domain controller or a cloud identity with privileged access. Rank findings by exploitability, exposure, business importance, evidence of attacker interest, and the likelihood that the weakness enabled the incident.

Compare scan results with the known timeline. A vulnerability that was present before the compromise may explain initial access. A newly discovered weakness on a system reached during lateral movement may explain privilege escalation. A clean result does not prove that a host was never compromised; it may indicate that the attacker used valid credentials, misconfiguration, social engineering, or a previously unknown technique.

Pay attention to relationships between weaknesses. An exposed remote desktop service, a reused local administrator password, and inadequate network segmentation can form a practical attack path even if none is rated as critical in isolation. Similarly, a vulnerable web application becomes more serious when its service account can reach sensitive databases. Attack-path context helps teams avoid patching the easiest items while leaving the route to valuable assets open.

Validate important findings manually or with a second source. False positives can waste scarce remediation capacity, while false negatives can create false confidence. Confirm software versions, affected components, exploit conditions, and compensating controls. For regulated organisations, preserve scan reports, validation notes, approvals, and remediation evidence so that the response can be explained to auditors, customers, insurers, and investigators.

Remediate Weaknesses And Verify Recovery

Remediation should begin with the weaknesses that allowed access or enabled movement through the environment. This may involve emergency patching, disabling exposed services, rotating credentials, revoking tokens, rebuilding compromised hosts, correcting identity permissions, or placing a vulnerable application behind additional controls. A patch is not a complete remediation if an attacker has already established persistence.

Use clean recovery sources and trusted administrative workstations. Reimaging a server while leaving the same vulnerable configuration, compromised account, or exposed management path in place simply recreates the conditions for another intrusion. Review firewall rules, segmentation, endpoint policies, logging, backup protection, and privileged access at the same time as software versions.

Run a verification scan after each remediation wave, allowing enough time for patch deployment and system restart. Confirm that the vulnerability is actually closed, that the service remains functional, and that no replacement exposure has appeared. Where a patch is unavailable, document a compensating control such as application-layer filtering, isolation, restricted access, or enhanced monitoring, together with an expiry date and accountable owner.

Recovery also needs to reflect Australian legal and operational realities. The Privacy Act 1988 and the Notifiable Data Breaches scheme may apply when personal information is involved, while the Security of Critical Infrastructure Act 2018 can create additional obligations for regulated critical infrastructure entities. A scan does not determine reporting duties, but it can provide evidence about affected systems, exposure periods, and the effectiveness of containment measures.

Turn The Scan Into A Repeatable Security Practice

A post-incident vulnerability assessment should produce more than a one-time report. Feed verified asset data, remediation status, attack paths, and recurring control failures into the organisation’s vulnerability management programme. Update detection rules and monitoring for the techniques observed during the event. If a weakness resulted from an unsupported platform, unclear ownership, or a slow patching process, assign a lasting control improvement rather than treating the issue as a single ticket.

Australian organisations should account for practical conditions such as limited specialist staff outside major cities, reliance on managed service providers, high use of cloud collaboration tools, and connectivity constraints at regional or remote sites. Security teams in Sydney or Melbourne may have dedicated responders, while a regional business may depend on a national provider for scanning, containment, and after-hours support. The process must work across both environments and define who can authorise disruptive action.

Use a concise remediation register that links each finding to evidence, business ownership, priority, action, due date, and verification result. Recommendations that commonly improve post-incident scanning include:

The final review should bring together security operations, infrastructure, application owners, legal advisers, privacy specialists, and relevant service providers. Confirm that every high-risk pathway has either been removed or formally accepted with a time-bound control. A post-incident vulnerability scan is complete when the organisation can show what was exposed, how the attack moved, what changed, and why the remaining risk is understood.

The practical takeaway is to treat scanning as a controlled validation of the entire response: preserve evidence first, scope systems carefully, test the attacker’s likely path, remediate the enabling weaknesses, and rescan until the route into the environment is demonstrably closed.