Incident Response practice questions

Terminate the EC2 instance immediately to stop the malicious traffic.

Why wrong: Termination causes the loss of all volatile memory and data stored in ephemeral storage, which is critical for identifying the C2 agent's behavior. Proper incident response requires imaging or isolating the instance while keeping it running or at least preserved on storage to allow for deep forensic analysis.

Reboot the instance to clear any malicious processes running in the background.

Why wrong: Rebooting clears the contents of the volatile memory (RAM), where many sophisticated malware variants reside. Any process data, network connections, or injected code stored in memory will be lost upon reboot, significantly hindering the ability to perform accurate memory forensics and identify the root cause of the compromise.

Delete all snapshots to prevent the attacker from accessing them.

Why wrong: Deleting snapshots serves no security purpose and actually destroys evidence that would be used to reconstruct the attack. Security teams need these snapshots to analyze what files were created or modified by the attacker, and deleting them would be a direct violation of standard incident response best practices.

AWS Glue

Why wrong: AWS Glue is a serverless data integration service used for ETL operations and data preparation for analytics. It is not designed for real-time threat detection or automated incident response and does not provide the security-focused alerting or remediation capabilities needed to handle unauthorized IAM credential usage.

AWS Direct Connect

Why wrong: Direct Connect provides a dedicated network connection between an on-premises data center and AWS. It is a networking service and has no role in the detection, investigation, or containment of security incidents related to IAM credentials or general cloud platform security monitoring.

AWS CloudTrail Management Events

Why wrong: Management events show operations performed on the S3 bucket itself, such as creating or deleting the bucket. They do not log individual object access like GetObject or PutObject, meaning they are insufficient for identifying which specific files an attacker accessed during a data breach incident.

VPC Flow Logs for the S3 interface endpoint

Why wrong: VPC Flow Logs capture network-level metadata like IP addresses and port numbers for traffic to and from network interfaces. While useful for seeing network connections, they do not provide the API-level context needed to identify which specific IAM identity performed an S3 action or which object was accessed.

AWS Config compliance history

Why wrong: AWS Config tracks resource configuration changes over time, such as whether a bucket is public or encrypted. It does not log activity or access events, so it cannot be used to identify who accessed specific objects or to reconstruct the actions taken by an attacker during a breach.

Delete all IAM users and recreate them with complex passwords.

Why wrong: This is a reactive and disruptive measure that does not address the underlying cause of the vulnerability. Unless the root cause was weak password management, simply rotating credentials will not prevent a repeat incident, and it ignores the need for systemic architectural hardening or policy improvements.

Increase the logging level for all services to capture more data.

Why wrong: While increasing logging improves future visibility, it does not prevent the vulnerability from being exploited again. It adds cost and operational overhead without directly mitigating the root cause of the unauthorized access, which is the key objective of the post-incident improvement process for long-term security.

Provide additional training to all employees on phishing prevention.

Why wrong: While training is helpful, it is not a technical control that mitigates systemic cloud security vulnerabilities. If the incident was caused by a misconfigured S3 bucket or overly permissive IAM policy, training users will not fix the infrastructure, leaving the door open for future attacks.

No user, including the root user, can delete the bucket.

Why wrong: The explicit Deny on the 's3:DeleteBucket' action for all principals prevents any user from deleting the bucket. This is the intended behavior of such a policy, which serves as a 'guardrail' to prevent accidental data loss, demonstrating the strength of resource-based policies in AWS.

The policy is invalid because a Deny statement requires an explicit Condition block.

Why wrong: A Deny statement is perfectly valid without a Condition block. Applying a global Deny to all principals is a common, though highly restrictive, technique used to ensure that specific sensitive operations cannot be performed by anyone, regardless of their IAM permissions or administrative status in the account.

Users can still delete the bucket if they have an Allow policy in their IAM user.

Why wrong: AWS policy evaluation logic dictates that an explicit Deny always takes precedence over an Allow. Even if an IAM user has full administrative rights with an explicit Allow for all actions, the bucket policy's Deny will override those permissions, successfully blocking the deletion operation.

Terminate all EC2 instances attached to the role.

