The eradication phase requires that analysts investigate the evidence collected during containment to understand the attacker’s methods and persistence mechanisms, then take action to remove the attacker from the environment. Responders need enough understanding to answer critical questions:

Eradication demands a practical understanding of the attacker’s TTPs sufficient to ensure their complete removal from the environment. As incident responders discover new indicators of compromise or persistence mechanisms during eradication, they should expand their efforts accordingly, contributing new insight into additional iterations of the response actions loop.

Eradication requires practical remediation: remove what the attacker installed, close the entry points they exploited, and restore systems to operation with confidence that the compromise will not immediately recur. Developing this understanding and applying it is the focus of the eradicate phase, with particular emphasis on performing root cause analysis to uncover the full scope of the compromise and prevent the same attack from succeeding again.

While short-form investigation focuses on gathering enough understanding to inform eradication actions, long-form investigation may continue in parallel to build a comprehensive understanding of the incident. Long-form investigation aims to uncover a greater understanding of the incident using forensic analysis techniques that often require more time and specialized expertise.

Long-form investigation serves purposes beyond immediate eradication needs. Organizations may require detailed forensic analysis for regulatory compliance, legal proceedings, insurance claims, or threat intelligence development. These investigations document the complete attack timeline, identify all compromised data, and build comprehensive evidence packages that meet legal standards for admissibility. It can be difficult or impossible to perform this level of detailed analysis within the time constraints of urgent eradication efforts, but it is also important not to hold up the business objectives of restoring operations. Organizations should balance the need for short-form investigation to support eradication with the benefits of long-form investigation for broader organizational goals.

The scope of long-form investigation should be defined in coordination with decision makers based on organizational requirements:

This coordination ensures that investigative resources focus on activities that provide tangible value to the organization.

Incident response teams should work with decision makers to define the scope and priorities of investigation tracks during the eradication activity. Wherever possible, organizations should focus on short-form investigations to inform eradication actions, while long-form investigations continue in parallel to meet broader organizational goals.

During the eradication activity, effective root cause analysis is essential for complete incident resolution. Without understanding the underlying causes of the compromise, responders risk leaving persistence mechanisms in place, missing compromised systems, or allowing the same attack to succeed again through different entry points. Root cause analysis helps responders move beyond simply removing the attacker’s immediate access to addressing the systemic weaknesses that exposed the environment to compromise.

Root cause analysis during incident response serves several goals. First, it helps the response team understand the complete attack chain, from initial access through privilege escalation, lateral movement, and data exfiltration, ensuring analysts identify all compromised systems and artifacts requiring eradication. Second, it reveals systemic weaknesses in security controls, processes, and policies that enabled the attack. Finally, it guides eradication priorities by distinguishing between surface-level symptoms and underlying causes that, if left unaddressed, would enable similar attacks.

To perform systematic root cause analysis during incident response, responders follow a structured approach:

The four P’s framework provides a method for categorizing root causes. Used in incident response, it helps organize findings from investigations into manageable areas for analysis and remediation. By recognizing that incidents often result from a combination of human, procedural, technical, and governance failures, responders can use the four Ps as a tool to brainstorm and document root causes:

Next, consider applying this root cause analysis approach to a cloud security incident example.

My team worked on an incident for a customer where an S3 bucket named dat-ng-cdn-890378906859 containing customer data had been publicly accessible for several months, resulting in unauthorized data exposure. The initial investigation identified the immediate cause: a developer misconfigured the S3 bucket permissions when deploying a new feature, setting the access control to allow any authenticated S3 principal to list and read the bucket contents, as shown in Listing 1.

This surface-level analysis pointed to a single action: a developer’s misconfiguration. However, applying systematic root cause analysis reveals a much broader risk of exposure. Using the iceberg model across the four P’s, we can envision the insecure S3 bucket as one element of risk, but the people, process, product, and policy elements should also be considered, as shown in Figure 4.

Looking at the people category, we found that developers lacked adequate training on cloud security best practices and secure AWS configuration. The developer who created the bucket had not received training on S3 access controls or data classification requirements. Additionally, there was no clear understanding within the development team about who was responsible for reviewing and approving cloud infrastructure changes, leading to assumptions that "someone else" would catch security issues.

Examining the process category revealed multiple procedural gaps that allowed the misconfiguration to persist undetected. The organization lacked a code review and approval process for Infrastructure-as-Code (IaC) templates, so the Terraform configuration that defined the bucket’s public access was never reviewed by another engineer. There was no IaC automated scanning before deployment to detect security misconfigurations. The deployment pipeline lacked a security approval gate that would require sign-off before provisioning resources with external access. After deployment, no regular auditing process scanned for publicly accessible S3 buckets across the AWS environment.

The product category identified technical control failures that compounded the problem. The organization’s IaC templates used for provisioning new buckets lacked secure defaults, requiring developers to explicitly configure security rather than inheriting safe settings. AWS CloudTrail logging was enabled, but no alerts were configured to notify the security team when there were unusual access patterns to the bucket. The organization had no automated remediation tools (like AWS Config rules) that would automatically revert dangerous permission changes.

An analysis of the policy category revealed governance and compliance gaps. The organization lacked a data classification policy requiring developers to identify sensitive data and apply appropriate access controls before storage. There was no cloud security policy establishing least-privilege requirements for S3 buckets. The change management policy didn’t require a security review for infrastructure changes, treating cloud resource provisioning as routine IT operations. Additionally, there was no audit process to verify that cloud resources met security standards and regulatory requirements.

This comprehensive root cause analysis transformed a simple developer error into a list of systemic failures that all contributed to the incident. Each identified root cause becomes a target for eradication and recovery actions: developer training programs, code review processes, IaC security scanning tools, secure default templates, automated alerting and remediation, and comprehensive cloud security policies. By addressing these underlying causes rather than simply changing the bucket permissions back to private, the organization reduced the likelihood of similar incidents across its entire cloud infrastructure. The improvements extended well beyond this single bucket.

A fishbone diagram (also known as a cause-and-effect diagram or an Ishikawa diagram) is a valuable tool to visually represent root cause analysis, illustrating how multiple contributing factors led to the incident. Developed by University of Tokyo professor Kaoru Ishikawa in the 1960s for quality management purposes, the diagram resembles a fish skeleton, with the head representing the problem (the effect) and the bones branching off to represent categories of potential issues (the causes). Ishikawa designed this tool to help teams systematically identify and analyze the root causes of problems rather than just addressing symptoms, using a visual format accessible to different learning styles.

Conventionally, the fishbone diagram included primary branch categories that represent the six M’s: Man (people), Machine (technology), Materials (data), Methods, Measurement, and Milieu (environment). An example of a fishbone diagram using the six M categories is shown in Figure 5. ^[2]

While defining the six M’s provides valuable distinction for some environments, the structure of the fishbone diagram can be simplified with an approach tailored to incident response. Instead of categorizing each cause under the six M’s, responders can broadly group causes into categories relevant to security incidents using the four P’s. Using the fintech SSH compromise (see Fintech SSH Compromise: Root Cause Analysis), a fishbone diagram using the four P’s captures the root causes identified during the investigation (Figure 6).

By visually mapping root causes, the fishbone diagram helps responders see how multiple contributing factors across people, processes, products, and policies led to the incident. The four P’s approach, integrated with the visual structure of a fishbone diagram, provides analysts with a practical tool for systematically exploring and documenting root causes during incident response.

The Sigma project provides a standardized format for writing detection rules that can be applied to log data from various sources. Unlike most detection methods built into commercial platforms, Sigma rules represent a portable set of log analysis and alerting mechanisms that can be quickly applied during log investigation to identify known IOCs and attacker behavior. ^[3]

