When Your Search Engine Becomes a Surveillance Pipeline

'But we already block extensions by ID using Chrome policies. How could this happen?' 'We told users not to install browser extensions from unknown publishers. Why is this still a problem?' 'We use an enterprise browser extension management tool. Doesn't that catch this?' 'Our DLP tool monitors outbound traffic. Wouldn't it see the data leaving?' These are the questions we hear every week. The answer to all of them is the same: you are protecting against the wrong thing. You are blocking known bad IDs. You are educating users about phishing. You are monitoring traffic at the network layer. What you are not doing is auditing the specific permissions and override declarations in every installed extension. Because extensions can change their behavior after being whitelisted. Because the outbound traffic to the attacker's server looks like a normal search API call. Because the user awareness training covers 'don't click on strange links', not 'don't install an extension that has the same permissions as a legitimate search tool'.

You need to look at three layers, and each layer requires a different role. For security engineers: Audit the chrome_settings_overrides section in every extension's manifest.json. An extension that sets 'search_provider' with a 'search_url' pointing to a domain not owned by the legitimate brand is a red flag. The fake Perplexity extension used perplexity-ai[.]online, not perplexity.ai. Write a script that queries the Chrome Management API for an inventory of installed extensions and cross-references their update URLs and manifest overrides. If you find an extension that overrides search and the search URL does not match the expected domain, treat it as a priority incident. For SOC analysts: Look for DNS queries to domains that are variations of known AI brands but not the exact domain. The attacker's domain for this extension was perplexity-ai[.]online. Look for HTTP requests on port 80 or 443 to such domains with a 'User-Agent' header that matches a browser but where the request body contains a query string that looks like a search term. Legitimate search engines use APIs over HTTPS. A search extension that sends queries over HTTP to a look-alike domain is exfiltrating data. For IT administrators: Use Group Policy or Chrome's browser management to restrict extension installation to a whitelist. But do not stop there. Set a policy that blocks extensions requesting 'declarativeNetRequest' permissions unless explicitly approved. Chrome policy supports this via the 'ExtensionSettings' key with 'blocked_permissions'. Example policy snippet: ```json { "ExtensionSettings": { "*": { "blocked_permissions": ["declarativeNetRequest

Vulnox assessment data from 40 enterprise environments (Q1 2026) reveals the following patterns: Finding 1: 68% of assessed organizations had no browser extension management policy beyond 'no admin rights'. In these environments, users could install any Chrome extension from the store. The remaining 32% had a whitelist, but only 12% audited the permissions of whitelisted extensions after initial approval. Finding 2: The most common mistake teams make is assuming that blocking extensions by ID is sufficient. In 7 out of 10 environments where an extension whitelist existed, the whitelist included extensions that had received permission updates post-approval. Chrome does not notify administrators when an extension's manifest permissions change in an update. The extension can silently add 'declarativeNetRequest' or change its search URL. Finding 3 (counterintuitive): Organizations that invested heavily in DLP and network monitoring often missed browser extension exfiltration because the data left via encrypted HTTPS to a domain that passed initial brand checks. In one assessment of a financial services client, the DLP team had a rule that flagged outbound traffic containing 'perplexity' in the domain. But the fake domain (perplexity-ai[.]online) used a hyphen, which the rule did not catch because it was written for exact string matching. The DLP team assumed they were protected. They were not. Finding 4: The AI branding vector is accelerating. Across Vulnox assessments in 2025-2026, we saw a 300% increase in malicious or deceptive browser extensions that use AI brand names (Perplexity, ChatGPT, Gemini, Claude) to gain trust. The fake Perplexity extension is just one example. The core pattern is always the same: use a legitimate-looking name, request search override permissions, and route traffic through an attacker-controlled logging server.

When an organization discovers a malicious extension like 'Search for perplexity ai', they often make mistakes that extend the breach or create secondary exposure. Mistake 1: Removing the extension without first preserving forensic evidence. The extension's manifest.json, background scripts, and any stored data in chrome.storage.local are critical for understanding what data was exfiltrated and for attribution. If you uninstall the extension immediately, you lose that evidence. Instead, take a forensic image of the user's Chrome profile directory before removal. The path is typically %LOCALAPPDATA%\Google\Chrome\User Data\Default\Extensions\[extension_id] on Windows. Mistake 2: Only focusing on the identified extension. In three Vulnox assessments, we found that a single malicious extension discovery led teams to ignore the search provider override that persisted in Chrome settings even after the extension was removed. The extension had already changed the default search engine in the user's Chrome profile. Simply uninstalling the extension does not revert that change. The override remains, and the browser continues to send queries to the attacker domain. You must also reset the default search engine in Chrome settings or push a policy to enforce a specific search provider. Mistake 3: Assuming that the extension only collected search queries. The fake Perplexity extension also used the 'suggest_url' to capture address bar input character by character. This means it collected URLs typed into the omnibox before the user pressed Enter. Those URLs can include internal application URLs, intranet paths, VPN gateways, and even plaintext credentials if users type them into the address bar. Teams that only rotate credentials for services accessed via search results miss the credential exposure that came from typed URLs. The recovery plan must include a review of all URLs that could have been typed during the infection window.