Cookie-Bite: The New Threat to MFA-Protected Microsoft Sessions via Browser Extensions

Well, lock up the cookies and hide your milk, because there’s a new heist in town—and it’s got a taste for your MFA-protected Microsoft sessions. Security researchers from Varonis have just dropped a proof-of-concept that makes today’s browser extension landscape about as trustworthy as a used car lot in a blackout. The attack? “Cookie-Bite.” The method? Leveraging a Chrome extension to quietly steal those juicy session cookies from Azure Entra ID and, as a result, punch right through your fortress of multi-factor authentication like it’s made of wet paper towels.

The Art of the (Cookie) Steal​

Let’s start by recognizing: stealing cookies is hardly the new bad-boy in the cybercrime playbook. Infostealers and adversary-in-the-middle phishing are basically built on the premise of prying session tokens from unsuspecting users and joyriding their accounts until the tokens expire or panic strikes. That said, Cookie-Bite introduces a new, disturbingly elegant flavor: a browser extension, equal parts stealth and persistence, that turns Chrome into a session cookie turnstile.
The practical upshot? Even users who diligently complete their MFA prompts, pat themselves on the back, and get on with their day are no safer than someone handing out spare keys on a city bus. Because once a rogue extension is in the mix, “defense in depth” becomes a quaint phrase you might see engraved on old IT helpdesk mugs.

Azure Entra ID: The New Cookie Jar​

If you haven’t met Azure Entra ID—which Microsoft bills as its robust, cloud-based identity service for IAM—you’re likely the envy of IT professionals everywhere trying to keep up with Azure’s expanding identity jungle. Here, the tasty session tokens are ESTAUTH and its long-haul cousin, ESTSAUTHPERSISTENT.

• ESTAUTH: This is the sprinter—transient, valid for one browser session (up to 24 hours) or until the app is closed. It means you’ve authenticated and cleared MFA, so you’re good to go.
• ESTSAUTHPERSISTENT: This one’s in it for the marathon—a persistent cookie that sticks around for up to 90 days, forged when “Stay signed in” is enabled, or when Azure’s Keep Me Signed In (KMSI) policy is in play.

What’s more is that, while the PoC focuses on Microsoft session tokens, it can be easily ported to target the cookies behind Google, Okta, AWS, and basically any service with high-stakes session management. In the world of cloud identity, one person’s trophy token is another’s golden ticket.
And yet, in this war of attrition, these cookies—meant to smooth the login process without bombarding users with constant authentication—become the chink in our digital armor. It’s a cruel irony: convenience, as always, makes a delightful meal for enterprising attackers.

PoC: Not Just Proof, but an Instruction Manual for Mayhem​

So how does Cookie-Bite work in practice? Varonis’ team crafted a Chrome extension that’s technically legitimate (in code structure, not ethics). Its core routine is this: lurk quietly for login events, specifically those matching Microsoft login URLs, then gleefully siphon off all cookies scoped to login.microsoftonline.com, filter out the prized tokens, and exfiltrate them using—wait for it—a Google Form.
Yes, the tool that HR uses to collect your favorite lunch options, repurposed for digital skulduggery. If nothing else, we should all be grateful they didn’t choose SurveyMonkey. Crowdsourced credential theft is not a path we need to explore.
And in a twist that will leave security vendors weeping into their SIEM dashboards, when Varonis packed their extension file (CRX) and scanned it on VirusTotal, not a single detection engine raised an eyebrow. Let’s just say threat actors everywhere are probably having a little internal party, complete with browser developer mode and some fresh PowerShell scripts.

Keeping Persistence... Persistently​