Why wrong: Terminating instances is a destructive and likely unnecessary action that causes significant downtime. The persistence is in the IAM role configuration, not the instance itself, so terminating instances does not remove the attacker's ability to use the modified role from other locations or through other services.

Delete the IAM role and recreate it with the original permissions.

Why wrong: Deleting a role is disruptive to all services that rely on it, potentially causing widespread outages. Reverting the policy to a known-good state via version control or IAM history is a safer, cleaner approach that maintains continuity while effectively removing the attacker's added permissions.

Enable Multi-Factor Authentication (MFA) for the IAM role.

Why wrong: MFA is not natively supported for IAM roles in the way it is for IAM users. Roles are assumed, not logged into directly, so enabling MFA here is not a valid remediation step for an already-compromised role that an attacker is currently using to maintain persistence in the environment.

Storing logs in an S3 bucket with public access enabled.

Why wrong: Public access to log files is a major security risk, allowing attackers to read or potentially delete the logs. Integrity must be protected by restricting access to the bucket to only the necessary security and audit roles, rather than exposing it to the public for any reason.

Encrypting the S3 bucket with a default AWS-managed KMS key.

Why wrong: While encryption is a best practice, it protects data at rest but does not guarantee the integrity of the log files against tampering or deletion. An attacker with sufficient privileges could still modify or delete logs unless additional controls like object locking or integrity validation are also implemented.

Using an S3 bucket in a different region than the logs.

Why wrong: Storing logs in a different region can improve availability, but it does not prevent log tampering. If an attacker has permissions, they can still access logs in a different region. Integrity validation is specifically designed to detect tampering, which is a more effective control than simple cross-region replication.

Increase the password complexity requirements for all users.

Why wrong: While improving password policies is a good long-term security practice, it does not stop the current brute-force attack. The attacker is already attempting to guess the current password, and changing the policy does nothing to halt the ongoing malicious requests targeting the current, already-vulnerable credentials.

Configure a CloudWatch alarm to notify the security team.

Why wrong: An alarm is a monitoring tool, not a containment action. It alerts the team that an attack is occurring, but it does not stop the attack. In an incident response scenario, active containment (like disabling the user) must be prioritized over passive alerting to prevent successful unauthorized access.

Delete the IAM group the user belongs to.

Why wrong: Deleting the group is an overly broad action that causes unnecessary disruption for other users in the same group. It is not an effective containment strategy because it does not stop the brute-force attack against the specific user, and it fails to address the root cause of the incident.

Notify the media about the incident to maintain transparency.

Why wrong: While transparency is important, external notification is a business and legal decision, not a technical post-incident review action. Focusing on technical improvements to the AWS environment is the purpose of the PIR, whereas media relations are handled by communications teams and legal counsel.

Rotate all root account passwords for all AWS accounts.

Why wrong: Root account credentials should rarely be used, and rotating them is standard practice but not a specific finding from a PIR. Focusing on the technical root cause of the incident is more valuable than routine maintenance tasks, which do not address the specific vulnerabilities identified during the review.

AWS Config timeline view

Why wrong: AWS Config tracks configuration changes, not access activity. It will tell you if the IAM role policy was modified, but it will not show you the actual API calls made by the role to other resources, making it ineffective for identifying which resources were accessed by an attacker.

Amazon GuardDuty summary page

Why wrong: GuardDuty alerts on suspicious activity, but it doesn't provide a list of all resources accessed by a specific IAM role. It is a detection tool, not a resource-access auditing tool, and it is intended to flag anomalies rather than provide a detailed history of legitimate vs. illegitimate resource usage.

AWS Trusted Advisor

Why wrong: Trusted Advisor provides recommendations for cost optimization, performance, and security best practices. It does not track user or role activity, and it cannot be used to audit what resources have been accessed, as it is designed for general environment health rather than forensic or incident-related activity analysis.

Delete the IAM user and recreate it with identical permissions once the incident has been successfully resolved and validated.

Why wrong: Deleting the user removes access keys and credentials but can disrupt application dependencies or leave orphaned resources behind. It is generally safer and cleaner to lock down the existing identity via explicit policies and credential rotation.

Modify the IAM user's assigned group memberships to remove administrative privileges without altering direct inline policies.

