GuardDuty C2 Alert With Incomplete VPC and DNS Visibility
A health-tech company has 60 AWS accounts. VPC Flow Logs are enabled in only 20 of them, DNS query logging is absent, and most private subnets route 0.0.0.0/0 to a NAT gateway. Twelve ALBs are internet-facing, including three that front internal admin tools. EKS uses Calico but network policies are in audit mode, not enforcement. GuardDuty reports an EC2 instance communicating with a known command-and-control domain over TCP 443. The instance is a CI build agent in a non-production account, but its subnet can reach a production S3 gateway endpoint and a payer integration over PrivateLink. A separate change opened TCP 5432 from 0.0.0.0/0 to a development database. The build team says blocking egress will break dependency downloads. The security team has 48 hours to decide.
1. What do you do in the first hour with the GuardDuty C2 finding, given that flow logs are missing in this account?
Read the worked answer
I would validate the finding details first: the instance ID, account, VPC, remote IP or domain, and whether GuardDuty has additional evidence. Even without VPC Flow Logs, I can use CloudTrail for instance-role API calls, S3 access logs or data events for the production bucket, EKS audit logs if the agent is containerized, and ALB logs if the host is behind a load balancer. DNS logging is absent, so the domain evidence may be limited to GuardDuty's own detection.
I would isolate the instance with a quarantine security group, preserve memory and disk, and avoid immediate termination. Because the subnet can reach production S3 and the payer PrivateLink, I would check the instance role's permissions and recent S3 access, and ask the payer integration owner for connection logs. Rotate any credentials or tokens reachable from the build agent.
For the build team, I would provide a temporary egress path through an allowlisted proxy rather than simply blocking all outbound traffic. The goal is to contain the compromised host while keeping dependency downloads working through a controlled path.
2. What visibility improvements would you prioritize first, and why those rather than others?
Read the worked answer
I would prioritize organization-wide VPC Flow Logs delivered to a central, queryable log archive, followed by Route 53 Resolver DNS query logs. Flow logs answer who talked to whom and how much data moved; DNS logs help identify domains and beaconing. Without those two, every GuardDuty finding in an uninstrumented account becomes an expensive guess.
Next I would enable EKS audit logs and enforce network policies after an audit period, because the cluster currently permits traffic that policy says should be blocked. For internet-facing ALBs, access logs and WAF logs are high value, especially for the admin tools. For the production S3 bucket and payer integration, I would add S3 data events and review PrivateLink or vendor-side logs.
I would not start with full packet capture everywhere. It is expensive and slow to query. The first objective is consistent coverage across accounts, with retention aligned to compliance, then targeted deep logging for crown-jewel paths.
3. How do you handle the 0.0.0.0/0 rule to port 5432 and the public admin ALBs?
Read the worked answer
I would treat both as exposure risks and check for evidence of exploitation before changing them. For the database, confirm whether the instance is publicly accessible, what authentication and encryption are in use, and whether any connections came from outside the VPC. If it is a development database, close the rule and use SSM Session Manager or a bastion instead. If an application depends on it, scope the source to the application security group.
For the admin ALBs, determine whether public exposure is intentional. Internal admin tools should sit behind VPN, Zero Trust access, or IP allowlists, with strong authentication and WAF. If immediate closure would break operations, add compensating controls and a dated remediation plan.
The build team's dependency downloads should be solved with an egress proxy or package mirror, not by leaving broad egress open. I would use drift detection and SCPs or config rules to prevent the 0.0.0.0/0 database rule from returning, while documenting any temporary exception.