Introduction to Malware Binary Triage (IMBT) Course
Looking to level up your skills? Get 10% off using coupon code: MWNEWS10 for any flavor.
Enroll Now and Save 10%: Coupon Code MWNEWS10
Note: Affiliate link – your enrollment helps support this platform at no extra cost to you.
HR HUDSON ROCK / INFOSTEALERS.COM
Threat Intelligence • October 28, 2026
Research / Cryptocurrency privacy
38,628 Crypto Orders. 10,139 IPs. What Wagyu’s Alleged Leak Means for Monero Privacy.
Monero’s cryptography was not broken. But newly examined order records show how a privacy-focused swap service can retain the exact connections its customers hoped to conceal.
Hudson Rock ResearchWagyu.xyz11-minute readOriginal dataset analysis
Can Monero users be traced through a hacked exchange? Not by magically decrypting Monero’s blockchain. But potentially by reading what a swap service knows before coins ever enter the privacy network — and what it records when those coins leave.
That is the central finding of Hudson Rock’s review of purported Wagyu.xyz transaction data supplied alongside a WhiteArmor-associated claim. The files contain order histories, cryptocurrency destinations, transaction identifiers, connection metadata and an IP-level activity index. They do not demonstrate an attack on the Monero protocol, and their alleged breach provenance has not been independently authenticated.
38,628
Total order records in orders.csv
10,139
Distinct IP addresses, not confirmed individuals
8,137
Orders naming a native XMR receiving address
4,580
Completed cross-chain-to-XMR records joining deposit TX, address and IP
Hudson Rock calculations from the provided CSVs; records span July 18–October 26, 2026. An order is not necessarily a completed trade, and an IP address is not necessarily a customer.
<div>01 / THE INCIDENT CLAIM</div>
<h2>WhiteArmor’s claim raises a different question than its ransom note.</h2>
<div>
<p>On October 27–28, 2026, ransomware-tracking services indexed WhiteArmor listings naming <strong>Wagyu.xyz</strong>, including a second entry called “wagyu.xyz unfairness.” The associated text concentrates on alleged unfair coin-flip odds and undisclosed swap fees. Its accusations are not proof of intrusion, ransomware deployment or financial misconduct, and Hudson Rock has not independently verified how the supplied files were obtained.</p>
<p>Wagyu presents itself as a no-KYC route between Monero (XMR), other cryptocurrencies and cross-chain infrastructure. Its service records therefore sit at a particularly sensitive boundary: a transparent blockchain on one side and a privacy-preserving cryptocurrency on the other. A leak at that boundary can expose relationships that Monero deliberately keeps off its public chain.</p>
</div>
<div><p><strong>The security story isn’t “Monero has been cracked.”</strong> It is that a service handling private-coin conversions may preserve an off-chain ledger linking customers’ requests, public-chain movements, private-coin destinations and connection metadata.</p></div>
<div>02 / THE PRIVACY GAP</div>
<h2>The blockchain hides the destination. The swap order records it.</h2>
<div>
<p>Monero uses stealth addresses, ring signatures and Ring Confidential Transactions to hide recipients, sender relationships and amounts in its on-chain records. A normal public observer cannot take an XMR receiving address and search the chain for a complete history of incoming and outgoing transfers.</p>
<p>But a swap service still has to know where to send funds. When a customer requests BTC → XMR, it may store the Bitcoin deposit transaction, the intended Monero receiving address, the order amount, the submission time, the client IP and the session used to track the order. Those values appear together in the supplied records.</p>
</div>
How an off-chain order links information that public XMR transactions do not
<div>
<div><div>Transparent chain</div><div>BTC / ETH / SOL deposit</div><p>Deposit address · transaction hash · asset and value</p></div>
<div>→</div>
<div><div>The sensitive junction</div><div>Wagyu order record</div><p>IP address · timestamp · session ID · browser headers · order mapping</p></div>
<div>→</div>
<div><div>Privacy chain</div><div>Native XMR destination</div><p>Receiving address supplied to the service · internal payout status</p></div>
</div>
<p>A link in a service database is not evidence that Monero’s hidden sender, recipient or amount has become public on-chain.</p>
<p>We isolated <strong>8,137 records</strong> with a native-XMR destination format and Monero output chain identifier; <strong>6,692</strong> were marked completed. Within the completed cross-chain subset, <strong>4,580</strong> records contained an incoming deposit transaction hash, a Monero receiving address and a client IP in the same row. Among these were <strong>1,011 completed BTC → XMR orders</strong> with that linkage.</p>
<div>
<div><div>A real BTC → XMR record, deliberately redacted</div>Supplied CSV / September 2026</div>
<div>
<div>Order typeBitcoin → native XMR</div>
<div>Recorded statusCompleted</div>
<div>Client IP<code>103.75.xxx.xxx</code></div>
<div>Transaction size$1,000–$5,000 band</div>
<div>BTC deposit transactionRecorded / hash withheld</div>
<div>XMR destinationRecorded / address withheld</div>
<div>Browser informationRecorded</div>
<div>Session identifierRecorded / withheld</div>
</div>
<p>Based on an actual completed row. Amounts are grouped, timestamps are reduced to the month, IP octets are masked, and complete wallet addresses, hashes, order IDs and session IDs are intentionally withheld to avoid reproducing a targetable user-level record.</p>
</div>
<p>This establishes that <strong>the supplied application data can map a public-chain deposit to an XMR destination and a network connection</strong>. It does <em>not</em> establish the customer’s legal identity, prove that the requestor owns the receiving wallet or reveal where any XMR later moves.</p>
<div>03 / TWO-WAY CORRELATION</div>
<h2>It works in reverse, too: XMR can become visible again at the exit.</h2>
<div>
<p>The more consequential angle is not limited to buying Monero. We found <strong>11,317 native-XMR-input swap records</strong> containing a 95-character Monero deposit address and a destination for another asset. Of those, <strong>9,187 completed records</strong> also retained an outgoing transaction hash in the corresponding order data.</p>
<p>For an XMR → ETH transaction, for example, the service can connect the private-coin <em>deposit it accepted</em> to the Ethereum address it paid, alongside IP and timing information. That destination can then be examined on Ethereum’s transparent blockchain. Crucially, the service’s XMR deposit address is <strong>not</strong> proof of which Monero wallet originally funded it; Monero does not disclose that sender relationship publicly.</p>
<p>Putting both directions together reveals the real exposure: <strong>entry and exit metadata can erode pseudonymity even while the private blockchain continues doing its job.</strong> It is a correlation problem, not an XMR decryption problem.</p>
</div>
<blockquote>Privacy can survive on-chain and still fail in the database sitting next to the chain.</blockquote>
<div>04 / THE SECOND CSV</div>
<h2>10,139 IPs — and an activity map extending beyond individual swaps.</h2>
<div>
<p>The companion file, <em>users_wagyu.csv</em>, is particularly informative. It groups activity by IP, providing an order count, number of distinct destinations, first and last observation, risk values, reported countries and network-provider classifications. We matched its <strong>10,139 IP-level entries</strong> against <em>orders.csv</em>: each one corresponds to an IP in the larger file, and the per-IP order totals reconcile exactly.</p>
<p>This is <strong>not</strong> a verified database of 10,139 unique human users. Shared IPs, corporate NAT, VPN servers, Tor exit nodes, hosting services and automated API traffic can represent multiple unrelated people — while one person can use several IPs.</p>
</div>
<div>
<div><div>1,328</div><p>IP addresses appear in both XMR-output orders and orders delivering other assets.</p></div>
<div><div>130</div><p>Repeated session IDs span more than one IP address in the order export.</p></div>
<div><div>261</div><p>XMR receiving addresses occur in orders submitted from more than one IP.</p></div>
</div>
<div>
<p>These are <strong>correlation opportunities, not proof of shared ownership</strong>. A reused session ID can be more informative than an IP alone, but it may belong to a shared integration or automated workflow. Likewise, a popular destination can be a custodial wallet rather than one individual.</p>
<p>The network labels themselves include Tor, VPN, hosting and ISP categories. The mere presence of an IP beside a trade does not reveal the person’s home address, and a country or routing code should not be treated as verified geography.</p>
</div>
<div>05 / THE RETENTION QUESTION</div>
<h2>One overlooked field may be the most uncomfortable: <code>userDeletedAt</code>.</h2>
<div>
<p>Among the supplied records, <strong>4,002 completed orders</strong> contain a populated field literally called <code>userDeletedAt</code>. Those same rows are still present in the export. All 4,002 retain an IP and destination; 3,180 also include a deposit transaction hash.</p>
<p>We cannot determine from the field name alone exactly what deletion operation occurred, what the site’s retention policy promised, or whether these rows came from a historical backup. So this is <strong>not proof of an unlawful failure to erase data</strong>. It is evidence that the supplied dataset still holds sensitive transaction metadata for records marked with a user-deletion timestamp.</p>
</div>
<div><p><strong>Why this matters:</strong> A privacy interface can make a transaction disappear from a user’s account view without necessarily removing the underlying connection between their IP, trade and destination from every operational record or backup.</p></div>
<div>06 / FACT-CHECK</div>
<h2>Can this data actually be used to trace XMR users?</h2>
<p>Yes, in a defined and limited sense. Here is the boundary between what the files demonstrate and what they do not.</p>
<div><table><thead><tr><th>Question</th><th>Assessment</th><th>Why</th></tr></thead><tbody>
<tr><td>Can a public-chain payment be linked to an XMR receiving address?</td><td>Supported in data</td><td>Completed cross-chain order rows record deposit transaction hash, XMR destination, client IP and timestamp together.</td></tr>
<tr><td>Can an XMR-to-crypto exit be linked to a transparent payout address?</td><td>Supported in data</td><td>XMR-input orders retain service deposit addresses and destination addresses, often with an outgoing transaction hash.</td></tr>
<tr><td>Can network and session metadata help correlate activity?</td><td>Supported in data</td><td>The IP rollup and reused session IDs create off-chain associations, subject to VPN, NAT and automation ambiguity.</td></tr>
<tr><td>Can the files alone identify the human behind an IP?</td><td>Not established</td><td>IPs, wallet addresses and request headers are not reliable proof of a legal identity or a single user.</td></tr>
<tr><td>Can an analyst follow subsequent XMR transfers on Monero?</td><td>Not demonstrated</td><td>Monero conceals on-chain sender, recipient and amount relationships; this dataset does not defeat that protection.</td></tr>
<tr><td>Does this establish who originally sent XMR to a service deposit address?</td><td>Not demonstrated</td><td>An operator-issued deposit address is not the originator’s wallet, and a private Monero input cannot be attributed from the address alone.</td></tr>
</tbody></table></div>
<p>A cross-chain transaction plus IP metadata can become an investigative lead. Identification may be possible when independently corroborated with exchange KYC data, lawful provider records or other reliable evidence. Without corroboration, it remains a lead — not an identification.</p>
<div>07 / THE SECURITY ANGLE</div>
<h2>For criminals, the off-chain metadata may be more useful than blockchain tracing.</h2>
<p>Exact trade context makes targeted social engineering far more credible. A criminal holding an order’s real amount, approximate time, asset pair and payout destination could construct a believable fake refund or support message. A large historical conversion could also become the basis of financial profiling or extortion. These are plausible abuse cases; we have not established that any has occurred.</p>
<div>
<div><h3>What a criminal could attempt</h3><ul>
<li><strong>Transaction-aware phishing:</strong> cite a real swap to impersonate support or demand a “recovery” payment.</li>
<li><strong>Cross-chain wallet clustering:</strong> connect public-chain activity to the same service session or network source.</li>
<li><strong>Targeted extortion:</strong> use historic transaction values and timing to suggest knowledge of a person’s finances.</li>
<li><strong>Dataset enrichment:</strong> compare exposed metadata with other compromised records to search for corroborating identity clues.</li>
</ul></div>
<div><h3>Where infostealers fit in</h3><p>Infostealer malware can expose browser activity, saved credentials, session artifacts and cryptocurrency-related information on an infected endpoint. In an entirely separate dataset, those artifacts may sometimes add context to a pseudonymous exchange order.</p><p><strong>No supplied evidence indicates that infostealers caused this alleged Wagyu incident, or that Hudson Rock matched any Wagyu customer to an infostealer infection.</strong> The risk is a general correlation mechanism, not a finding about specific users.</p></div>
</div>
<div>08 / WHAT THE ACTOR CLAIMS</div>
<h2>The allegations about hidden fees and rigged games need a separate audit.</h2>
<div>
<p>The WhiteArmor-associated text alleges undisclosed swap fees and manipulated coin-flip odds. The accompanying configuration snapshot does distinguish public and “hidden” fee tiers, while an example order contains discrepant quoted, fee and later adjustment fields. Those findings warrant investigation, but a snapshot or attacker calculation alone does not prove an intentional scheme or the exact amount of customer losses.</p>
<p>The attached aggregate fee summary covers <strong>28,840 completed swap/bridge orders</strong>, a subset that reconciles to completed order counts in the larger CSV. Yet the summary records <strong>11,098</strong> orders in its <code>over</code> category, whereas the actor’s note alleges <strong>13,190</strong> above the quoted rate. Likewise, the note’s coin-flip outcome imbalance does not by itself establish statistical rigging. We have therefore not adopted its claims of “proven” fraud as fact.</p>
<p>There is a further reason not to manufacture a spectacular dollar-volume figure from <em>orders.csv</em>: several expired orders contain implausibly huge <code>amountUsd</code> values. This article reports record counts and verified field co-occurrence rather than summing every row into a misleading trading-volume estimate.</p>
</div>
<div>09 / RECOMMENDATIONS</div>
<h2>What users and privacy-focused platforms should take from this.</h2>
<div>
<div><h3>For users</h3><ul>
<li>Assume a swap provider may retain source and destination addresses, amounts, timestamps and connection metadata, even without an account or KYC.</li>
<li>Be skeptical of unsolicited refund, recovery or verification messages that reference a real historic order.</li>
<li>Avoid unnecessarily sharing transaction IDs or linking wallet addresses to public profiles. VPN or Tor use can limit direct-IP exposure but cannot erase information intentionally submitted to the service.</li>
<li>If you believe your order information was exposed, check announcements through a known authentic channel; do not enter recovery phrases or private keys into support links.</li>
</ul></div>
<div><h3>For exchanges and bridges</h3><ul>
<li>Minimize how long IP addresses, session identifiers, destination addresses and order mappings are retained together.</li>
<li>Separate high-sensitivity transaction data from operational telemetry; implement least privilege, encryption and audited access.</li>
<li>Explain what “delete” means across live systems, logs, analytics exports and backups; verify actual retention controls.</li>
<li>Build incident response around the <em>linkage</em> between records, not merely the presence of standalone wallet addresses.</li>
</ul></div>
</div>
<div>10 / THE TAKEAWAY</div>
<h2>Monero can keep a secret that the service around it does not.</h2>
<p>Our analysis does not show a vulnerability in Monero’s cryptography. It shows that a purported exchange order dataset contains enough <em>off-chain</em> information to connect thousands of privacy-coin transactions to source-chain movements, destination addresses, IPs and sessions. The records can support meaningful correlation; they cannot, on their own, name users or follow hidden XMR transfers.</p>
<p><strong>For any company selling financial privacy, metadata retention is part of the threat model.</strong> A “no-KYC” transaction can still leave a remarkably detailed trail — and that trail may survive long after the user thinks the transaction has disappeared.</p>
<div>METHODOLOGY & SOURCES</div>
<h2>How we verified the numbers and limited the claims.</h2>
<div>
<p>We analyzed the supplied <code>orders.csv</code> (38,628 rows; 45 columns), the <code>users_wagyu.csv</code> IP-level summary (10,139 rows), the WhiteArmor-associated note, and supporting configuration, fee and coin-flip files. We reconciled IP order counts, isolated native XMR address formats and order kinds, checked completion status and counted field co-occurrence. The IP-summary export has a misaligned network-classification header, which we accounted for during inspection.</p>
<p>The datasets’ origin, completeness and authenticity are not independently established. We did not independently verify blockchain settlement, identify private individuals, publish full wallet addresses or IPs, or attempt to follow Monero transactions. “Completed” means the export labels an order as completed, not independently verified settlement. The publication of a ransomware-group listing is a claim, not proof of encryption or exfiltration.</p>
</div>
<div>
<p><strong>Public incident context:</strong> <a href="https://cyberthreatintelligence.net/ransomware-victim/wagyu-xyz-whitearmor-2026" rel="noreferrer" target="_blank">Wagyu.xyz / WhiteArmor listing, October 27</a>; <a href="https://cyberthreatintelligence.net/ransomware-victim/wagyu-xyz-unfairness-whitearmor-2026" rel="noreferrer" target="_blank">“Wagyu.xyz unfairness” listing, October 28</a>; <a href="https://hackerfeeds.com/ransomware/reports/2026-10" rel="noreferrer" target="_blank">HackerFeeds reporting methodology</a>.</p>
<p><strong>Monero technical references:</strong> <a href="https://www.getmonero.org/get-started/faq/" rel="noreferrer" target="_blank">Official Monero FAQ</a>; <a href="https://web.getmonero.org/resources/moneropedia/stealthaddress.html" rel="noreferrer" target="_blank">Stealth addresses</a>; <a href="https://docs.getmonero.org/interacting/remote-nodes/" rel="noreferrer" target="_blank">Network and IP privacy considerations</a>.</p>
<p>Figures are from Hudson Rock’s analysis of supplied material, not independent confirmations from Wagyu. WhiteArmor’s financial accusations are presented as allegations, not proven findings. No personally identifying raw records are republished.</p>
</div>
HUDSON ROCK RESEARCH
Threat intelligence and the cybercrime ecosystemInfostealers.com · October 28, 2026
Threat intelligence and the cybercrime ecosystemInfostealers.com · October 28, 2026
The post 38,628 Crypto Orders. 10,139 IPs. What Wagyu’s Alleged Leak Means for Monero Privacy. appeared first on InfoStealers.
Article Link: 38,628 Crypto Orders. 10,139 IPs. What Wagyu's Alleged Leak Means for Monero Privacy. | InfoStealers