While Sigma rules represent opportunities to characterize threats in many different log sources, including Windows Event Logs, Syslog, cloud service logs, web server logs, and more, the Sigma project is not an analysis tool in itself. Instead, the Sigma rules and the corresponding Sigma CLI tool provide a framework for defining detection logic that can be converted into queries for specific log analysis platforms. For example, a Sigma rule defining suspicious PowerShell activity can be converted into a Splunk search query, an Elasticsearch query, or a query for other log analysis tools. ^[4]

However, some tools natively support Sigma rules without requiring conversion into a backend system. For Windows Event Log analysis, the open-source tool Hayabusa is a fast forensic analysis tool to identify threats using Sigma rules. ^[5] Hayabusa quickly scans Windows Event Log (EVTX) files and generates a threat report and optional timeline. For an analysis completed using EVTX files from multiple systems collected in January and February 2020, the Hayabusa command shown in Listing 2 generates a CSV timeline report of all identified threats during that period. The resulting CSV file will characterize the identified threats across all analyzed event logs, providing insight into attacker activity during the incident. The timeline of threat events is shown in Figure 7.

Hayabusa is a valuable tool for analyzing Windows Event Logs during eradication, but Sigma rules are more broadly valuable when integrated into SIEM platforms for log investigation at scale.

Security Information and Event Management (SIEM) platforms address the challenge of analyzing disparate data from multiple log sources. SIEM platforms normalize and aggregate logs into a centralized repository where analysts can search, correlate, and analyze events across the environment. Instead of manually reviewing logs on individual systems, responders can query the SIEM for specific indicators of compromise across all ingested log sources simultaneously. This centralization significantly reduces the time required to scope an incident and identify all affected systems.

SIEM platforms provide significant value to incident response by aggregating, normalizing, and correlating log data from disparate sources. During eradication, this centralized visibility allows responders to quickly pivot from one indicator of compromise to related events across the entire environment. Analysts can track a compromised account’s activity from initial authentication through lateral movement to data exfiltration without manually searching individual system logs. SIEM alerting rules can identify suspicious patterns that span multiple log sources, such as failed authentication attempts followed by successful logins from unusual locations. Further, many SIEM platforms support custom detection rules via frameworks such as Sigma, enabling organizations to rapidly deploy new detections as they discover attacker techniques during investigations.

However, SIEM platforms also present challenges. The platforms require substantial investment in both licensing costs and infrastructure to ingest, process, and store large volumes of log data. Effective SIEM operation demands skilled analysts who understand both the platform’s query language and the nuances of log data from different sources. Detection rules require continuous tuning to reduce false positives while maintaining sensitivity to real threats, creating an ongoing maintenance burden. Log sources need to be properly configured to send relevant data to the SIEM, requiring coordination across IT teams and careful planning about what to ingest, given storage costs.

Organizations that deploy SIEM platforms without investing in the people, processes, and ongoing maintenance required to operate them effectively gain little security benefit despite significant financial investment.

Process memory dumps capture the working memory of a single running process rather than the entire system’s physical memory. This targeted approach reduces the volume of collected data and focuses analysis on the specific process of interest, making it ideal for investigating suspicious applications or malware.

Start by suspending the target process to ensure memory contents remain stable during capture. The Microsoft SysInternals tool PsSuspend freezes the process without terminating it, preventing the process from modifying its memory during the capture. ^[10] After freezing the process, ProcDump (also from SysInternals) can create a complete memory dump of the suspended process, as shown in Listing 6.

The -ma flag in ProcDump creates a full memory dump including all accessible memory for the process. This comprehensive capture ensures all process memory regions are collected, including heaps, stacks, and loaded modules.

Process memory dumps can be analyzed with standard debugging tools such as WinDbg and x64dbg, or with straightforward string extraction. In Listing 7, Sysinternals Strings extracts readable strings from the Word process memory dump. With the extracted strings, analysts can search for indicators of compromise, such as PowerShell commands and accompanying command-line arguments, as shown in Listing 8.

Process-specific memory investigation is useful for focusing on artifacts from a given process with a small capture data set, but it does not provide in-depth insight into the configuration of the entire system. Use process memory captures when analysts have identified specific suspicious processes and need a detailed analysis of their runtime behavior. For broader investigations that require visibility into all running processes, network connections, and kernel artifacts, whole-system memory capture provides greater value.

Whole-system memory investigation captures the complete physical memory of a compromised system, preserving all running processes, network connections, registry data, and kernel artifacts. This comprehensive approach to memory capture provides visibility into the entire system state, making it valuable for investigations that require broad context into attacker activity across the target system.

Memory capture tools acquire physical RAM and paged memory (swap) from the running system without requiring a reboot. Windows systems can use WinPMEM, while Linux systems commonly use LiME (Linux Memory Extractor). ^{[11] [12]} The time required to capture memory depends on the amount of RAM and system performance, but typically takes only a few minutes, as shown in Listing 9. The captured memory image preserves volatile artifacts that disappear when the system is powered off, including running processes, network connections, decrypted data, and malware residing only in memory.

After capturing memory, analysts can use tools like Volatility and MemProcFS to extract and analyze artifacts from the memory dump. ^{[13] [14]} Volatility provides plugins that parse memory structures to reveal processes, network connections, loaded modules, registry hives, and other artifacts. This offline analysis allows multiple analysts to examine the same memory image in parallel without impacting the running system.

One particularly valuable resource from Volatility memory analysis is the enumeration of installed drivers on a Windows system. Windows drivers with vulnerabilities represent an opportunity for an attacker to gain escalated privileges, ultimately allowing attackers to disable endpoint protection systems and other system controls. The driver enumeration scan in Listing 10 uses Volatility to display all loaded drivers from the captured memory image, including the suspicious KfeCoSvc driver associated with Kyocera printer software that is vulnerable to privilege escalation attacks ^[15].

While Volatility remains the most widely used memory analysis framework, MemProcFS offers a compelling alternative that can accelerate memory investigation during eradication. MemProcFS mounts a memory image as a virtual file system, allowing analysts to browse memory contents using familiar file navigation tools rather than running individual plugins and waiting for output.

The file system abstraction in MemProcFS provides immediate access to processes, modules, handles, registry hives, and network connections through a directory structure. Further, MemProcFS integrates with other analysis tools through the file system interface, allowing analysts to use standard UNIX or PowerShell commands to search, filter, and extract artifacts from memory.

For example, after collecting a memory image with WinPMEM, the analyst mounts it using MemProcFS as shown in Listing 11. Next, analysts search the mounted file system for instances of backup.exe, an IoC identified during log investigation, using PowerShell Get-ChildItem and Select-String as shown in Listing 12. The search revealed multiple artifacts associated with backup.exe, including registry entries, prefetch files, and file reads from the user’s Downloads folder.

Whole-system memory investigation provides the broad visibility needed to understand attacker activity across the entire system. Use whole-system memory capture when investigating unknown compromises, mapping attacker lateral movement, or identifying all systems and processes requiring eradication. The comprehensive nature of whole-system memory analysis makes it particularly valuable during the eradication phase, ensuring analysts identify all attacker artifacts before recovery begins.

Network investigation during eradication relies on multiple data sources that offer varying levels of visibility into attacker activity. Packet capture (PCAP) offers the most detailed view, recording complete network conversations including payload data. When available, packet captures allow analysts to reconstruct exactly which data the attacker accessed or exfiltrated, which commands they executed over the network, and which tools they deployed. However, full packet capture generates enormous storage requirements and is typically limited to specific network segments or time windows. NetFlow and similar flow data (IPFIX, sFlow) provide a more scalable alternative, recording metadata about network connections, including source and destination addresses, ports, protocols, byte counts, and timestamps without capturing payload content. Flow data reveals connection patterns and data transfer volumes, making it valuable for identifying lateral movement and data exfiltration even when packet captures are unavailable.

