Imagine this, it's Tuesday morning, you're sipping your coffee, reviewing the security dashboard.
Everything is great, MFA adoption is at 100% and your privileged accounts are vaulted.
You my dear sir, or ma'am have built a fortress, but right now at this very moment an attacker
is logged into your network as your CF, they are not guessing passwords, they are not trying
to brute force anything, they are calmly browsing your internal finance portal, preparing
to initiate a multi million dollar wire transfer and your entire security stack is silent.
But how? They didn't break in through the front door, they didn't pick the lock, they
walked in with the key, they stole last week, not a password, not an MFA code, but a simple
humble browser cookie, welcome to the identity navigator, this is your host Rohit, today
we are diving into one of the most sophisticated and frankly, terrifying attack vectors in modern
identity security, the past the cookie or token theft attack, this isn't your script
kitty level stuff, this is the technique that nation state actors and elite cybercrime
groups are using to bypass the un-bipassable multi factor authentication.
And as my friend Emma Nagra at Crowdstrike and I were discussing recently, if you are
not planning for this, your zero trust architecture has a gaping hole in it.
I have to call them and out because he was the motivation behind this episode.
Him and I were just talking about random stuff and something he spoke really sparked my curiosity.
So Aman if you are listening, thank you very much.
So over the next few minutes, we are going to get super technical, we will tell the story
of the humble session cookie, how it became our greatest weakness and the incredible new
technologies being built by Microsoft, Octa and Google to finally, finally kill this
attack vector.
We are talking about binding sessions to the very silicon of your device.
So grab your headphones, fire up your terminal and get ready, we are going on a heist.
All right, to understand the heist, you have to understand the loot and the loot in this
case is something called a bearded token and we have spoken about it a few times in this
podcast and funny enough, the TV show Ozark was the motivation behind the episode around
bearded token and this time it's my friend.
So it feels like anytime I speak about tokens, I have to be motivated externally.
Now in the world of identity, there are two fundamental types of tokens, bearded token
and proof of possession tokens.
Now I know what you are, the purest among you are thinking, but Rohit, there are too many
other types of tokens, yep, I'm generalizing a little bit, but at a broad level, we have
two types of tokens, bearded tokens and proof of possession tokens.
Think of it like a bearded token is like a physical key card to a hotel room.
The rule is simple, whoever beards the key card gets in.
The door lock doesn't ask for your photo ID, it doesn't care if you are the registered
guest or if you just found the card lying in the hallway, possession is 100% of the law.
That is how most of the web has worked for decades.
When you log into a website, the server gives your browser a session cookie.
This cookie is a bearded token with every single click you make, every page you visit,
every action you take, the browser beautifully persists or presents this cookie.
See, it says I have the key card, let me in.
And the server who is like a tired, overworked bouncer at a massive nightclub, this glance
is at the ticker, it sees a valid signature, a valid expiration date and it waves you through.
Go on in, it matters.
Before turning to the next of a million requests, that's a pretty famous nightclub.
It's not running a full background check on you every single time you ask for a drink,
it cannot, it's too inefficient.
Technically, this is your cookie header in an STTP request, often containing a jot,
JSON, web token or JWT or some other session identifier.
It's just a fancy name for a string of text, a magic string that grants access.
For a long time, this was fine.
We protected the initial log in with a strong password, then we added MFA, we figured
if the front door is locked, the key card inside is safe, right?
The attacker stopped trying to pick the lock on the front door.
They realized it was easier to just steal the key card from someone who was already inside.
So if the cookie is the key card, how are the bad guys stealing it?
It's not like they can physically reach into your browser or can they?
There are a few primary methods and believe me, they're slick.
First, you have the straight forward smash and grab in for stealer malware.
Think of malware like Redline or YDAR.
This isn't a ransomware that announces itself, it's silent, it's a ghost.
It gets onto a machine, usually through a fishing link or a malicious download and its
only job is to steal credentials.
It goes straight for the cookie jar, the local database files where browsers like Chrome
and Edge store your active session cookies.
It grabs them, zips them up and sends them back to the attacker's command and control server.
The attacker now has a folder full of valid session cookies from dozens of employees.
They can literally just inject these cookies into their own browser and bam, they're locked
in as your employees, but the second method, this one is genius.
It's called the adversary in the middle or AITM fishing.
Imagine the attacker sends you a fishing email, it looks perfect, it's from IT, asking you
to re-authenticate to view a new company policy.
You click the link, the page you land on is a pixel perfect replica of your company's
Microsoft or Octa's login page.
Here is the evil part though, you're not talking to a fake page, you're talking to a proxy.
The attacker's server is sitting in the middle between you and the real login page.
Tools like Evil Gen X makes this terrifyingly easy.
You enter your username, the proxy passes it to the real site.
The real site asks for your password, the proxy asks you for it and passes it on.
The real site sends you an MFA push notification, the proxy waits.
You approve it on your phone, the proxy sees the approval go through.
You sir have now completed a perfectly valid MFA protected login.
The real IDP server satisfied issues a session cookie and sends it to the proxy, obviously
thinking it's your browser.
The attacker's proxy now has your session cookie.
It forwards you to the real document you were meant to see, so you suspect nothing.
But the attacker just hit the jackpot, they have the golden ticket, your post MFA session
cookie.
They can now use it from their own machine anywhere in the world.
You see the problem here, right?
You use the MFA, you did everything right and it didn't matter.
The attacker didn't break MFA, it just waited for MFA to be completed and stole the price
that came after.
Now, the smart people who build the internet have known about this bearer token problem
for a long, long time.
Over a decade ago, a brilliant proposal started making the rounds at the IETF, the internet
engineering task force.
It was called simply token binding.
The idea was elegant.
What if the session cookie wasn't just a standalone key card?
What if it was magically tied to the specific unique connection between the browser and
the server?
Technically, the idea was to tie the STTP session, which is the cookie, to the underlying TLS,
which is the transport layer security channel.
When your browser opens a secure STTPS connection, it establishes a unique encrypted tunnel and
token binding proposed that the browser would generate a unique public-private key pair
for the TLS tunnel.
When the server issued a cookie, it would include a signature proving it was meant for the
browser holding that specific TLS key.
So even if an attacker stole the cookie.
and try to replay it from their machine their TLS connection would be different they wouldn't have the right private key the server would reject the cookie.
It was perfect it's all the problem completely and it went absolutely nowhere because it was a classic chicken and egg dilemma for it to work the browsers needed to implement it like chrome and firefox etc.
They needed to implement it and the servers needed to implement it like Microsoft Google all the big web apps.
The browser vendor said why should we build this if no server supports it and the server vendor said why should we build this if no browsers supported it died a slow silent death.
What a shame it was a cautionary tale in tech standards a perfect solution is useless without adoption it was like a UN resolution that everyone agrees it's fantastic idea but nobody actually bothers to impose or enforce a ghost of what could happen.
Now before I get political which I have no understanding or expertise in I will stick to the session and the tokens and the cookies.
So let's go ahead with the cookies the story doesn't end there because one company was in a unique position to solve the chicken and the problem.
My dream company when I was growing up I always wanted to work for this company this company is Microsoft why because the control the chicken and the egg.
They have the operating system windows and they have the identity provider enter ID formerly known as a georeactive directory so they had everything so they said fine we will do it ourselves of course Microsoft you can and what the built is a masterclass in security architecture it's a feature in enter ID called as token protection.
It's all starts with a special artifact call a primary refresh token or PRT when a user logs into a modern enter joined windows device entry doesn't just issue a regular old token it issues a PRT and this PRT is special because it is cryptographically bound to the device itself using the trusted plate for module or TPM.
Now you would ask me what is a TPM think of it like a tiny grumpy paranoid security guard that lives on a specific or a special chip shoulder it into your computer's motherboard.
This little guard has fun job and one job only to protect secrets.
You can ask the TPM to use a secret key to sign something but you can never ask it to give you the key it it will not under any circumstances let the private key leave the chip quite trustworthy so here is the flow.
You log into windows enter ID issues a PRT the PRT and a private key are generated and that private key stored inside the TPM which locks it down.
Now you try to access an application like say SharePoint your browser needs an access token it goes to entrap with your PRT and says hello Mr. Entra I need a token for SharePoint.
Entra being a zero trust believer says I don't know you do prove you are the rightful owner of this PRT.
So it sends back a non a random string of characters of one time challenge your machine passes this non to the TPM and says hey grumpy sign this for me using the key we stored earlier.
The TPM signs the non with the private key and hands the signature back and your machine sends this signature to enter need right now enter ID checks the signature it knows the public key associated with that PRT and if the signature is valid it proves that the request is coming from the exact same device that the PRT was issued to it's called the proof of position.
Now what happens if an attacker steals the PRT using malware they try to replay it from their machine enter sends them a non and says cool story bro now sign this the attackers cannot they don't have the TPM they don't have the private key and game over the stolen token is a useless string of text.
This is a true session to device binding and you enforce it with a simple check box in a conditional access policy.
It's called always say something like required token protection for sign in sessions.
If you ask me it's the most beautiful thing I've ever seen.
After my wife of course now that's a great story if you live in a pure Microsoft word but what about everyone else what about octa.
Octa doesn't have the luxury of owning the operating system so they had to get creative and their strategy is centered on their endpoint agent octa verify.
Octa's flagship solution here is called octa fast pass the goal is similar prove the user is on a managed trusted device but the mechanism is different it had to be.
With fast pass octa verify on the device registers itself with the octa service during this process it creates a unique cryptographic key pair and stores the private key securely on the device in the keychain or TPM were available.
This effectively enrolls the device as a trusted authenticator so when you go to login instead of just a password the application redirects to octa with sends a challenge.
Octa verify intercepts this uses the device private key to sign the challenge and sends it back.
This is powerful phishing resistant authentication it's a proof of possession check at the front door.
So now every time somebody comes and tells me I cannot this is the solution that I refer them back to because this was absolutely wonderfully done by octa.
Just imagine the engineering brains behind this doing something outside of the Microsoft ecosystem.
But what about the session cookie after you login this is where it gets nuanced for a long time that session cookie was still a bearer token.
To combat this octa has been rolling out layered defenses one is device binding for creating sessions this is a clever trick that ensures the browser that starts the login flow is the same one that finishes it.
Preventing an attacker from intercepting the authorization code in the a it m attack and redeeming it on their own machine.
Most recently or a little bit recently they have introduced something called as as an an IP bindings for sessions their policy says if the session cookie was issued to a user on Comcast in California it should only ever be used for another Comcast IP in California.
If a request suddenly comes from a data center in Romania octa flags it as a species and can terminate the session.
So let's contrast the two philosophies Microsoft approaches it like having a biometric chip embedded in your hand.
Every time you want to do anything get a drink open a door you have to scan your hand the check is continuous and tied to your physical self or in this case the device is silicon.
Octa's approach is like having an incredibly smart bouncer at the main entrance who does a full biometric scan when you first arrive.
Fast pass once you are in the club they are watching you on security cameras looking for suspicious behaviors like you suddenly teleporting from the dance floor to the VIP lounge in another country as and binding now both are massive improvement over the old show it again and walk in model.
Microsoft is arguably more cryptographically pure for session production.
While octa's fast pass provides phenomenal fishing resistant at the point of authentication.
Both need in my opinion but for years this was the state of play you had Microsoft's integrated OS level solution and octa's agent based ecosystem.
But remember that failed token binding standard from years ago well I lied a little when I said it died.
The idea never truly died it just went dormant and now it's back and this time it looks like it's going to work.
It has a new name though device bound session credentials or dbsc.
This time it's not a fake proposal it's a concrete web API being actively developed and shipped by.
Google and Microsoft in Chrome and Edge.
So they learned their lesson.
Instead of waiting for the other side to move,
the two biggest browser vendors are building it together.
So here is our DBSC works.
And it's, are it brilliantly simple.
When you visit a login page, like your IDP,
your browser, if it supports DBSC, tells the server,
"Hey, I can do this new DBSC thing."
It also generates a fresh public private key pair,
just for this website and stores the private key securely.
During login, after you authenticate,
the browser sends the public key to the IDP.
The IDP, instead of issuing a normal session cookie,
issues a special one that is cryptographically bound
to that public key.
Now for every single subsequent request to that website,
the browser automatically and transparently uses
its shared private key to sign a piece of the request.
The server checks this signature on every request.
If it is missing or invalid, it knows the cookie was stolen
and it is being used without the corresponding private key.
It kills the session instantly.
This is the holy grail.
It's the original vision of token binding,
but implemented directly in the browser where it belongs.
It doesn't require a special operating system
or a third party agent.
It just works.
Now when this is fully rolled out,
it would be the death knell for the entire class
of past the cookie attacks.
An attacker can steal the cookie databases all they want.
The cookie will be useless without the device bound
private keys to activate them.
Use it to my ears.
This is the cavalry arriving.
It's the happy ending to our story
where the entire ecosystem, the IDPs and the browsers
finally aligns to fix a fundamental flaw
in how the web works.
Okay, so I don't know about you, but my brain is full.
That was a whirlwind of PRTs and TPMs and DBSCs.
It's super fascinating.
But what does it mean for you?
The I am enthusiast or an I am leader
or somebody on the treadmill or somebody is trying to sleep.
Or maybe taking a stroll in the park.
What do we actually do with this information?
So here is your playbook.
I acknowledge the threat.
The first step is admitting you have a problem.
Past the cookie is not a theoretical attack.
It is happening and it is successful.
Run a threat modeling session and ask the hard questions.
If an attacker stole a valid session cookie for our VPNs
or our primary cloud apps, could we detect it?
Could we stop it?
The answer for most is a terrifying no.
Second, turn on the feature you already own.
If you are a Microsoft Android shop,
you are sitting on a cold mind.
Go into your conditional access policies this week.
Create a new policy targeted at a pilot group of users
and start with the IT admins and executives
and enable the session control that says
required token protection for sign-in sessions.
Test it, monitor it and then start rolling it out.
Don't just buy the tool.
You have to flip the on switch.
You would be surprised how often that's the missing step.
Third, configure your Octa environment.
If you are an Octa shop, your priority is deploying Octa fast pass.
This is your number one defense against AITM fishing.
Everything else can wait.
Mandate it for all users.
No exception lists or requests or groups here.
And then explore the session level controls.
Enable the device binding for creating sessions feature.
And critically configure network based session binding
of ASN or IP.
Be careful here.
Overly strict IP binding can cause a nightmare for users
who travel or work from home.
ASN is often a better balance.
So understand the trade-offs based upon
how your company is structured
and where your users work from.
Or their operating model or their hybrid travel frequently.
What not?
Fourth, watch DBSC like a hawk.
This is the future.
Start asking your vendors about their DBSC support roadmap.
When will your IDP support issuing DBSC bound cookies?
When will your keys as apps support validating them?
This is going to be a standard security baseline
in the next 18 to 24 months.
So be ahead of the curve.
And finally, don't abandon the basics.
None of this incredible token binding technology
absolves you of the need for good old fashioned
and point security.
A compromise device is a compromise device.
If an attacker has root on a machine,
all bets are off.
They can abuse the TPM or steal secrets from memory.
You still need a word class end point detection
and response solution to detect the initial intrusion
and the malware that tries to steal these tokens
in the first place.
This is true zero trust.
This is the next iteration of defense in them.
So how was this billion dollar cookie heist?
A story about a fatal flaw in the foundation of the web
and the incredible engineering that's finally fixing it.
The key takeaway is this.
The era of the simple bearer token is ending.
The future of identity is proof of possession.
We are moving to a word where your identity
is not just what you know or what you have
but where you are cryptographically proven
to be on a specific trusted device.
Is this the end of the story?
Of course not.
This is a perpetual arms race.
As we close this door, attackers will move to the next window.
They might focus more on compromising the device itself
or finding flaws in the TPM
or on exploiting the seams between the different technologies.
Our job is to stay vigilant to keep learning
and to keep building.
Let me know how you felt about this episode.
You can send me an email at
[email protected]
or reach out to me via LinkedIn.
Thank you for listening.
Until next time, this is Rohit, your identity navigator.
(upbeat music)
(upbeat music)
PodcastTranscript AI