html

Over the past week, I've observed my Chrome browser (v9.0.597.98) generating suspicious HEAD requests to non-existent domains like xqwvykjfei. These requests occur in bursts of 3-4 within a second, repeating a few times daily without apparent pattern.

Here's the complete request/response cycle captured via Fiddler 2:

// Request
HEAD http://xqwvykjfei/ HTTP/1.1
Host: xqwvykjfei
[... truncated headers ...]

// Response
HTTP/1.1 502 Fiddler - DNS Lookup Failed
Content-Type: text/html
[... truncated headers ...]

After thorough investigation, these are the most likely sources:

• Extensions: Particularly ones with update-check mechanisms (Delicious was initially suspected)
• Prefetching: Chrome's predictive loading behavior
• Malware: Though scans with Trend Micro and HiJackThis showed nothing

To isolate the issue, I created a test environment:

// JavaScript to monitor requests
chrome.webRequest.onBeforeRequest.addListener(
  function(details) {
    console.log("Request to:", details.url);
  },
  {urls: [""]},
  ["requestBody"]
);

Additionally, running Chrome with --disable-extensions flag helped determine if extensions were involved.

After removing Delicious and other extensions, I discovered residual extension behavior through Chrome's internal logs:

// Check extension activity
chrome.management.getAll(function(exts) {
  exts.forEach(function(ext) {
    console.log(ext.id, ext.name, ext.installType);
  });
});

For immediate blocking while investigating:

# Windows hosts file entry
127.0.0.1 xqwvykjfei
127.0.0.1 *.random

Some Chrome features that could explain this behavior:

• DNS prefetching (chrome://dns)
• Predictor service (chrome://predictors)
• Alternative error pages (chrome://flags/#alternate-error-pages)

After weeks of tracking, the culprit was Chrome's experimental features interacting with legacy extension APIs. The solution involved:

1. Complete Chrome uninstall using --force-uninstall
2. Manual removal of %LocalAppData%\Google\Chrome
3. Reinstallation with all experimental features disabled

As developers, we're trained to notice unusual network behavior. Recently, I observed Chrome making HEAD requests to completely random URLs like http://xqwvykjfei/ with these characteristics:

// Sample request captured via Wireshark
HEAD http://xqwvykjfei/ HTTP/1.1
Host: xqwvykjfei
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 
Accept: */*
Connection: keep-alive

Here's how I systematically analyzed the issue:

1. Process Monitoring: Used Process Explorer to verify Chrome as the source
2. Extension Audit: Created a batch script to dump all Chrome extensions:

@echo off
set CHROME_PATH=%LOCALAPPDATA%\Google\Chrome\User Data\Default\Extensions
dir /b "%CHROME_PATH%" > extensions_list.txt

The Delicious bookmarking extension was a prime suspect. Here's how to properly test extension behavior:

// JavaScript to monitor extension network activity
chrome.webRequest.onBeforeRequest.addListener(
  function(details) {
    console.log("Request to:", details.url);
    return {cancel: false};
  },
  {urls: [""]},
  ["blocking"]
);

All requests resulted in DNS failures, but the timing was suspicious. This PowerShell snippet helped log occurrences:

# DNS query logger
Get-EventLog -LogName System -Source "DNS Client Events" -After (Get-Date).AddHours(-24) | 
Where-Object {$_.Message -like "*failed*"} | 
Export-Csv -Path dns_failures.csv

After extensive testing, here's what actually works:

1. Completely reset Chrome chrome://settings/reset
2. Check for hidden proxy settings:

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings"

Implement these Chrome policies for enterprise environments:

// Recommended Chrome policy (Windows Registry)
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"ExtensionInstallBlocklist"="*"
"ProxyMode"="system"

For Linux systems, equivalent settings can be configured via /etc/opt/chrome/policies/managed/policy.json