Your First Cloud Security Investigation

Investigate an overprivileged IAM user, lock them down, and set up audit logging.

Introduction

30 Second Summary

Every company storing data in the cloud worries about the same thing: who can access their systems, and are they doing anything dangerous. One employee with too much access can accidentally delete critical files or rack up thousands in unexpected charges.

In this project, you will step into the role of a cloud security analyst on AWS. You will investigate an overprivileged user, lock down their permissions to only what they need, and set up permanent audit logging so nothing slips through again.

What You'll Build

Picture opening the CloudTrail console, filtering by a suspicious user's name, and seeing every API call they made laid out with timestamps, IP addresses, and service names.

By the end of this project, you'll have:

A restricted IAM user locked down with a custom least-privilege policy that allows only what they need and blocks everything else.
A completed CloudTrail investigation showing exactly which API calls the overprivileged user made, when they made them, and from where.
A permanent audit trail delivering logs to S3, proving you can set up compliance-ready logging for any AWS account.
Secret Mission: Validate your custom policy using the IAM Policy Simulator without ever switching accounts.

Do I need an AWS account?

You need an existing AWS account with admin-level access (root user or IAM admin user) to follow along. If you do not have one, create a free account at aws.amazon.com before starting.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters. You're stepping into the role of a cloud security analyst who has inherited an AWS account with a serious problem: a developer with far too much access.

Set Up the Security Scenario

Before you can investigate a security problem, you need a security problem.

In this step, you will create an IAM user with dangerously broad access and simulate the kind of activity a real analyst would need to investigate. By the end, your account will have a "crime scene" ready for your CloudTrail investigation.

In this step, get ready to:

Create an overprivileged IAM user named dev-analyst with full admin access.
Sign in as dev-analyst and browse multiple AWS services to generate CloudTrail events.
Return to your admin account with the crime scene set.

Create the overprivileged IAM user

In the real world, cloud security problems often start with a user who has more access than they need. You will create an IAM user called dev-analyst and give them the AdministratorAccess AWS managed policy, which grants unrestricted access to every service in your account.

In the AWS Management Console, type IAM in the top search bar and select IAM from the results.
In the left navigation pane, select Users.
Select Create user.

Seeing an IAM Identity Center reminder?

If you have IAM Identity Center enabled, the console may display a reminder that it is best to manage user access there. For this project, you are intentionally creating an IAM user to simulate a security scenario. Continue with the IAM user creation.

On the Specify user details page, enter dev-analyst in the User name field.
Select the checkbox next to Provide user access to the AWS Management Console.
Choose I want to create an IAM user.
Under Console password, select Autogenerated password.
Clear the checkbox next to User must create a new password at next sign-in. You will sign in as this user shortly, so skipping the password reset keeps things simple.
Choose Next.

Now you need to give dev-analyst permissions. The outline calls for attaching the policy directly to the user.

On the Set permissions page, under Permissions options, choose Attach policies directly.
In the Permissions policies search box, type AdministratorAccess.
Select the checkbox next to the AdministratorAccess policy.
Choose Next.

What is AdministratorAccess?

AdministratorAccess is an AWS managed policy that grants full access to every AWS service and resource in your account. In a real organization, handing this to a developer is a major security risk. That is exactly the misconfiguration you are simulating.

On the Review and create page, confirm the user name is dev-analyst and AdministratorAccess is listed under permissions.
Choose Create user.

The Retrieve password page appears with the new user's credentials.

Choose Download .csv file to save the credentials file. You will need the sign-in URL, username, and password in the next substep.
Keep this page open or save the information somewhere you can access it.

Confirm the user was created by navigating back to the Users list. You should see dev-analyst in the list.

Don't see dev-analyst in the Users list?

Make sure you completed the creation wizard by choosing Create user on the Review and create page. If you navigated away before that step, start the user creation process again.

Help me troubleshoot creating the dev-analyst IAM user.

Generate activity as dev-analyst

Now you need to simulate the kind of activity a real security analyst would investigate. You will sign in as dev-analyst and browse several AWS services, generating CloudTrail events along the way.

Open an incognito window (or a different browser) so you can sign in as dev-analyst without disrupting your admin session.
Go to the AWS sign-in page at https://console.aws.amazon.com/.
Choose IAM user as the user type.
Enter your 12-digit AWS account ID (or account alias), the user name dev-analyst, and the password from the .csv file you downloaded.
Choose Sign in.

Find your account ID quickly

