The first objective of containment is to prevent the attacker from continuing malicious activities. In the past, this meant unplugging affected systems from the network, an approach that is no longer practical for many organizations with disparate and distributed systems. Modern containment strategies require more sophisticated approaches that balance security needs with operational requirements. This includes techniques such as network isolation, account restrictions, and process termination.

Network isolation uses technologies such as private VLANs, access control lists, cloud security groups, and software-defined networking to restrict the movement of attackers without completely disrupting business operations. Rather than disconnecting systems entirely, responders can sever specific communication paths while maintaining critical business functions. For example, isolating a compromised web server from internal systems while maintaining its internet-facing services allows containment without complete service disruption.

Account restrictions disable or limit access to compromised accounts, ideally without alerting the attacker to defensive measures. This can include changing account passwords, revoking privileges, or implementing conditional access policies that limit access while maintaining the appearance of normal operations. Organizations should coordinate credential resets carefully to avoid triggering attacker awareness while still achieving effective containment.

Process termination stops identified malicious processes, though this action should also be executed carefully to avoid tipping off sophisticated attackers who may have monitoring capabilities in place. Advanced adversaries may implement watchdog processes that respawn terminated malware, and human-operated ransomware groups have been observed accelerating encryption timelines when they detect defensive actions, making subtle containment approaches preferable to aggressive process killing in many scenarios.

The second objective ensures that critical evidence is captured before it disappears or becomes corrupted. This evidence is subsequently used to gain further insight into the attacker’s tactics, techniques, and procedures (TTPs) during the eradicate activity, to help responders understand the attack, and potentially to support future legal action. Organizations should prioritize evidence collection by volatility, collecting the most transient data first.

Memory acquisition captures volatile data that would be lost if systems were powered down or rebooted. Memory dumps preserve information about running processes, host configuration details, network connections, and other artifacts critical for understanding attacker activities. Tools like WinPMEM ^[1] (and the companion Linux memory acquisition tool Linpmem) enable rapid memory capture with minimal system impact, allowing analysts to preserve evidence while maintaining system availability.

Forensic imaging of affected systems preserves the complete state for detailed analysis. While full disk imaging has become less common due to storage costs and time constraints, selective imaging of critical systems or specific directories remains valuable for detailed investigation. Organizations can focus imaging efforts on systems that contain unique evidence, such as the initial point of compromise or systems where attackers deployed custom tools.

Log preservation ensures that evidence of attacker activity isn’t lost to rotation or deletion. This includes not only security logs but also application logs, authentication records, and network flow data that might reveal attack patterns. Forward logs to a centralized, secure location immediately upon discovering a compromise to prevent attackers from deleting or modifying local log files to cover their tracks.

Passive containment focuses on limiting damage without alerting the attacker to defensive actions, allowing organizations to gather intelligence while reducing risk. This approach works best when organizations have strong monitoring capabilities and can afford to accept some continued attacker presence in exchange for a better understanding of the threat.

When it is available to the incident response team, analysts can gain valuable insight by monitoring attacker tactics, techniques, and procedures before implementing containment actions. This insight can reveal additional compromised systems, help responders understand data targeting patterns, and inform comprehensive remediation strategies. For example, monitoring an attacker’s lateral movement attempts reveals which systems they consider high-value targets, informing both immediate containment priorities and long-term security improvements.

Honeypots and deception technologies divert attackers from real assets to decoy systems designed to appear valuable while actually containing no sensitive data. These controlled environments allow observation of attacker techniques while protecting production systems from damage. Organizations can deploy honeypots that closely mirror production systems to attract attacker attention, but mark them clearly in backend systems to distinguish legitimate alerts from deception-based detections.

Active containment takes decisive action to stop attacker activities, accepting that the attacker may become aware of defensive efforts and potentially accelerate their timeline. Organizations choose this approach when the risk of continued attacker access outweighs the intelligence value of observation, or when immediate triggers, such as active data destruction, demand an urgent response.

Network segmentation isolates compromised segments from the rest of the network through multiple technical approaches. This might involve introducing firewall rules or access control lists that block traffic associated with attacker activity, activating pre-configured network segmentation policies to isolate systems, or physically disconnecting network segments when software controls prove insufficient.

System isolation removes specific compromised systems from the network while maintaining forensic integrity and, where possible, management access for investigation. Modern Endpoint Detection and Response (EDR) tools can isolate systems while maintaining forensic connections for investigation, allowing analysts to collect evidence, analyze running processes, and observe attacker behavior without granting attackers network access to other systems. Prefer EDR isolation features over network-based isolation controls when available, allowing responders to continue using EDR solutions to collect evidence while preventing attacker access.

Service disruption disables compromised services or applications to prevent further damage when other containment methods prove insufficient. This might include stopping web services that attackers are using to exfiltrate data, disabling remote access protocols such as Remote Desktop Protocol (RDP) or Secure Shell (SSH) that provide attacker entry points, or shutting down specific business applications that attackers have compromised. Organizations should coordinate service disruption with business stakeholders to understand operational impacts and identify alternative workflows during the containment period.

.When RMM Tools Turn Against You: The Stryker Compromise