DNS logs represent another important data source that attackers often overlook when covering their tracks. Every system lookup for command-and-control domains, malware distribution sites, or exfiltration endpoints leaves a record in DNS logs. Proxy logs provide similar visibility into web traffic, capturing URLs, user agents, and response codes that reveal the behavior of attacker tools and data-staging activities. Many attackers tunnel their communications through web proxies to blend with normal traffic, making proxy logs essential for understanding the full scope of attacker operations. Firewall logs round out the perimeter view, documenting allowed and blocked connection attempts that help identify both successful attacker access and failed reconnaissance attempts.

Organizations that have deployed Network Detection and Response (NDR) platforms gain significant investigative advantages during eradication. While often positioned as tools for threat hunting and real-time detection, NDR platforms also offer valuable investigative features that help responders understand attacker activity across the network. These systems integrate multiple detection capabilities, including signature-based alerting, machine-learning-based anomaly detection, behavioral analytics, and threat intelligence integration. For incident response analysts, alerts generated by NDR platforms provide a valuable investigative resource, enabling responders to quickly identify suspicious network activity associated with the incident.

NDR tools often provide built-in investigation workflows that guide analysts through examining network activity, pivoting from one indicator to related events across the environment. These workflows can accelerate initial analysis, helping responders identify systems requiring deeper investigation. However, analysts should treat NDR findings as one input among many rather than a complete picture of attacker activity. The real value of NDR during eradication lies in its ability to surface connection patterns and anomalies that point to compromised systems, which responders can then investigate using the network data sources and connection-mapping techniques described below.

Beyond NDR platforms, responders can analyze raw network data to map attacker connections directly. This approach works with the flow data, DNS logs, and firewall logs available in most environments, providing connection mapping capabilities without specialized NDR tooling. By mapping these connections, responders can ensure that eradication actions address every compromised system, removing all attacker access points.

For example, consider an incident where an attacker gained unauthorized access to a system in an AWS environment. Using Virtual Private Cloud (VPC) flow logs, responders can reconstruct the attacker’s network connections to identify all the systems they accessed.

One option for visualizing these connections is to generate a network connectivity graph using the VPC Flow Log Analysis tool. Written by Florian Pfisterer (with a simplified fork by this author), this open-source tool processes VPC flow logs and generates a visual graph of network connections, with thicker lines indicating greater data transfer between systems. ^{[16] [17]}

Using this author’s fork of the VPC Flow Log Analysis tool, analysts can generate a network connectivity graph from VPC flow logs collected during the incident. The example in Listing 13 demonstrates the commands used to combine VPC flow log files collected from the AWS S3 log storage destination, generate the network graph data, and start a local web server to visualize and interact with the graph. By assigning host names in the graph-generator/known-ips.ts file, responders can easily review connectivity between the systems under investigation and other systems in the environment.

Network investigation findings directly inform eradication scope: every system the attacker accessed requires examination for persistence mechanisms, every external IP address contacted should be blocked, and every compromised credential used for lateral movement should be rotated. Visualization or other network mapping techniques help responders understand the attacker’s actions and ensure eradication actions address all compromised systems.

Static analysis involves examining the malware binary without executing it. This approach is safer than running the malware (though it still requires safe handling of the malware; see the sidebar Safety in Malware Analysis) and can quickly reveal useful information about the sample’s purpose and capabilities.

Static analysis techniques can include:

Basic identification and file hashing provide a foundation for further analysis with cyber threat intelligence (CTI) sources. Threat intelligence platforms like VirusTotal, Hybrid Analysis, and other online services allow analysts to submit file hashes and retrieve existing analysis reports. Using a hash (or other identifying characteristic, such as a string-based search) allows analysts to collect and review CTI insight without having to share the malware sample itself. An example hash search result for a malware sample using VirusTotal is shown in Figure 9.

Analysts can gain considerable insight by analyzing file metadata and the structure of malware samples. For Windows malware samples, PE (Portable Executable) analysis tools like PE Studio or PE-Bear reveal compilation timestamps, imported libraries and functions, embedded resources, and digital signature information. ^{[18] [19]} Imported functions can reveal what capabilities the malware uses: imports from ws2_32.dll indicate network activity, crypt32.dll suggests encryption routines, and advapi32.dll functions like RegSetValueEx indicate registry manipulation. The example in Figure 10 shows PE-Bear’s analysis of a malware sample, revealing imported functions from kernel32.dll including functionality to determine if the malware is running in a debugger, a common tactic used to detect a sandboxed environment.

For deeper analysis, tools like Ghidra reveal the disassembled code, though this level of analysis requires significant expertise and time. ^[20]

Static analysis provides analysts with valuable insight into malware samples without the risks associated with execution. However, it has limitations: static analysis may not reveal the full behavior of the malware, especially if it employs obfuscation or other anti-analysis techniques. To gain a more comprehensive understanding of malware functionality, dynamic analysis is often necessary.

Dynamic analysis involves executing the malware in a controlled environment and observing its behavior. This approach reveals what the malware actually does rather than what it might do. The tradeoff is increased risk: analysts will be running malicious code, which requires careful isolation to prevent unintended consequences.

The basic workflow for dynamic analysis follows a consistent pattern:

This dynamic analysis process is iterative. Each time analysts complete the basic workflow, they will learn more about the malware. It is often necessary to repeat the dynamic analysis multiple times to obtain a complete picture of the malware’s behavior.

Monitoring or instrumentation tools capture the malware’s behavior during execution. For Windows systems, Process Monitor from Sysinternals is a widely used tool for dynamic analysis. Analysts can configure Process Monitor to capture detailed file system, registry, network, and process activity, using filtering features to focus on the malware process and its children. The example in Figure 11 shows Process Monitor capturing activity from a malware sample, revealing process execution for cmd.exe.

Automated sandbox platforms also offer an alternative to manual dynamic analysis. Online services like Hybrid Analysis, Any.Run, and Joe Sandbox execute samples in instrumented environments and produce detailed behavioral reports. ^{[21] [22] [23]} These platforms handle the isolation and monitoring complexity, providing reports that enumerate file system changes, registry modifications, network connections, and process activity. For known malware families, sandbox reports often provide sufficient detail to guide eradication without requiring manual analysis.

Not all malware yields to basic analysis techniques. Recognizing when a sample exceeds the capabilities of the incident response team and requires specialist assistance is important:

When necessary, engage specialized malware analysis resources, whether internal security research teams, managed security service providers, or external forensic consultants.

The goal of malware analysis during eradication is to obtain insight for practical action. Focus analysis efforts on answering specific questions: what does this malware create, where it persists, what needs to be done to remove it, and how the findings can help scope other infected systems.

When conducting a BEC investigation, analysts should examine mailbox rules and message forwarding configurations on affected accounts. BEC attackers frequently create inbox rules that automatically forward copies of incoming email to external addresses, delete messages from specific senders (particularly security alerts or responses from fraud targets), or move messages to obscure folders where victims will not notice them. These rules provide persistent access to communications even after the attacker’s initial access is contained.

In Microsoft 365 systems, analysts can use PowerShell commands such as Get-InboxRule to enumerate all inbox rules for affected accounts. The ForwardTo, DeleteMessage, and MoveToFolder attributes will reveal any policy actions taken on inbound messages. The example in Listing 14 demonstrates how to list inbox rules for a specific user account, revealing any rules that might indicate attacker persistence.

Examine organization-level mail flow and transport rules for incidents involving administrative access. Sophisticated BEC attackers may create organization-wide rules that redirect specific messages, block security notifications, or allow domains under their control to bypass inbound message controls.

Review OAuth application permissions and third-party integrations for each affected account. Modern BEC attacks often involve OAuth consent phishing, in which victims grant malicious applications access via OAuth consent flows. These applications maintain access to email even after password resets, making them a persistent threat that password rotation alone will not resolve.

For Microsoft 365 environments, use Microsoft’s Get-AzureADPSPermissions.ps1 script to enumerate all delegated permission grants across the tenant as shown in Listing 15. ^[25] This script inventories delegated permissions and application permissions, revealing which applications have access to user data and what level of access they possess. The output CSV file lists all applications with granted permissions, allowing analysts to identify any high-privilege applications that may have been authorized during the compromise window.

