Google's Dynamic Tagging on a "Privacy" Wallet

xmrwallet.com loaded Google's dynamic tagging infrastructure (gtag.js), 4 tracking property IDs, Google Ads Conversion Linker, and a DoubleClick pixel on a Monero wallet for 4+ years. The site's Content Security Policy blocked nothing. DDoS-Guard stored visitor IPs in plaintext cookies. No other cryptocurrency wallet in the industry does any of this. Here is the evidence.

What Google's Dynamic Tagging Infrastructure Is

A technical clarification: xmrwallet.com loaded googletagmanager.com/gtag/js (the Global Site Tag loader), not the classic gtm.js container. The distinction is cosmetic. Both are remotely-managed JavaScript frameworks that fetch configuration from Google's servers at runtime, execute dynamic code in the browser, and cannot be pinned to a fixed hash (no SRI). Both can be reconfigured server-side without any change to the site's code. In this document, "GTM/gtag" refers to this entire dynamic tagging infrastructure.

This is not an analytics script. It is a remote code injection platform.

The difference between analytics and GTM:

• Analytics (static .js file) = reads data about user behavior. Auditable. Version-locked. SRI-hashable.
• gtag.js / GTM (dynamic loader) = fetches configuration from Google's servers at runtime. Can execute arbitrary JavaScript via linked tags and properties. Changes propagate instantly without deploy, code review, version control, or SRI hash. Invisible to auditors.

His Own Code vs. Reality

The operator's website, GitHub repository, and Terms & Conditions make specific technical claims. Network traffic captures contradict every one of them.

Google Analytics Does NOT Require Tag Manager

If the operator genuinely wanted analytics (page views, traffic stats), he could use:

GTM Lives Across the Entire Wallet Session