Sophisticated incidents may require adaptive containment that evolves based on attacker behavior, adjusting response tactics as the incident unfolds and new intelligence emerges. This approach combines passive and active techniques, transitioning between them based on threat assessment and operational requirements.

Progressive restrictions gradually increase containment measures based on the actions of attackers, allowing organizations to gather intelligence in the early stages while maintaining the ability to escalate to aggressive containment when necessary. Starting with passive monitoring, teams can progressively implement more aggressive containment measures as they understand the threat scope and the attacker’s objectives. For example, analysts might begin by monitoring attacker lateral movement attempts to map target systems, then implement network restrictions that prevent access to high-value targets while preserving attacker access to lower-value decoy or honeypot systems that continue to provide intelligence.

Deceptive containment makes the attacker believe they maintain access while actually operating in a controlled environment, providing the intelligence benefits of passive monitoring while reducing operational risk. This might involve redirecting attacker tools to honeypot systems that appear identical to production systems, providing false data that appears valuable but actually contains no sensitive information, or allowing access to sandboxed environments that prevent real damage.

Certain scenarios demand immediate containment, regardless of incomplete understanding, where the risk of delayed action outweighs the value of additional intelligence gathering or comprehensive scoping.

Active data destruction is the most urgent trigger, in which attackers are actively deleting or encrypting critical data, and leaving no time for intelligence gathering or coordinated response planning. When responders observe ransomware encryption spreading across file shares, attackers wiping event logs to cover their tracks, or database tables being dropped in real time, immediate containment may be the most reasonable action to best meet the organization’s needs. The speed of modern ransomware can encrypt thousands of files per minute, making every second of delay costly in terms of data loss and recovery effort.

Ongoing data exfiltration of sensitive information to external locations demands urgent action, particularly when the data includes intellectual property, customer records, or regulated information that could result in significant financial or reputational damage. Monitor for large data transfers to cloud storage services, suspicious database queries that retrieve thousands of customer records, or the creation and transfer of file archives to external sites.

The volume and sensitivity of exfiltrated data will affect regulatory notification requirements, potential fines, and the organization’s reputation. For example, when observing a compromised service account executing database queries that have retrieved sensitive PII and establishing connections to a suspicious external IP address, organizations will likely transition to immediate containment actions, even if responders haven’t yet identified how the service account was initially compromised.

Threats to critical operations or safety systems will also warrant immediate action to prevent operational disruption or physical harm that could affect services or employee safety. Industrial control systems, medical devices, payment processing infrastructure, and other safety-critical or business-critical systems can rarely tolerate extended compromise time while teams gather intelligence. The operational and safety consequences of delayed response in these environments may outweigh the investigative benefits of continued monitoring.

Regulatory requirements may mandate specific containment timeframes for certain incident types, overriding tactical considerations about optimal response timing. Healthcare data breaches under the Health Insurance Portability and Accountability Act (HIPAA), payment card compromises under the Payment Card Industry Data Security Standard (PCI DSS), and personal data incidents under the General Data Protection Regulation (GDPR) all carry specific notification timelines that effectively require rapid containment to minimize the scope of affected records and demonstrate reasonable response efforts. ^{[5] [6] [7]}

Regulatory frameworks may also define breach severity based on the number of affected individuals and the duration of unauthorized access, creating direct financial incentives for rapid containment. For example, when discovering unauthorized access to a database containing Protected Health Information (PHI), organizations should implement immediate containment within hours rather than days to limit the compliance window and reduce the number of affected patient records requiring notification under HIPAA breach notification rules. Delays could expand both the legal exposure and the population requiring individual notification.

Complex incidents affecting multiple systems require coordinated containment to prevent attackers from maintaining access through overlooked systems or pivoting to alternative infrastructure when they detect partial containment efforts.

Simultaneous isolation of all known compromised systems prevents attackers from pivoting to maintain access through alternative pathways that remain available during otherwise sequential containment actions. When attackers have established a presence on multiple systems, isolating them one at a time alerts the adversary to defensive activities and provides an opportunity to accelerate their timeline, deploy additional persistence mechanisms, or trigger destructive payloads. Coordinate timing and communication across technical teams to ensure comprehensive coverage where network, endpoint, and application teams all execute containment actions within a narrow time window. For example, when responding to a lateral movement incident in which attackers have compromised fifteen workstations across three departments, analysts may simultaneously enable EDR isolation on all affected systems while the network team implements VLAN restrictions and the identity team disables compromised accounts. This coordinated approach prevents attackers from detecting partial containment and moving to systems that remain accessible.

A credential reset is necessary across the entire environment when credential theft is identified. To be effective, the credential reset procedures should be coordinated to avoid creating windows in which attackers maintain access through credentials that have not yet been rotated. Domain-wide credential compromises require rotating passwords for all privileged accounts, service accounts, and potentially all user accounts in a coordinated fashion that minimizes the gap between resets. Plan the sequence of credential resets to prioritize the most privileged accounts first, coordinate with business units to identify appropriate maintenance windows, and communicate clearly with users to prevent legitimate access disruptions.

