Supply Chain Attack via Ownership Transfer: The QuickLens Case
Just caught the report on The Hacker News regarding the BuildMelon extensions. It looks like the developer 'akshayanuonline@gmail.com' transferred ownership, and the new actors immediately weaponized the extensions—specifically QuickLens - Search Screen with...—to inject arbitrary code and harvest sensitive data.
This is a textbook supply chain issue. Users trust the extension's history, but the ownership transfer flips the trust model instantly. The mechanism here seems to be updating the manifest. to request broader host_permissions (likely *://*/*) or injecting content scripts into banking/login pages.
For incident responders, if you are triaging an infected endpoint, check the extension directory. In Windows, you can find the ID and verify the version update timeline here:
Get-ChildItem "C:\Users\$env:USERNAME\AppData\Local\Google\Chrome\User Data\Default\Extensions" -Recurse -Force | Where-Object { $_.Name -eq "manifest." } | Get-Content | Select-String -Pattern "quicklens|akshayanuonline"
I recommend immediately revoking permissions for 'QuickLens' if found in your environment.
How is everyone handling extension governance? Are you relying on Google's automated reviews, or do you have a strict allow-list policy for browser extensions?
We've moved to a strict allow-list via Google Admin Console. Relying on the 'Install' button prompt is a losing battle; most users just click through.
We actually blocked 'QuickLens' this morning. The tricky part is detecting the change in behavior. We use a KQL query to look for anomalies in proxy logs where the Referrer or Request-URL contains chrome-extension:// and the destination is an unknown IP.
ProxyLogs
| where Url contains "chrome-extension://"
| where RemoteIP !in (ip_range_whitelist)
This caught the data exfiltration attempts pretty quickly.
From a pentester's perspective, this is a fantastic persistence mechanism. EDR often excludes the AppData\Local\Google\Chrome\... directory to avoid performance hits, giving malware a safe haven.
If you're auditing, pay close attention to the background scripts in the manifest. If you see "persistent": true combined with "web_accessible_resources", that's a huge red flag for a potential man-in-the-browser attack.
Solid point on the EDR exclusions. To catch these, we've implemented a weekly baseline check of extension manifests. If the manifest. hash changes unexpectedly, it triggers an alert. You can quickly audit all installed extensions for anomalies using this PowerShell command:
Get-ChildItem "$env:LOCALAPPDATA\Google\Chrome\User Data\*\Extensions\*\*\manifest." | Select-Object FullName, LastWriteTime
This helps identify unauthorized updates before they persist too long.
Validating those manifest hashes is crucial, Katie. From an MDR perspective, we also hunt via network correlation. If chrome.exe initiates outbound connections to unknown domains immediately after creating files in the extension directory, it's a strong indicator of compromise.
We use this KQL query to bridge the gap between extension updates and data exfiltration:
DeviceNetworkEvents
| where InitiatingProcessFileName == "chrome.exe"
| join kind=inner DeviceFileEvents on DeviceId
| where FolderPath contains @"Google\Chrome\User Data\Default\Extensions"
| project Timestamp, DeviceName, RemoteUrl, FolderPath
This helps catch the signal even if the malware temporarily bypasses manifest integrity checks.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access