DEV Community

Dishanth
Dishanth

Posted on

You've Been Breached for 3 Weeks. Your SIEM Has No Idea.

The attacker was already inside when the Monday standup happened.

They were there during the Thursday all-hands. They watched the Slack messages. They enumerated the S3 buckets while the security team reviewed last week's alert queue.

Twenty-six days. Average cloud breach dwell time, 2024.

That number should make you uncomfortable. Not in a "we should look into this" way. In a "our entire detection philosophy is wrong" way.


The Lie We've Been Telling Ourselves

Here's the security industry's dirty secret: EDR, SIEM, and GuardDuty were all built for a threat model that no longer exists.

They assume attackers bring something foreign into your environment — a malicious binary, a known-bad IP, an anomalous API call pattern. Catch the foreign thing. Stop the breach.

Scattered Spider didn't bring anything foreign. They used a phone call and valid credentials. They moved through the network with PowerShell and the AWS CLI — tools your own admins use every day. They looked like your team, because they were using your team's tools.

Your EDR saw nothing. Your SIEM had nothing to rule on. GuardDuty was watching for known-bad IPs while the attacker pivoted using a legitimate IAM identity.

This is called Living-off-the-Land. And it's not a sophisticated nation-state technique anymore. Script kiddies are doing it. Because it works.

The tools designed to protect you are functionally blind to the way modern attacks actually operate.

The Only Alert That Can't Lie to You

Somewhere in your environment right now, there's an analyst triaging alerts. Let's say 200 a day. Of those 200:

  • 180 are noise
  • 15 require investigation
  • 4 are actual threats
  • 1 might be a real breach

They don't know which one. Neither do you. Every alert requires the same question: is this actually malicious, or does it just look weird?

Now imagine one alert that eliminates that question entirely.

A honeytoken is a fake credential — a fake AWS access key, a fake database password, a fake API token — that exists nowhere in your legitimate infrastructure. No real system uses it. No real workflow touches it. It was planted specifically to be found by someone who shouldn't be in your environment.

If it fires, the triage is already done.

An attacker found your credentials. They are using them. Right now.

No false positives. No "this might be a misconfigured Lambda." No "let me check if this is the new contractor." The alert firing is the confirmation. This is the only detection in your entire stack where you skip straight from alert to incident response.

That's not an incremental improvement. That's a different category of signal.


What Those 26 Days Actually Look Like

Let's make the dwell time concrete, because "26 days" sounds like a statistic and statistics don't feel real.

Day 1–3: Attacker uses phished credentials to access the environment. Small API calls. Read-only operations. Getting a feel for the layout.

Day 4–7: Enumeration. What's in S3? Which IAM roles exist? What does the VPC topology look like? They're building a map.

Day 8–12: Privilege escalation. They find a role with broader permissions than it should have. They assume it.

Day 13–18: Lateral movement. They're in multiple accounts now. They've found the data.

Day 19–24: Staging. Slow exfiltration designed to look like normal traffic patterns.

Day 25–26: They're done. Or they left a backdoor. You'll find out during the forensics engagement you're about to pay for.

A honeytoken planted in Day 4's enumeration path fires on Day 4. You catch them while they're still reading your S3 bucket names. Before privilege escalation. Before lateral movement. Before exfiltration.

That's the difference between a 26-day breach and a 4-hour incident.


How to Actually Deploy This Today

Not theory. Exact steps.

Move 1: Canary AWS Credentials — 30 minutes

# Create an IAM user that will never legitimately be used
aws iam create-user --user-name svc-backup-restore-prod

# Generate access keys — these get planted, never used legitimately
aws iam create-access-key --user-name svc-backup-restore-prod

# Where to plant them:
# → .env file in an S3 bucket that's "private but not locked down"
# → GitHub Actions secret with a convincing legacy name
# → Secrets Manager entry: "legacy-backup-credentials-DO-NOT-DELETE"
# → Hardcoded in a comment in an internal wiki page