For example, when investigating a suspected Kerberos Golden Ticket attack, coordinate a comprehensive credential reset: start with the KRBTGT account (twice to invalidate all existing tickets), then all domain administrator accounts, then privileged service accounts, and finally standard user accounts. Implement resets in rapid succession to minimize the window during which attackers can use not-yet-reset credentials to regain access after detecting initial containment efforts.

Infrastructure-wide changes, such as firewall rule updates or network topology modifications, require careful planning and testing to ensure that containment measures don’t inadvertently disrupt business-critical communications or introduce new vulnerabilities in the environment. Large-scale firewall changes can block legitimate business traffic if rules are too broad, while network segmentation modifications might isolate systems needed for critical operations. Test containment changes in non-production environments, when possible, maintain rollback procedures for rapid recovery from unintended impacts, and coordinate with network operations teams who understand traffic dependencies.

Network containment provides broad control over attacker communications through controls that can be implemented quickly to manage large numbers of systems.

VLAN isolation moves compromised systems to isolated network segments with restricted access, effectively quarantining them from the production network. Private VLANs can prevent attackers from continuing to access systems while maintaining necessary management access for incident response activities. Designating a quarantine VLAN, for example, allows responders to configure the minimum access requirements needed to support the investigation effort while denying attackers access to systems.

Firewall rule implementation blocks specific protocols, ports, or destinations used by attackers at network control points. Micro-segmentation using host-based firewalls or software-defined networking provides more granular control over individual system communications when network-wide rules prove too broad. Implement emergency firewall rules that block known command-and-control IP addresses while maintaining business-critical traffic flows, and refine them as analysts gather more intelligence about the attacker’s infrastructure.

Another option is to leverage DNS sinkholes, allowing organizations to redirect attacker-designated hostnames to internal systems. By adding the attacker domains and host names to DNS servers used by impacted systems, organizations can stop command-and-control (C2) access while maintaining visibility into attempted connections (through DNS server logs and DNS-redirected connection logs) that can inform threat intelligence efforts.

In a recent engagement, an attacker deployed C2 malware resolving the name www[dot]thirtjo13ht[dot]top to communicate with their infrastructure. Internal DNS servers typically use recursive resolution to resolve external names, allowing the malware to connect to the attacker’s C2 servers, as shown in Figure 5. By adding the domain thirtjo13ht[dot]top to the internal DNS server, as shown in Figure 6, the incident response team redirected all C2 traffic to an internal quarantine server, preventing the attacker from maintaining control while allowing analysts to observe connection attempts to identify other compromised systems.

While DNS sinkholes are valuable for some scenarios, they have limitations. For example, some attackers will use hardcoded IP addresses or encrypted DNS to bypass DNS-based controls, making sinkholes ineffective. Also, attackers may use a legitimate hosted infrastructure provider name for their malicious web application (such as live-okta-verify[dot]vercel[dot]app), making it impractical to sinkhole a broad service provider domain without disrupting legitimate traffic.

For larger organizations, network route manipulation can redirect entire network ranges to containment infrastructure, enabling enterprise-wide isolation. This advanced technique requires coordination with network engineering teams and careful planning to avoid disrupting legitimate business communications while achieving effective containment of widespread compromises.

.DNS Over HTTPS and Sinkhole Limitations

Host-based containment provides precise control over individual systems through multiple enforcement mechanisms that balance investigation needs with operational security.

EDR isolation features quarantine systems while maintaining forensic access, allowing incident responders to continue evidence collection while preventing attacker communications. Modern EDR platforms can block network access except for management connections, preserving the ability to remotely collect memory dumps, deploy analysis tools, and retrieve forensic artifacts.

Local firewall configuration restricts network access at the host level when EDR capabilities are unavailable. Configure host firewalls to prevent both inbound and outbound connections except for specific management protocols necessary for system administration and forensic investigation. Host-specific firewall tools, including Windows Firewall and Linux Netfilter (managed using iptables), can implement connection restrictions while maintaining access to domain controllers for authentication, DNS servers for name resolution, and incident response systems for remote management.

Process and service restrictions prevent execution of attacker tools while maintaining essential system functionality for business operations. Application control technologies such as Windows AppLocker, macOS Gatekeeper, and Linux AppArmor can block the execution of unauthorized executables, scripts, and libraries based on publisher certificates, file paths, or file hashes.

Application-specific containment addresses compromises within specific services through targeted restrictions that maintain operational capability while limiting attacker access. This approach recognizes that a complete service shutdown often causes unacceptable business impact, requiring more precise intervention that contains the threat posed by the attacker while preserving system functionality.

Web Application Firewalls (WAFs) block malicious requests to compromised web applications while maintaining legitimate access for authorized users. Organizations can introduce application-level containment by deploying WAF rules that detect and prevent several common attack classes. WAF tools might include Software as a Service (SaaS) offering from Cloudflare, for example, or might be locally deployed tools such as ModSecurity rules (for Windows and Linux web servers). WAF services can help limit what attackers can use to attack systems, but should not be relied on as long-term defenses without resolving underlying platform vulnerabilities.

