Daily Blog #813: Solution Saturday 4/19/25

 

Hello Reader, 

Another week has come and gone but Chris Eng's streak continues unbroken! It's up to all of you to decide if you are ready to step up to the challenge tomorrow for this weeks challenge!

 

The Challenge:

It's becoming more common that the first thing an attacker will try to do if they get access to a user's system is extract all of the saved browser passwords. Profile a popular browser password extractor (such as WebBroweerPassView or HackBrowserData) and detail what artifacts are left behind that would reveal their usage on a Windows 11 system. Extra points if you:
a. Try multiple browser password viewing tools
b. Try MacOS as well as Windows

 

The Winning Answer:

Chris Eng / Ogmini Blog

 https://ogmini.github.io/2025/04/14/David-Cowen-Sunday-Funday-Browser-Password-Extraction.html

https://ogmini.github.io/2025/04/15/LaZagne-Artifacts.html

https://ogmini.github.io/2025/04/16/WebBrowserPassView-Artifacts.html

https://ogmini.github.io/2025/04/18/HackBrowserData-Artifacts.html

Read More

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 #807: Sunday Funday 4/13/25

 

Hello Reader, 

This week I'm hoping for more of you to get involved and give Chris Eng some competition. With that in mind I'm going to make this challenge as accessible as possible but still have an outcome that increases the overall knowledge of the field. So let's get started on this week's browser stored credential challenge.

The Prize:

$100 Amazon Giftcard

 

The Rules:

1. You must post your answer before Friday 4/18/25 7PM CST (GMT -6)
2. The most complete answer wins
3. You are allowed to edit your answer after posting
4. If two answers are too similar for one to win, the one with the earlier posting time wins
5. Be specific and be thoughtful
6. Anonymous entries are allowed, please email them to dlcowen@gmail.com. Please state in your email if you would like to be anonymous or not if you win.
7. In order for an anonymous winner to receive a prize they must give their name to me, but i will not release it in a blog post
8. AI assistance is welcomed but if a post is deemed to be entirely AI written it will not qualify for a prize. 

The Challenge:

It's becoming more common that the first thing an attacker will try to do if they get access to a user's system is extract all of the saved browser passwords. Profile a popular browser password extractor (such as WebBroweerPassView or HackBrowserData) and detail what artifacts are left behind that would reveal their usage on a Windows 11 system. Extra points if you:
a. Try multiple browser password viewing tools
b. Try MacOS as well as Windows

Read More

Daily Blog #806: Solution Saturday 4/12/25

 

Hello Reader, 

This week Chris Eng comes back again with some research in his own Daily Blogs about WSL. While I think we can all appreciate Chris's winning streak I'm looking for all of you to come out in force this coming week to challenge him for a win!

 

The Challenge:

What artifacts are left behind when running a docker container using Ubuntu WSL (which I believe is the default standard. Bonus points for artifacts that reflect interactions between the container and the host.

 

The winning answer:

Chris Eng / OG Mini Blog

https://ogmini.github.io/2025/04/08/David-Cowen-Sunday-Funday-WSL-Docker.html

https://ogmini.github.io/2025/04/10/WSL-Docker-Part-2.html

https://ogmini.github.io/2025/04/11/WSL-Docker-Part-3.html

Read More