Inheriting a Messy AWS Environment: Your First 30-Day Security Audit
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Inheriting an AWS environment with no documentation is a common situation. The prior team may have left, the startup acquired by your company had no security program, or the environment grew organically over years with no formal governance. Whatever the cause, the first challenge is the same: you cannot fix what you cannot see, and you cannot see everything at once across 30+ AWS regions and potentially dozens of accounts.
The first 30 days should be almost entirely about visibility. Resist the temptation to immediately start fixing things before you understand the full scope — a premature change can break production systems you did not know existed or remove access from teams who are depending on what looks like an over-privileged policy but turns out to be a business-critical integration. Understand first, then prioritize, then remediate.
Week 1: Immediate critical risk identification
The first week focuses exclusively on findings that represent active exposure with potential for immediate data loss or ongoing attacker access. Three conditions warrant same-day action before any systematic audit is complete: root accounts without MFA (direct administrative takeover risk), S3 buckets or RDS instances exposed to the public internet (data exfiltration risk), and GuardDuty findings that indicate active compromise from a prior intrusion. Enabling GuardDuty and CloudTrail across all accounts and all regions is a prerequisite for the rest of the audit because without these detective controls active, you are auditing a static snapshot while potentially missing live attacker activity. The discovery queries for EC2 security groups, RDS public accessibility, and S3 bucket ACLs can be run in parallel across all regions using AWS CLI loops or AWS Config rules.
Day 1: Secure root accounts and enable detective controls
For every AWS account: log in as root, verify MFA is enabled on the root account (console > My Security Credentials > Multi-factor Authentication), and delete any root access keys (there should be none). Enable GuardDuty in every region of every account — this starts generating findings about anomalous activity immediately and is the fastest way to detect if prior compromise is ongoing. Enable CloudTrail organization-wide if using AWS Organizations: create an organization trail in the management account that logs all accounts and all regions to a central S3 bucket with CloudTrail log file integrity validation enabled.
Days 2-3: Find all public resources
Run the public resource discovery queries for S3, EC2, and RDS across all regions and all accounts. For S3: enable S3 Block Public Access at the account level for every account (in S3 console > Block Public Access settings for this account > enable all four options) — this prevents future public access and does not break existing private bucket access. Review any bucket where Block Public Access was blocking you from enabling (these buckets have explicit public access grants that need individual review). For EC2: pull all security groups with 0.0.0.0/0 inbound rules in all regions: this can be done with a simple AWS Config rule or a manual loop across regions using the CLI query above.
Days 4-5: Evidence of prior compromise
Check for indicators of compromise that may have been present before you took over. Enable GuardDuty and check if any High or Critical findings appear within 24 hours — findings about anomalous instance behavior or unusual API calls that appear immediately after enablement indicate ongoing malicious activity, not just historical exposure. Pull the last 90 days of CloudTrail from every region using Athena or CloudTrail Lake and search for: CreateUser events, CreateAccessKey events, RunInstances calls in unusual regions, and StopLogging calls. Any of these from unrecognized source IPs or at unusual hours warrants immediate investigation.
Weeks 2-4: Systematic audit and remediation roadmap
Once immediate critical risks are stabilized, the goal shifts to building a complete, structured picture of all remaining security debt so that remediation can be prioritized by risk rather than by what you happen to notice first. AWS Security Hub with the CIS AWS Foundations Benchmark enabled gives you a scored, severity-rated list of every failing control across all accounts within 24 hours of activation, which becomes the master document for tracking remediation progress. The IAM right-sizing work — deactivating unused keys, removing wildcard permissions, and documenting every role's business owner — is the most time-consuming phase but also the most consequential, because overpermissioned IAM is the mechanism that turns any single compromised credential into a full-environment breach.
Enable Security Hub with CIS Benchmark
Enable AWS Security Hub in every account and region, configure it to evaluate against the CIS AWS Foundations Benchmark and AWS Foundational Security Best Practices. Security Hub's summary dashboard shows your score per account and the full list of failing controls with severity. Export the complete findings list to a spreadsheet, sort by severity, and use this as the master remediation tracking document. Each finding includes remediation guidance — Security Hub findings are the backbone of your 30-day remediation roadmap for anything not already addressed in Week 1.
IAM right-sizing and documentation
After the immediate risk fixes, begin the systematic IAM audit: download the credential report, identify all inactive users and keys for deactivation, use IAM Access Analyzer to identify over-privileged roles and policies, and document every IAM user and role with its business owner (who requested this access and what service depends on it). This documentation phase prevents remediation mistakes: deactivating an access key that powers a production integration creates an outage. Build the IAM ownership map before deactivating anything beyond the obvious (keys unused for 12+ months, users who left the company).
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
The first 30 days of an inherited AWS environment audit should follow a clear sequence: secure root accounts, enable detective controls (GuardDuty, CloudTrail, Security Hub), identify public resources, check for evidence of prior compromise, then build a structured remediation roadmap from the Security Hub CIS findings. Resist the urge to remediate during discovery — some findings that look like vulnerabilities are load-bearing configurations for systems you have not yet documented. Complete the visibility phase first, document what you find, then remediate by severity. The output of the first 30 days is not a secure environment — it is a complete map of the security debt and a prioritized plan for the next 90 days of remediation work.
Frequently asked questions
What is the first thing to do when inheriting an AWS environment you know nothing about?
First: gain root account control. Ensure you (or a trusted member of your team) can log in as the root user, have MFA enabled on the root account, and no existing root access keys exist (aws iam list-access-keys should return nothing for the root account; delete any that exist). Then: generate the IAM credential report (aws iam generate-credential-report; aws iam get-credential-report --output text --query Content | base64 -d) to get a snapshot of all IAM users, their access key status, last-use dates, and MFA status. This two-step sequence — secure root access, then inventory all human IAM identities — establishes your baseline before any investigation.
How do I find all AWS accounts in the organization I just inherited?
If the environment uses AWS Organizations: aws organizations list-accounts returns all member accounts with their IDs, names, and status. If no Organizations structure exists (single account or unorganized multi-account): check for organization emails in the billing console and ask all engineering teams for any AWS account IDs they know about — teams often create shadow accounts. For each account you identify: enable AWS Security Hub in every account and every region, enable GuardDuty in every account and every region, and check CloudTrail configuration (is it logging to a central S3 bucket, or is each account logging locally, or are some accounts not logging at all?). The discovery phase goal is a complete account inventory before any remediation begins — you cannot fix what you do not know exists.
How do I find all publicly accessible AWS resources in an inherited environment?
For S3: aws s3api list-buckets, then for each bucket check aws s3api get-bucket-acl and aws s3api get-bucket-policy. Faster: run AWS Trusted Advisor security checks (Amazon S3 Bucket Permissions check lists all public buckets). Enable AWS Config rule s3-bucket-public-read-prohibited for ongoing detection. For EC2: check security groups for 0.0.0.0/0 inbound rules on sensitive ports: aws ec2 describe-security-groups --filters Name=ip-permission.cidr,Values='0.0.0.0/0' --query 'SecurityGroups[*].[GroupId,GroupName,IpPermissions]'. For RDS: aws rds describe-db-instances --query 'DBInstances[?PubliclyAccessible==`true`]' in each region. For Lambda: aws lambda list-functions (check function URLs with public auth set to NONE). Enable AWS IAM Access Analyzer to continuously identify resources shared with external principals.
How do I audit IAM in an inherited AWS environment?
IAM audit sequence: (1) Credential report: download the credential report (aws iam get-credential-report) and flag any IAM users with access keys that have not been used in 90+ days (candidates for deactivation), any users without MFA (security risk), and any users with passwords enabled but no recent console activity. (2) Over-privileged policies: aws iam list-policies --scope Local lists all custom IAM policies; review each for * actions or * resources — these are over-permissioned. Use IAM Access Analyzer to find policies that exceed what the principal actually uses (IAM Access Analyzer generates access-advised policies). (3) Unused credentials: aws iam list-access-keys for each user and check last-used dates. Deactivate any key unused for 90 days. (4) Roles with cross-account trust: aws iam list-roles --query 'Roles[*].[RoleName,AssumeRolePolicyDocument]' — any role trusting an external account ID requires justification.
What is AWS Security Hub and how does it help with an inherited environment audit?
AWS Security Hub aggregates security findings from multiple AWS services (GuardDuty, Inspector, IAM Access Analyzer, Macie) and evaluates your environment against security standards including the CIS AWS Foundations Benchmark and the AWS Foundational Security Best Practices standard. Enable Security Hub in every account and every region using the Security Hub multi-account management feature. Within 24 hours of enabling: Security Hub produces a score (0-100) for each account against the CIS Benchmark and lists all failing checks with severity ratings and remediation guidance. This gives you the fastest possible structured view of security debt across the entire inherited environment. Focus first on Critical and High severity findings — these represent the actual risk surface, not just best practices.
How do I check for signs of prior compromise in an inherited AWS environment?
Prior compromise indicators to check: (1) GuardDuty historical findings: if GuardDuty was previously enabled, review all past findings, especially any that were never resolved (Finding status: Active). (2) CloudTrail anomalies: search for API calls from unusual source IPs, API calls with unusual user agents (curl, python-requests), CreateUser or CreateAccessKey events that do not correspond to known provisioning, and calls to regions the organization does not normally use. (3) Unexpected EC2 instances: instances in regions you do not use, with instance types associated with crypto mining (high compute instances), or with security groups allowing all inbound traffic. (4) Unexpected IAM users or access keys: any IAM user created in the last 90 days with no corresponding service ticket or onboarding record. (5) S3 bucket access logs (if enabled): look for access patterns from unknown IP addresses to data buckets.
What is the 30-day remediation priority order for an inherited AWS environment?
Priority sequence: Week 1 (immediate critical risks): secure root accounts with MFA, delete root access keys, disable publicly accessible S3 buckets with sensitive data, close security group rules allowing 0.0.0.0/0 inbound on RDB ports (3306, 5432, 1433), enable GuardDuty in all accounts and regions, enable CloudTrail in any account that is not logging. Week 2 (high severity): enable Security Hub and review CIS benchmark findings, deactivate IAM access keys unused for 90+ days, disable IAM users who have not logged in for 90+ days, enable AWS Config for configuration drift monitoring. Week 3-4 (medium severity): remediate over-privileged IAM policies using IAM Access Analyzer recommendations, tag all untagged resources to establish ownership, enable Macie on S3 buckets to identify sensitive data, document all accounts and resources discovered in weeks 1-2. Create a written remediation roadmap for findings that cannot be fixed in 30 days.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.