Database access restrictions can limit queries from compromised applications or accounts to prevent data exfiltration while preserving normal business operations. Implement query monitoring that flags unusual patterns, such as large result sets, schema enumeration, or access to sensitive tables outside intended access methods. Database activity monitoring tools, including IBM Security Guardium, can block or quarantine suspicious queries based on data volume thresholds, query complexity, or access patterns that deviate from established baselines. ^[8]

Organizations increasingly deploy AI agents with broad access to internal systems via integration frameworks such as the Model Context Protocol (MCP), enabling automated tools to query databases, access file systems, send messages, and execute code on behalf of users. These integrations create a containment surface that responders should address when compromised accounts have access to AI agent capabilities, or when the agent integrations themselves are exploited through prompt injection or other platform vulnerabilities. Containment actions include disabling AI agent tool access and MCP server connections, revoking the service principals or API keys that grant AI systems access to organizational data, and monitoring AI-generated outputs for signs of data leakage through carefully crafted queries.

Modern containment strategies center on identity as the new security perimeter, recognizing that traditional network boundaries have dissolved in hybrid cloud, remote work, and SaaS-dominated environments. Identity providers (IdPs) now serve as the primary control plane for containment, requiring complex procedures for comprehensive containment, including credential revocation, token invalidation, and session management across distributed platforms.

When addressing identity-based compromises, organizations should systematically implement containment actions to ensure complete coverage across all authentication mechanisms that attackers might leverage to maintain access. Start by invalidating credentials immediately, then address active sessions, and finally implement conditional access policies that prevent re-authentication while the team investigates. In this section, we’ll explore each of these steps in more detail, with actionable recommendations for effective identity containment.

Evidence collection during containment requires prioritization based on volatility and investigative value to ensure critical information is preserved before containment actions modify system state or destroy transient data. Volatile data, including memory dumps, active network connections, and running processes, deserves the highest priority because this information disappears when systems are powered down or rebooted, or through natural attrition over time.

Memory analysis can reveal running malware, decrypted credentials in process memory, and active network connections that might not appear in logs. Capture memory from compromised systems before implementing containment actions that would alter the system state or power cycle the machine. For example, memory acquisition tools like WinPMEM or Linux Memory Extractor (LiME) can acquire a memory dump from the compromised web server before isolating it to a quarantine VLAN, preserving evidence of the web shell’s in-memory configuration and active command-and-control sessions that won’t survive a network disconnect.

System artifacts, including registry hives, event logs, and temporary files, provide insight into attacker activities and persistence mechanisms with less time sensitivity than volatile data. These artifacts offer a more permanent record of compromise that can survive system restarts and most containment actions, though some data, such as certain cache files or temporary directories, may be cleared during normal system operations. Collect Windows registry hives to identify persistence mechanisms, event logs to establish timeline data, and browser cache to reveal attacker reconnaissance activities. Prefetch files, ShimCache entries, and AmCache records provide execution history that helps reconstruct the use of the attacker’s tools even after the malicious files are deleted.

Network evidence, including packet captures, NetFlow data, and firewall logs, reveals communication patterns and data movement across the environment. This evidence helps analysts understand the scope of data exfiltration, identify command-and-control infrastructure, and discover additional compromised systems based on lateral movement patterns. Full packet captures provide the most detail but consume significant storage, while Network Flow logs (including NetFlow logs, VPC Flow Logs, and similar log types) offer a lighter-weight alternative that still reveals connection patterns, data volume transferred, and communication timing details.

Application data, including web server logs, database transaction logs, and application-specific artifacts, can also provide useful insights for the investigation. While network evidence shows communication patterns, application logs provide context on which data attackers accessed, modified, or exfiltrated. This evidence provides crucial information for impact assessment, regulatory notification requirements, and understanding attacker objectives.

Cloud service containment requires understanding the shared responsibility model that defines security boundaries between cloud service providers and customer organizations. For Infrastructure as a Service (IaaS) cloud services, providers typically manage infrastructure security, including physical hardware, hypervisor security, and network infrastructure protection, while customers remain responsible for identity and access management, data encryption, application security, and operating system patching. By contrast, Software as a Service (SaaS) providers manage nearly all infrastructure and application security, leaving customers responsible primarily for identity management, data access authorization, and user access controls. Platform as a Service (PaaS) offerings fall somewhere between the two, with providers managing the underlying platform security while customers handle application-level security and data protection.

The division of responsibilities between what the cloud customer and what the cloud provider are responsible for is known as the cloud security demarcation. This separation of responsibilities determines which containment actions the cloud customer can implement directly and which require escalation to the cloud provider’s support teams.

For example, if attackers exploit a vulnerability in the underlying hypervisor or physical network infrastructure, the cloud customer likely cannot directly contain the threat and needs to engage the cloud provider’s security team, while compromised Identity and Access Management (IAM) credentials or misconfigured user account access are within the cloud customer’s containment authority. Understanding this demarcation before incidents occur enables faster, more effective containment by clarifying which team controls each potential containment mechanism. A summary of common cloud security demarcation responsibilities is shown in Figure 9.

.Cloud Service and Responsibility Definitions