Look for applications with high-privilege permissions, such as email, Mail.ReadWrite, Mail.Send, or MailboxSettings.ReadWrite that were granted during the compromise window. Applications with these permissions can enumerate, read, send, and manage email without user interaction, making them effective persistence mechanisms for BEC attackers.

Investigate delegated permissions and multi-mailbox access configurations. Attackers with access to one compromised account often grant themselves additional permissions to access other mailboxes. Look for recently added mailbox delegation permissions, particularly "Full Access" or "Send As" permissions that allow one user to read another user’s email or send email on their behalf. These permissions persist independently of password changes and require explicit revocation. For Microsoft 365 environments, use Get-MailboxPermission and Get-RecipientPermission to identify all delegated access configurations across affected accounts.

Another important element in a BEC investigation is to analyze financial transactions initiated during the compromise window. These resources will vary significantly by environment and will require close coordination with finance and accounting teams to identify relevant transactions.

Analyze authentication logs and sign-in patterns to establish the timeline of attacker access. Review sign-in logs for suspicious patterns such as impossible travel (logins from geographically distant locations within short time periods), sign-ins from unusual locations or IP addresses, or multiple accounts accessed from the same IP address. This analysis helps identify the scope of compromise and any additional accounts requiring investigation.

In Microsoft 365 environments, export sign-in logs from the Entra admin center and analyze location patterns using PowerShell. The script in Listing 17 parses exported sign-in logs and displays each authentication event with timestamp and location, sorted by user and time.

The output in Listing 17 reveals an impossible travel pattern: the user ldolman@falsimentis.com authenticated from both Ashburn, Virginia, and Columbus, Ohio, within a five-minute window. Since these locations are approximately 300 miles (482 kilometers) apart, physical travel between them in one minute is impossible. This pattern strongly suggests credential compromise, with the legitimate user signing in from one location while an attacker uses stolen credentials from another.

Coordinate with finance and accounting teams to trace any fraudulent transactions initiated during the compromise window. BEC attackers often monitor email traffic for weeks before striking during major payment periods, or end-of-quarter rushes when workload may increase the likelihood of a successful attack. Review wire transfer requests, invoice payments, and vendor payment modifications that occurred during the identified compromise period.

When attackers compromise software vendors and inject malicious code into legitimate software updates, the resulting compromises appear to come from trusted sources and may bypass security controls that would normally detect malicious activity. In a software-based supply chain compromise, start by identifying all systems that installed the compromised software version. Review software deployment logs, package manager histories, and endpoint management systems to build a comprehensive list of affected systems. This scope may extend beyond initially identified systems due to the pervasive nature of supply chain attacks.

Analyze the malicious code to understand its capabilities and artifacts. Work with the software vendor to obtain information about indicators of compromise specific to the compromised version. Since supply chain incidents can affect so many end users, security researchers and the incident response community often share IOCs for major supply chain incidents shortly after identification.

For example, a 2025 supply chain attack discovered by GitLab’s Vulnerability Research Team identified multiple compromised Node Package Manager (NPM) packages with a worm-like propagation mechanism to distribute the Shai-Hulud malware. ^[27] In their assessment of the incident, GitLab researchers shared multiple IOCs to identify the malicious artifacts created by the compromised NPM packages, as shown in Table 1.

Supply chain malware is often designed to meet specific goals such as committing financial fraud (including decentralized finance/cryptocurrency theft), gaining persistence on compromised endpoints, exfiltrating data, or conducting hacktivist campaigns. Examine the affected software elements to identify the possible goals of the attack and guide subsequent assessment. For example, if malware distributed through a supply chain compromise includes functionality to establish persistence or facilitate remote access, analysts should investigate whether the compromised software was used to move laterally within the environment.

Sophisticated supply chain attacks will use the initial compromise as a foothold for further activity. Review logs from affected systems for signs of lateral movement, credential dumping, or deployment of additional tools. The scope of eradication may extend well beyond removing the compromised software if the attacker used it to establish additional persistence.

Hardware supply chain compromises involve physical modifications to devices during manufacturing, shipping, or maintenance. These attacks are rare but extremely difficult to detect and eradicate. Indicators include unexpected firmware modifications, unauthorized hardware components, or unusual device behavior that cannot be explained by software analysis.

Physical hardware modifications cannot be remedied by software and typically require hardware replacement. Conduct a thorough inspection of suspicious devices to identify unauthorized chips, modified firmware, or unexpected network behavior at the hardware level.

Document all serial numbers, procurement sources, and shipping chains for affected hardware. This information helps determine the scope of potential compromise and whether other devices from the same batch or supplier may be affected. Coordinate with hardware vendors and law enforcement, as hardware supply chain attacks often have broader implications beyond a single organization.

When third-party service providers or partner organizations with access to the organization’s environment are compromised, attackers can pivot from the partner’s environment into the target organization using legitimate access channels. This type of attack is growing in prevalence: as more organizations improve their own defenses, attackers target weaker links in the supply chain to gain entry. The risk to downstream organizations is significant, as attackers can leverage trusted relationships to bypass security controls after exploiting the vulnerable partner organization.

When responding to a partner compromise, start by identifying all access points the compromised partner has to the environment, including VPN connections, API integrations, federated authentication, and shared infrastructure. Review authentication logs for all accounts associated with the compromised partner. Look for unusual access patterns, access from unexpected locations, or access during timeframes when the partner was known to be compromised.

Examine data shared with or accessible to the compromised partner. Service providers often have broad access to customer data through legitimate business relationships. Determine what data the partner could access, whether any data was exfiltrated during the compromise, and whether any organizational data was stored in the compromised partner environment.

In incidents where the partner compromise has local access to sensitive data and reports evidence of a breach, enumerate the disclosed data to identify what information may have been exposed. Work with the partner organization to obtain as much information as possible about the incident, leveraging non-disclosure agreements as needed to collect detailed insight, to help assess the risk and impact to the organization.

Coordinate with the compromised supplier or partner throughout the eradication process. They may have valuable information about the attacker’s capabilities, IOCs specific to the compromise, and the timeline of malicious activity. When possible, share information about what the investigation uncovers, as these findings may help the supplier understand the broader impact of their compromise.

Infrastructure-as-a-Service compromises present two distinct attack surfaces that require different investigative approaches: the cloud control plane and the infrastructure itself. Understanding this distinction helps structure a thorough investigation before removing the attacker’s access.

Cloud Control Plane Investigation

The cloud control plane encompasses all the management APIs, IAM systems, and configuration services that govern how cloud resources are created, modified, and accessed. Attackers who compromise control plane access can create new resources, modify security configurations, and establish persistence mechanisms that survive infrastructure rebuilds.

Control plane investigation relies primarily on log analysis and differential analysis. Review cloud provider audit logs (AWS CloudTrail, Azure Activity Log, GCP Cloud Audit Logs) to identify all API calls made during the compromise timeframe. Look for resource creation, IAM modifications, security group changes, and any actions that could establish persistence or expand access.

Differential analysis compares the current environment against a known-good baseline (see the sidebar Differential Analysis for Threat Investigation). Organizations using Infrastructure-as-Code (IaC) tools like Terraform, CloudFormation, or Pulumi can compare the deployed state against their source-controlled definitions to identify unauthorized changes. For environments without IaC, compare against documented architecture diagrams, previous configuration exports, or pristine reference environments. Pay particular attention to IAM policies, assume-role trust relationships, security groups, and resource configurations that differ from expected baselines.

Investigate IAM thoroughly. Attackers frequently create new roles, modify existing policies, or add themselves to privileged groups. Examine assume-role policies that allow cross-account access, as attackers may use compromised credentials to pivot to other AWS accounts or Azure subscriptions. For example, the AWS IAM enumeration example in Listing 18 lists all IAM roles with sts:AssumeRole permissions, revealing roles that can be assumed by other principals including an external AWS account identified as 013628954028.

