Beyond the Weekly Headlines: 30Tbps DDoS, Docker Malware, & 'Double-Tap' Skimmers
Caught the latest Weekly Recap on THN, and while the 30Tbps DDoS attack is grabbing all the headlines (and rightfully so—that volume is terrifying), I'm actually more concerned about the persistence of the 'Double-Tap' skimmers and the new wave of Docker malware.
The 'Double-Tap' technique essentially acts as a dual-layer obfuscation. The first script often looks benign or acts as a distraction, while the second payload executes the actual exfiltration. It’s a nightmare to detect with standard WAFs if you don't have good behavioral analysis in place.
On the container side, we're seeing more malware targeting exposed Docker APIs. If you haven't locked down your daemon sockets, now is the time. I've been auditing our cloud environments and found a few instances where the API was inadvertently exposed on 0.0.0.0.
Here's a quick one-liner I'm using to hunt for suspicious high-CPU containers that might be mining or doing something they shouldn't:
docker ps -q | xargs -I {} docker stats --no-stream --format "table {{.Container}}\t{{.CPUPerc}}\t{{.MemUsage}}"
Regarding that massive DDoS attack—anyone here relying on on-prem scrubbing, or are we all just admitting defeat and routing traffic through cloud scrubbers like Cloudflare or Akamai at this point? 30Tbps feels like it would saturate almost any local pipe instantly.
We shifted to always-on cloud scrubbing last year after a few UDP amplification attacks. It’s not cheap, but trying to mitigate a multi-Tbps attack at the edge of our data center is futile. We use BGP announcements to pull traffic into the scrubbing center when thresholds are breached. As for the Docker malware, definitely look into runtime security tools like Falco. It helps detect the crypto-miner behavior immediately when the container spins up.
On the 'Double-Tap' skimmers, we've had success using Content Security Policy (CSP) in strict report-only mode initially to catch the domains they're exfiltrating to. Usually, the second-stage payload calls out to a new domain that isn't in your allowlist. Also, ensure your integrity checks (Subresource Integrity) are actually enforced; it's the only way to be sure the JS loading hasn't been tampered with.
For Docker, make sure you aren't exposing the daemon on a TCP port without TLS verification. We saw a spike in scans for port 2375 recently. If you must use remote access, tunnel it over SSH instead.
ssh -L /var/run/docker.sock:/var/run/docker.sock user@remote-host
This keeps the socket secure over the encrypted tunnel rather than exposing the raw API to the internet.
Building on Omar's CSP suggestion, DNS monitoring acts as a great safety net for skimmers. We often see the second-stage payloads reaching out to domains generated via algorithms (DGAs) right after the initial script loads.
You can spot this by watching for high entropy queries. Here is a basic KQL query we use to hunt for suspicious long alphanumeric domains:
DnsEvents
| where QueryTimestamp > ago(1h)
| where QueryName matches regex "[a-z]{30,}"
| summarize count() by QueryName
It helps catch the C2 infrastructure before the exfiltration starts.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access