The core containment objectives for cloud systems mirror traditional incident response goals: isolate the compromised resource to prevent further malicious activity, collect evidence for investigation and threat intelligence, and preserve forensic data for recovery and remediation activities. Cloud platforms provide several native features that facilitate these objectives, including flexible tagging systems to mark resources as under investigation, snapshot capabilities to capture system state, and termination protection mechanisms to prevent accidental destruction of evidence. Teams should leverage these cloud-native features rather than attempting to replicate on-premises containment procedures that may not translate effectively to cloud environments.

Identity-first containment takes priority in cloud environments because credentials represent the most common persistence and lateral movement mechanism for cloud-focused attackers. Compromised IAM user access keys, service account keys, OAuth tokens, and refresh tokens provide attackers with persistent access that survives traditional network-based containment measures. Disable compromised access keys immediately to prevent their use for API calls or console access; terminate active user sessions across all applications; revoke OAuth refresh tokens that could generate new access tokens; and rotate service principal credentials used by automated systems. Consider the operational impact of identity-based containment on downstream automation and business processes that depend on the affected credentials.

For example, when rotating a compromised service account key that authenticates a critical data processing pipeline, coordinate with application teams to update the credential in all systems that use it, implement the rotation during a maintenance window if possible, and have rollback procedures ready in case the credential update causes unexpected failures. Document which applications and automation workflows use each privileged identity before incidents occur, enabling rapid assessment of containment impact when those identities are compromised.

Network isolation in cloud IaaS environments is implemented through multiple complementary controls that prevent further compromise while preserving evidence for investigation. Remove compromised instances from production scaling groups and load balancers to prevent them from receiving user traffic while keeping the instances running for forensic analysis. Modify security group rules, network Access Control Lists (ACLs), or move the instance to a pre-configured isolation Virtual Private Cloud (VPC) dedicated to incident response activities, where the team controls all network ingress and egress. Enable termination protection and deletion protection on compromised resources to prevent accidental or malicious destruction by other administrators who might not be aware of the ongoing investigation.

Consider using cloud provider snapshot features to create point-in-time copies of storage volumes and virtual machine states. These features make it straightforward to preserve the compromised system’s exact configuration for detailed forensic analysis while the team continues containment activities. Always consider the cost-benefit analysis of snapshot storage costs versus the investigative value of preserving the system state, especially for large-scale incidents involving many compromised resources.

Cloud platforms provide robust resource tagging capabilities that facilitate clear identification of compromised assets during containment and throughout the investigation lifecycle. These metadata tags serve multiple purposes: they clearly mark resources as under investigation to prevent accidental modification or deletion, enable automated policy enforcement through tag-based access controls, and provide audit trails for compliance and post-incident review.

Establish consistent tagging conventions before incidents occur to ensure all team members apply tags uniformly during high-pressure containment activities. Common tagging schemes include status indicators (IncidentResponse:Active, Status:Quarantined), case identifiers (IR-Ticket:INC-2025-1234, IR-Case:2026-001), containment dates (ContainedDate:2025-10-27), and analyst assignments (IR-Owner:jsmith@company.com). Multiple tags can be applied to a single resource to provide comprehensive context, and tags can be updated as the incident progresses through different phases.

Resource tags enable practical operational benefits during containment activities. Use tags to create filtered views in cloud consoles that show only compromised resources; configure automated alerts when tagged resources are accessed or modified; implement tag-based access controls that restrict who can start or terminate quarantined instances; and generate reports for management on containment status across the environment. Some organizations implement automation that prevents deletion of resources tagged with incident response markers until the case is formally closed and documented.

For example, when containing a suspected compromised EC2 instance in AWS, apply multiple resource tags to provide comprehensive tracking: Status:UnderInvestigation to indicate active IR activities, IR-Case:2026-001 to link to the ticketing system, ContainedBy:security-team to identify the responsible team, ContainedDate:2025-10-27 for timeline reconstruction, and EvidencePreserved:Yes to confirm snapshots were captured. Configure AWS Resource Groups to dynamically collect all resources tagged with Status:UnderInvestigation, providing a single dashboard view of all contained assets across the AWS environment. Implement IAM policies that prevent anyone except incident responders from terminating instances tagged with Status:UnderInvestigation, protecting evidence from accidental destruction during investigation.

Cloud provider tagging capabilities extend beyond compute instances to storage volumes, network interfaces, load balancers, and even snapshots themselves, enabling comprehensive tracking of all resources related to an incident. Apply consistent tags to snapshots created during containment to link them back to the original incident case number and establish a clear chain of custody for forensic evidence. Tag network security groups or firewall rules created specifically for containment purposes with descriptive labels like IR-Purpose:Quarantine and IR-Case:2026-001, facilitating cleanup after incident resolution and preventing these temporary configurations from lingering indefinitely in production environments.

Enabling termination protection on contained IaaS cloud resources prevents accidental deletion of critical evidence during investigation, creating a safety mechanism that requires explicit two-step confirmation before anyone can destroy potentially valuable forensic data. Cloud administrators and automation systems often have the ability to terminate instances as part of routine operations, creating a risk that someone unfamiliar with the ongoing investigation might delete a contained system, thinking it’s simply unused or misconfigured. Termination protection is a technical control that enforces evidence preservation via the cloud provider’s API, requiring authorized personnel to first disable protection before terminating the resource.