You’d be forgiven for thinking that getting a malicious extension past the gates is the hard bit. But Varonis doesn’t stop there. Once in, the attacker can deploy a PowerShell script, handily triggered by Windows Task Scheduler, to make sure that the unsigned, devious extension reinjects itself every time Chrome blinks awake.
This is persistence with a vengeance. Even a reboot, a browser restart, or accidentally closing 84 tabs (don’t act like you haven’t) won’t stop the extension from reappearing like a stubborn piece of spyware.
So as you marvel at the seamless integration of developer tools, PowerShell, and Windows’ penchant for running “just one more scheduled task,” spare a thought for the beleaguered endpoint managers who now have yet another vector to contain.

Cookies Out, Tokens In: The Attacker’s Homecoming​

Once the cookie tokens are whisked away to some attacker’s spreadsheet, injecting them into a browser session is remarkably easy. Using tools like the highly legitimate (and probably well-intentioned) Cookie-Editor Chrome extension, an adversary can simply browse over to login.microsoftonline.com, drop in the stolen cookies, refresh, and presto: Azure treats them as authenticated. MFA? What MFA?
A hacker’s idea of “single sign-on” is everyone using the same set of stolen cookies.
From that new vantage point, attackers can:

• Use Microsoft Graph Explorer to enumerate users, election-style.
• Snooze in every channel of Teams, reading or sending messages.
• Open up Outlook Web and read, download, or forward every last bit of email.

And if you were hoping things stopped at basic data exfiltration, sorry—it goes deeper. With third-party tools like TokenSmith, ROADtools, and AADInternals, the attacker can escalate privileges, register unauthorized applications, or move laterally faster than you can hit “rotate password.”

The Unseen Implications for IT Pros​

At this point, every IT pro who’s spent the last year championing zero trust, device management, or tight conditional access policies should be feeling both vindicated and terrified. The flexibility of browser extensions—as both productivity tools and unwitting malware delivery vehicles—has always been a double-edged sword, but Cookie-Bite sharpens it to a fine, faintly glowing point.
There’s a lesson here: browser security is not an isolated concern. Your cloud identity stack, your device management policies, and that “just one custom script” sitting in someone’s startup folder are now all part of the same risk equation. If any part of the chain is weak, attackers won’t hesitate to exploit it for persistent, MFA-busting access to your environment.

Defense: It’s Already a Cat-and-Mouse Game​

Now, to Microsoft’s credit, their detection mechanisms are not asleep at the wheel. When Varonis simulated login attempts in their PoC—using a VPN, yet another modern life necessity—the logins were flagged as “atRisk.” This makes monitoring for abnormal sign-ins a critical component of any defense strategy. Of course, merely being “flagged” is cold comfort when the attacker has already embedded themselves in your Outlook calendar.
Conditional Access Policies (CAPs) are another must-have. By restricting logins by IP range, device ID, or even custom signals (“Did this Chrome browser just time-travel from Cupertino to Kyiv in 10 minutes?”), organizations can limit the blast radius of a stolen token. If you’re not already wielding CAPs like a seasoned Dungeon Master, now’s the time to learn.
Then there’s the wild west of browser extension management. For Chrome, Google provides ADMX templates—essentially policy controls that allow admins to restrict extension installation to only pre-approved, internally vetted add-ons. Equally important? Lock down Developer Mode. There is no faster way to let malware skip onto your system than to let any user operate Chrome in full developer free-for-all.
And remember: every time you let someone run Chrome in Developer Mode, somewhere in Redmond, a Microsoft PM sheds a single, silent tear.

Chrome Extensions: Blessing, Curse, and Everything in Between​

Like all things in IT, the very flexibility that makes browser extensions so universally beloved is also what makes them unspeakably dangerous. Extensions can request, and be granted, permissions that would make a seasoned systems administrator shudder: full read/write access to browser storage, custom logic on sensitive domains, the ability to exfiltrate data to who-knows-where.
And browser marketplaces? Despite increasingly tight scrutiny, it’s still entirely possible for malicious code to hide in plain sight, or for a perfectly good extension to go rogue after a hostile takeover.
Want a real-world implication? Next time you roll out some nifty HR tool or productivity shortcut as an extension, be ready to answer some very pointed questions from your CISO. Especially if your extension update process is “just trust the vendor, they seem nice.”

