The method — and its honest limits

A DNS sinkhole (Pi-hole) sees every domain a host tries to resolve before any connection is made. That’s the right layer for this question: I’m not decrypting payloads or claiming to read what Microsoft received — I’m documenting where my host reaches out, and then stopping the connection at the door. DNS reveals the telemetry surface; blocking at DNS means the request never leaves the network.

• Observation: Pi-hole query log on a Raspberry Pi 5, laptop DNS pointed at it
• Attribution: pihole -q <domain> to prove which blocklist caught each endpoint
• Scope: my own EliteBook only, on my own network

What showed up

Filtering the query log for Microsoft-owned destinations, these telemetry endpoints were being requested by the host — and blocked:

Each was blocked on both A and AAAA lookups — IPv6 telemetry doesn’t slip past a sinkhole that filters AAAA too, which is a common gap when people only set IPv4 DNS.

The scale

Across normal use, the dashboard settled at roughly 24% of all DNS queries blocked. That number isn’t all telemetry — it includes ads and trackers from a 2.3-million-domain blocklist — but the Microsoft/Edge diagnostic endpoints are a consistent, recurring slice of it, requested in the background without user action.

Why it matters

At a personal level, this is the difference between assuming a machine phones home and proving which endpoints it contacts, with per-domain attribution. At an organisational level, the same DNS-layer visibility is how you’d inventory and control outbound telemetry across an estate — and under GDPR / the Swiss nFADP, “what leaves the endpoint, to whom” is a question a business is expected to be able to answer.

The honest caveat stands: DNS tells you the destination, not the contents. But for telemetry, the destination is the finding — and it’s also the control point.

From research to mitigation

Seeing the telemetry surface concretely is what justified building the infrastructure to block it network-wide: a hardened Pi-hole sinkhole, verified end to end. That build is written up separately as a lab — this piece is the reason it exists.

Takeaways

• DNS is the cheapest visibility you’ll ever get. No agent, no packet capture — a sinkhole shows the outbound telemetry surface of every device behind it.
• Filter AAAA, not just A. IPv6 telemetry is a silent bypass otherwise.
• Attribution beats a blocklist count. pihole -q turns “something was blocked” into “this specific endpoint, caught by this list” — which is what makes it evidence.

All observation was performed on my own host and network. No third-party systems were accessed; this documents outbound DNS requests from a personal machine and their mitigation.

The lure

The victim received three messages in quick succession on WhatsApp from an unknown number, claiming to be from “Diana, your check-in manager” at the booked hotel. The messages stated that the hotel was ending its Booking.com partnership, that the reservation had to move to the hotel’s “direct booking system”, that a 50% discount was available for rebooking through a personal link, and that a full refund of the original payment would follow. To “verify”, the victim was told to approve two push notifications or SMS codes from their bank.

The link was hosted at booking.roomstation.help/reservation/[redacted].

Initial red flags

Triage chain

Phase 1 — CTI feed search. Searched my personal Inoreader CTI dashboard for Booking.com. Three relevant items surfaced from the prior weeks: BleepingComputer on the breach forcing reservation PIN resets (April 2026), SecurityWeek confirming attacker access to user information (April 2026), and an earlier BleepingComputer piece on a Booking.com phishing campaign using a lookalike ん character (August 2025).

Phase 2 — open-source research. Searching for the hotel-partner phishing scam tied the activity to Storm-1865 (Microsoft’s attribution), using the ClickFix technique against hotel employees to deploy XWorm and VenomRAT. Bridewell tracks it as intrusion set BR-UNC-030 with Russian-origin code comments in the customer phishing kit; Krebs documented the phishing-as-a-service infrastructure behind the 50%-discount fraud; and the earlier name “I Paid Twice” came from Sekoia (November 2025).

Phase 3 — Have I Been Pwned. Checking the victim’s exposure showed three breaches. The most operationally relevant was Luxottica (2021) — name, DOB, phone, address — the likely source of the phone number used to reach them on WhatsApp. Booking.com’s April 2026 breach supplied the booking-specific data (hotel name, dates).

Phase 4 — URLscan.io infrastructure analysis. Submitting the domain returned the detail that made the whole thing click:

A domain one minute old, on a cert issued two days before contact, not yet on any blocklist — this was live, freshly rotated infrastructure, not a stale link.