# Detection: EventBridge rule — any API call from this identity
# → SNS topic → PagerDuty → wake someone up immediately
# False positive rate: zero. It fires, you have an active compromise.
Enter fullscreen mode Exit fullscreen mode

Move 2: Canary Files — 1 hour

Go to canarytokens.org. Generate a Word doc or PDF that phones home the instant it's opened — attacker's IP, OS, browser, timestamp.

Name it something irresistible:

  • AWS_Master_Credentials_2024.xlsx
  • VPN_Recovery_Codes_EMERGENCY_BACKUP.docx
  • Executive_Compensation_Confidential_DO_NOT_SHARE.pdf

Drop it in file shares a compromised account can reach. An attacker enumerating a breached file server will open the most interesting-looking file. You'll have their IP within seconds.

Move 3: Ghost Services — 2 to 4 hours

Spin up listeners no legitimate user should ever touch:

  • Fake RDP on an internal subnet
  • Ghost SSH server on an internal IP
  • Fake database endpoint: db-prod-backup-01.internal

They don't need to do anything. Log the connection. Fire an alert. Any connection is malicious by definition.

The MITRE Map Nobody's Filling In

Pull up your ATT&CK coverage heatmap. I'll wait.

Initial Access looks okay. Execution looks decent. Then you hit Discovery and Lateral Movement and the heatmap goes cold.

That's not an accident. Those are exactly the phases where LOTL attacks live — and exactly where signature-based detection fails by design.

Here's what deception covers that your stack doesn't:

Technique What Fires
T1018 — Remote System Discovery Attacker hits decoy host during recon
T1078 — Valid Accounts Honeytoken fires at first credential use
T1083 — File & Directory Discovery Canary file opened during enumeration
T1021.001 — RDP Lateral Movement Ghost RDP logs the connection attempt
T1530 — Cloud Storage Object Access Canary S3 object touched by wrong identity
T1552 — Unsecured Credentials Planted credentials used — case closed

These six techniques represent the exact kill chain of the Scattered Spider breach. Every single one invisible to EDR and SIEM — by design.

Where the Industry Is Heading

The honeypot era is over. The deception grid era is starting.

What's being built now — and what your team should be wiring together — is deception as a trigger layer integrated into your automated response fabric.

The architecture:

Honeytoken fires → SOAR playbook triggers → Identity isolated → CloudTrail history pulled → Full lateral movement chain reconstructed → Analyst reviews a complete picture

By the time a human looks at it, the affected identity is contained, the blast radius is mapped, and the timeline is documented. The analyst isn't triaging. They're reviewing.

Teams running this architecture are catching and containing in under an hour what takes the average org 26 days to even detect. The delta isn't tool budget. It's architecture philosophy.


The Math Is Embarrassing

Canary credentials: 2 hours of your time.
Canary files: 1 hour.
Ghost services: an afternoon.

Total: one engineer-day.

What does a 26-day undetected breach cost?

  • IR retainer activation: $50K–$200K
  • Forensics engagement: $100K+
  • Regulatory notification: legal fees, potential fines
  • Customer communication: reputational damage that doesn't show up on an invoice
  • Whatever walked out the door: priceless, in the worst way

One engineer-day versus a seven-figure incident. That's not a risk calculation. That's negligence math.


Deploy Something Today

Your SIEM is doing its job. Your EDR is doing its job. They were built for a threat model that's ten years old and they're doing exactly what they were designed to do.

The attacker with valid credentials, living off your land, touching only legitimate services — they were never in scope.

Deception doesn't fix your existing tools. It covers what they were never designed to see. And it does it with a signal quality nothing else in your stack can match: if it fires, it's real.

One fake credential file. One ghost service. One canary doc with a name too good to ignore.

Plant them this week. The 26-day breach that doesn't happen won't make the news. But you'll know.


Dishanth C A writes about detection engineering, AI security, and the gap between enterprise security theater and what actually catches attackers. MS Cybersecurity @ Yeshiva University. Currently building at the intersection of SOAR, XDR, and deception technology.

Top comments (0)