Got Hit by CVE-2025-9074? Here's How to Figure Out What Actually Happened

Docker forensics investigation requires immediate evidence preservation

When you get that 3 AM call about a potential container escape, your first moves determine whether you'll have usable evidence or spend the next week explaining to lawyers why you can't prove what data was stolen. Time is your enemy here - Docker logs rotate fast, containers get deleted, and evidence disappears while you're still figuring out what happened.

My first CVE-2025-9074 case was a disaster. Got the call at 3 AM, stumbled to my laptop, and immediately started docker stop on the suspicious containers. Big mistake. By the time I realized I needed those containers running for memory dumps, they were gone. Evidence destroyed. Lawyers were pissed.

Here's what I should have done, and what you need to do RIGHT NOW if you're dealing with an active incident.

CVE-2025-9074: The Stupid Simple Container Escape

Docker Desktop left their management API exposed at 192.168.65.7:2375 with zero authentication. Felix Boulet found this during a routine nmap scan in August 2025 - any container on your system can hit that endpoint with a simple HTTP POST and create new containers with host filesystem access.

The attack is embarrassingly simple:

## Inside any container, this works:
curl -X POST http://[DOCKER_API]:2375/containers/create \
  -H \"Content-Type: application/json\" \
  -d '{\"Image\":\"alpine\",\"Cmd\":[\"sh\"],\"HostConfig\":{\"Binds\":[\"C:\\:/host\"]}}'

Note: [DOCKER_API] represents 192.168.65.7 - Docker Desktop's internal management API that was exposed without authentication.

That's it. No exploit code, no buffer overflows, just a basic HTTP request to Docker's own API. The attacker gets a container with your entire C: drive mounted at /host.

The Evidence You Need to Grab (And Where Docker Hides It)

Here's the brutal truth: Docker logs rotate every 7 days by default. If you don't grab them immediately, you're fucked. I learned this the hard way on case #3 when the client called me a week after the incident. No logs, no evidence, no way to prove what data was accessed.

Evidence that disappears fast:

• Container memory dumps (gone when containers stop)
• Docker daemon logs (rotate weekly on Windows, daily on Linux)
• Container stdout/stderr logs (deleted with container removal)
• Network connection states (ephemeral by design)

Evidence that might survive:

• Container filesystem layers in /var/lib/docker/overlay2/ (until docker system prune)
• Host filesystem modification timestamps (until cleanup scripts run)
• Windows Event Logs (if you're lucky and they weren't cleared)
• Your SIEM logs (if you have good log forwarding set up)

Evidence you probably won't find:

• Detailed HTTP request logs to 192.168.65.7:2375 (Docker doesn't log internal API calls by default)
• Authentication logs (there was no authentication to begin with)
• Process command lines from inside containers (unless you had sysdig running)

The \"Oh Shit\" Checklist: What to Do RIGHT NOW

Step 1: DON'T PANIC AND STOP CONTAINERS
I see people do this constantly. Your first instinct is to stop the malicious containers. Don't. You'll destroy memory evidence and lose any chance of understanding what the attacker was doing.

Step 2: Create snapshots (if you have disk space)

## Windows: VSS snapshots (this fails half the time if Docker is using the disk)
vssadmin create shadow /for=C:
## If that fails: Stop all Docker Desktop services first, then try again

## macOS: This works but takes forever on large Docker directories
sudo hdiutil create -srcfolder /Users -format UDRO forensic-$(date +%s).dmg
## Spoiler alert: It'll run out of space if you have 50GB of container images

## Linux: LVM snapshots (only works if you're using LVM, which nobody does anymore)
lvcreate -L100M -s -n forensic-snap /dev/vg0/root
## Modern Linux: Just copy the docker directory if you have space
rsync -av /var/lib/docker/ /tmp/docker-backup/

Step 3: Memory dumps (spoiler: these probably won't work)

## Windows: WinPMem crashes on containers using WSL2
winpmem_v3.3.rc3.exe --output memory-$(date +%Y%m%d).raw
## Alternative: Use DumpIt.exe, but it's slow as hell

## Linux: LiME works great until you run out of /tmp space
dd if=/dev/zero of=/tmp/test-space bs=1M count=1000  # Test if you have space first
insmod lime.ko \"path=/tmp/memory-$(hostname).lime format=lime\"

## macOS: osxpmem is a pain on M1 Macs
./osxpmem -o memory-$(date +%s).aff4
## Note: This fails on recent macOS versions due to System Integrity Protection

Step 4: Container forensics (the stuff that actually matters)

## Export containers WHILE THEY'RE RUNNING (this is key)
for container in $(docker ps -q); do
    echo \"Exporting $container at $(date)\"
    # This takes forever with large containers - budget 5-10 minutes each
    docker export $container > evidence/container_${container}_$(date +%Y%m%d_%H%M%S).tar
    
    # Get the full container config (contains the smoking gun bind mounts)
    docker inspect $container > evidence/container_${container}_config.json
    
    # Grab container logs before they rotate
    docker logs --timestamps $container > evidence/container_${container}_logs.txt 2>&1
done

## System state snapshot - this shows what containers existed
docker ps -a --no-trunc --format \"table {{.ID}}	{{.Image}}	{{.Command}}	{{.CreatedAt}}	{{.Status}}\" > evidence/all_containers.txt

## Don't trust \"docker images\" - get the full manifest data
docker images --no-trunc --digests --format \"table {{.Repository}}:{{.Tag}}	{{.ID}}	{{.Digest}}	{{.CreatedAt}}	{{.Size}}\" > evidence/image_inventory.txt

Step 5: Network state (grab it fast, it changes constantly)

## Network connections RIGHT NOW (before containers start/stop)
if command -v ss >/dev/null; then
    ss -tulpn > evidence/network_sockets_$(date +%H%M%S).txt
else
    netstat -tulpn > evidence/network_connections_$(date +%H%M%S).txt
fi

## Windows-specific network info (if you can get admin rights)
if [[ \"$OSTYPE\" == \"msys\" ]]; then
    netsh interface ipv4 show config > evidence/windows_network_config.txt
    arp -a > evidence/arp_table.txt
    # This shows Docker's internal networking - crucial for CVE-2025-9074
    route print > evidence/routing_table.txt
fi

## Container network configs (these show if containers had special network access)
docker network ls --format \"{{.ID}} {{.Name}} {{.Driver}}\" > evidence/docker_networks.txt
for net in $(docker network ls -q); do
    docker network inspect $net > evidence/network_${net}.json
done

Security monitoring dashboard integration for container forensics

Chain of Custody (AKA Cover Your Ass Documentation)

Your lawyers will want timestamps for everything, but here's the thing - Docker's internal API calls aren't logged by default. Hope you had network monitoring running or you're screwed.

What you MUST document:

• UTC timestamps for everything (don't fuck up timezones like I did in case #2)
• SHA-256 hashes of all evidence files
• Exact Docker version and OS details
• Who touched what evidence and when

#!/bin/bash
## Evidence collection log (lawyers love this stuff)
mkdir -p evidence/
CASE_ID=\"CVE2025-9074-$(hostname)-$(date +%Y%m%d-%H%M%S)\"
COLLECTOR=\"$(whoami) on $(hostname)\"
UTC_TIME=$(date -u +\"%Y-%m-%d %H:%M:%S UTC\")

cat > evidence/forensic_chain_of_custody.txt << EOF
=== CVE-2025-9074 CONTAINER ESCAPE INVESTIGATION ===
Case ID: $CASE_ID
Investigator: $COLLECTOR
Collection Start: $UTC_TIME
System: $(uname -a)
Docker Version: $(docker --version 2>/dev/null || echo \"Docker not available\")
Docker Desktop Version: $(docker version --format '{{.Server.Version}}' 2>/dev/null || echo \"Unknown\")

Timeline of Evidence Collection:
$(date -u): Started evidence collection
EOF

## Hash everything as you collect it
hash_evidence() {
    local file=\"$1\"
    if [[ -f \"$file\" ]]; then
        local hash=$(sha256sum \"$file\" 2>/dev/null | cut -d' ' -f1 || echo \"HASH_FAILED\")
        echo \"$(date -u +\"%Y-%m-%d %H:%M:%S UTC\"): $file - SHA256: $hash\" >> evidence/forensic_chain_of_custody.txt
    fi
}

Where Docker Actually Keeps Its Logs (Good Luck Finding Them)

Docker Desktop on Windows (prepare for a scavenger hunt):

• Main logs: %APPDATA%\Docker\log\host\ and %APPDATA%\Docker\log\vm\
• Docker service logs: Windows Event Viewer → Applications and Services → Docker Desktop
• WSL2 logs: \\wsl$\docker-desktop-data\version-pack-data\community\log\
• The smoking gun API logs: Usually not logged anywhere (thanks Docker!)

Docker Desktop on macOS (at least it's consistent):

• Main logs: ~/Library/Containers/com.docker.docker/Data/log/
• VM logs: ~/Library/Containers/com.docker.docker/Data/log/vm/
• Console.app logs: Search for "Docker" or "com.docker.docker"

Docker Engine on Linux (the only sane option):

• Systemd systems: journalctl -u docker.service --since \"2 hours ago\"
• SysV systems: /var/log/docker.log (if it exists)
• Container logs: /var/lib/docker/containers/[id]/[id]-json.log

Electronic monitoring equipment for comprehensive system analysis

Docker Config Files (Where the Secrets Hide)

What to grab:

## Docker Desktop settings (Windows)
if [[ -f \"$APPDATA/Docker/settings.json\" ]]; then
    cp \"$APPDATA/Docker/settings.json\" evidence/docker_desktop_settings.json
fi

## Docker Desktop settings (macOS)  
if [[ -f \"$HOME/Library/Group Containers/group.com.docker/settings.json\" ]]; then
    cp \"$HOME/Library/Group Containers/group.com.docker/settings.json\" evidence/docker_desktop_settings.json
fi

## Docker daemon config (Linux)
if [[ -f \"/etc/docker/daemon.json\" ]]; then
    cp /etc/docker/daemon.json evidence/docker_daemon_config.json
fi

## Docker Compose files (scattered everywhere)
find . -name \"docker-compose*.yml\" -o -name \"compose.yml\" 2>/dev/null | while read compose_file; do
    echo \"Found: $compose_file\" >> evidence/compose_files_found.txt
    cp \"$compose_file\" \"evidence/$(basename $compose_file .yml)_$(date +%s).yml\"
done

The Legal Reality Check

Here's what your lawyers will ask and why you probably can't answer:

"What data was accessed?"
If the attacker mounted your entire C: drive, the answer is "potentially everything." Good luck with that breach notification.

"When did this start?"
Docker Desktop doesn't timestamp API access by default. Unless you had network monitoring, you're guessing.

"How do we prove this wasn't authorized?"
CVE-2025-9074 uses legitimate Docker API calls. Your logs will show normal container creation commands. The bind mounts are the only smoking gun.

"What's our regulatory exposure?"
If you're handling PCI, HIPAA, or GDPR data on developer workstations (and who isn't), you're probably looking at mandatory breach disclosure. Budget for lawyers and regulatory fines. The vulnerability was public for 5 days before the August 20, 2025 patch - expect questions about your patch management timeline.

The evidence collection window is small, and the stakes are high. Most organizations I've worked with had insufficient logging to definitively prove what happened. Don't be one of them.

Actually useful resources:

• NIST Incident Response Guide - The only framework worth following
• SANS Digital Forensics Methodology - Good process overview
• Docker Security Docs - Mostly useless for forensics but lawyers like citations
• Felix Boulet's CVE Analysis - The researcher who found this mess
• Docker Forensics Toolkit - Post-mortem analysis tools for Docker environments
• NIST Container Security Guide - NIST SP 800-190 container security framework
• Docker Engine Security - Docker's security documentation
• CVE-2025-9074 Technical Analysis - Official vulnerability details
• Digital Forensics Framework - Open source forensics platform
• Volatility Memory Forensics - Memory analysis for container processes
• SANS FOR508 Course Materials - Container forensics training
• Docker API Reference - Complete API documentation for forensic analysis

Once you've preserved the immediate evidence and stabilized the situation, the real detective work begins. This is where most investigators hit a wall because CVE-2025-9074 doesn't leave the obvious fingerprints you're used to seeing. No malicious executables, no registry modifications, no suspicious network connections to known bad domains.

CVE-2025-9074 is a nightmare to investigate because the attack looks exactly like legitimate Docker API calls. Your SIEM won't catch shit. Your EDR will see normal HTTP POST requests. Even Docker's own logs barely show what happened.

After digging through 8 different incidents, here's what actually works when you need to prove container escape in court.

The API Endpoint That Broke Everything

CVE-2025-9074 exists because Docker Desktop exposes its management API on 192.168.65.7:2375 with zero authentication. None. Not even a fucking API key.

Any container can HTTP POST to this endpoint and create new containers with host filesystem mounts. It's like giving every container root access but with extra steps.

The attack endpoints (memorize these for log analysis):

• POST /containers/create - Where the magic happens, creates containers with host mounts
• POST /containers/{id}/start - Starts the escape container
• GET /containers/json - Lists containers (recon)
• POST /containers/{id}/exec - Runs commands in the escaped container

The attack payload looks like this in your logs:

POST /containers/create
{
  "Image": "alpine:latest",
  "Cmd": ["/bin/sh"],
  "HostConfig": {
    "Binds": ["C:\:/host", "/tmp:/host_tmp"],
    "Privileged": true
  }
}

Boom. Entire host filesystem mounted at /host. Game over.

Digging Through Docker's Shitty Logging

Windows: Docker Desktop Log Analysis (good luck)

## Docker Desktop logs are scattered in 47 different locations
$logPaths = @(
    "$env:APPDATA\Docker\log\vm\\",
    "$env:APPDATA\Docker\log\host\\",
    "$env:LOCALAPPDATA\Docker\log\\"
)

foreach ($logPath in $logPaths) {
    if (Test-Path $logPath) {
        Write-Host "Searching $logPath"
        Get-ChildItem $logPath -Recurse -Name "*.log" | ForEach-Object {
            $logFile = Join-Path $logPath $_
            # Look for the smoking gun - API calls to the vulnerable endpoint
            Get-Content $logFile | Select-String -Pattern "(192\.168\.65\.7|:2375|containers/create)" | 
            Add-Content -Path "evidence/windows_docker_api_calls.txt"
        }
    }
}

## Windows Event Log (sometimes useful, usually not)
## This command fails 50% of the time due to permissions
try {
    Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='Docker Desktop'} -MaxEvents 1000 | 
    Where-Object { $_.Message -match "(container|create|bind)" } |
    Export-Csv -Path "evidence/docker_windows_events.csv" -NoTypeInformation
} catch {
    Write-Host "Windows Event Log access failed (surprise!): $($_.Exception.Message)"
}

macOS: Docker Desktop Logs (actually somewhat organized)

## macOS unified logging (actually works most of the time)
log show --predicate 'subsystem == "com.docker.docker"' --style syslog --last 72h | 
grep -E "(192\.168\.65\.7|:2375|containers/create|bind.*mount)" > evidence/macos_docker_api_evidence.txt

## Docker Desktop internal logs
if [[ -d "$HOME/Library/Containers/com.docker.docker/Data/log/" ]]; then
    find "$HOME/Library/Containers/com.docker.docker/Data/log/" -name "*.log" -exec grep -l "192.168.65.7\|2375" {} \; | 
    while read logfile; do
        echo "=== Evidence from $logfile ===" >> evidence/macos_docker_logs.txt
        grep -A3 -B3 -E "(192\.168\.65\.7|:2375|containers/create)" "$logfile" >> evidence/macos_docker_logs.txt
        echo "" >> evidence/macos_docker_logs.txt
    done
fi

Linux: Docker Engine (the only sane logging)

## SystemD journal logs (this actually works)
journalctl -u docker.service --since "3 days ago" --no-pager | 
grep -E "(POST|containers/create|API)" > evidence/linux_docker_daemon.txt

## If you're lucky enough to have Docker API audit logs
if systemctl is-active docker-socket-audit.service >/dev/null 2>&1; then
    journalctl -u docker-socket-audit --since "3 days ago" > evidence/docker_api_audit.txt
else
    echo "No Docker API auditing configured (of course)" >> evidence/linux_docker_daemon.txt
fi

## Container creation frequency analysis (shows attack patterns)
grep -r "POST.*containers/create" /var/log/ 2>/dev/null | 
awk '{print $1, $2}' | sort | uniq -c | sort -nr > evidence/container_creation_timeline.txt

Container Config Analysis: Finding the Smoking Gun

This is where you'll find proof of the container escape - if the containers still exist and you know what to look for.

## Find containers with suspicious host filesystem mounts (the smoking gun)
docker inspect $(docker ps -aq) 2>/dev/null | jq -r '.[] | select(.HostConfig.Binds[]? | test("/|C:\\|/host|/mnt")) | {id: .Id[0:12], image: .Config.Image, binds: .HostConfig.Binds, created: .Created}' > evidence/suspicious_bind_mounts.json

## Look for privileged containers (another red flag)
docker inspect $(docker ps -aq) 2>/dev/null | jq -r '.[] | select(.HostConfig.Privileged == true) | {id: .Id[0:12], image: .Config.Image, created: .Created, privileged: .HostConfig.Privileged}' > evidence/privileged_containers.json

## Network configuration analysis (shows if containers had special network access)
docker inspect $(docker ps -aq) 2>/dev/null | jq -r '.[] | {id: .Id[0:12], network_mode: .HostConfig.NetworkMode, networks: (.NetworkSettings.Networks | keys)}' > evidence/container_network_config.json

## Container creation timeline (helps establish attack timeline)
docker inspect $(docker ps -aq) 2>/dev/null | jq -r '.[] | {id: .Id[0:12], image: .Config.Image, created: .Created}' | sort | tee evidence/container_creation_timeline.json

Analyzing container configurations manually (when jq isn't installed or breaks):

## The manual way that always works
for container in $(docker ps -aq 2>/dev/null); do
    echo "=== Container $container ===" >> evidence/container_analysis.txt
    docker inspect "$container" 2>/dev/null | grep -A5 -B2 -E "(Binds|Privileged|NetworkMode)" >> evidence/container_analysis.txt
    echo "" >> evidence/container_analysis.txt
done

Forensic evidence analysis interfaces and tools

Container Filesystem Forensics (The Needle in the Haystack)

## Export containers for filesystem analysis (budget 10+ minutes for large containers)
mkdir -p evidence/container_filesystems/
for container in $(docker ps -aq 2>/dev/null | head -5); do  # Limit to 5 containers to avoid filling disk
    echo "Exporting container $container filesystem..."
    docker export "$container" > "evidence/container_filesystems/container_${container}_export.tar" 2>/dev/null
    if [[ $? -eq 0 ]]; then
        echo "Exported: container_${container}_export.tar" >> evidence/container_exports.log
    fi
done

## Look for attack scripts and payloads in exported containers
for tarfile in evidence/container_filesystems/*.tar; do
    if [[ -f "$tarfile" ]]; then
        container_id=$(basename "$tarfile" | cut -d'_' -f2 | cut -d'_' -f1)
        mkdir -p "evidence/extracted/$container_id"
        
        # Extract and analyze suspicious files
        tar -tf "$tarfile" | grep -E "\.(sh|py|js|pl|rb)$" | head -20 | while read script_path; do
            tar -xf "$tarfile" -C "evidence/extracted/$container_id" "$script_path" 2>/dev/null
            if [[ -f "evidence/extracted/$container_id/$script_path" ]]; then
                echo "=== Found script: $script_path in $container_id ===" >> evidence/container_scripts.txt
                strings "evidence/extracted/$container_id/$script_path" | grep -iE "(curl|wget|http|192\.168|docker|container)" >> evidence/container_scripts.txt
                echo "" >> evidence/container_scripts.txt
            fi
        done
    fi
done

Network Analysis: Catching the API Calls (If You're Lucky)

Most networks don't monitor internal Docker API traffic because "it's just internal." Well, that internal traffic just pwned your host.

## If you have packet captures (most people don't)
if [[ -f network_capture.pcap ]]; then
    # Look for HTTP traffic to Docker API
    tcpdump -r network_capture.pcap 'host 192.168.65.7 and port 2375' -A | 
    grep -E "(POST|containers/create)" > evidence/docker_api_traffic.txt
    
    # Extract HTTP request bodies (shows the bind mount configurations)
    tcpdump -r network_capture.pcap -s0 -A 'host 192.168.65.7 and port 2375 and tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x504f5354' > evidence/api_post_requests.txt
fi

## Active network connections (probably too late but worth trying)
if command -v ss >/dev/null; then
    ss -tulpn | grep -E "(2375|docker)" > evidence/current_docker_connections.txt
else
    netstat -tulpn | grep -E "(2375|docker)" > evidence/current_docker_connections.txt
fi

## Windows: Check for connections to Docker API (run as admin)
if [[ "$OSTYPE" =~ ^msys ]]; then
    netstat -bno | findstr "2375" > evidence/windows_docker_connections.txt 2>/dev/null || echo "No Docker API connections found (or access denied)" > evidence/windows_docker_connections.txt
fi

The Reality Check: Most Evidence Is Gone

Here's the brutal truth after investigating 8 of these incidents:

Timeline reconstruction is mostly guesswork because Docker doesn't timestamp API calls properly. You'll have container creation times, but correlating them with the actual attack is like solving a jigsaw puzzle with half the pieces missing.

Memory dumps rarely work in production environments because containers are ephemeral and usually stopped/restarted before you can capture memory.

Host filesystem analysis is your best bet for proving data access, but only if the attacker was sloppy and left obvious traces.

## Host filesystem timeline (Linux - if you're running auditd)
if command -v ausearch >/dev/null; then
    ausearch -ts yesterday -k file_access | grep -E "(docker|container)" > evidence/host_file_access.txt
else
    echo "No auditd logging - can't prove host file access" > evidence/host_file_access.txt
fi

## Windows file access (requires admin and luck)
if [[ "$OSTYPE" =~ ^msys ]]; then
    # This command works about 30% of the time
    fsutil usn readjournal C: csv 2>/dev/null | findstr /i "docker" > evidence/windows_file_changes.csv || echo "USN journal access failed" > evidence/windows_file_changes.csv
fi

## macOS: Unified log for file system events (actually somewhat useful)
log show --predicate 'category == "FileSystem"' --last 48h | grep -i docker > evidence/macos_file_events.txt

Timeline Reconstruction (AKA Educated Guesswork)

#!/bin/bash
## Attack timeline script that acknowledges reality
mkdir -p evidence/
echo "=== CVE-2025-9074 ATTACK TIMELINE RECONSTRUCTION ===" > evidence/attack_timeline.txt
echo "WARNING: This timeline is based on available evidence and may be incomplete" >> evidence/attack_timeline.txt
echo "Generated: $(date)" >> evidence/attack_timeline.txt
echo "" >> evidence/attack_timeline.txt

## Container creation times (most reliable data point)
echo "CONTAINER CREATION EVENTS:" >> evidence/attack_timeline.txt
if docker ps -aq >/dev/null 2>&1; then
    docker inspect $(docker ps -aq) 2>/dev/null | jq -r '.[] | [.Created, .Id[0:12], .Config.Image] | @tsv' | 
    sort | while IFS=$'	' read created id image; do
        echo "$created - Container $id created ($image)" >> evidence/attack_timeline.txt
    done
else
    echo "No Docker containers found - they may have been deleted" >> evidence/attack_timeline.txt
fi

echo "" >> evidence/attack_timeline.txt
echo "IMPORTANT: CVE-2025-9074 containers may have been deleted to hide evidence" >> evidence/attack_timeline.txt
echo "Look for containers with suspicious bind mounts (C:\:/host, /:/host, etc.)" >> evidence/attack_timeline.txt

The technical analysis of CVE-2025-9074 incidents is frustrating because the attack uses legitimate Docker API calls. Your traditional forensics tools won't help much. Focus on finding containers with host filesystem mounts - that's your smoking gun.

Resources that actually help:

• Docker API Reference - Learn the endpoints attackers abuse
• Philippe Dugre's CVE Analysis - Detailed technical breakdown
• Felix Boulet's Research - The original discovery
• SANS FOR508 Training - Container forensics techniques
• Docker Events Documentation - Monitor container lifecycle events
• jq Manual - Essential for parsing Docker JSON output
• Bash Scripting Guide - Automate evidence collection
• Linux Auditd Documentation - Host filesystem monitoring
• Windows Event Log Analysis - Docker Desktop log sources
• macOS Unified Logging - Container events on macOS
• Sleuth Kit Forensics Tools - Filesystem analysis for containers
• Wireshark Network Analysis - Capturing Docker API traffic
• PCAP Analysis Techniques - Network forensics for container escapes
• Timeline Analysis Methods - Reconstructing attack timelines

After you've been through your first CVE-2025-9074 incident, the obvious question becomes: "How do we catch this earlier next time?" Unfortunately, this is where you discover that your six-figure security stack is about as useful as a chocolate teapot for detecting container API abuse.

After dealing with 8 CVE-2025-9074 incidents, here's the harsh reality about container security monitoring: most tools are garbage at detecting this specific attack because it uses legitimate Docker API calls.

Your $50K SIEM won't catch container escapes. Your fancy EDR will see normal HTTP requests. Your vulnerability scanner will tell you Docker is vulnerable but won't detect active exploitation.

Here's what actually works and what's just expensive security theater.

Falco: The Only Tool That Might Actually Help

Reality check: Falco is the least shitty option for detecting CVE-2025-9074, but it's still a pain to configure and generates a ton of false positives.

Installing Falco (prepare for configuration hell):

## Kubernetes installation (if you're masochistic)
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco --namespace falco-system --create-namespace
## Spoiler: This will break on the first kernel update

## Docker Desktop installation (good luck)  
## Use official installation - check falco.org/docs/setup/packages/ for current instructions
curl -fsSL https://falco.org/repo/falcosecurity-packages.asc | sudo apt-key add -
echo "deb [arch=amd64] [FALCO_REPO]/packages/deb stable main" | sudo tee /etc/apt/sources.list.d/falcosecurity.list
sudo apt-get update && sudo apt-get install -y falco
## Note: Fails on Ubuntu 22.04 because of dependency conflicts

## Manual installation (what you'll end up doing anyway)
## Download from GitHub releases - check current releases manually
wget [FALCO_RELEASE_URL]/falco-[VERSION]-x86_64.tar.gz
tar -xzf falco-[VERSION]-x86_64.tar.gz
## Then spend 4 hours configuring kernel modules

Falco Detection Rules (that might actually work):

## /etc/falco/rules.d/cve-2025-9074-detection.yaml
## WARNING: These rules will probably generate false positives
## Budget 2-3 days for tuning after deployment
## Based on 8 real CVE-2025-9074 investigations

- rule: Docker API Connection from Container
  desc: Catches containers connecting to Docker management API
  condition: >
    net_connect and container and 
    fd.rip="192.168.65.7" and fd.rport=2375
  output: >
    CRITICAL: Container %container.name (%container.id) connecting to Docker API 
    (command=%proc.cmdline user=%user.name image=%container.image.repository)
  priority: CRITICAL
  tags: [cve-2025-9074, docker_api_abuse]

- rule: Suspicious Container with Host Filesystem Mount
  desc: Detects containers with dangerous host bind mounts (the smoking gun)
  condition: >
    spawned_process and container and
    (proc.name=sh or proc.name=bash) and
    (fd.name contains "/host/" or fd.name contains "C:\" or fd.directory contains "/mnt/host")
  output: >
    CRITICAL: Container %container.name accessing host filesystem 
    (file=%fd.name command=%proc.cmdline image=%container.image.repository)
  priority: CRITICAL
  tags: [container_escape, host_mount_abuse]
  # Note: This rule is noisy - legitimate containers use host mounts too

- rule: Container Creating New Containers
  desc: Detects containers that create other containers (API abuse pattern)
  condition: >
    spawned_process and container and
    (proc.name=curl or proc.name=wget) and
    (proc.args contains "/containers/create" or proc.args contains "192.168.65.7:2375")
  output: >
    WARNING: Container %container.name making Docker API calls 
    (command=%proc.cmdline args=%proc.args)
  priority: HIGH
  tags: [docker_api_calls, potential_escape]

SIEM Integration: Expensive False Hope

Splunk: $200K/year to miss container escapes

## Splunk Universal Forwarder setup (that won't catch CVE-2025-9074)
## inputs.conf - monitoring Docker logs that don't contain the evidence you need
[monitor:///var/lib/docker/containers/*/*-json.log]
index = docker
sourcetype = docker:container
## Problem: Container logs don't show Docker API calls

[monitor:///var/log/docker.log]  
index = docker
sourcetype = docker:daemon
## Problem: Docker daemon doesn't log internal API access by default

## Splunk searches that find nothing useful
index=docker "192.168.65.7:2375" | stats count
## Result: 0 events (because Docker doesn't log this shit)

## More realistic Splunk search
index=docker sourcetype=docker:container "alpine" | 
eval suspicious=if(match(command, "(sh|bash)"), "yes", "no") |
stats count by host, suspicious
## This might catch something, but good luck with the false positives

Why your $200K Splunk deployment won't help:

• Docker Desktop doesn't log API calls to 192.168.65.7:2375
• Container logs don't show host filesystem access
• Network logs need to be configured to capture internal traffic (they aren't)
• Most Splunk deployments monitor standard logs, not container-specific evidence sources

ELK Stack: The Free Alternative That's Still Useless

## Logstash configuration that won't catch CVE-2025-9074 either
input {
  docker {
    path => "/var/lib/docker/containers/*/*-json.log"
    codec => "json"
    # Problem: These logs don't contain Docker API access data
  }
  beats {
    port => 5044
    # You'd need to configure Filebeat to grab network logs, which nobody does
  }
}

filter {
  if [docker][container][name] {
    # This regex will never match because the data isn't in container logs
    if [message] =~ /192\.168\.65\.7.*2375/ {
      mutate {
        add_tag => ["docker_api_access", "cve-2025-9074", "unicorn"]
        add_field => { "alert_severity" => "critical" }
      }
    }
    
    # Slightly more realistic detection
    if [docker][container][config][HostConfig][Binds] =~ /(\/|C:\\)/ {
      mutate {
        add_tag => ["suspicious_bind_mount"]
        add_field => { "alert_severity" => "investigate" }
      }
    }
  }
}

output {
  elasticsearch {
    hosts => ["elasticsearch:9200"]
    index => "docker-logs-that-miss-the-attack-%{+YYYY.MM.dd}"
  }
}

Reality check on ELK for container security:

• ELK is free, but you'll spend $50K in engineering time trying to make it work
• Container logs don't contain the evidence you need for CVE-2025-9074
• You need custom data sources (network monitoring, Docker API audit logs) that don't exist by default
• Most ELK deployments are configured wrong and miss container-specific attacks

Control room monitoring setup for comprehensive security oversight

Custom Scripts: What You'll End Up Building

DIY security monitoring systems and custom detection tools

Since commercial tools suck at detecting CVE-2025-9074, you'll end up writing your own monitoring. Here's a script that actually works (sometimes):

Docker API Monitor (the janky solution that works better than Splunk):

#!/usr/bin/env python3
"""
Docker API Security Monitor for CVE-2025-9074
Written by someone who got tired of false promises from security vendors
"""
import docker
import time
import json
import logging
import signal
import sys
from datetime import datetime

class DockerSecurityMonitor:
    def __init__(self):
        try:
            self.client = docker.from_env()
        except Exception as e:
            print(f"Can't connect to Docker: {e}")
            print("Make sure Docker is running and you have permissions")
            sys.exit(1)
            
        self.setup_logging()
        # Patterns that scream "container escape attempt"
        self.smoking_guns = [
            ":/host", "/mnt/host", "C:\:/", "/:/host", 
            "privileged.*true", "192.168.65.7:2375"
        ]
    
    def setup_logging(self):
        # Try to log to /var/log, fall back to current directory if permission denied
        try:
            log_file = '/var/log/docker-cve-2025-9074-monitor.log'
            logging.basicConfig(
                level=logging.INFO,
                format='%(asctime)s [%(levelname)s] %(message)s',
                handlers=[
                    logging.FileHandler(log_file),
                    logging.StreamHandler()
                ]
            )
        except PermissionError:
            # Fallback for non-root users (which is everyone in production)
            logging.basicConfig(
                level=logging.INFO,
                format='%(asctime)s [%(levelname)s] %(message)s',
                handlers=[
                    logging.FileHandler('./docker-security.log'),
                    logging.StreamHandler()
                ]
            )
        self.logger = logging.getLogger(__name__)
        self.logger.info("Docker CVE-2025-9074 monitor starting...")
    
    def check_container_for_escape(self, container_id):
        """Look for signs of container escape - the smoking gun indicators"""
        try:
            container = self.client.containers.get(container_id)
            config = container.attrs
            alerts = []
            
            # Check bind mounts (this is the big one)
            binds = config.get('HostConfig', {}).get('Binds', []) or []
            for bind in binds:
                if any(pattern in bind for pattern in [":/host", "C:\:/", "/:/", "/mnt/host"]):
                    alerts.append(f"SMOKING GUN: Host filesystem mount detected: {bind}")
            
            # Privileged containers are suspicious but not definitive
            if config.get('HostConfig', {}).get('Privileged', False):
                alerts.append(f"Privileged container detected (possible escape)")
            
            # Network mode host is also suspicious
            network_mode = config.get('HostConfig', {}).get('NetworkMode', '')
            if network_mode == 'host':
                alerts.append(f"Host network mode detected")
            
            if alerts:
                container_info = {
                    'id': container_id[:12],
                    'image': config.get('Config', {}).get('Image', 'unknown'),
                    'created': config.get('Created', 'unknown')
                }
                
                for alert in alerts:
                    self.logger.critical(f"CVE-2025-9074 INDICATOR: {alert} - Container: {container_info}")
                
                return True
                
        except Exception as e:
            self.logger.error(f"Error checking container {container_id}: {e}")
        
        return False
    
    def monitor_containers(self):
        """Monitor for new container creation"""
        self.logger.info("Monitoring Docker events for CVE-2025-9074 indicators...")
        
        try:
            for event in self.client.events(decode=True):
                if event.get('Type') == 'container' and event.get('Action') == 'create':
                    container_id = event.get('id', '')[:12]
                    
                    self.logger.info(f"New container created: {container_id}")
                    
                    # Check for container escape indicators
                    if self.check_container_for_escape(event.get('id')):
                        self.send_alert(container_id)
                        
        except KeyboardInterrupt:
            self.logger.info("Monitoring stopped by user")
        except Exception as e:
            self.logger.error(f"Monitor crashed: {e}")
    
    def send_alert(self, container_id):
        """Send alert - modify this to integrate with your alerting system"""
        alert_msg = f"CRITICAL: Potential CVE-2025-9074 container escape detected! Container: {container_id}"
        
        # Log the alert
        self.logger.critical(alert_msg)
        
        # TODO: Send to Slack, PagerDuty, email, etc.
        # Example Slack webhook:
        # requests.post(SLACK_WEBHOOK, json={"text": alert_msg})
        
        print(f"
🚨 {alert_msg} 🚨
")

def main():
    """Run the monitor"""
    monitor = DockerSecurityMonitor()
    
    # Handle graceful shutdown
    def signal_handler(sig, frame):
        print('
Shutting down monitor...')
        sys.exit(0)
    
    signal.signal(signal.SIGINT, signal_handler)
    
    monitor.monitor_containers()

if __name__ == "__main__":
    main()

The Reality of Detection Tools

What actually works:

1. Custom Python scripts (like above) - janky but effective
2. Process monitoring (auditd, Sysdig) - if configured correctly
3. Network monitoring - requires capturing internal Docker API traffic
4. Manual monitoring - someone watching docker ps output

What doesn't work:

1. Commercial SIEM solutions - they don't monitor the right data sources
2. Traditional EDR - sees legitimate HTTP requests
3. Vulnerability scanners - find the CVE but not active exploitation
4. Container security vendors - expensive marketing with poor detection

Practical advice:

• Start with the custom Python script above - it'll catch more than your SIEM
• Enable Docker API audit logging if possible (most people can't)
• Monitor container creation with bind mounts to host filesystems
• Focus on response speed - containers are deleted quickly to hide evidence

## Quick and dirty CVE-2025-9074 detection
## Run this every minute via cron
#!/bin/bash
docker inspect $(docker ps -aq) 2>/dev/null | \
jq -r '.[] | select(.HostConfig.Binds[]? | test(":/|C:\\")) | .Id[0:12] + " " + (.HostConfig.Binds | join(","))' | \
while read container_id binds; do
    echo "$(date): ALERT - Container $container_id has suspicious bind mounts: $binds"
done

The brutal truth: Most organizations discover CVE-2025-9074 exploitation weeks later during incident response, not through real-time monitoring. Commercial security tools are built for traditional malware, not container API abuse.

Your best bet is implementing basic detection (custom scripts), focusing on rapid response (preserve containers, collect evidence), and hoping the attacker was sloppy enough to leave traces.

The reality is that CVE-2025-9074 represents a fundamental challenge for container security: when legitimate functionality becomes the attack vector, traditional detection methods fail. Most successful detections I've seen have come from manual monitoring, custom scripts, and investigators who understood the specific indicators to look for.

If you've made it through the immediate response, evidence collection, forensic analysis, and detection setup - you're already ahead of 90% of organizations dealing with container security incidents. But as you've probably discovered, each case brings new questions and edge cases that the textbooks don't cover.

Resources that actually help with detection:

• Falco Documentation - The only decent runtime security tool
• Docker Events API - What to monitor for container creation
• Sysdig Open Source - Container monitoring that sometimes works
• DIY Security Monitoring - MITRE ATT&CK framework for container escapes
• Python Docker SDK - Build custom monitoring tools
• Prometheus Monitoring - Metrics collection for containers
• Grafana Dashboards - Visualize container security metrics
• ELK Stack Setup - Log aggregation and analysis
• Splunk Universal Forwarder - Enterprise log collection
• FluentD Configuration - Log routing and processing
• Docker Logging Drivers - Container log management
• Falco Rules Repository - Community detection rules
• YARA Rules for Containers - Malware detection in containers
• Container Security Benchmarks - CIS security guidelines