Webloc & Ad-Tech Surveillance: 500M Devices Tracked by Law Enforcement
Just caught the Citizen Lab report on Webloc. It’s wild to see the scale—500 million devices tracked via ad exchange data. The actors involved (Hungarian Intel, El Salvador police, and US departments) aren't exactly a surprise given the industry trends, but the consolidation of Cobwebs into Penlink creates a massive surveillance entity.
From a defensive standpoint, this isn't a "vulnerability" we patch, but it is a massive data exposure issue. Webloc exploits the "Bidstream"—the real-time auction process where apps bid to show ads. Location data and device identifiers (GAID/IDFA) are often leaked here. If your org's mobile devices are running ad-supported apps, your corporate locations are likely in this database.
We can't stop the ad ecosystem, but we can harden endpoints. Ensure your MDM policies strictly disable the Google Advertising ID (limit ad tracking) and enforce Apple's App Tracking Transparency (ATT).
Additionally, we should monitor if any of our own infrastructure is being used to access these tools. If you have proxy visibility, hunt for traffic to these vendors.
Here is a basic KQL query to start hunting for access to these domains in your DNS or Proxy logs:
// Hunt for connections to known surveillance tech infrastructure
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteUrl has_any ("cobwebs", "penlink", "webloc")
| project Timestamp, DeviceName, InitiatingProcessAccount, RemoteUrl, RemoteIP
| summarize Count() by DeviceName, RemoteUrl
| order by Count desc
Has anyone here encountered Webloc or Cobwebs traffic in their environment? Or are we relying purely on privacy policies (like Apple's ATT) to mitigate this bidstream leakage?
Solid KQL query. I'd also suggest joining this with IdentityLogonEvents to see if the accounts accessing these domains are escalated or if it's just generic browsing. We ran a similar hunt for 'GrayKey' traffic last year and found a few false positives from a marketing team researching competitors. Always verify the context before flagging the user.
The MDM angle is crucial. For Android specifically, you need to ensure the limit_ad_tracking flag is set to 1 for all corporate profiles. If you are auditing devices manually, you can check this via ADB:
adb shell settings get global limit_ad_tracking
If it returns '0', the device is sending the ad ID. This is our primary defense against the bidstream harvesting.
It's terrifying because this is all 'legal' data purchase. They aren't hacking the phones; they are just buying the data the ad networks are selling. Unless we block all ad traffic at the gateway (which breaks a lot of legitimate apps and free content), we are fighting a losing battle on the collection side. We need to focus on what happens if that data is used to target our executives physically.
Frank’s KQL is solid for detection, but you need to know exactly what’s leaving the perimeter. The bid request payload is where the real PII lives—often down to hashed emails or lat/long.
I recommend intercepting test device traffic with mitmproxy to inspect the OpenRTB JSON. It helps identify which specific parameters your ad partners are broadcasting.
mitmproxy --set block_global=false -s parse_bidstream.py
This allows you to grep the user object to see if identifiers are actually present before deciding on a gateway block.
Since we can't patch the ad networks, we have to harden the endpoints. I've started deploying strict Edge policies to disable 'Ad Personalization' for corporate profiles. It won't stop the tracking entirely, but it reduces the unique identifiers sent in the bidstream.
# Disable personalized advertising ID via Registry
New-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\AdvertisingInfo" -Name "Enabled" -Value 0 -Force
Pair this with a DNS sinkhole for known ad exchanges.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access