🚨 xmrwallet.com steals your Monero view key — proof from live network capture

[phishdestroy]

Security Analysis: www.xmrwallet.com — Private Key Exfiltration

Date: 2026-02-18
Analyst: PhishDestroy Research
Severity: CRITICAL
Evidence type: Live network traffic capture (Firefox WebExtension request interceptor)

---

Since our “Russian friend” continues to lie, evade, and keep messaging us, we interpret this as a request for a more thorough audit and further action to prove our findings. As long as he continues to engage, we will continue analyzing his scam website — which паразитирует on branding, paid articles, and rating manipulation. We will also begin taking action against this: submitting removal requests challenging manipulated reviews addressing fraudulent reputation tactics It’s amusing that he thinks accusing someone of phishing will work here. Apparently, it was enough for him to get: 20+ issues removed 50+ reviews taken down But it’s time to put an end to this. His garbage operation is going to be shut down.

request_analytics_2026-02-18T15-07-55.json
url_analysis_www.xmrwallet.com_2026-02-18T15-07-47.json

Executive Summary

www.xmrwallet.com is a custodial web wallet that systematically collects and stores the private view key of every Monero wallet opened through the service. Beyond the initial authentication, the view key is re-transmitted with every single API request during the session — encoded in Base64 inside the session_key parameter. This means the server operator has full, permanent visibility into every incoming transaction of every wallet ever used on the platform.

Additionally, wallets created on the platform (isnew=1) are definitionally compromised from birth, as the key generation occurs within the browser JavaScript served by the same server.

---

Evidence

1. Initial Authentication — Private View Key Transmitted in Plaintext

Endpoint: POST https://www.xmrwallet.com/auth.php

Two distinct wallets were authenticated during the captured session. Both address and viewkey were sent to the server:

Wallet A — Existing wallet (isnew=0)

address:      46EkQdF7iQ4i4Ah935SipgXbDSryh5yv76UnhsPXTaUYegCMJPqDN88UKCuraauhmbYBK2YzDX76E46KQHAKYV9a63vokJb
viewkey:      efba13ecb8b360660a3dcaafaf7cf99149713d064b9d64997b2454d58ee67800
isnew:        0
timestamp:    1771427175981

Wallet B — Newly created wallet (isnew=1)

address:      49uroty7nZtKkendSiLWv5avrtJvRqhXTG6t4Xy2ByDzhwxxKimTz7C3m1WwHTJiUcBZspQi3FygQXP55wQfKBHKB8U8pYT
viewkey:      7c6e0a46172809792b524466e4a86b58db3b48e5d3441dead24416d79bbc9909
isnew:        1
timestamp:    1771427204479

Note: viewkey is the private view key of a Monero wallet. Whoever possesses it can see every incoming transaction, all balances, and all transaction history of the wallet — permanently and irrevocably.

---

2. View Key Re-Transmitted on Every Subsequent Request

This is the most damning finding.

After auth.php the server issues a session_key. Decoding the Base64 components of session_key reveals:

session_key = [encrypted_blob] : [base64(wallet_address)] : [base64(view_key)]

Decoded values for Wallet A session:

Part[1] (b64 decoded): 46EkQdF7iQ4i4Ah935SipgXbDSryh5yv76UnhsPXTaUYegCMJPqDN88UKCuraauhmbYBK2YzDX76E46KQHAKYV9a63vokJb
Part[2] (b64 decoded): efba13ecb8b360660a3dcaafaf7cf99149713d064b9d64997b2454d58ee67800

Decoded values for Wallet B session:

Part[1] (b64 decoded): 49uroty7nZtKkendSiLWv5avrtJvRqhXTG6t4Xy2ByDzhwxxKimTz7C3m1WwHTJiUcBZspQi3FygQXP55wQfKBHKB8U8pYT
Part[2] (b64 decoded): 7c6e0a46172809792b524466e4a86b58db3b48e5d3441dead24416d79bbc9909

The session_key (containing the plaintext wallet address and view key in Base64) was transmitted in 40 separate POST requests to the following endpoints:

Endpoint	Purpose
/getheightsync.php	Blockchain sync status
/gettransactions.php	Transaction list
/getbalance.php	Current balance
/getsubaddresses.php	Subaddresses
/getoutputs.php	Outputs (UTXOs)
/dashboard.html	Dashboard page
/send.html	Send page
/receive.html	Receive page
/transactions.html	Transactions page
/account.html	Account page
/logout.php	Logout

What the operator CAN do with the view key:

• See all incoming transactions (amounts, timestamps, subaddresses)
• Monitor real-time balance
• Track transaction history indefinitely
• Correlate wallet activity with IP addresses (collected server-side)

What the operator CANNOT do with view key alone:

• Spend funds (requires spend key / seed)

However: if the wallet was created on this service, the spend key may also be in operator possession.

---

Proof of Evidence

All findings are derived from raw HTTP request data captured by a Firefox WebExtension (webRequest API). The following artifacts were analyzed:

• request_analytics_2026-02-18T15-07-55.json — aggregate domain/method/parameter statistics
• url_analysis_www_xmrwallet_com_2026-02-18T15-07-47.json — full per-request data including POST bodies

Key verification steps anyone can replicate:

1. Open url_analysis_*.json, search for "auth.php" — observe address and viewkey fields in requestBody.formData
2. Search for "session_key" — take any value, split by :, Base64-decode parts 1 and 2 — they decode to the wallet address and view key respectively
3. Count entries containing session_key — all 40 POST requests to functional endpoints carry the key material

---

Recommendations

If you have used www.xmrwallet.com:

1. Do not use the created wallet (49uroty7...) — treat as fully compromised
2. Do not send any funds to the existing wallet (46EkQdF7...) — the operator can monitor all incoming transactions
3. Generate a new wallet offline using Feather Wallet, Monero GUI (offline), or a hardware wallet
4. If you previously stored funds in wallets used on this service, move them immediately
5. Assume the operator has correlated your IP address with both wallet addresses

General rule: Never enter a private key or view key into any web service. Monero web wallets that require your view key cannot provide privacy — they become surveillance infrastructure.

---

Disclosure

This analysis is published for public awareness and community protection. The wallet addresses exposed in this report are research artifacts. The findings demonstrate a systemic architectural issue, not an isolated bug.

Status: No coordinated disclosure attempted. The collection of private view keys appears intentional by design (required for the service to function server-side). There is no fix that preserves the current architecture while eliminating the privacy violation.

---

Analysis by PhishDestroy Research | https://github.com/phishdestroy/destroylist