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 #804: Introducing Puck!

 

Hello Reader,

I'm excited to share some news today—Evan Anderson, who you might recognize from our Vibe Coding livestreams, has just launched a new product: Puck!

Puck (available at puck.tools) is the result of Evan’s 20 years in cybersecurity, including extensive experience in offensive operations and advanced red team deployments. At its core, Puck simulates a threat actor within your network with one simple mission: to get back home.

But let’s be clear—Puck isn’t an automated pentesting framework, a vulnerability scanner, or an attack surface mapping tool. It does just one thing, and it does it exceptionally well: it tests your network's egress controls. Using a wide array of protocols, techniques, and methods—much like a sophisticated command-and-control (C2) tool or real-world threat actor—Puck tries to reach out. If it succeeds, it reports back with the exact methods that worked, alerting you to any changes that may have weakened your defenses.

Puck is especially valuable in environments that require strict segmentation, such as PCI-regulated networks and other high-security zones where internet access is supposed to be tightly controlled. It can be deployed either as a virtual machine or a physical device, running continuously to ensure you're immediately aware of any egress violations caused by network changes.

Check it out at puck.tools—I genuinely think it’s a fantastic tool!

Read More

Daily Blog #718: Building test environments in 2025

Hello Reader,

A while back, I shared a post on LinkedIn about building test environments for simulating attacks and creating better training datasets. This is something I’ve done extensively for both my coworkers and my SANS students. With the discontinuation of Detection Lab several years ago, I started exploring alternatives. After reviewing the issues section of Detection Lab and consulting ChatGPT O1, I’ve identified two promising replacements that are currently being maintained:

---

1. Project ADAZ

Four years ago, Christophe Tafani-Dereeper joined us on the Forensic Lunch to discuss his Azure-supported project for spinning up instrumented networks for testing. According to his GitHub page, it’s still being actively updated. I’ll be revisiting Project ADAZ in my upcoming blog posts to see how it performs today and whether it still meets my needs as it did back then.

Key Features:

• ELK Backend: Provides a robust and widely-used stack for log aggregation, analysis, and visualization.
• Azure Integration: Leverages Azure to create and manage the test environment, making it ideal for organizations already invested in Microsoft’s ecosystem.
• Open Source: Free to use, with full access to the source code for customization.

Limitations:

• Azure Costs: While the software is free, the resources used on Azure (e.g., VMs, storage, bandwidth) can add up quickly.
• Azure Dependency: It’s tightly coupled with Azure, which may not be ideal for those working with other cloud providers or looking for multi-cloud solutions.
• Complexity: Initial setup and configuration may require familiarity with Azure, ELK, and Terraform.It is well documented though and I felt it easy to setup.
  

---

2. Splunk Attack Range

The Splunk Threat Research Team has developed an instrumented network-building script, specifically designed for collecting and analyzing logs with Splunk. It’s another compelling option for creating test environments.

Key Features:

• Broad Platform Support: Works with VirtualBox, Azure, and AWS, offering flexibility across various deployment scenarios.
• Splunk-Centric: Designed to send logs directly to Splunk, enabling quick analysis and visualization.
• Actively Maintained: Updates and support from the Splunk Threat Research Team ensure compatibility with current Splunk releases and threat models.
• Attack Simulations: Pre-configured to simulate adversary techniques using open-source tools like Atomic Red Team, enabling realistic threat scenarios.

Limitations:

• Splunk Dependency: Works best with Splunk as the log receiver, making it less attractive for organizations using alternative log aggregation solutions like ELK.
• Resource Requirements: Environments built with Splunk Attack Range can be resource-intensive, requiring significant compute and storage, especially for larger simulations.
• Learning Curve: Requires familiarity with Splunk configurations and potential tuning for specific use cases.

---

What’s Next?

I’ll be deploying both of these solutions in my test environments to compare their performance, usability, and suitability for various scenarios. Additionally, I’m on the lookout for robust Terraform scripts to build similar environments with cloud-based identity providers (e.g., Azure AD or Google Cloud Identity) instead of traditional local Active Directory.

If you know of any such scripts or have experience with either of these projects, please share your thoughts in the comments below—I’d love to hear your insights!

Also Read: Getting free Azure credits for testing

Read More