Browser Extensions as Wiretaps: Analyzing the 'Perplexity' Clone Incident
Just came across the Microsoft report regarding the malicious Chrome extension impersonating Perplexity. The technique used here is particularly nasty: it abused the chrome.webRequest API to intercept traffic at the address bar level, logging keystrokes before forwarding the request to the actual search engine.
This is a classic example of a "search hijacker" but with significantly higher fidelity regarding data capture. Since Google removed it after disclosure, we need to focus on detection for the next iteration. The extension acted as a local proxy, so you might see DNS requests to non-Google domains immediately following a user typing in the Omnibox.
For those hunting this in your environments, I recommend auditing extension permissions. Any extension requesting "" access or specific host permissions for search engines should be scrutinized.
Here is a quick script to dump installed extension IDs and versions for forensic analysis:
$ExtPath = "$env:LOCALAPPDATA\Google\Chrome\User Data\Default\Extensions"
Get-ChildItem $ExtPath -ErrorAction SilentlyContinue | ForEach-Object {
$Id = $_.Name
$VersionPath = Get-ChildItem "$ExtPath\$Id" | Select-Object -First 1
$Manifest = Get-Content "$ExtPath\$Id\$($VersionPath.Name)\manifest." -Raw | ConvertFrom-Json
[PSCustomObject]@{
Name = $Manifest.name
Version = $VersionPath.Name
ID = $Id
Permissions = $Manifest.permissions -join ', '
}
} | Format-Table -AutoSize
How are you all handling browser extension governance in your enterprise environments? Are you strictly whitelisting, or relying on reputation scoring?
Good catch on the PowerShell script. From a SOC perspective, these are nightmare fuels because the traffic is HTTPS, so standard payload inspection won't see the search terms being intercepted. We've had to rely on correlating process creation of Chrome with high-frequency DNS requests to new domains. If the extension routed traffic through an attacker-controlled server, there should be a mismatch between the expected destination (Google/Perplexity) and the actual destination IP seen in NetFlow.
Whitelisting is the only way to sleep at night. We pushed a Chrome policy via GPO last year to block all extensions by default and only allow a specific list of IDs. It creates some helpdesk tickets for shadow IT, but it beats dealing with credential theft. Users just see 'Admin has disabled extensions' if they try to install something like this Perplexity clone.
I've seen similar techniques during phishing engagements. Users don't bat an eye at granting 'read and change data on all websites' when installing a 'productivity tool.' The real risk here isn't just the search interception; it's that if they have that level of access, they can likely inject scripts into banking sessions too. Always check the 'Permissions' tab before hitting 'Add to Chrome'—if a simple tool asks for broad access, it's a red flag.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access