Why wrong: Modifying group memberships fails to address permissions granted directly via inline policies or attached managed policies. Attackers may still retain privileges through alternative permission pathways if direct access controls are not fully neutralized.

Enable AWS CloudTrail Lake event data stores to capture future API activities originating from the compromised principal.

Why wrong: While CloudTrail Lake is valuable for auditing and threat hunting, enabling it is an investigative enhancement rather than an active mitigation step. It does not actively revoke active sessions or prevent ongoing unauthorized resource access.

AdministratorAccess policies override bucket policy Deny statements.

Why wrong: In AWS, an explicit Deny in any policy always takes precedence over any Allow, including those provided by the AdministratorAccess managed policy. If the user is successfully accessing the bucket, it means the Deny statement is not being evaluated or is not matching the specific request context.

The request is coming from an AWS service, which ignores the Deny policy.

Why wrong: Some AWS services access S3 buckets using internal service-linked roles that might not be evaluated against source IP conditions in the same way as standard IAM users. If the administrator is using an AWS-managed service to access the data, the source IP condition may not apply as expected.

The Condition block only applies to the root user.

Why wrong: Condition blocks in IAM and bucket policies apply to the identity making the request, regardless of whether it is an IAM user, role, or the root user. The restriction applies to the request context, and AdministratorAccess does not exempt a principal from being subject to bucket policy restrictions.

Create a cross-account IAM role in the backup account and share the credentials.

Why wrong: Sharing static credentials is a significant security risk and violates best practices. Credentials can be leaked or intercepted, providing an attacker with persistent access to the backup account, potentially allowing them to encrypt or delete the backups, which would render the recovery process impossible.

Enable public read access on the backup bucket during the recovery process.

Why wrong: Enabling public read access is extremely dangerous, as it exposes the company's backups to the entire internet. An attacker could potentially download the company's sensitive data, leading to a massive data breach on top of the existing ransomware incident that triggered the recovery process.

Merge the production and backup accounts into a single account.

Why wrong: Merging accounts is a complex and disruptive administrative task that does not improve security. In fact, it increases the blast radius of a potential compromise by placing production and backup resources in the same security boundary, which is the opposite of the intended recovery isolation strategy.

Update the security group of the instance to block all egress traffic.

Why wrong: While blocking egress is useful to stop C2 communication, it does not revoke the stolen credentials that the attacker is already using. The attacker could have already saved these credentials to an external machine, meaning they could continue to perform API calls even if the instance is blocked.

Delete the IAM user associated with the instance role.

Why wrong: Roles cannot be 'deleted' in the same way as IAM users, and deleting the IAM role would break the application functionality completely. This is a destructive action that does not specifically address the stolen temporary credentials currently being used by the attacker from a remote location.

Disable the GuardDuty service to stop the alerts.

Why wrong: Disabling the alerting service is a dangerous practice that blinds the security team to ongoing malicious activity. It does not remediate the underlying issue of the stolen credentials and would prevent the team from observing further attempts by the attacker to move laterally in the account.

VPC Flow Logs

Why wrong: VPC Flow Logs capture metadata about network traffic (5-tuple data) but do not capture the payload of the packets. While they help identify potential C2 traffic by looking at IP and port destinations, they cannot confirm botnet behavior through packet-level analysis or command inspection.

AWS CloudTrail

Why wrong: CloudTrail records AWS API calls, which reflect administrative actions and configuration changes. It does not have visibility into the network traffic flowing to or from an EC2 instance, making it incapable of detecting botnet communication patterns occurring at the network layer.

Amazon Inspector

Why wrong: Amazon Inspector is primarily used for identifying software vulnerabilities and unintended network exposure on EC2 instances. It is a proactive security tool rather than a reactive network forensic tool designed to analyze ongoing malicious communication or botnet traffic patterns during an active incident investigation.

Write a local Bash script and run it from your laptop.

Why wrong: Running scripts from a local machine is risky, as it creates a single point of failure and lacks the necessary auditing. Furthermore, managing credentials for 500 accounts locally is insecure and inefficient, making it nearly impossible to ensure consistent execution or handle errors gracefully across all accounts.

Use an S3 bucket to share a list of compromised keys.