For example, when a compromised EC2 instance in AWS is detected, enable termination protection immediately via the AWS console or CLI to prevent any user or automation from deleting the instance until protection is explicitly removed, as shown in Listing 5. This protection persists even if someone has IAM permissions that would normally allow instance termination, providing defense against both accidental deletion by administrators and intentional deletion by attackers who might have compromised cloud credentials. Azure provides similar capabilities through deletion locks that prevent resource deletion until the lock is removed, while Google Cloud Platform offers Compute Engine instance deletion protection that can be enabled during containment operations.

Table 3 provides equivalent commands for enabling termination or deletion protection across cloud providers.

Termination protection extends beyond compute instances to other critical resources, including Elastic Block Storage (EBS) volumes, snapshots, databases, and network configurations that contain evidence or support ongoing investigation. Apply protection to EBS volumes attached to contained instances to prevent their deletion even if the instance itself is somehow terminated, and enable snapshot protection to preserve exact copies of compromised systems throughout the investigation. Document which resources have termination protection enabled in incident tracking systems, establishing clear procedures for removing protection only after formal evidence preservation is complete and legal hold requirements are satisfied.

SaaS platform containment differs fundamentally from IaaS containment because organizations lack direct access to the underlying systems and can only leverage containment capabilities exposed by the SaaS provider through its administrative interfaces. While IaaS environments grant organizations control over virtual machines, network configurations, and security groups, enabling teams to implement custom containment measures, SaaS platforms provide only the containment features built into their administrative consoles and APIs. This limitation requires adapting containment strategies to work within provider-defined boundaries, often accepting less granular control than organizations would have in self-managed infrastructure.

Identity and session containment take the highest priority in SaaS environments, where organizations cannot directly access or isolate the underlying infrastructure. Reset passwords for compromised user accounts immediately to invalidate current credentials, or set temporary random passwords that prevent both attackers and legitimate users from accessing the account until the team completes the investigation. Revoke all active sessions and refresh tokens to force re-authentication, ensuring that password resets actually terminate attacker access rather than leaving active sessions that survive credential changes. For service principals and application accounts, rotate API keys, client secrets, and OAuth credentials that authenticate automated integrations and workflows.

Consider whether to disable accounts entirely or use platform-specific freeze features that preserve data while blocking sign-in, choosing based on whether the team needs to maintain access to the account’s data for investigation or can afford a complete lockout. For example, when containing a compromised Microsoft 365 administrator account, immediately reset the password through the Microsoft 365 admin center, use the revoke sessions feature to invalidate all active authentication tokens forcing the user to re-authenticate everywhere, disable the account to prevent any sign-in attempts, and rotate the credentials for any service principals or application registrations that the administrator may have created, documenting each action with timestamps for incident timeline reconstruction.

Integration and automation containment prevent compromised accounts from maintaining persistent access through third-party applications and automated workflows that often survive credential resets. Disable third-party applications that the compromised account authorized, including OAuth-connected apps, browser extensions, and mobile applications that maintain their own authentication tokens. Review and disable automation rules in platforms that could exfiltrate data or perform unauthorized actions using the compromised account’s permissions. Revoke outgoing webhooks that may send sensitive data to attacker-controlled endpoints, disable Continuous Integration/Continuous Deployment (CI/CD) deployment keys that could allow code injection into production systems, and invalidate API tokens used to authenticate programmatic access to the SaaS platform.

After containment, replace integration credentials with new secrets and re-authorize only legitimate integrations after verifying their configuration. For example, when investigating a compromised Slack workspace administrator account, audit the workspace’s installed apps and custom integrations, and disable any unfamiliar OAuth applications (especially those requesting broad permissions, such as read all messages or access all channels). Remove webhook configurations that send data to external URLs not expressly authorized by the organization. Revoke any API tokens created by the compromised account, and review bot users for unauthorized automation that might persist after the human account is disabled.

Cloud infrastructure requires fundamentally different containment approaches that leverage cloud-native controls and account for the ephemeral nature of cloud resources, where traditional network-based isolation may be impossible or ineffective.

API-based isolation using cloud provider APIs to modify security groups, network ACLs, or IAM policies provides rapid, programmatic containment that can be automated and applied at scale. Use AWS Security Groups to block all inbound and outbound traffic to a compromised EC2 instance, Azure Network Security Groups (NSGs) to quarantine virtual machines, or Google Cloud Platform (GCP) firewall rules to isolate compute instances. This approach enables containment through infrastructure-as-code tools like Terraform or CloudFormation, allowing teams to version control containment procedures and execute them consistently across hundreds of cloud resources. For example, use the Azure CLI to create a quarantine NSG and attach it to a compromised virtual machine’s network interface, denying all traffic except SSH access from a specific jump box IP address. This quarantines the instance while maintaining incident response access for investigation, as shown in Listing 7.

