Daily Blog #812: Testing AWS Log latency - Removing Users from Groups

 

 

Hello Reader,

Welcome back to another installment in the AWS CloudTrail speed test series. Today’s focus shifts to the opposite of yesterday’s action: RemoveUserFromGroup. This event is triggered when you revoke permissions by removing an IAM user from a group.

Fifth Test: AWS RemoveUserFromGroup Event

For this test, I removed a user from an existing IAM group, which typically results in an immediate change to their permission set. As with all IAM actions, the key question remained: how long will it take for CloudTrail to log it? And in which region?

Since IAM is a global service, the event should appear in the us-east-1 region, just like all prior IAM tests we've run. To confirm, I initiated the action and started the stopwatch.

Results

Sure enough, the RemoveUserFromGroup event appeared in us-east-1 after just 1 minute and 45 seconds.

Once again, CloudTrail continues to deliver IAM-related logs well within SLA expectations:

• Faster than AWS’s 15-minute SLA
• Close to their 5-minute goal for critical events

Coming Up

In tomorrow’s post, I’ll be testing something a little more involved: creating and attaching an inline policy to a user. Can CloudTrail keep up? We’ll find out—stay tuned!

Read More

Daily Blog #811: Testing AWS Log latency - Modifying User Permissions

 

Hello Reader,

Continuing our series on AWS CloudTrail speed tests, today’s test focuses on a new IAM-related action: AddUserToGroup. This event is generated when you modify a user’s permissions by assigning them to an IAM group which would grant additional permissions.

Fourth Test: AWS AddUserToGroup Event

Today’s scenario involved changing account permissions by adding an IAM user to a group. This is a common way to grant new permissions via group policies. Once the user was added to the group, the AddUserToGroup event was expected to show up in CloudTrail.

Just like previous IAM tests, this raised the question: which region would the event appear in? Since IAM is a global service, AWS documents that such activity will be logged in the us-east-1 region, regardless of where the API call originates.

Results

After initiating the action and starting the stopwatch, the AddUserToGroup event appeared in us-east-1 exactly 2 minutes later.

This result is consistent with our prior IAM tests, and once again demonstrates that CloudTrail logs IAM events well within the official AWS SLA:

• Faster than the 15-minute SLA
• Faster than the 5-minute “goal” for critical events but slower than the other events we've looked at

Coming Up

In tomorrow’s post, I’ll continue testing IAM activity—next up: removing a user from a group. Stay tuned to see if the performance holds!

Read More

Daily Blog #810: Testing AWS Log latency - CreateUser

 

Hello Reader,

Continuing from yesterday’s post, it's time for another AWS CloudTrail speed test. Today, I’m examining the CreateUser event, which is triggered when a new IAM user is created in an AWS account.

Third Test: AWS CreateUser Event

Going into this test, I knew that IAM events which are global are logged in us-east-1. It’s often the default region for global events and appears first in AWS region lists. To be thorough, I also checked us-east-2 just in case.

Results

After creating the user and starting a timer, the CreateUser event appeared in us-east-1 after approximately 2 minutes. That’s slightly longer than the ConsoleLogin and CreateAccessKey tests, but still well within AWS’s official timelines.

The delivery was:

• Faster than the 15-minute SLA
• Faster than the 5 minute goal

Coming Up

In tomorrow’s blog post, I’ll continue this series by testing the log delay for changing account permissions. Stay tuned for more CloudTrail timing insights!

Read More

Daily Blog #809: Testing AWS Log latency - CreateAccessKey

 

Hello Reader,

Continuing from yesterday’s post, it's time for another AWS CloudTrail speed test. Today, we're testing the CreateAccessKey event, which occurs when a new Access Key ID is created for an IAM user.

Second Test: AWS CreateAccessKey Event

When I first ran this test, I wasn’t sure which region the log would appear in. Unlike the console sign-in URL, IAM is a global service. That means there’s no region-specific endpoint that clearly indicates where CloudTrail logs will land for IAM activity.

I had a theory that the event would appear in us-east-1—mainly because it's always listed first in AWS’s list of regions. Just to be sure, I switched between us-east-1 and us-east-2 during testing.

Results

Sure enough, after just 90 seconds, the CreateAccessKey event appeared in us-east-1, confirming my suspicion. Just like with the ConsoleLogin event, the delivery was:

• Faster than the 15-minute SLA
• Quicker than AWS’s target goal of 5 minutes for critical events

Coming Up

In tomorrow’s blog post, I’ll be testing the log delay for changing account permissions. Stay tuned!

Read More

Daily Blog #808: Testing AWS Log latency - ConsoleLogin

Hello Reader,

In a recent Sunday Funday discussion, I asked about the actual log delay across the major cloud providers. By log delay, I mean the time it takes for an event to appear in a cloud provider’s audit log after it has occurred.

Chris Eng did a solid job documenting this behavior for Azure, but didn’t cover AWS or Google Cloud. So, this post kicks off a new blog series where I’ll be digging into the log delays for those platforms—starting with AWS, and then moving on to Google Cloud.

First Test: AWS ConsoleLogin Event

For this initial test, I focused on the ConsoleLogin event in AWS. This is a CloudTrail-logged event that captures when a user successfully signs into the AWS web console.

The first time I ran the test, I unknowingly logged in through the us-east-2 region but was searching for logs in us-east-1. Since CloudTrail logs are region-specific, this led to confusion. Whether you’re using the Event History view or checking the S3 bucket where logs are stored, you need to ensure you're looking in the correct region if you want to see the expected log appear.

I knew something was off when my stopwatch hit 17 minutes without any sign of the login event—even though AWS provides a 15-minute SLA for log delivery. Once I switched my search to us-east-2, I immediately found the ConsoleLogin event and realized I needed to redo the test.

Results

After logging out and back in (confirming again that my login URL showed us-east-2), I monitored CloudTrail for the event. The ConsoleLogin event showed up within 90 seconds of clicking the “Sign in” button.

That’s not only faster than the 15-minute SLA, but also quicker than AWS’s targeted 5-minute delivery time for critical events.

Coming Up

In tomorrow’s blog post, I’ll test the log delay for API key creation. Stay tuned!

Read More

Daily Blog #777: Forensic Lunch Test Kitchen 3/14/25

 

Hello Reader,

Tonight Evan and I tried to fix the workflow and fix some bugs in our CloudTrail log explorer. We had some successes and some failures and ended with the idea that we need a better set of prompts to redefine the problem. We rolled back some changes but made some progress in the end. 

 

Also Read: Daily Blog #776: Forensic Lunch Test Kitchen 3/13/25

Read More

Daily Blog #776: Forensic Lunch Test Kitchen 3/13/25

 

Hello Reader,

Tonight on the 'vibe stream' Evan and I added AWS SSO credential support to our AWS CloudTrail explorer script. It lead us into some interesting rabbit holes and ended with us realizing we should get Github commits ready before trying to tweak our workflow. 

 

You can watch it here:

 

Also Read: An Azure log entry to look for when a threat actor is in

Read More

Daily Blog #762: Forensic Test Kitchen with Cursor Rules

Hello Reader,

Tonight we continued to expand our usage of Claude 3.7 in Cursor to see if we can see can have the cursor rules files to get our model to behave better. Check out the video below:

Also Read: Forensic Test Kitchen with more Claude 3.7!

Read More