The Hidden Dangers: Risk Lurking Beneath the Surface​

Perhaps the most underappreciated risk in the Cookie-Bite scenario is the sheer subtlety of it all. A Chrome extension is easy to ignore, especially if it’s quietly sideloaded through PowerShell scripts running under the radar. Because these extensions aren’t detected by most antivirus products (VirusTotal gave this PoC a clean bill of health), they may persist, churning away in the background for weeks or months—especially if the target’s environment is lax about extension audits and developer privileges.
And as long as so many organizations prioritize patching Windows over curating their browser ecosystem, attackers will continue to have a field day exploiting this “last mile” of security.

Practical Steps: Don’t Just Panic—Plan​

By now, you might be thinking of switching careers or—for those with a stubborn sense of mission—fortifying your Chrome policies. Good plan. Here’s a distilled action list for IT professionals seeking to get ahead of Cookie-Bite and its inevitable copycats:

• Enforce enterprise policies for browser extensions using Chrome’s ADMX controls; allow only signed, company-approved extensions and block Developer Mode for all but a handful of trusted admins.
• Tighten conditional access policies in Azure Entra ID: restrict logins by known IPs, device IDs, or risk signals. Assume every session token is one bad click away from compromise.
• Monitor for abnormal sign-ins and session replays—if possible, using tools that detect location/time anomalies, or sudden bursts of privilege escalation.
• Educate users (and developers) on the perils of unsanctioned extensions. One person’s “nifty productivity hack” is another’s wide-open backdoor to sensitive data.
• Audit your devices regularly for sideloaded or unsigned extensions. Don’t trust and verify.

And, please, stop letting people run PowerShell scripts they found on Reddit.

Will MFA Ever Be Enough?​

This brings us to the uncomfortable truth at the heart of Cookie-Bite: even multi-factor authentication—the security panacea du jour—isn’t enough if attackers can simply sidestep it with valid session cookies. MFA is still critical, but “session hardening” and context-aware access controls are the next battleground.
Imagine treating your session tokens like the fragile, high-value assets they are. Force reauthentication for suspicious access, regularly expire persistent cookies, and keep a close eye on who’s asking for a login from that Chrome instance with a suspiciously shiny set of extensions.

Humanity, Convenience, and Security: The Eternal Struggle​

If there’s a take-home lesson for the broader IT crowd, it’s this: every convenience comes with a cost. And in the browser extension market, the cost is sometimes your entire cloud workload. Security teams need to stop thinking of browsers as “just another app” and start treating them like privileged middleware sitting atop the most sensitive interfaces in the modern enterprise.
At the same time, let us not forget the average user—who, much like the Cookie-Bite attacker, just wants a session that persists and never worries about another login prompt again. Sorry, users, but the age of “set-and-forget” is over. The only thing that should persist for 90 days is a healthy respect for session management best practices.

Looking Ahead: What’s Next for Browser Attacks?​

Browser-based attacks are only getting trickier. With Chrome extensions offering both incredible productivity and an open invitation for abuse, the days of trusting your browser to serve as a loyal gatekeeper are behind us. Cookie-Bite is a warning shot—an indication that the next generation of attackers won’t bother with spearfishing for passwords when the cookie jar is easier to crack and yields a much sweeter reward.
Microsoft, Google, AWS, and Okta will, no doubt, continue to harden their session and authentication practices. But IT shops everywhere would do well to remember: the next disaster might begin with a single click to “Add Extension.”
So, next time you’re auditing your security stack, spare a thought for those humble browser cookies sitting in every employee’s Chrome instance. They might just be the most valuable asset you’ve got—and the riskiest.
And remember, if your Chrome browser asks you to “stay signed in,” politely decline—and maybe, just maybe, pass on the dessert.

---

Source: BleepingComputer Cookie-Bite attack PoC uses Chrome extension to steal session tokens