app.html is a Single Page Application. Internal navigation (login → create → dashboard → send → receive) happens via hash changes (#/login.html, #/create.html, #/dashboard.html), not page reloads. This means:

Why Different Scans Show Different Results

URLScan results for xmrwallet.com show varying request counts and tracking IDs across scans of the same URL on the same day. This is not random — it is the expected behavior of dynamic tagging with evasion configuration. Three mechanisms explain every observed variation:

1. Dynamic Container Updates (The Invisible Backdoor)

The operator logs into their Google Analytics/gtag dashboard, adds or removes tracking properties, and publishes. The wallet's HTML, CSS, and visual UI remain 100% identical — but the invisible JavaScript executed in the victim's browser changes instantly. The different Google IDs found across URLScan scans (sometimes 2, sometimes 4) are simply different historical states of the operator's remote Google configuration.

2. Conditional Firing & Evasion Triggers

Google's tagging platforms allow operators to set Triggers — conditions that determine when scripts fire. The operator could configure tracking to activate only for:

• Specific referrers (user came from Google Ads, Reddit, or a bookmark — not from urlscan.io)
• Specific geographic regions (target victims in certain countries only)
• Click events (fire only after user clicks "Create Wallet" or "Login")
• Cookie presence (fire only if _ga cookie exists = returning visitor, not first-time scanner)
• Random sampling (fire for X% of users — selective profiling)

This explains why some URLScan results show 33–42 requests with Google tracking, while others of the same page show fewer. The scanner is seeing different trigger states — the operator's configuration decides who gets tracked and who doesn't.

3. Server-Side Script Cloaking (PHP)

The server runs PHP/8.2.29 (confirmed in response headers). PHP can serve visually identical HTML but conditionally inject or omit the <script> tag that loads Google's infrastructure based on:

What xmrwallet.com Deployed

4 Google Tracking Identifiers

9 Cookies Set Per Visitor

Source: URLScan.io scan 019c605d-4a6d-71ab-82a1-df03ef60ae9a (Feb 15, 2026) — behaviour tab, cookies section.

Security Headers: Nothing Protected

What Google Saw

For 4+ years, every xmrwallet.com session generated 28+ requests to Google servers. Google received:

No Other Wallet Does This

We scanned every major web-based cryptocurrency wallet on URLScan.io. The result is unambiguous:

The Operator Is Deleting URLScan Results

The pattern is visible in the scan data itself:

Since our investigation began, the operator has systematically erased evidence across every platform. The Google tracking code was removed within 72 hours. Now URLScan results are being targeted.

What URLScan Shows Over Time

What We Archived Before Deletion

All 100 URLScan result pages have been downloaded as full HTML archives. Key scans:

How It Worked: Step by Step

This simulation shows what happened during every xmrwallet.com session. Every step is based on captured network traffic and URLScan evidence.

Response to xmrwallet.com "Farewell Letter" — April 2026

In April 2026, the operator published a "Brief Letter and Final Update." Below is our response. Not to convince the operator — that is pointless — but to document the lies for the public record.

On "The view key is required by the service"

From their Terms of Service (archived Dec 2023):

This contradicts their own opening statement: "Our services provides in-browser monero blockchain access and generates new seeds client-side."

If the view key is sent to the server and "stored in memory" — the architecture is server-side scanning, not client-side. Every legitimate Monero wallet (Monero GUI, Feather, Monerujo, Cake Wallet) scans the blockchain locally using WebAssembly or native code. The view key never leaves the device.

The operator knew this from day one. Their own Reddit posts boasted about being "more private than MyMonero" — while running 4 Google tracking IDs and sending the view key to a server behind Russian DDoS-Guard infrastructure.

On the Terms of Service — Forensic Analysis

The ToS was clearly written without legal review, in broken English suggesting OCR artifacts or machine translation. This is a direct marker of a fraudulent service pretending to be Canadian:

The person who registered as a Canadian government official (Nathalie Roy) couldn't write basic English legal terms. These aren't typos — they're markers of someone who doesn't operate in English legal systems.

On the Signature

Previous communications: Best Regards, Nathalie or just — N. Reddit responses to victims signed as Nathalie. Now, in the farewell letter:

No longer Nathalie. No longer a person. "The Creator." They understand investigations are active. They understand the name is burned. The shift from personal identity to abstract title is not humility — it's legal distancing.

On "Playing Dumb" — A Russian Scammer Pattern

The farewell letter performs ignorance. This is characteristic of a specific scam culture:

On Deleting URLScan Evidence

After our investigation began documenting the Google tracking IDs via URLScan.io, the operator started requesting deletion of scans that showed the tracking infrastructure. 63 public scans documented the presence of gtag.js, Google Ads, and DoubleClick on a "privacy wallet." The operator knows that no legitimate wallet runs these scripts. Deleting the evidence doesn't make it disappear — we archived everything, and we reconstructed the mechanism:

Live Proof-of-Concept: We Rebuilt The Scam

Since the operator is deleting scans, we built an exact replica of the theft mechanism. Same request structure. Same session_key format. Same view key exfiltration. Even the same Google tracking ID (data goes to their property — they can change it in our operator panel).

The demo includes:

• Full wallet replica — seed generation (real Monero 1626-word dictionary with CRC32 checksum), login, dashboard, send/receive, subaddresses, QR codes
• Operator panel — balance manipulation, fake transactions, theft strategies (silent skim, sync error, deposit trap), session tagging, cloaking configuration, connection/IP history
• View key risk visualization — blockchain scanner simulation, identity correlation graph (real IP + Tor = same person), attack timeline, privacy comparison
• Network intelligence graph — interactive canvas showing how multiple wallets, IPs, exchanges, and darknet addresses connect through the operator's data
• Deep fingerprinting — canvas hash, WebGL/GPU, audio context, fonts, media devices, and 30+ data points the operator collects on every visitor
• Post-theft reports — FSB forwarding (DDoS-Guard already has the data), Interpol (cross-border jurisdiction), darknet sale (KYC-linked wallets), blackmail dossier

Why Google Tag Manager Is Not "Just Analytics"

For security professionals, this is obvious. For everyone else:

Anyone with minimal security knowledge understands that CORS policies, CSP headers, and script isolation of a wallet claiming "privacy by design" are fundamentally incompatible with loading advertising infrastructure. The app page didn't have the tracker in the source — correct. But it wasn't isolated. And we demonstrated exactly how this works.

Namesilo's Response

After understanding there was a federal investigation, Namesilo:

• Launched domain discount promotions (to make our pricing statements outdated)
• Transferred the protected domain to Namecheap (to distance themselves)
• The information written in our investigation was accurate at the time of writing, signed and timestamped

The Bottom Line

The operator believes they're a genius because they stole a lot of money — possibly more than the annual budget of their hometown. They believe that because the investigation didn't immediately spell out the exact theft method, we didn't know. Seriously?

As we have said before: no sense of remorse, no understanding of what they did and what they have done will come until there is a search/arrest warrant and they are stripped of access to the stolen money. Then, perhaps (we doubt it), they will remember that they do not run the world. This applies to both overconfident parties — possibly the same person.