Serverless containment addresses unique challenges posed by compromised Lambda functions, container instances, or other serverless compute resources that lack traditional network presence or persistent state. Serverless functions execute on demand in isolated runtime environments, making traditional network isolation ineffective because the next function invocation may run on completely different infrastructure. Instead, disable event triggers that invoke the compromised function where possible. Preserve the serverless function’s code, replacing it with code that returns an access denied response and logs access attempts for further data collection. We include a Node.js example for AWS Lambda in Listing 8 and example deployment instructions in Listing 9.

Multi-cloud coordination becomes critical when incidents span multiple cloud providers with different containment capabilities, API interfaces, and security models. Each cloud provider offers distinct isolation mechanisms with varying capabilities, where AWS security groups operate differently from Azure NSGs or GCP firewall rules, requiring incident responders to understand the differences and adapt containment strategies to platform-specific features.

Pervasive network encryption complicates traditional containment strategies by obscuring attacker activity. While widespread network cryptography has significantly improved the overall security of modern systems, it has also created new opportunities for threat actors to use encryption as an evasion technique to bypass network-based detection and containment controls.

Transport Layer Security (TLS) interception is particularly valuable to organizations, enabling analysts to inspect encrypted communications from attackers during active incidents. Where possible, organizations should implement TLS inspection proxies that decrypt, inspect, and re-encrypt traffic using trusted certificates deployed to managed endpoints. Once deployed, restrict egress network access via TLS to only those proxies, ensuring that all encrypted traffic passes through inspection points. Log and investigate any TLS connections that attempt to bypass the interception proxies, as they may represent attempts by attackers to evade analysis.

Distributed workforces create unique containment challenges that extend organizational security boundaries far beyond traditional corporate networks into uncontrolled home networks, personal devices, and diverse geographic locations.

Network visibility limitations arise when remote devices operate on home networks outside organizational control, preventing traditional network-based containment and monitoring techniques. Organizations lack visibility into the network infrastructure between remote devices and the internet, cannot control which devices connect to the same home network, and cannot implement network-based isolation when those home routers are owned by internet service providers or employees.

For remote work environments, organizations should shift containment strategies toward endpoint-focused controls rather than network-based approaches. This is often implemented using EDR isolation features to quarantine remote devices while preserving the communication channel required for incident response.

Personal device contamination requires containment strategies that distinguish between corporate and personal data while respecting employee privacy boundaries and legal restrictions. Many organizations permit or require employees to use personal devices for work through Bring Your Own Device (BYOD) programs, creating scenarios in which containment actions might affect personal device use. For BYOD programs, organizations should implement Mobile Device Management (MDM) or Mobile Application Management (MAM) solutions that can selectively manage and eliminate corporate data, revoke access to company resources, or isolate business applications without affecting personal information. Document clear policies about the extent of organizational control over personal devices and ensure employees understand containment capabilities before incidents occur.

Home network compromise scenarios present complex ethical and legal considerations when attackers pivot from compromised corporate devices to family systems owned by non-employees. Attackers who compromise a corporate laptop on a home network might scan for other devices, such as personal computers, smart home systems, or family members' devices, creating potential liability and notification obligations when employee family members become collateral victims. Organizations should determine in advance which notifications they will provide to employees about home network risks, what assistance they will offer to help secure personal systems, and what coordination may be necessary with employees' households during containment activities. These decisions require legal review and clear communication with employees before incidents occur.

VPN tunnel isolation prevents lateral movement while maintaining business continuity for legitimate remote workers when responders suspect compromise but cannot immediately disable all remote access. Implement granular access controls that distinguish between compromised and clean remote sessions, allowing legitimate remote workers to continue accessing necessary resources while containing suspected compromises. Configure VPN concentrators to support user- or device-specific access policies that restrict network access for individual remote sessions without affecting all remote workers. For example, to contain a system under investigation, modify the VPN access control list to restrict the compromised employee’s VPN session to only access email and the help desk ticketing system, preventing lateral movement to file shares and internal applications while allowing the employee to report issues and receive guidance.

Cloud service dependencies challenge traditional containment when remote workers rely heavily on SaaS applications that may lack granular isolation capabilities and operate outside organizational network perimeters. Remote workers often access most applications directly over the internet, bypassing corporate networks and VPN connections, making network-based containment impractical. Instead, leverage identity-based controls and conditional access policies to contain compromised credentials, restrict access based on device compliance, or force re-authentication to interrupt active sessions. Document the containment capabilities of critical SaaS applications during planning activities, identifying which services support granular session termination, per-user restrictions, or conditional access policies that can be applied by the incident response team.

Physical device recovery presents logistical challenges when compromised systems reside in employee homes across different cities, states, or countries rather than being physically accessible in corporate facilities. Coordinate with employees to retrieve devices through secure shipping arrangements, schedule on-site visits where warranted by incident severity, or implement remote wiping capabilities that preserve business continuity but may destroy forensic evidence. Balance the investigative value of forensic evidence against the business impact of device unavailability and the logistical complexity of physical recovery across distributed locations. For example, for a suspected malware infection on a remote sales representative’s laptop in another state, consider shipping a pre-configured replacement laptop overnight while arranging return shipping for the compromised device with instructions to power it down until the shipping container arrives, avoiding the expense and delay of sending forensic specialists on-site for a routine malware case.