Each cloud provider has different mechanisms for cross-account or cross-tenant trust relationships. Table 2 summarizes equivalent commands for investigating role and permission assignments across providers.

Pay particular attention to privileged roles and roles with permissions to modify IAM itself (iam:PutRolePolicy, iam:AttachUserPolicy, iam:CreateRole, iam:UpdateAssumeRolePolicy, etc.), as these permissions allow attackers to continuously create new persistence mechanisms as long as they retain access to the cloud environment.

Infrastructure Investigation

For the infrastructure itself (virtual machines, containers, storage, databases, etc.), apply the same forensic procedures used in on-premises environments. The important difference is that cloud environments offer additional capabilities for evidence preservation, such as snapshots and logging.

Examine virtual machine and container images for backdoors and persistence. Attackers often modify VM images or container images stored in registries to ensure that newly deployed instances automatically include backdoors. Review recent changes to images in the environment, using differential analysis with known-good baselines (such as gold images used for automated deployments).

Analyze storage access and potential data exfiltration. Cloud storage services like S3, Azure Blob Storage, and Google Cloud Storage are common targets. Review storage access logs to identify which objects were accessed, downloaded, or had permissions modified. Check for publicly exposed buckets or containers that the attacker may have configured to enable anonymous access. Use the cloud provider’s native tools to evaluate aggregate logging data, or use command line tools to analyze access patterns as shown in Listing 19. ^[35]

Investigate serverless functions and event-driven infrastructure. Attackers can deploy malicious serverless functions that execute in response to triggers, providing persistent access without traditional compute infrastructure. Review recently deployed or modified functions, examining their code for backdoors and their triggers for unexpected event sources. Check IAM roles for excessive permissions that could enable privilege escalation or lateral movement.

Review network configurations and security group modifications. Attackers modify firewall rules, security groups, and network ACLs to enable access to compromised resources or to establish command-and-control channels. Check VPC peering connections, VPN configurations, and transit gateway attachments that could enable lateral movement to other cloud environments or on-premises networks.

Software-as-a-Service compromises typically involve account takeover, OAuth token abuse, and exploitation of application-level access controls rather than traditional infrastructure compromise. These compromises are particularly difficult to investigate, since affected organizations lack access to the underlying infrastructure to collect logs or forensic images from the SaaS provider. Further, many smaller SaaS providers have limited logging capabilities, making it challenging to reconstruct attacker activity. Organizations often have to rely on minimal insight from the SaaS provider combined with logs from their own integrated systems to piece together the attacker’s actions.

When investigating an incident involving a SaaS provider, start by identifying the provider’s logging capabilities. Major platforms such as Microsoft 365, Google Workspace, and Salesforce provide audit logs via administrative consoles or APIs. Smaller or specialized SaaS applications may have minimal logging, or logs may only be available by opening a support case with the provider. Request activity reports and access logs covering the compromise timeframe, and specifically ask whether any additional logging data is available beyond standard administrative interfaces.

Use integration logging from on-premises or IaaS environments connected to the SaaS platform. Organizations often connect SaaS applications to internal systems via APIs, webhooks, or other middleware. These integration points may capture request logs, authentication events, or data transfer records that provide insight into attacker activity even when the SaaS platform’s native logging is limited. Review logs from identity providers, API gateways, SIEM systems, and any custom integration services that interact with the compromised SaaS application.

Enumerate SaaS privileges to identify persistence mechanisms and excessive permissions. Attackers frequently create new administrative accounts, elevate privileges on compromised accounts, create API keys, or grant OAuth consent to malicious applications. Review user roles and permissions, looking for recently modified access levels or accounts with administrative privileges that don’t align with job responsibilities. Examine OAuth applications and third-party integrations, identifying any applications that were consented to during the compromise timeframe or applications that have suspicious permission scopes.

Windows systems provide numerous persistence locations that attackers exploit. The specific locations used vary by attacker sophistication and the privileges they obtained during the compromise. Responders should address each category systematically, using insights from the investigation to guide removal efforts.

Windows persistence mechanisms span registry Run keys, scheduled tasks, services, WMI event subscriptions, startup folders, and numerous other locations. The Sysinternals Autoruns utility allows analysts to enumerate multiple persistence mechanisms on a system in a single view. Autoruns displays entries from dozens of persistence locations and highlights items that may be suspicious based on signature verification and VirusTotal integration, as shown in Figure 17.

Export the Autoruns results to a file for documentation before making changes, using the GUI File | Save feature or the command line version autorunsc.exe to produce a CSV file, as shown in Listing 20. Compare the output against a known-good baseline from a clean system of the same configuration to identify entries that should not be present.

After identifying malicious persistence through Autoruns or investigation techniques, remove each mechanism using the appropriate method for its type. Persistence mechanisms identified in Autoruns can be removed from within the Autoruns GUI. Alternatively, use PowerShell to remove persistence mechanisms manually, as shown in Listing 21.

The removal sequence first disables the service to prevent a restart, then stops the service, and finally deletes the service registration entirely. Using sc.exe delete rather than PowerShell’s Remove-Service ensures compatibility with older Windows versions where Remove-Service may not be available. The final verification command should return no results if removal succeeded.

Similar approaches apply to other Windows persistence types as well.

Linux systems provide different persistence mechanisms than Windows, but the systematic approach to removal remains the same. Use the persistence inventory from investigation to guide removal, addressing all identified mechanisms as part of coordinated eradication. Table 3 summarizes several common Linux persistence types and their removal methods.

Verify removal by listing the persistence mechanism using administrative commands such as atq and by listing the files in associated configuration directories such as /var/spool/at to confirm malicious entries no longer appear.

Web shells provide attackers with interactive access to compromised web servers. Remove the web shell file and any associated configuration or log files the shell may have created. Investigation may have identified multiple web shells deployed for redundancy. Remove all identified shells as part of coordinated eradication.

Web shells may be deployed as standalone files, as embedded content within existing web application files, or as configuration modifications that execute across multiple files. The example in Listing 22 shows a simple standalone web shell file that executes commands passed via the cmd GET parameter. Web shell eradication would involve deleting this file from the web server.

The example in Listing 23 shows an obfuscated web shell embedded within an HTML file. The HTML file is likely part of a larger web application, so eradication involves removing the obfuscated PHP code while preserving the rest of the HTML content.

The example in Listing 24 is more subtle, attempting to establish persistence by modifying the PHP configuration to automatically load a backdoor script for every request. Removing this web shell requires reverting the configuration change and deleting the backdoor script.

After removing web shell content, restart the web server to clear any in-memory artifacts that might persist after file deletion. Some web shells load components into memory that continue executing even after the file is removed.

Cloud environments present unique persistence challenges because attackers can create resources that execute code without traditional host-based persistence. The investigation phase should have identified unauthorized cloud resources, IAM modifications, and changes to container images. Eradication now focuses on removing these cloud-native persistence mechanisms.

Lambda/Serverless Functions

Serverless functions allow attackers to execute code without managing servers, making them attractive for persistence. Delete malicious functions identified during the investigation using the cloud provider’s CLI tools.

After deleting functions, review CloudTrail, Azure Activity Log, or Cloud Audit Logs to confirm the deletion was successful. Check for associated triggers such as API Gateway endpoints, S3 event notifications, or CloudWatch Events rules that may need to be removed.

IAM Policy Modifications

IAM changes represent a particularly insidious form of cloud persistence because they grant access rather than execute code directly. Attackers who modify IAM policies can grant themselves persistent access across cloud accounts that will survive even comprehensive credential rotation.