Your 12-digit account ID is shown in the top-right dropdown of the AWS console where your account name appears. You can also find it in the Connection URL inside the .csv file you downloaded.

Once you are signed in as dev-analyst, you will visit three different service consoles. Each visit generates API calls that CloudTrail records.

Type S3 in the top search bar and select S3 to open the Amazon S3 console. Let the page load fully.
Type EC2 in the top search bar and select EC2 to open the Amazon EC2 console. Let the page load fully.
Type IAM in the top search bar and select IAM to open the IAM console. Let the page load fully.

Why do I need to visit these consoles?

Every time you open a service console, the browser makes API calls on behalf of the signed-in user. CloudTrail records these calls as management events.

By visiting S3, EC2, and IAM, you are creating a realistic trail of activity across multiple services. In the next step, you will use CloudTrail to find and analyze exactly these events.

You are done generating activity. Time to leave the dev-analyst session.

Close the incognito window (or the separate browser) where you signed in as dev-analyst.

Verify the crime scene is set

Before you move to the investigation, confirm everything is in place. What do you expect to see on the dev-analyst user's Permissions tab?

Switch back to your primary browser where you are signed in as your admin user.
In the IAM console, select Users in the left navigation pane.
Select dev-analyst from the list.
Select the Permissions tab.

You should see AdministratorAccess listed as an attached policy. This confirms your overprivileged user is set up and has been browsing services they probably should not have access to.

Don't see AdministratorAccess on the Permissions tab?

Make sure you selected Attach policies directly during user creation and checked the box next to AdministratorAccess. If the policy is missing, select Add permissions on the Permissions tab, choose Attach policies directly, search for AdministratorAccess, select it, and choose Add permissions.

Help me attach AdministratorAccess to my dev-analyst user.

Your security scenario is ready. You have an overprivileged user who has been browsing services across your account. Next, you will open CloudTrail and investigate exactly what this user did.

Investigate with CloudTrail

Your security scenario is set. In the last step, you created the dev-analyst user with full admin access and browsed several AWS services while signed in as that user.

Here is the problem. You know dev-analyst has dangerously broad access, but you do not know exactly what they did. CloudTrail Event History is the tool real cloud security analysts use to answer that question. In this step, you will run your first investigation.

In this step, get ready to:

Filter CloudTrail Event History to find dev-analyst's API activity.
Read a CloudTrail event record to understand who did what, when, and from where.
Identify which AWS services dev-analyst accessed.

Open CloudTrail and filter events by user

Every API call made in your AWS account is automatically recorded by CloudTrail. You do not need to turn anything on. It has been running since the moment your account was created.

In the AWS Management Console, click the search bar at the top of the page.
Type CloudTrail and select CloudTrail from the results.
In the left navigation pane, click Event history.

What is CloudTrail Event History?

Event History provides a searchable record of the last 90 days of management events in your AWS account. Management events are API calls that create, modify, or describe your AWS resources.

It is enabled by default on every AWS account and costs nothing to use. This is the same data a security analyst would pull up first when investigating suspicious activity.

You are about to filter Event History to show only dev-analyst's activity. Think back to what you did as dev-analyst in the last step. How many API calls do you think AWS recorded behind the scenes?

Find the Lookup attributes dropdown near the top of the page.
Click the dropdown and select User name.
In the text field next to the dropdown, type dev-analyst.
Press Enter to apply the filter.

You should now see a list of events tied to the dev-analyst user. Each row shows an API call with columns including Event name, Event time, User name, and Event source. You probably see more events than you expected. Even a quick visit to a console page can trigger multiple API calls under the hood.

Not seeing any events?

CloudTrail events can take a few minutes to appear in Event History. If your list is empty, wait a moment and refresh the page.

Double-check that you selected User name from the Lookup attributes dropdown and typed dev-analyst exactly (no extra spaces).

If you still do not see events, try switching your console Region to US East (N. Virginia) using the Region selector in the top right corner. Some global services like IAM record their events in that Region.

Help me find CloudTrail events for my dev-analyst user.

Read a CloudTrail event record

Each event in the list represents a single API call. Clicking on one opens the full event record in JSON format. This is where you get the details of exactly what happened.

Click on any event in the filtered list to expand its details.
Scroll down to the Event record section to see the full JSON.

You are now looking at the raw data a security analyst uses to reconstruct what happened in an account.

What do these fields mean?

A CloudTrail event record contains several key fields that tell the full story of an API call:

