1. Executive summary
The extortion group tracked as BYOD posted a victim entry on 2026-10-07 naming Gate, a Singapore-based crypto exchange, and claims to hold data on 12 million users. The listed data classes are customer-facing and identity-heavy: phone numbers, nicknames, balance and VIP tier, a 2FA indicator distinguishing passkey from authenticator, region, UIDs, gender, position, assets under management, profit rates, verification status, city, strategy, account age and a profile key. No CVE, exploited component or initial-access vector is disclosed in the source, and BYOD has no MITRE ATT&CK profile in our reference data, so the attribution and the breach mechanism are unconfirmed. For EMEA financial services clients the exposure is indirect but material: leaked 2FA-type and verification-status fields shorten credential and account-takeover paths against any institution whose customers or counterparties also hold Gate accounts, and the same actor has a second, finance-sector victim posted alongside this one.
2. Regulatory framing
| Article | Trigger (the fact in this item) | Practical impact |
|---|---|---|
| DORA Art. 28 | The compromised entity is a crypto exchange, an ICT third-party service provider to any EMEA client that integrates it for custody, settlement or on/off-ramp | Clients must establish whether Gate sits in their register of ICT third-party providers and whether the incident affects a service they consume |
| DORA Art. 29 | Same third-party relationship, where Gate is used for a function that is not readily substitutable | Clients must assess concentration risk if the affected service cannot be moved to an alternate provider at short notice |
| NIS2 Art. 21(2)(d) | Supply chain exposure to a provider whose customer data set is now in an extortion group's hands | Clients must review supply chain security measures covering this provider relationship |
No DORA Art. 17, 18 or 19 obligation is engaged on the facts available: those articles attach to an incident at the client itself, and the source gives no evidence of impact on a client's own ICT systems. No UK NIS 2018 duty is engaged on the available facts.
3. Technical analysis & attack chain
The source is a ransomware.live victim listing. It contains a claim of data theft and a threat to publish, and nothing else. There is no disclosed initial-access vector, no exploited CVE, no malware family, no command-and-control detail and no timeline. An attack chain cannot be reconstructed from this material, and we will not manufacture one.
What the listing does state, verbatim in substance, is the claimed data set: 12 million users, phone numbers, nicknames, balance and VIP tier list, a 2FA indicator that differentiates passkey from authenticator, region, UIDs, gender, position, assets under management, profit rates, verification status, city, strategy, account age and a profile key. The operator's message is extortion-flavoured, offering contact through a contact tab and stating "we will take you down when communication has been established between our team and yours." That is a negotiation demand, not a technical disclosure.
Two points of analytical value survive the thinness of the source.
First, the 2FA indicator field. If the claim is accurate, the data set tells an attacker which accounts use a passkey and which use an authenticator app. That distinction matters because the two are not equally resistant to phishing and session theft, and a leaked field that labels each account by method lets an attacker target the weaker cohort first. This is a claim in the listing, not a verified property of the data, and it should be treated as such.
Second, the profile key field. A per-account key of this kind, if it is a stable identifier used in account recovery or profile lookup, is the sort of value that supports credential-stuffing and account-recovery abuse across any platform that shares the identifier. We do not know its format or its function from the source.
A second victim listing from the same group, Standpointe / Trinite Solutions, was posted to the same index and lists financial statements, customer bank accounts, deposit slips, payment and cheque registers, tax and accounting records, customer names, phones, emails and addresses, employee identities and commercial secrets. The two listings share the group's closing line about the contact tab and establishing communication. This is the only corroboration available that BYOD is an active extortion operation with a finance-sector focus, and it is single-sourced to the same index.
Confidence caveat: every factual claim in this section rests on ransomware.live victim listings, which republish operator posts without verifying the underlying data. The 12 million figure, the field list and the 2FA indicator claim are the operator's assertions. Nothing here has been independently corroborated, and no sample of the data has been reviewed. Treat the entire data-set description as unverified.
4. Mitigation & containment
P1 (within 24 hours)
- Determine whether your institution holds a Gate account, a Gate custody or settlement relationship, or any integration that passes customer identity data to Gate. If yes, treat the relationship as an active third-party incident and open a DORA Art. 28 third-party record against it.
- If any customer or counterparty identity data flows to or from Gate, pull the list of affected accounts and force a credential reset on your own side for any account that shares an email address, phone number or UID with a Gate account.
- Where your authentication stack can read a 2FA-method signal, prioritise step-up challenges for accounts still on authenticator-app or SMS methods rather than passkeys, on the assumption that the leaked 2FA indicator field is accurate. This is a precaution against a claim, not a confirmed exposure.
- Suspend any automated account-recovery or profile-lookup flow that keys off a Gate-issued identifier until you have confirmed what the "profile key" field is.
P2 (within 72 hours)
- Complete the DORA Art. 29 concentration assessment if Gate supports a function you cannot substitute at short notice.
- Review the contract against DORA Art. 30 key contractual provisions, specifically breach notification, data return and audit rights, and confirm whether Gate has notified you of this incident. The source gives no evidence that Gate has notified anyone.
- Add the leaked field set to your fraud-monitoring rules: verification-status and AUM fields combined with a phone number are enough to build a convincing social-engineering pretext against high-value customers.
P3 (within 7 days)
- Reassess whether the Gate relationship should continue, and document the decision.
- Brief customer-facing and fraud teams on the leaked field list so they can recognise a pretext call that quotes a customer's VIP tier, AUM or verification status back at them.
No vendor fix, patch or version pin applies here. This is a data-exposure and third-party-risk event, not a software vulnerability, and there is no CVE to remediate.
5. Indicators of compromise
No indicators of compromise available in the source material. The source contains no hashes, domains, IP addresses, file paths, registry keys or command lines.
The source does describe observable data classes. These are not atomic indicators and cannot be pivoted on mechanically, but they are the fields to watch for if the data set is published or offered for sale.
| Behaviour | Where to observe | Confidence |
|---|---|---|
| Appearance of Gate customer records containing phone number, nickname, balance/VIP tier, 2FA method indicator, region, UID, gender, position, AUM, profit rate, verification status, city, strategy, account age and profile key | Dark web marketplaces, paste sites, credential-stuffing tooling, customer-support fraud attempts | Low, single-sourced to the operator's own listing |
| Credential-stuffing attempts against accounts matching the leaked identifier set | Authentication logs, WAF, account-takeover alerts | Low, contingent on the data set being real and published |
| Pretext calls or emails quoting VIP tier, AUM or verification status | Customer fraud reports, contact-centre logs | Low, single-sourced |
6. Detection
Insufficient indicators to author detection rules. The source provides no file artefacts, command lines, registry keys, scheduled-task names, ransom-note text or network indicators. The only strings present are the operator's prose and the victim's name, which are reporting about the event rather than artefacts of it, and a rule built on them would detect this advisory rather than the threat.
7. Sources
- Ransomware.live, "Ransomware: BYOD named Gate | Crypto Exchange (SG)", https://www.ransomware.live/id/R2F0ZSB8IENyeXB0byBFeGNoYW5nZUBCWU9E, published 2026-10-07
- Ransomware.live, "Ransomware: BYOD named Standpointe / Trinite Solutions", https://www.ransomware.live/id/U3RhbmRwb2ludGUgLyBUcmluaXRlIFNvbHV0aW9uc0BCWU9E, date not given in source
- Ransomware.live, "Victim: Gate | Crypto Exchange – BYOD", https://www.ransomware.live/id/R2F0ZSB8IENyeXB0byBFeGNoYW5nZUBCWU9E, date not given in source
8. Adverse Trace position
We assess this as a medium-severity, unconfirmed data-extortion claim against a third-party crypto exchange, not a direct threat to EMEA client infrastructure. The severity is held at medium because the underlying data set is unverified, the actor has no MITRE ATT&CK profile in our reference data, and no technical mechanism is disclosed; the impact would rise to high for any client that consumes Gate services or shares customer identifiers with it. We will monitor ransomware.live and adjacent leak sites for publication of the data set or a sample, watch for the profile-key field appearing in credential-stuffing tooling, and issue a follow-up if Gate confirms the breach or if the data is published. Clients with a Gate relationship should treat the P1 items above as the immediate action and confirm to us whether that relationship exists so we can scope the follow-up correctly.
Published via PulseTrace — Adverse Trace threat intelligence.