Revert unauthorized IAM policy changes by comparing current policies against the baseline configuration established before the incident. If the organization uses infrastructure-as-code, the IaC repository provides a definitive baseline for comparison. Remove unauthorized users and service principals that the attacker created to maintain access. Revoke elevated permissions granted during the compromise, particularly administrative roles assigned to standard user accounts or overly permissive policies attached to existing roles. Reset access keys for compromised accounts to invalidate any credentials the attacker may have stolen.

Container Image Modifications

Container images provide another vector for cloud persistence. Attackers who modify container images ensure their code executes whenever new containers are deployed from those images. This persistence survives container restarts, scaling events, and even cluster redeployment if the compromised images remain in use.

Remove manipulated images from both local Docker hosts and container registries. After removing images from registries, force redeployment of affected workloads to ensure running containers are replaced with instances from known-good images. Review CI/CD pipelines to ensure they build from trusted base images and that build processes have not been compromised.

Attackers often create unauthorized local user accounts on compromised systems to maintain access. Following an investigation, remove unauthorized local user accounts to prevent them from being used for continued access.

Locally created unauthorized user accounts on Windows can be removed using Windows administrative GUI tools or PowerShell commands as shown in Listing 25. Following the removal of an account, verify that it no longer exists by attempting to retrieve it again.

Similarly, on Linux systems, analysts can remove unauthorized local user accounts using the userdel command, as shown in Listing 26.

These steps are straightforward: identify the unauthorized local accounts, remove them, and verify removal. However, organizations with complex identity environments, including Windows Active Directory, Entra, and other identity providers, should take a more structured approach to account and credential remediation.

Attackers who compromise Active Directory infrastructure can gain access to cryptographic materials that allow them to forge authentication tokens, persist across password resets, and maintain access through multiple authorization paths. Simply resetting passwords for known-compromised accounts is insufficient. Attackers who obtain privileged credentials or authentication secrets can continue accessing systems until those underlying key materials are changed.

A credential reset after an Active Directory compromise requires a structured, phased approach rather than a single mass reset. Execute credential resets in phases aligned with account privilege levels (tier 0 through tier 2) and infrastructure criticality.

NOTE: Microsoft’s tier model for enterprise access defines three account tiers: tier 0 (domain admins, enterprise admins, schema admins), tier 1 (server and application admins), and tier 2 (workstation users). ^[38]

Phase 1: Privileged Account Reset

Reset credentials for all Tier-0 and Tier-1 privileged accounts first. These accounts provide the greatest access and represent the highest risk if attackers retained copies of the credentials.

Privileged accounts requiring immediate reset include:

Before or concurrently with privileged account resets, analysts should reduce privileged group memberships to the minimum required. Remove any unauthorized members from Domain Admins, Enterprise Admins, Backup Operators, and similar groups.

Phase 2: Service Account and Identity Infrastructure Reset

Reset credentials for service accounts and identity infrastructure components. These accounts often have broad access across the environment and may be targeted for persistence.

Service accounts requiring reset include directory synchronization accounts, certificate authority service accounts, database service accounts, and application service accounts that authenticated to compromised systems. Coordinate with application teams to update service configurations before the reset takes effect.

For identity infrastructure accounts, pay particular attention to:

Phase 3: General User Account Reset

After privileged and service accounts are secured, execute a staged reset of remaining user accounts. Prioritize targeted users and accounts with broad data access before the general user population.

Plan for user impact during mass credential resets. Prepare helpdesk staff for increased support volume. Use self-service password reset (SSPR) with strong identity proofing where possible to reduce administrative burden. Communicate the reset timeline to affected users in advance.

Credential resets prevent attackers from using stolen passwords for future authentication attempts. However, password resets alone do not revoke existing sessions or invalidate tokens issued before the reset. Attackers who established sessions or obtained tokens before the password change can continue using those authorization materials until they expire or are explicitly revoked. Responders need to take additional steps to address cryptographic root rotation, session revocation, and hybrid identity remediation.

The krbtgt account (sometimes capitalized as KRBTGT in Microsoft documentation) is the cryptographic root of trust for Kerberos authentication in Active Directory. Attackers who obtain the krbtgt hash can forge Golden Tickets that grant access to any resource in the domain. ^[40] These forged tickets remain valid regardless of user password resets until the krbtgt password itself is reset.

When investigation indicates attackers compromised domain controllers, executed DCSync attacks, or obtained the krbtgt hash, responders need to reset the krbtgt password twice with appropriate delays between resets.

Reset the krbtgt password using Active Directory Users and Computers or PowerShell, as shown in Listing 28.

Wait at least the maximum Kerberos ticket lifetime (default ten hours) between the first and second resets. This delay allows legitimately issued tickets to expire naturally before the second reset invalidates the key they were issued under. In practice, administrators may want to wait longer, perhaps twenty-four to forty-eight hours, to account for systems that may be offline so that they can receive updates when they reconnect.

Verify replication completed successfully after each reset using repadmin /replsum before proceeding. Incomplete replication can result in authentication failures when users authenticate against domain controllers with inconsistent krbtgt keys.

Multi-Domain Forest Considerations

In multi-domain forests, reset krbtgt in child domains before resetting it in parent domains. Each domain has its own krbtgt account, and the reset sequence should follow trust relationships. Perform two resets per domain, with appropriate delays, and verify replication between each reset.

Domain controllers authenticate to each other using machine account passwords. Attackers who compromise domain controllers may have obtained machine account credentials, allowing them to impersonate domain controllers even after other remediation steps are complete.

As part of the eradication effort, reset the domain controller machine account passwords individually after completing krbtgt resets. Use netdom to reset each domain controller’s machine account password:

Execute this command on each domain controller, specifying a different domain controller as the /server target. The /passwordd:* parameter prompts for the password interactively rather than exposing it on the command line.

Allow replication to complete between machine account resets to ensure password history remains synchronized across domain controllers. Domain controllers maintain a password history of two. If password changes exceed this history before replication completes, authentication failures between domain controllers can occur.

If the forest recovery is in response to a security breach involving inter-domain or inter-forest trusts, reset trust passwords after re-establishing control over domain controllers and completing krbtgt resets.

Trust passwords secure the authentication channel between domains and forests. Attackers who compromised trust relationships can use them to move between trusted environments. Reset trust passwords on the trusting side of each affected trust relationship to sever any attacker persistence that relies on compromised trust credentials.

Unconstrained delegation allows a service to impersonate any user who authenticates to it and to store their Kerberos tickets for reuse. Attackers who compromise a system with unconstrained delegation can harvest tickets from any user who connects, including privileged accounts. This makes unconstrained delegation a significant risk for persistence and lateral movement.

Review computer and user objects for unconstrained delegation settings and disable them where not strictly required. Identify objects with unconstrained delegation enabled as shown in Listing 30.

For objects that no longer require delegation, disable the setting, as shown in Listing 31.

Where delegation is required for application functionality, migrate to constrained delegation or resource-based constrained delegation, which restricts the services to which an account can delegate user access. Constrained delegation provides equivalent functionality while significantly reducing the attack surface. ^[41]

Organizations with hybrid Active Directory and Entra ID environments face additional remediation requirements. Password resets in on-premises Active Directory do not automatically revoke cloud sessions, and attackers who compromised hybrid identity infrastructure may have established persistence in both environments.

Hybrid identity remediation combines on-premises credential resets with cloud session revocation and conditional access enforcement. The goal is to ensure attackers cannot reauthenticate from compromised devices after credentials are reset.

Entra ID Session and Token Revocation

Revoke all refresh tokens and active sessions for compromised users in Entra ID. This forces re-authentication for all cloud applications the next time they attempt to use stored tokens. Password reset alone is insufficient because existing tokens remain valid until they expire or are explicitly revoked.

Revoke user sessions using the Microsoft Graph PowerShell SDK or through the Entra admin center. Using PowerShell, revoke all refresh tokens for a compromised user as shown in Listing 32.

Alternatively, in the Entra admin center, navigate to Identity | Users | [select user] | Revoke sessions to invalidate all refresh tokens for the user.