Traditional incident response focuses heavily on compromised endpoints and servers, but modern organizations face increasingly complex incidents that don’t fit the attacker-on-a-host model, where responders can simply isolate infected systems from the network. These scenarios require fundamentally different containment approaches that often prioritize service disruption, data flow control, and third-party coordination over traditional network isolation.

Sarah, the incident response team lead for a Kubernetes managed service provider, had been working on an incident that impacted multiple customers in AWS. An AWS GuardDuty alert flagged unusual API activity from an unfamiliar IP address, which the team traced to AWS credentials in a read-only Kubernetes dashboard that was (unfortunately) exposed to the internet. The dashboard used a service account with read permissions to cluster-wide secrets. Kubernetes (K8s) audit logs showed that the attacker used dashboard access to list secrets across three customer namespaces: TechFlow Solutions, Meridian Financial, and Cascade Logistics.

CloudTrail logs confirmed that the attacker had only used credentials from TechFlow’s namespace to launch two EC2 instances in the TechFlow AWS account. However, because the K8s audit logs showed the attacker had viewed secrets for all three customers, Sarah got approval to implement simultaneous coordinated containment across all three customer AWS accounts to prevent the attacker from pivoting to the other exposed credentials.

A different team had already taken steps to remedy the Kubernetes dashboard exposure. Sarah’s role was to prevent unauthorized access to the customer’s AWS accounts. She began containment by disabling the exposed AWS access keys across all three customer accounts. For TechFlow Solutions, she disabled the access key the attacker had been actively using, as shown in Listing 10.

Sarah repeated the same credential-disabling process for the Meridian Financial and Cascade Logistics accounts, even though CloudTrail showed no evidence of attacker activity in those environments. This precautionary containment prevented the attacker from using any credentials disclosed through the K8s dashboard.

Next, Sarah isolated the two EC2 instances launched by the attacker in the TechFlow account. She applied resource tags to mark them as under investigation, enabled termination protection to prevent accidental deletion, and created EBS snapshots for forensic analysis, as shown in Listing 11.

Next, she modified the security groups attached to both compromised instances to quarantine them while maintaining SSH access for investigation, as shown in Listing 12.

With the AWS resources contained, Sarah addressed the Kubernetes platform compromise. Rather than deleting the overprivileged service account (which would destroy evidence), she disabled it by removing its Role-Based Access Control (RBAC) bindings, as shown in Listing 13.

To validate containment effectiveness, Sarah continued to monitor CloudTrail, confirming no new API activity from the disabled access keys. K8s audit logs showed no new dashboard access attempts, and the quarantined security groups prevented all outbound connections from the compromised EC2 instances. She configured CloudWatch alarms to alert if disabled access keys were reactivated or if new access keys were created for the compromised service accounts.

Sarah documented the containment actions for incident tracking and customer notification:

The multitenancy containment approach ensured that all potentially exposed credentials were invalidated simultaneously, preventing the attacker from pivoting to other customer environments after detecting defensive actions in the confirmed compromise.

Marcus Chen, a senior support desk analyst at Vanguard Point Advisors, a mid-size financial services firm, received an urgent call from Robert Dackinson in the accounting department. Robert reported that several spreadsheets had become corrupted with unusual file extensions, and he found a text file on his desktop titled README_RANSOM.txt. Marcus recognized the indicators immediately and escalated the ticket to Priority 1, in accordance with the organization’s ransomware response playbook.

The playbook’s first step required immediate EDR isolation to prevent further access to company systems. Marcus opened CrowdStrike Falcon and searched for Robert’s workstation using the company’s standard naming convention. The search returned Robert’s system RD-LAPTOP-278 as shown in Figure 14.

Marcus selected the device and initiated network containment through Falcon’s isolation feature, as shown in Figure 15 and Figure 16. This action immediately blocked all network communication from Robert’s laptop except for the encrypted management channel that Falcon uses to maintain remote access for investigation. This step prevented the ransomware from spreading to network file shares or attempting other lateral movement while preserving the ability to collect forensic evidence remotely.

After several seconds, Marcus validated the containment action by inspecting the status of Robert’s workstation. CrowdStrike indicated that the isolation command had been successfully applied with the status label "Update network containment status", as shown in Figure 17. Marcus updated the incident ticket to capture the containment time for later timeline reconstruction.

With the system successfully quarantined, Marcus continued to follow the playbook’s identity-containment steps. He accessed the organization’s Okta identity platform and temporarily disabled Robert’s account to prevent the ransomware from using any cached credentials to access cloud applications or network resources. Marcus then revoked all active sessions and refresh tokens for Robert’s account across all connected applications.

Marcus documented all containment actions in the incident ticket, with precise timestamps, as shown in Table 7.

The rapid containment prevented the ransomware from spreading beyond Robert’s workstation. Later investigation revealed that the ransomware had successfully encrypted 247 local files but had been isolated before it could access network file shares that contained critical financial data. The coordinated EDR and identity containment approach, executed in under ten minutes from initial report, demonstrated the value of well-documented playbooks and modern containment tools for ransomware response.