Instance 'i-00bf460dd30495cab' has an admin port (SSH/RDP) open to the entire internet (0.0.0.0/0). Automated scanners probe every public IP for open port 22/3389 within minutes of it appearing. An attacker who finds it attempts credential brute-forcing or exploits any unpatched SSH/RDP vulnerability directly, with nothing else to compromise first.
Restrict the security group rule to your specific IP instead of 0.0.0.0/0: aws ec2 revoke-security-group-ingress --group-id sg-0c345cdeb4e2d1ac8 --protocol tcp --port 22 --cidr 0.0.0.0/0 aws ec2 authorize-security-group-ingress --group-id sg-0c345cdeb4e2d1ac8 --protocol tcp --port 22 --cidr 203.0.113.42/32
Bucket 'taskflow-customer-documents-09c1253f' doesn't have full S3 Block Public Access protection enabled. Without this protection, a single mistake — an overly broad bucket policy, a public ACL grant, someone copy-pasting a policy from a tutorial — immediately exposes every object to anyone on the internet via a plain s3:GetObject call, with nothing left to catch the mistake.
Enable all four Block Public Access settings unless there's a specific, documented reason not to: aws s3api put-public-access-block --bucket taskflow-customer-documents-09c1253f --public-access-block-configuration "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"
'taskflow-contractor' has more than one active access key at the same time. A second active key is often a forgotten one, created for a one-off task and never deactivated. Every active key is a separate way in — an attacker only needs to compromise the forgotten one, not the one you're actively watching.
Confirm which key is genuinely still in use, then deactivate the other: aws iam list-access-keys --user-name taskflow-contractor aws iam get-access-key-last-used --access-key-id AKIAJ2X9QW4TZP7RMNBS aws iam update-access-key --user-name taskflow-contractor --access-key-id AKIAJ2X9QW4TZP7RMNBS --status Inactive
The root account performed 'DescribeSecurityGroups' via ec2.amazonaws.com on 2026-08-22 18:32:22+05:30, within the last 90 days. Root should never be used for routine operations — every action taken as root is unrestricted and can't be permission-limited.
GuardDuty is not enabled in this region. It's free to turn on and provides automated threat detection (unusual API calls, known-malicious IPs, compromised credentials) — with it off, there is no automated detection layer at all.
EBS volume 'vol-0055a87f463e789c6' is not encrypted at rest. If this volume's underlying storage is ever exposed — a misconfigured snapshot shared publicly, physical disk decommissioning at AWS's end — the data on it is readable in plaintext, no encryption key required.
Existing volumes can't be encrypted in place — snapshot it, copy the snapshot with encryption enabled, then create a new volume from that: aws ec2 create-snapshot --volume-id vol-0055a87f463e789c6 aws ec2 copy-snapshot --source-snapshot-id <SNAPSHOT_ID> --encrypted --source-region us-east-1 aws ec2 create-volume --snapshot-id <ENCRYPTED_SNAPSHOT_ID> --availability-zone us-east-1a
EBS volume 'vol-07ef2d308b17414d4' is not encrypted at rest. If this volume's underlying storage is ever exposed — a misconfigured snapshot shared publicly, physical disk decommissioning at AWS's end — the data on it is readable in plaintext, no encryption key required.
Existing volumes can't be encrypted in place — snapshot it, copy the snapshot with encryption enabled, then create a new volume from that: aws ec2 create-snapshot --volume-id vol-07ef2d308b17414d4 aws ec2 copy-snapshot --source-snapshot-id <SNAPSHOT_ID> --encrypted --source-region us-east-1 aws ec2 create-volume --snapshot-id <ENCRYPTED_SNAPSHOT_ID> --availability-zone us-east-1a