For compromised user accounts, revoke all refresh tokens immediately after resetting their passwords. If investigation suggests the attacker can complete self-service password reset or MFA challenges, block the user entirely by disabling their account as shown in Listing 33.

Alternatively, in the Entra admin center, navigate to Identity > Users > [select user] > Properties and set Block sign in to Yes to disable the account.

Some Entra integration applications support back-channel logout, which actively notifies connected applications to terminate sessions when an administrator revokes access. Without back-channel logout support, application sessions may remain active until their tokens expire naturally, even after the identity provider session is terminated. For applications that do not support back-channel logout, manually terminate sessions through each application’s administrative interface.

Entra Connect and Directory Synchronization

If Entra Connect or another directory synchronization service is compromised, reset the synchronization service account credentials and review the synchronization configuration for unauthorized changes.

Attackers who compromise directory synchronization can modify cloud identities, create backdoor accounts for persistent access, or alter group memberships that propagate to the cloud environment. Verify that synchronization rules have not been modified and that no unauthorized objects are being synchronized.

Review the Entra Connect synchronization service account in the Entra admin center under Identity | Hybrid management | Microsoft Entra Connect | Connect Sync. Reset the service account credentials and verify the connector configuration. On the Entra Connect server, open the Synchronization Rules Editor to review inbound and outbound synchronization rules for unauthorized modifications.

Modern authentication creates session tokens, refresh tokens, and OAuth grants that persist independently of password changes. When a user authenticates through single sign-on, they receive tokens for each connected application that may remain valid for hours, days, or indefinitely, depending on configuration.

Attackers who compromise accounts with SSO access can use stolen tokens to access connected applications even after the password is changed. Browser sessions, OAuth tokens, personal access tokens, and API keys all provide access paths that persist even after credential rotation. Comprehensive account remediation requires revoking all active sessions and tokens associated with compromised accounts.

Revoke refresh tokens and active sessions through each identity provider in use. Most identity platforms provide administrative capabilities to terminate all sessions for a specific user. This forces reauthentication for all connected applications the next time they attempt to use stored tokens.

For applications that do not receive logout notifications from the identity provider, manually terminate sessions through each application’s administrative interface. Prioritize applications that contain sensitive data or provide access to critical infrastructure. Review the application inventory developed during the investigation to ensure all connected applications are addressed.

Attackers may have activated malicious OAuth applications that provide persistent access to user data and connected services. These applications receive delegated permissions that remain valid even after password changes and session termination.

Review OAuth applications authorized by compromised accounts and revoke any unauthorized consents. Focus on applications with broad permissions such as mail access, file access, or administrative capabilities. Legitimate-looking application names may mask malicious OAuth grants. Verify each application against known authorized applications. Apply this process to all affected identity providers and SaaS platforms involved with the incident.

For example, GitHub is a platform where third-party applications can provide persistent access through OAuth grants. Attackers who create malicious GitHub applications and add them to repositories or organization-level assets maintain persistent API access even after credential resets and token revocation. Analysts should review GitHub app integrations (as shown in Figure 19) and the permissions and repository access granted to each application (as shown in Figure 20) to identify and remove any unauthorized applications.

Personal Access Tokens (PATs) and similar long-lived credentials are tied to individual user identities and provide programmatic access to platforms and services. Unlike session tokens that expire relatively quickly, PATs often remain valid for months or years, providing persistent access that survives password resets. Common examples include GitHub and GitLab personal access tokens, AWS access keys associated with IAM users, Azure user credentials, and Platform-as-a-Service (PaaS) tokens from vendors like Heroku, Replit, and Render.

Attackers who obtain these credentials from compromised developer workstations or configuration files can access resources as the compromised user without triggering re-authentication. These access paths often have broad permissions, making them attractive for continued access to the environment.

Revoke all personal access tokens associated with compromised user accounts. Most platforms provide an interface to list and revoke tokens. For example, GitHub users can review tokens under Settings | Developer settings | Personal access tokens. For AWS IAM users, list and delete access keys associated with compromised accounts, as shown in Listing 34.

Table 5 provides equivalent commands for revoking cloud credentials across providers.

Generate new tokens only after eradication is complete and the account is confirmed to be secure.

Browser-stored credentials present a particular challenge. Browsers maintain password managers, authentication cookies, and session tokens that attackers can extract and use on other systems. Clear browser profiles on compromised systems and consider requiring password changes for accounts whose credentials were saved in affected browsers.

API keys and service credentials provide programmatic access to applications and services without being tied to a specific user identity. These shared credentials are used for application-to-application communication, webhook authentication, and service integrations. Because they are not associated with individual users, they often have broad access and may not be subject to the same lifecycle management as user credentials.

Common examples include application API keys for SaaS platforms, webhook authentication secrets, database connection strings, service-to-service authentication tokens, and third-party integration credentials. Azure service principals and GCP service account keys also fall into this category when used for application authentication rather than individual user access.

Rotate all potentially compromised API keys through the appropriate management interface. For Azure service principals:

Delete old keys only after new keys are deployed and validated in all dependent systems. Coordinate with application teams to update configurations before deleting old credentials to avoid service interruption.

Backups older than the compromise mean data loss for the intervening period, requiring strategies to minimize business impact. Restore user-created files selectively from newer backups after thorough investigation, ensuring they do not reintroduce a threat to the environment. Recover data from application databases if separate database backups are available that can be validated as clean.

It is important to ensure that the response effort focuses on addressing the right vulnerabilities. Using the evidence collected during the investigation, including root cause analysis, identify the vulnerabilities or weaknesses that led to the incident. Prioritize vulnerabilities confirmed to have been exploited by the attacker for remediation.

Vulnerabilities are associated with Common Vulnerabilities and Exposures (CVE) identifiers. ^[43] Use CVE identifiers to track and reference vulnerabilities in documentation, and to access vendor guidance on patching or remediation advice. Vulnerability patching is not always straightforward or consistent: assess vulnerabilities in the context of the organization’s specific environment and software versions.

When available, refer to threat intelligence sources for additional context about the exploited vulnerability. While vendor advisories describe a vulnerability’s technical details, threat intelligence sources offer additional insight into how attackers exploit it in the wild. For example, resources, including CISA’s Known Exploited Vulnerabilities (KEV) catalog, provide additional context about actively exploited vulnerabilities, including binding operational directive timelines for federal agencies. ^[44]

For example, consider the Fortinet FortiWeb vulnerability CVE-2025-64446: a path traversal vulnerability that allows an attacker to execute administrative commands (such as disabling firewall rules) via specially crafted HTTP requests. ^[45] The CVE information published for this vulnerability includes technical details, affected versions, and links to vendor patches, as shown in Figure 21. Further, the KEV entry for the CVE confirms that the vulnerability is actively exploited with concise remediation guidance, as shown in Figure 22.

Cyber threat intelligence sources can also provide additional details not otherwise publicly linked to CVE or KEV reports. For example, one threat intelligence report on CVE-2025-64446 provides a link to a working exploit for this vulnerability. Using GitHub Copilot AI integration, analysts can obtain additional intelligence about the exploit’s functionality and IOCs, as shown in Figure 23. This additional context can inform detection and remediation efforts during eradication.

When the attack vector is a configuration weakness rather than a software vulnerability, review the specific misconfiguration and the corrective action required. Configuration weaknesses may include overly permissive firewall rules, default credentials, exposed management interfaces, missing security headers on web applications, and more. Corrective efforts should focus on remediating the specific misconfiguration that enabled the attack, while also addressing operational practices to prevent such misconfigurations in the future.

Apply security patches for exploited vulnerabilities as part of the eradication process. This is a straightforward recommendation that will be intuitive for organizations, but there are important considerations to ensure effective patching during incident response.

Test and Verify Before Broad Rollout

Every patch should be tested and verified prior to broad deployment. Develop a documented procedure for applying and verifying the patch, including expected outcomes and rollback steps if issues arise. Testing in a non-production environment helps identify compatibility issues before they affect critical systems.