userIdentity identifies who made the call. You will see dev-analyst here.
eventName is the specific API action that was called, such as ListBuckets or DescribeInstances.
eventSource shows which AWS service handled the call, such as s3.amazonaws.com or ec2.amazonaws.com.
eventTime is the exact timestamp of when the call happened.
sourceIPAddress shows the IP address from which the request originated.

In a real investigation, you would cross-reference these fields to build a timeline of a user's activity and determine whether any of it was unauthorized.

Identify which services dev-analyst accessed

Now that you can read individual events, zoom out and look at the bigger picture. The Event source column in your filtered results tells you which AWS services dev-analyst interacted with.

Scroll through the filtered events list.
Look at the Event source column for each row.
Take note of the different service domains you see.

Before you tally up the results, think about which services you expect to see. You visited three consoles as dev-analyst. Do you remember which ones?

You should see event sources including s3.amazonaws.com, ec2.amazonaws.com, and iam.amazonaws.com. Each one confirms that dev-analyst accessed that service. You may also see signin.amazonaws.com from the console login event and other service domains from background API calls.

Why does this matter?

These event sources are your evidence. They prove that dev-analyst was not just sitting idle with admin access. They actively browsed multiple services, including ones they have no business accessing.

This is the data you will use in the next step to write a least-privilege policy. Your investigation tells you what the user actually needs (S3 access) versus what they should not have (EC2, IAM, and everything else).

Your investigation is complete. You now know exactly what dev-analyst did and which services they touched. Next up, you will use this evidence to lock down their permissions with a custom least-privilege policy.

Lock Down with Least Privilege

Your CloudTrail investigation revealed exactly which services dev-analyst has been accessing. You know they browsed S3, EC2, and IAM. Now you have the evidence to act on.

The problem is that dev-analyst still has the AdministratorAccess policy, which grants permissions to every service in AWS. Their actual job only requires reading S3 buckets. In this step, you will write a custom least-privilege policy that allows only what they need and remove the dangerous broad permissions.

In this step, get ready to:

Create a custom IAM policy that allows only S3 read access.
Replace dev-analyst's AdministratorAccess with your new least-privilege policy.
Verify the restrictions by signing in as dev-analyst and testing access to multiple services.

Create a custom least-privilege policy

The principle of least privilege means giving a user only the permissions they need to do their job. Right now, dev-analyst has AdministratorAccess, which is like giving someone the master key to every room in a building. You are going to write a policy that only opens the rooms they actually need.

In the IAM console, click Policies in the left navigation pane.
Click Create policy.
In the Policy editor section, select the JSON tab.
Clear any default JSON in the editor, then paste this policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListAllMyBuckets",
                "s3:GetBucketLocation",
                "s3:ListBucket"
            ],
            "Resource": "*"
        }
    ]
}

What does this policy do?

This policy has one statement that grants three specific S3 permissions.

s3:ListAllMyBuckets lets the user see the names of all S3 buckets in the account.
s3:GetBucketLocation lets the user check which AWS Region each bucket is in.
s3:ListBucket lets the user list the objects inside individual buckets.
"Resource": "*" applies these three permissions to all S3 buckets. No other AWS service is mentioned, so everything else is implicitly denied.

Click Next.
On the Review and create page, enter S3ReadOnlyCustom in the Policy name field.
Click Create policy.

You should see a success banner confirming that the S3ReadOnlyCustom policy was created. It appears in the policies list with a Customer managed type label.

Don't see your new policy?

Make sure you entered the policy name S3ReadOnlyCustom before clicking Create policy. A policy without a name cannot be created.
If you see a syntax error, double check that the JSON uses curly braces and square brackets exactly as shown in the code block above. A missing comma or bracket is the most common mistake.
help me fix a JSON syntax error in my IAM policy

Replace dev-analyst's permissions

Your custom policy is ready. Now you need to swap out the overprivileged AdministratorAccess and replace it with your scoped S3ReadOnlyCustom policy.

Click Users in the left navigation pane.
Click dev-analyst.
Select the Permissions tab.
Find the AdministratorAccess policy in the list and click Remove next to it.
Confirm the removal when prompted.

The Permissions tab should now show no policies attached to dev-analyst. This user currently has zero AWS permissions.

Click Add permissions on the Permissions tab.
Select Attach policies directly.
In the search box, type S3ReadOnlyCustom and select the radio button next to it.
Click Next, then click Add permissions.

The Permissions tab now shows S3ReadOnlyCustom as the only attached policy. The dangerous AdministratorAccess is gone.

What is remediation?

