Context: What we're hearing from security teams
Since Microsoft disclosed the malicious Perplexity AI-branded extension, we've received numerous questions from security teams trying to understand the implications for their environments. These inquiries come from Slack channels, incident response calls, and architecture reviews. They're the real concerns of practitioners who need to brief their CISOs, update policies, and explain to users why that helpful AI search tool isn't as innocent as it seems.
AI branding has become a social engineering vector, with browser extensions as the delivery mechanism. Here's what teams are actually asking.
Q1: Wait, this thing captured every letter I typed before I even hit Enter?
Yes. The extension declared a suggest_url parameter pointing to the attacker-controlled domain perplexity-ai[.]online. In Chromium's architecture, suggestion URLs receive keystroke-level input as you type in the Omnibox. This means every character you entered was transmitted to an intermediary server before any redirect occurred.
This isn't speculation. The extension shipped with server-side code (server.js) that logs all incoming requests, including method, URL, and full HTTP headers. The suggest_url mechanism turns the address bar into a real-time surveillance channel.
For your threat model: This is active keystroke capture, not passive search logging. If users type credentials, internal hostnames, or sensitive queries into the Omnibox, that data transits the attacker's infrastructure before the browser completes the search.
Q2: How did it override my default search engine without asking?
The extension used chrome_settings_overrides in its manifest to force itself as the browser's default search provider:
"is_default": true
Chromium permits this for legitimate use cases, but Google's single-purpose policy states that extensions requesting settings overrides alongside powerful network permissions may violate store guidelines. This extension combined search overrides with declarativeNetRequest capabilities, which is a red flag.
Your enforcement option: Enterprise policy controls can prevent extensions from modifying search settings. Use the DefaultSearchProviderEnabled and DefaultSearchProviderSearchURL policies to lock down the search provider at the organizational level. Users can still install extensions, but they can't hijack search traffic.
Q3: What's the deal with declarativeNetRequest? I thought MV3 was supposed to be more secure.
Manifest Version 3 introduced declarativeNetRequest (DNR) as a privacy-forward alternative to webRequest, which had full visibility into all network traffic. DNR is more restrictive by design, but it's not harmless. This extension requested three DNR-related permissions:
- declarativeNetRequest: Redirects matching requests to attacker-chosen URLs
- declarativeNetRequestFeedback: Monitors which redirect rules fire (confirms exfiltration success)
- declarativeNetRequestWithHostAccess: Combined with host_permissions, enables full interception on the attacker's domain
The extension used DNR to create a two-hop redirect chain: user query → perplexity-ai[.]online (logs everything) → legitimate search engine (user sees normal results). The data theft happens on hop one. The redirect on hop two provides cover.
MV3 is more secure than MV2 for blocking certain legacy abuses, but it didn't prevent this attack. The takeaway: DNR permissions in a search extension should trigger scrutiny, especially when combined with host_permissions to non-vendor domains.
Q4: Could this have stolen credentials or session tokens?
Microsoft's analysis found no evidence of credential theft or token exfiltration in the observed behavior. However, the extension's permissions and architecture create the capability for such activity. It has:
- Host permissions to perplexity-ai[.]online
- Keystroke-level capture via suggest_url
- Full HTTP header logging (confirmed by the shipped server code)
If users typed credentials into the Omnibox (for example, searching for "login to internal-app.company.com"), those strings transited the attacker's server. Whether the operator chose to parse and store them is unknown. The risk exists.
For incident response: If this extension was installed in your environment, treat Omnibox input as potentially compromised. Rotate credentials for any internal systems users might have searched for by name. Review logs for queries containing "login", "password", or internal hostnames.
Q5: How do I find out if anyone in my org installed this thing?
The extension ID is flkebkiofojicogddingbdmcmkpbplcd. Google removed it from the Chrome Web Store, but installed instances persist until users manually remove them.
Detection approaches:
- Endpoint management: Query Chrome extension inventories via your MDM or endpoint agent. Most tools can enumerate installed extensions by ID.
- Browser policy: Use the
ExtensionInstallBlocklistpolicy to block the extension ID retroactively and force removal. - Advanced hunting: If you have Microsoft Defender for Endpoint or similar telemetry, query for the extension ID in browser process data. Microsoft published hunting queries in their disclosure.
Check for the domain perplexity-ai[.]online in your DNS logs or proxy logs. Any queries to that domain indicate the extension was active.
Q6: Why did this extension include its own server code? That's weird, right?
Extremely weird. The extension package included server.js (Node.js proxy) and nginx.conf (web server configuration). Legitimate extensions don't ship with server-side infrastructure code. This suggests one of two scenarios:
- The developer accidentally included their backend code in the extension package (operational security failure).
- The developer intended to distribute a reference implementation for others to deploy similar infrastructure.
Either way, the included code is definitive proof that query interception and logging was architecturally intentional. The server.js file explicitly logs request method, URL, and full HTTP headers. It also proxies suggestion queries to suggestqueries.google[.]com and adds permissive CORS headers (Access-Control-Allow-Origin: *).
The nginx.conf filters CORS origins exclusively to *.oda[.]digital, which appears to be operator infrastructure. This is forensic gold for threat intelligence teams trying to map the campaign's scope.
Q7: What should I tell users about AI-branded extensions?
Frame it around verification, not fear. Users associate AI tools with productivity and legitimacy, which is exactly why attackers use AI branding. Your training should focus on:
- Domain mismatch: The legitimate Perplexity AI service is at perplexity[.]ai, not perplexity-ai[.]online. Typosquatted domains are a primary indicator of spoofing.
- Permission scrutiny: A search assistant doesn't need declarativeNetRequest or host_permissions to arbitrary domains. If an extension requests network manipulation capabilities, ask why.
- Publisher verification: Check the extension's developer field in the Chrome Web Store. Legitimate vendors publish under verified accounts with established histories.
Make it concrete: "If the extension's domain doesn't match the vendor's website, don't install it. If it asks for permissions that seem unrelated to its stated purpose, don't install it."
Q8: What's our policy response? We can't ban all extensions.
You don't need to. Implement a tiered approach:
Tier 1: Organizational allow-listing
Use the ExtensionInstallAllowlist policy to permit only vetted extensions. This is the gold standard for regulated environments but requires ongoing maintenance.
Tier 2: Block high-risk permissions
Use ExtensionSettings policy to block extensions requesting declarativeNetRequest, webRequest, or host_permissions to <all_urls>. This catches most surveillance-capable extensions without manual review.
Tier 3: Lock search settings
Enforce DefaultSearchProviderEnabled and DefaultSearchProviderSearchURL to prevent extensions from overriding search. Users can install extensions, but they can't hijack traffic.
Tier 4: Monitoring
Even with controls in place, monitor for unauthorized extensions and DNS queries to non-standard search domains. Behavioral signals matter.
The goal isn't to eliminate risk entirely. It's to make the attack cost higher than the attacker's expected return.
Where to go for more
Microsoft's full disclosure includes indicators of compromise, advanced hunting queries, and detailed manifest analysis. Google's extension policy documentation explains the single-purpose policy and permission justification requirements. For broader context on browser extension threats, MITRE ATT&CK includes techniques T1176 (Browser Extensions) and T1539 (Steal Web Session Cookie).
If you're updating your extension policy, start with the CIS Google Chrome Benchmark or the NSA's Chromium hardening guidance. Both provide specific policy recommendations for enterprise deployments.
The threat isn't new. The branding is.