Track Patch Status with Inventory Management

Use inventory management to ensure that all systems requiring remediation receive patches. Technology platforms such as configuration management databases (CMDBs) or vulnerability scanners can help automate this documentation process. For organizations without these tools, manual spreadsheets or other tracking mechanisms (simple lists, tickets, etc.) can provide visibility into patch status across the environment. The goal is to maintain a clear record of which systems have been patched and which still require remediation.

Balance Change Management with Speed

Use change management processes where possible, but many organizations will benefit from prioritizing speed and risk reduction during incident response. A vulnerability actively exploited against the organization poses an immediate risk that often justifies expedited patching. Coordinate with decision-makers to establish an appropriate risk tolerance for bypassing standard change windows. Document any deviations from normal procedures for the incident record.

Consider Phased Rollout for Large Environments

For environments with many affected systems, consider a phased rollout in which groups of systems are patched and verified before moving to the next group. This approach identifies concerns or problems with patching early in the process before they affect all systems. Start with lower-risk systems, when possible, to validate the patch before applying it to critical infrastructure.

Verify System Functionality After Patching

Use system verification procedures to ensure systems preserve needed functionality after patching. Coordinate with system owners to validate that patched systems continue to operate correctly. Some patches may require configuration changes or application updates to maintain compatibility. Document any issues encountered and their resolutions for future consideration.

Some systems cannot be patched immediately due to end-of-life software, vendor constraints, or operational dependencies. When patching is not feasible, organizations should implement compensating controls to reduce risk until the system can be updated or replaced.

Network segmentation isolates vulnerable systems from potential attack sources. Place unpatchable systems in dedicated network segments with strict network access control rules limiting inbound and outbound connections to only required traffic. Monitor these segments closely for signs of exploitation attempts.

Application-layer controls, such as web application firewalls, can block exploitation attempts for web-based vulnerabilities. Deploy virtual patching rules that detect and block exploit traffic patterns specific to the vulnerability. These controls provide temporary protection but should not replace permanent remediation (see WAF Bypass Opportunities).

Enhanced monitoring increases visibility into potential exploitation attempts. While not a vulnerability remediation measure, monitoring provides early warning if attackers attempt to exploit the vulnerability, which can reduce future risk to the organization if analysts can quickly identify and respond to future attacks. Configure logging and alerting for access to vulnerable services, unusual process execution, and network connections associated with known exploit behavior.

Plan a timeline for permanent remediation via system upgrades, replacements, or migrations to supported platforms. Communicate this timeline to stakeholders and track progress toward completion. Over time, compensating controls can degrade in effectiveness as attackers develop new bypass techniques or as organizational or technological changes in other platforms inadvertently weaken the controls. Additionally, maintaining compensating controls requires ongoing effort and attention, diverting resources from other security priorities. Treat unpatchable systems as technical debt that accumulates risk until permanently addressed.

When remediating an exploited vulnerability, consider the broader environment for similar vulnerabilities. The vulnerability exploited in the incident may not be unique to the compromised system. Other systems running the same software version may also be vulnerable to the same attack. Expand remediation beyond systems directly involved in the incident to all systems with the same vulnerability.

Use vulnerability scanning tools to identify all instances of the vulnerable software across the environment. Commercial vulnerability scanners, open-source platforms such as Greenbone (which includes OpenVAS), or agent-based scanning via EDR platforms can identify other vulnerable systems that should also be remediated. ^[50]

Open-source vulnerability scanning tools such as Nuclei can use vulnerability identifiers to scan for additional vulnerable targets. ^[51] Nuclei uses a YAML-based template system to define vulnerability checks, making it easy to create custom checks for specific CVEs.

For example, consider a scenario in which a network-attached camera is vulnerable to a Server-Side Request Forgery (SSRF), where specific HTTP requests can access internal network resources, disclosing sensitive information. In this example, an attacker can access a specific endpoint on the IP cameras (/fetch) with the url parameter to trigger the SSRF vulnerability and access other resources on behalf of the camera. Using the SSRF vulnerability, an attacker can access an internal administrative page that returns configuration details, including AWS credentials stored in the camera’s configuration for saving video footage to an S3 bucket, as shown in Listing 36.

To identify other vulnerable IP cameras on the network, create a custom Nuclei template that checks for the presence of the vulnerable endpoint and parameter, as shown in Listing 37.

With the template saved in a file (e.g., ssrf-url-fetcher.yaml), run Nuclei against a list of target IP addresses to identify other vulnerable cameras, as shown in Listing 38.

Vulnerability scanning is a valuable tool for identifying other systems that may share the same vulnerability exploited during the incident. By expanding remediation beyond the systems directly involved in the compromise, responders reduce the risk of subsequent attacks through the same vulnerability on other systems in the environment.

Vulnerability remediation is not limited to patching software flaws. System misconfigurations often contribute to attack success by providing attackers with opportunities they would not have on hardened systems. Consider which opportunities exist to apply configuration hardening during the eradication action, based on security baselines and lessons learned from the incident.

Harden System Configurations

In Apply System Hardening Processes, we looked at the preparation activity for applying CIS benchmarks and other hardening guides. ^[52] In the eradication waypoint, responders should revisit these processes to ensure that the hardening guides have been applied to the extent possible based on the investigation findings and the needs of the organization.

For many organizations, system configuration hardening is completed during initial system deployment. System updates, configuration changes, and new features introduced with product updates can, over time, expand the attack surface for devices. During eradication, review system configurations to ensure that hardening measures remain in place and that no new weaknesses have been introduced.

Enumerate Accessible Services

Port scan systems to enumerate open services and identify unnecessary exposure. Consider a network perspective when performing this step: scanning from an internal network segment reveals different services than scanning from an external perspective. Compare results against documented service requirements to identify services that should be disabled or restricted. Pay particular attention to management interfaces, legacy protocols, and services that were not intentionally exposed.

To enumerate accessible services, use tools like Nmap to perform comprehensive port scans. ^[53] For example, the Nmap command in Listing 39 scans a target system for open TCP ports and attempts to identify running services through version enumeration, providing insight into the accessible services on the target. Alternatively, vulnerability scanning platforms can provide similar service enumeration capabilities as part of their scanning process.

As an alternative to port scanning, which can be taxing on network resources or introduce risk of service disruption, review local listening services on each system. For Windows systems, use PowerShell Get-NetTCPConnection and Get-NetUDPEndpoint cmdlets to enumerate listening TCP and UDP ports, as shown in Listing 40. For Linux systems, use ss -tuln or netstat -tuln commands to list listening services. On macOS systems, use lsof -i -n -P | grep LISTEN.

Enumerating accessible services on each system provides a more accurate view of the services that could expose systems, but requires access to each system individually and coordination to collect and review the results.

Review Network Device Configurations

Review the configuration of network devices, including firewalls, routers, and switches, to ensure that access controls align with the principle of least privilege. Poor change management practices often lead to overly permissive rules that unnecessarily expose systems. Firewall rules may accumulate over time as temporary exceptions become permanent, or as rules are added without removing obsolete entries.

For example, consider the FortiGate firewall policy in Listing 41. In this configuration, a Virtual IP (VIP) object exposes an internal web server on port 8080 to the public internet via port 11111 on a public IP address. Replicated from a customer’s environment, this configuration was no longer needed but remained active, exposing the internal web server to potential attack from the internet.

Review access controls to limit the exposure of critical systems. Remove rules that are no longer required and restrict overly broad allow rules.

Disable Unnecessary Services

Disable unnecessary services and protocols that attackers commonly exploit. Remote access services, in particular, should be limited to those required for business operations. Services such as Telnet, FTP, RDP, and SMB are frequently targeted by attackers and should be disabled unless explicitly required. Where remote access is required, use secure alternatives such as SSH or VPNs with multi-factor authentication.