In cloud security, remediation is the act of fixing a security finding. You just completed a remediation: you identified an overprivileged user, wrote a scoped policy, and replaced the broad permissions. This is exactly what a security analyst does after an investigation.

Still seeing AdministratorAccess?

Make sure you clicked Remove next to AdministratorAccess and confirmed the removal. Refresh the page to see the updated permissions list.
If you attached S3ReadOnlyCustom but forgot to remove AdministratorAccess, the user still has full admin access. Both policies apply at the same time, and AdministratorAccess overrides any restrictions.
help me remove AdministratorAccess from my IAM user

Verify the lockdown works

You have replaced the permissions on paper. Now it is time to prove the lockdown actually works by testing it the way a real attacker would encounter it.

Before you test, think about what you expect to happen. If dev-analyst now has only S3 read permissions, what should they see when they try to open the EC2 console?

Open a separate browser or incognito window and sign in as dev-analyst using the IAM sign-in URL for your account.
Open the EC2 console.

You should see an authorization error message. The console will display something along the lines of "You are not authorized" or "You don't have permissions." This proves dev-analyst can no longer access EC2.

Now open the IAM console.

Another authorization error. dev-analyst cannot manage users or policies.

Finally, open the S3 console.

You can see the list of S3 buckets. This is the one service dev-analyst is allowed to access. Your least-privilege policy works: the user can do their job but nothing else.

Why does this before-and-after matter?

In a real security role, you would document this before-and-after comparison as evidence of remediation. Before: the user had access to S3, EC2, and IAM. After: the user can only access S3. That delta is your proof that you reduced the attack surface.

S3 console also showing an error?

Verify you attached the S3ReadOnlyCustom policy to dev-analyst. Switch back to your admin account, go to IAM > Users > dev-analyst > Permissions, and confirm S3ReadOnlyCustom is listed.
Check that your custom policy JSON includes s3:ListAllMyBuckets in the Action array. Without this action, the S3 console cannot display the bucket list.
help me debug why my restricted IAM user cannot access S3

Your remediation is verified. You locked down an overprivileged user with a custom least-privilege policy and proved it works. Next up, you will set up a persistent audit trail so that all future account activity is logged permanently to S3.

Set Up Your Audit Trail

Your investigation is complete and your remediation is in place. The dev-analyst user is locked down to S3 read-only access thanks to your custom S3ReadOnlyCustom policy.

But there is still a gap. CloudTrail Event History only keeps 90 days of data. You also cannot search across multiple attributes at once. For real-world compliance and governance, organizations need permanent audit logs they can store and search indefinitely. In this step, you will create a CloudTrail trail that delivers logs to an S3 bucket for long-term storage.

In this step, get ready to:

Create a CloudTrail trail named security-audit-trail that delivers audit logs to a new S3 bucket.
Verify that compressed log files are being delivered to your bucket.

Create a new CloudTrail trail

Event History is great for quick lookups, but it disappears after 90 days. A CloudTrail trail is a persistent pipeline that captures API activity and delivers it as log files to an S3 bucket you own.

Return to the CloudTrail console in the navigation pane.
In the left navigation pane, choose Trails.
Choose Create trail.
For Trail name, enter security-audit-trail.
For Storage location, select Create new S3 bucket.
Enter a unique bucket name. Include your name and today's date to keep it globally unique, for example security-audit-yourname-20260814.
Clear the Log file SSE-KMS encryption checkbox to disable it. Your log files will use the default SSE-S3 encryption instead.

What is a CloudTrail trail?

A trail is a configuration that tells CloudTrail to deliver a copy of every API event to an S3 bucket you control. Unlike Event History, which expires after 90 days, trail logs persist in your bucket until you choose to delete them.

Trails created in the console are automatically multi-Region. This means your single trail captures activity across every enabled AWS Region in your account.

Bucket names must be globally unique

S3 bucket names are shared across all AWS accounts worldwide. If you get a naming conflict, try adding extra numbers or initials to make it unique.

Choose which events to log

After filling in the trail details, you land on the log events configuration page. This is where you choose what types of API activity the trail records.

On the Choose log events page, keep the default Management events selected.
Confirm that both Read and Write are checked under API activity.
Choose Next.
On the Review and create page, review your settings.
Choose Create trail.

Your new trail appears on the Trails page. CloudTrail automatically starts logging as soon as the trail is created.

What are management events?

Management events are control-plane API calls that create, modify, or delete AWS resources. Examples include creating an S3 bucket, attaching an IAM policy, or launching an EC2 instance.

By logging both Read and Write management events, your trail captures everything from listing resources to deleting them. This is the standard configuration for compliance auditing.