Phase 5 — NCSC.ch corroboration. The Swiss NCSC archive showed the campaign in Wochenrückblick 47/2023 and 10/2024, confirming continuous activity against Swiss residents for over two years. I reported the case on 13 May 2026; an NCSC analyst confirmed the report, validated the attribution to the Booking.com breach data, and acknowledged the URLscan IOC for downstream blocklist action.

Indicators of compromise

DOMAIN:   booking.roomstation.help
IP:       188.114.97.3 (Cloudflare front)
IP:       104.18.94.41 (Cloudflare front)
ASN:      AS13335 (CLOUDFLARENET)
TLS CN:   Let's Encrypt E8 intermediate — issued 11 May 2026
TTP:      ClickFix — "Sicherheitsüberprüfung wird durchgeführt"
THEME:    Hotel partnership-termination + 50% discount + dual-bank approval
GROUP:    Storm-1865 (Microsoft) / BR-UNC-030 (Bridewell)
CAMPAIGN: "I Paid Twice" / Booking.com partner phishing
NCSC REF: RNR-277766 (13 May 2026)

MITRE ATT&CK mapping

Takeaways

The decisive signal wasn’t any single red flag — it was the URLscan domain age. A one-minute-old domain on a two-day-old cert reframes the whole case from “probably phishing” to “live, actively rotated campaign infrastructure”. The HIBP pivot was the other lesson: the attacker’s contact channel (the WhatsApp number) traced back to an unrelated 2021 breach, while the booking specifics came from the 2026 one — two separate leaks combined into one convincing lure.

References

• Malwarebytes — Booking.com breach gives scammers what they need
• Krebs on Security — Booking.com Phishers May Leave You With Reservations
• Bridewell — The Booking.com Phishing Campaign
• State of Surveillance — Booking.com Breach Timeline
• NCSC.ch — Wochenrückblick 47/2023
• NCSC.ch — Wochenrückblick 10/2024

The targeted family member’s name and identifying details have been omitted. The case was triaged with their consent and no personal data is reproduced.

The claim

BrowserGate, disclosed by Fairlinked e.V. and covered by BleepingComputer and The Next Web, alleged that LinkedIn’s production JavaScript transmits an encrypted browser fingerprint — including the list of installed browser extensions — to its servers on every page load, without the user’s knowledge or consent. I treated it as a threat-verification exercise rather than news to repeat: capture the evidence, or discard the claim.

Verifying it in DevTools

With Chrome’s DevTools Network tab open on LinkedIn, I filtered the traffic and found the endpoint the disclosure named:

• 3 × HTTP 200 POST requests to the sensorCollect endpoint per session
• ~0.4 kB per call, ~1.2 kB per session — small encrypted payloads consistent with a fingerprint, not page content
• Source traced to an obfuscated Webpack bundle (chunk.905, module 75023) — deliberately hard to read
• A third-party tracker (Human Security / PerimeterX) injected via a hidden iframe

The claim held up: the data was real, it was leaving the browser, and the delivering script was obfuscated.

Mitigation — and proving it worked

Verification isn’t just confirming the problem; it’s confirming a fix. I switched to Brave (which blocks this class of tracking by default) and re-ran the identical capture:

Then I corroborated with an independent method — EFF’s Cover Your Tracks, which tests a browser against 311,004+ real fingerprints:

Two independent methods agreed: the data left Chrome, and Brave stopped it.

Why it matters — the regulatory angle

An installed-extension list can reveal sensitive traits — health conditions, politics, or religion inferred from what someone installs. Under GDPR Article 9, processing special-category data requires explicit consent, which silent fingerprinting doesn’t obtain. The context isn’t hypothetical: LinkedIn’s parent, Microsoft, was fined EUR 310M by the Irish DPC in October 2024 for prior data-protection violations, and the ceiling for a breach at that scale is roughly 4% of global turnover.

Takeaways

• Verify, don’t repeat. A disclosure is a hypothesis until reproduced. DevTools turned a headline into confirmed evidence.
• A fix isn’t done until it’s measured. “Switch to Brave” only counts because I re-captured and saw blocked:other and 0.0 kB.
• Privacy is a security problem. Fingerprinting is a data-protection and regulatory exposure, not just an annoyance — the lens a Swiss or EU business actually needs.

Source & references

Full capture notes and screenshots: jaalso/security-research.

• Fairlinked e.V. — original BrowserGate disclosure
• The Next Web — LinkedIn BrowserGate extension scanning
• EFF Cover Your Tracks — browser fingerprinting test

Testing was performed on my own browser and account; no LinkedIn systems were attacked or accessed beyond normal browsing. This is independent verification of a publicly disclosed issue.