Why wrong: This is an insecure mechanism that involves manually or programmatically updating and reading from a central repository. It does not provide the orchestration logic needed to actually perform the rotation or deletion across the accounts, nor does it provide a clean audit trail of the remediation status.

Use CloudWatch Events to trigger Lambda functions in every account.

Why wrong: While this is possible, it is significantly harder to manage at scale compared to Systems Manager Automation. Coordinating 500 separate Lambda deployments and ensuring they remain consistent is complex, and it lacks the centralized state management and reporting features that are built into Systems Manager.

Delete the S3 bucket to prevent further unauthorized data access.

Why wrong: Deleting the bucket destroys potential forensic evidence and logs required to understand the scope of the breach. Incident response protocols dictate that resources should be isolated and preserved for investigation rather than destroyed, as data recovery or root cause analysis would be impossible without the original environment state.

Disable AWS CloudTrail logging to stop generating potentially malicious log entries.

Why wrong: Disabling CloudTrail hides the attacker's actions and prevents investigators from tracking subsequent lateral movement or persistence mechanisms. Maintaining visibility is critical during an active incident, and stopping logs would prevent security teams from reconstructing the attack timeline and identifying exactly which objects were accessed during the breach.

Revoke all IAM user credentials globally to lock down the entire AWS account.

Why wrong: Revoking all credentials globally is an overly broad response that causes massive business disruption beyond the scope of the incident. It would halt all legitimate operations and potentially trigger automated service failures across the account, whereas the incident is specifically identified to be isolated to a single bucket.

The bucket policy must include a Principal element to restrict access to specific identities.

Why wrong: While a Principal element is standard for bucket policies, the issue here relates to the evaluation logic of Allow vs. Deny. Even if a Principal was specified, the lack of an explicit Deny means that other authorized IAM users could still access the bucket outside the provided IP range.

The S3 bucket is configured with a public access block that is too permissive.

Why wrong: Public Access Block settings are designed to prevent public access, but they do not override the logic of bucket policies regarding authenticated access. The bypass is caused by the interaction between the resource policy and the identity-based policy, not by the public access block configuration of the bucket.

The 'aws:SourceIp' condition does not function for requests made through an AWS service like CloudFront.

Why wrong: While it is true that SourceIp can behave differently with proxies or CloudFront, the fundamental issue is the policy's structure. Regardless of the IP source, the absence of a Deny statement means that any user with existing IAM permissions remains authorized to access the bucket's content.

Attempt to brute-force the ransomware decryption key using high-performance compute instances.

Why wrong: Ransomware encryption is typically based on strong, complex algorithms like AES-256 or RSA-4096, making brute-force attacks computationally infeasible. This strategy would waste valuable time and resources during a critical recovery period when restoring from backups is the standard, reliable recovery path for infrastructure impacted by encryption-based threats.

Copy the encrypted volumes to a new account and run a vulnerability scan.

Why wrong: Scanning encrypted volumes will not reveal the underlying data or help recover it from the ransomware. Moving the volumes to a new account consumes time and does not provide a recovery path, failing to address the business need for restoring service availability and accessing the encrypted data.

Format the EBS volumes and manually copy data from the underlying S3 logs.

Why wrong: Manual data reconstruction from log files is extremely slow, error-prone, and likely incomplete. EBS volumes contain structured data and file systems that cannot be easily recreated from unstructured application logs, making this an ineffective recovery strategy that would result in significant data loss and prolonged downtime.

Amazon CloudWatch

Why wrong: CloudWatch is primarily for monitoring metrics, logs, and performance data. While it can be used to set up alarms for security events, it lacks the specialized correlation, finding aggregation, and forensic visualization capabilities that are required for centralized security incident management and deep root-cause investigation.

AWS Artifact

Why wrong: AWS Artifact provides on-demand access to AWS security and compliance reports, such as ISO certifications and SOC reports. It is not an incident response tool and does not provide visibility into active security alerts or findings related to an organization's internal infrastructure and operations.

AWS Systems Manager

Why wrong: Systems Manager is an operations management tool used for configuration, patching, and task automation. While it can be used for remediation, it is not a tool for aggregating security findings or providing the investigative visualization required for incident response and threat analysis.