Will this cost anything?

One copy of ongoing management events delivered to S3 is free from CloudTrail. The S3 storage charges for a single-account learning environment are negligible (pennies per month).

Verify log delivery in your S3 bucket

CloudTrail takes about 5 minutes to publish its first log files to your bucket. While you wait, this is a good time to review the work you have done so far in this project.

Wait about 5 minutes for CloudTrail to deliver its first batch of log files.
Open the S3 console by searching for S3 in the AWS search bar at the top of the page.
Find and click on the bucket you created for your trail.

Before you drill into the folder structure, what do you think CloudTrail has stored in this bucket? What format do you expect the files to be in?

Click into the AWSLogs folder.
Click into the folder named with your AWS account ID.
Click into the CloudTrail folder.
Click into your Region folder (for example us-east-1).
Click into today's date folder.

You should see .json.gz files listed inside the date folder. These are compressed JSON log files containing every management API call made in your account. Unlike Event History, these logs persist until you delete them.

Now confirm your trail's status. Return to the CloudTrail console by searching for CloudTrail in the AWS search bar.
In the left navigation pane, choose Trails.
Verify that security-audit-trail shows a status of Logging.

Your audit trail is live. Every API call across your entire AWS account is now being permanently recorded to your S3 bucket.

Not seeing any log files in the bucket?

Make sure at least 5 minutes have passed since you created the trail. CloudTrail needs time to deliver its first batch.
Double check you are looking in the correct bucket. The bucket name should match what you entered during trail creation.
Make sure you are drilling into the full folder path: AWSLogs > your account ID > CloudTrail > your Region > today's date.
If the trail status does not show Logging, click on the trail name and verify that logging is enabled on the trail detail page.

Help me troubleshoot why my CloudTrail trail is not delivering log files to my S3 bucket.

Secret mission

Validate with the IAM Policy Simulator

So far, you have tested your custom policy by logging in and out of the dev-analyst account. Real security analysts use the IAM Policy Simulator to validate permissions without switching accounts. Can you validate your entire least-privilege policy from a single screen?

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Cost warning

IAM users and policies are free. One CloudTrail trail delivering management events to S3 is also free.

The only ongoing cost is S3 storage for trail log files, which amounts to pennies per month for a single-account learning environment.

Resources you used:

IAM user: dev-analyst (no ongoing cost).
IAM custom policy: S3ReadOnlyCustom (no ongoing cost).
CloudTrail trail: security-audit-trail (no ongoing CloudTrail cost).
S3 bucket for trail logs (minimal storage cost).

Keep everything running

No action needed. Choose this if you are still exploring CloudTrail logs or experimenting with IAM policies.

Your CloudTrail trail continues logging at virtually no cost.
IAM users and policies are completely free.
S3 storage charges for trail logs are pennies per month.

Pause - I'll come back to this later

Stop new log delivery to save on S3 storage while keeping your existing resources intact.

In the CloudTrail console, choose Trails from the navigation pane.
Select security-audit-trail and stop logging on the trail.
This stops new log delivery but keeps your existing log files in S3.
Your IAM user, policy, and existing logs remain in place for when you return.

Delete - I don't want to use this again

Remove all project resources and start fresh.

Close any separate browser window or incognito session where dev-analyst is signed in.
In the IAM console, choose Users from the navigation pane. Select dev-analyst and delete the user. Follow the confirmation prompts.
In the IAM console, choose Policies from the navigation pane. Search for S3ReadOnlyCustom, select it, and delete the policy. Follow the confirmation prompts.
In the CloudTrail console, choose Trails from the navigation pane. Select security-audit-trail and delete the trail. Follow the confirmation prompts.
In the S3 console, select your trail log bucket. Empty the bucket first, then delete it. Confirm each action when prompted.

Nice Work!

You just completed your first cloud security investigation on AWS! You went from inheriting a dangerously overprivileged user to locking them down, investigating their activity, and setting up long-term audit logging.

You've learned how to:

Investigate account activity using CloudTrail Event History, filtering by user to trace exactly which AWS services they accessed, when, and from where.
Write a custom least-privilege IAM policy and remediate an overprivileged user by replacing broad AdministratorAccess with scoped, S3-only permissions.
Set up a persistent CloudTrail trail delivering compressed audit logs to an S3 bucket for long-term compliance storage.
Secret Mission: Used the IAM Policy Simulator to validate your custom policy without switching accounts, the way real security analysts do it.

Ready to quiz yourself?