SideDoor

The problem

Most breaches are not break-ins. Someone signs in with a stolen session and MFA is never even asked. Once authentication succeeds, the application stops checking who you are and only checks that you hold the session cookie. Steal it and you are the user. Replaying it is one HTTP header, and there is nothing to patch because the app worked exactly as designed.

What I built

A closed lab that reproduces the attack two ways, an adversary-in-the-middle relay and a stolen-cookie replay, and then the detection that catches both. The detection was the hard half and where most of the work went.

• Six context-comparison rules that never read the cookie, comparing issuance context against later use: network origin and ASN, location over time, and TLS/JA4 fingerprint drift.
• Four of the rules ship as Sigma; the two that need arithmetic on coordinates stay in the engine, because a Sigma rule that pretends to do that is worse than no rule.
• Multi-signal correlation: no single rule is a verdict. A session must trip at least two independent signals before it is called a replay, since any one signal can be faked.

The part that taught me the most

Tuning out false positives. A real person moving from home wifi to mobile data looks almost exactly like a theft. Getting the rules to stay silent on that, and writing a test that proves they stay silent, took more care than catching the obvious replay. Anyone can catch an attack in a log full of attacks. Detection engineering is everything you do so it does not fire on a normal Tuesday.

Responsible disclosure

The defensive half is published as an open repository with a full write-up. The attack tooling is withheld by design.