You enabled GuardDuty. You turned on Security Hub. Now your dashboard is filling up with findings that have names like Recon:EC2/PortProbeUnprotectedPort and UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS. Some are marked "High." Some are "Medium." You have no idea which ones to care about.
This guide translates the most common AWS security findings into plain English. For each finding, we'll cover what it means, how urgent it is, and the specific action to take.
GuardDuty Findings
UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS
Plain English: Someone took the temporary credentials from one of your EC2 instances and used them from outside AWS. This usually means an attacker has compromised an instance and is extracting its IAM role credentials to use from their own machine.
Urgency: HIGH. This is an active compromise. The attacker has valid credentials and is using them.
Action: Isolate the affected EC2 instance immediately (modify its security group to deny all traffic). Revoke the IAM role's active sessions. Review CloudTrail for what the attacker did with the credentials. Investigate how the instance was compromised.
CryptoCurrency:EC2/BitcoinTool.B!DNS
Plain English: An EC2 instance in your account is communicating with a cryptocurrency mining pool. Either someone is using your infrastructure to mine crypto, or — more likely — your instance has been compromised and an attacker is using it for mining.
Urgency: HIGH. This is almost always a compromised instance. The mining itself is a cost concern, but the bigger issue is that an attacker has access to your infrastructure.
Action: Terminate the instance (after capturing a snapshot for forensic analysis if needed). Investigate how it was compromised — check for exposed access keys, unpatched vulnerabilities, or overly permissive security groups. Rotate any credentials the instance had access to.
Recon:EC2/PortProbeUnprotectedPort
Plain English: Someone on the internet is probing your EC2 instance's open ports. This is reconnaissance — an attacker is checking which services are running and looking for vulnerabilities.
Urgency: LOW to MEDIUM. Port scanning is constant on the internet. This finding is only concerning if the probed port is actually open and running a service. If it is, the priority is securing that service — not chasing the scanner.
Action: Check the security group for the affected instance. Is the probed port intentionally open? If not, close it. If it is, ensure the service behind it is patched and properly configured. Don't waste time trying to block individual scanner IPs — there are millions of them.
UnauthorizedAccess:EC2/RDPBruteForce or SSH BruteForce
Plain English: Someone is trying to guess the password for RDP (Windows) or SSH (Linux) on your instance by trying many combinations.
Urgency: MEDIUM. Brute force attacks are extremely common and usually automated. They're dangerous only if they succeed — which they will if you're using weak passwords or have key-based auth disabled.
Action: Confirm that SSH key-based authentication is enforced (password auth disabled). Restrict the security group to allow SSH/RDP only from known IP ranges, not 0.0.0.0/0. Consider using AWS Systems Manager Session Manager instead of direct SSH/RDP access.
Stealth:S3/ServerAccessLoggingDisabled
Plain English: Server access logging was disabled on an S3 bucket. This could mean someone is trying to cover their tracks by turning off logging before accessing the bucket's data.
Urgency: MEDIUM to HIGH. If you didn't disable this logging intentionally, investigate who did and why. Check CloudTrail for the PutBucketLogging API call.
Action: Re-enable server access logging on the bucket. Review CloudTrail to identify who disabled it. If it wasn't a known administrator, treat this as a potential compromise indicator.
Config / Security Hub Findings
S3 Bucket Public Read Access
Plain English: One of your S3 buckets can be read by anyone on the internet.
Urgency: HIGH (unless the bucket is intentionally public, like a static website). Public S3 buckets are one of the most common sources of data breaches.
Action: If the bucket should be private, enable the S3 Block Public Access setting for that bucket immediately. Review the bucket contents to understand what data may have been exposed. If the bucket is intentionally public (static website, public assets), suppress this finding.
IAM Root Account MFA Not Enabled
Plain English: Your root account — the one with unrestricted access to everything — has no second factor of authentication. If someone guesses or steals the password, they own your entire AWS account.
Urgency: CRITICAL. Enable MFA on the root account right now.
Action: Go to IAM → Security credentials for the root user. Add an MFA device. Use a hardware security key if possible; a virtual authenticator app (Authy, 1Password) is the minimum.
Security Group Allows Unrestricted SSH (port 22) Access
Plain English: A security group allows SSH connections from any IP address on the internet (0.0.0.0/0). This means anyone can attempt to connect to instances using this security group.
Urgency: MEDIUM. It's not an active exploit, but it's an open door. Combined with weak credentials or an unpatched SSH vulnerability, it becomes high severity.
Action: Restrict the security group to allow SSH only from specific IP ranges (your office IP, your VPN). Better yet, remove direct SSH access entirely and use AWS Systems Manager Session Manager for shell access.
CloudTrail Not Enabled in All Regions
Plain English: CloudTrail is logging API activity in some regions but not all. An attacker who provisions resources in a region without CloudTrail coverage leaves no audit trail.
Urgency: MEDIUM. Attackers specifically target regions without monitoring.
Action: Update your CloudTrail configuration to log in all regions. This is a single setting change — enable "Is trail applied to all regions?" in the trail configuration.
When to Investigate vs. When to Suppress
Not every finding requires investigation. Port scans, DNS queries to known domains, and other internet noise generate low-severity findings that are informational, not actionable. The key is to suppress known-good patterns (your security scanner's IP, your NAT gateway's traffic) and investigate anything that's new, unexpected, or involves IAM credentials.
A good rule of thumb: if the finding involves credentials, access keys, or IAM — investigate immediately. If it involves network reconnaissance — check the security group, fix if needed, then move on. If it's a compliance configuration finding — schedule remediation based on severity.
Related Reading
Protect your AWS accounts before it's too late
Vigilare monitors your AWS accounts for suspension risks — billing anomalies, IAM issues, GuardDuty findings, and more — and alerts you before AWS takes action.
Written by Vigilare Engineering
Platform Team