This Week's/Trending Posts

Solution Saturday Series

Sunday Funday Series

Forensic Lunch

The Most/Recent Articles

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!

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!

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!

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!

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!

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

wsl

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

mtt

Daily Blog #805: Mount That Thing!

 


Hello Reader,

If you've ever done forensics on modern linux systems disk images you may have encountered the dread that comes with dealing with lots of LVMs (Logical Volume Management) which none of the commercial forensics tools seem to be able to fully handle, yes even Xways.  Well instead of being full of existential dread of having to export, reimport and handle all of these partitions you can take advantage of the command line kung fu of Hal Pomeranz to automate this process for you!

Hal wrote a tool called MTT or Mount That Thing which .. well it's mounts things! You provide it with the linux disk images and it takes care of finding, identifying and mounting all of the LVMs and partitions within it so the data is accessible.  

Overview of the Script

This script is designed to automate the following operations:

  • Mounting disk images (E01 or raw)

  • Handling LVM volumes

  • Automatically identifying and mounting partitions

  • Exporting mounted partitions into E01 format if desired

  • Safely unmounting and cleaning up devices and volumes when finished

All mount operations are performed read-only, with noexec and other conservative options to preserve evidence integrity.


Key Features

Mounting Disk Images

  • E01 support: If the image is in Expert Witness format, the script uses ewfmount to extract the raw image and proceed with analysis.

  • Partition detection: For full disk images (e.g., MBR), it uses losetup -P to enumerate partitions and identify associated file systems.

  • LVM support: Detects and activates volume groups, carefully handling potential naming collisions with already mounted LVM volumes.

  • Filesystem recognition: Supports EXT2/3/4, XFS, BTRFS, and FAT file systems, with logic to apply the appropriate mount options for each.

  • Root partition detection: Identifies the likely root partition via fstab or naming heuristics and mounts it first.

  • Command logging: All mount operations are logged to a MOUNTING file within the target directory for reproducibility and audit trails.

Export to E01 Format

When invoked with the -E flag, the script will:

  • Export each mounted partition using ewfacquire

  • Segment the output if required via the -S option (e.g., for 2 GB chunks)

  • Name exports based on their mount point or partition origin to maintain clear context

  • Store exports and logs in an exported/ subdirectory of the target mount path

This is especially useful for archiving or handing off discrete pieces of evidence.

Safe and Comprehensive Unmounting

Using the -U flag, the script will:

  • Unmount all associated filesystems

  • Deactivate volume groups via vgchange -a n

  • Detach all loopback devices with losetup -d

  • Kill any ewfmount processes by unmounting their working directory

This ensures that the analyst can return the system to a clean state after analysis or re-run the script on a new image without residual device conflicts.


Usage Example

Mount and export an image:

./mount_image.sh -d /mnt/evidence -E -S 2147483648 image.E01

Unmount everything cleanly:

./mount_image.sh -U /mnt/evidence

Default behavior places mount artifacts under a mount/ directory, but this can be overridden with the -d flag.

Give it a shot! 

https://github.com/halpomeranz/dfis/blob/master/mtt.sh