> ## Content Index
> Fetch the complete content index at: https://f4n6.co.uk/llms.txt
> Use this file to discover other available public pages before exploring further.

# N0n exposes Solid Trading B.V. FX data including FIX credentials and client hashes
- URL: https://f4n6.co.uk/security-feed/n0n-exposes-solid-trading-b-v-fx-data-including-fix-credentials-and-client-hashes/
- Published: 2026-10-18T11:50:30.000Z
- Updated: 2026-10-18T11:50:30.000Z
- Author: Jeff Davies
- Tags: #security-feed, N0n

## 1\. Executive summary

The ransomware and extortion group tracked as N0n listed Solid Trading B.V., a Netherlands-based FX liquidity and trading technology provider, on its leak site on 2026-10-18, publishing a data set it claims includes live client order and execution records, a client database with platform user password hashes, credit limits, clearing paths and fee schedules, FIX venue session configurations with liquidity provider login credentials, and trade history with bank matching audit records. The listing is marked NOT PAID and EXPOSED, meaning the operators state the data has already been released rather than held under negotiation. The exposure of FIX session credentials and client password hashes is the material risk: those secrets authenticate machine-to-machine trading sessions and platform accounts, and they do not expire on their own. No CVE is associated with this item and there is no CISA KEV entry, so this is a data-exposure and credential-compromise event, not a patchable software vulnerability. EMEA banks and institutions that route FX orders through Solid Trading, or that hold accounts on its platform, should treat their FIX credentials and platform passwords as compromised until the provider confirms otherwise.

## 2\. Regulatory framing

| Article                                                                         | Trigger (the fact in this item)                                                                                                                                                                  | Practical impact                                                                                                                                                                                                   |
| ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| DORA Art. 19: reporting of major ICT-related incidents to competent authorities | A critical ICT third-party provider to trading institutions has had FIX session credentials and client order data exposed, and the affected institutions rely on that provider for order routing | Affected clients must assess whether the incident meets their own major-incident threshold and report within the applicable deadline; the trigger is the third-party dependency, not the provider's own disclosure |
| DORA Art. 28: ICT third-party risk — general principles                         | The exposure originates at an ICT third-party provider (Solid Trading) whose FIX sessions and platform sit in the client's trading path                                                          | Clients must determine their contractual and operational exposure to this provider and whether continuity arrangements are adequate                                                                                |
| NIS2 Art. 21(2)(d): supply chain security measures                              | Compromised FIX credentials at a supplier give a route into client trading systems through the supplier relationship                                                                             | Clients must assess supply chain security measures covering this provider, including credential handling and session controls                                                                                      |

## 3\. Technical analysis & attack chain

The source material is a leak-site listing. It describes what N0n claims to hold, not how the intrusion was carried out. The following steps are the confirmed facts from the listing; the intrusion mechanism is not stated in the source and is not asserted here.

1. N0n listed Solid Trading B.V. (Netherlands) as a victim on its leak site, dated 2026-10-18.
2. The listing states the data set is NOT PAID and EXPOSED, i.e. published rather than withheld.
3. The claimed contents are: live client trading records (order and execution data for the banks and institutions trading through the firm, with amounts and account identifiers); a client database of companies and platform users with password hashes, credit limits, clearing paths and fee schedules; FIX venue session configurations including login credentials for liquidity providers; and trade history with bank matching audit records.

What matters to a defender is the nature of the four data classes, because each carries a different follow-on risk.

FIX venue session configurations with liquidity provider login credentials are the highest-impact item. FIX (Financial Information Exchange) sessions authenticate a trading participant to a venue or liquidity provider using a session-level login, typically a SenderCompID/TargetCompID pair plus a password or, in some deployments, a shared secret or key. Whoever holds those credentials can attempt to establish a session as the legitimate participant. If the venue does not bind the session to a source IP or a client certificate, possession of the credentials is sufficient to submit orders. The listing does not state which venues, which liquidity providers, or whether the credentials are still valid, so the exposure has to be treated as live until each counterparty confirms rotation.

The client database with password hashes is the second item. The listing says "password hashes" without naming the algorithm. If the platform used a fast hash (MD5, SHA-1, or unsalted SHA-256), the hashes are crackable and the resulting plaintext can be replayed against the platform and against any other service where users reused the password. If it used a slow, salted scheme (bcrypt, scrypt, Argon2), offline cracking is far slower but not impossible for weak passwords. The source does not say which, so both cases must be planned for.

Live client trading records with amounts and account identifiers, and trade history with bank matching audit records, are confidentiality exposures. They do not by themselves grant access, but they give an attacker the account identifiers, order flow and matching detail needed to craft convincing payment or trade instructions against the named banks and institutions, and they expose client positions and volumes.

No initial access vector, exploited component, CVE, malware family, persistence mechanism, command-and-control channel, or lateral movement detail is present in the source. None is asserted. The listing gives no sample hashes, no file names, no infrastructure, and no negotiation or payment detail beyond the NOT PAID / EXPOSED status.

Attribution caveat: the group is named only as "N0n" in the listing. There is no MITRE ATT&CK profile for this actor, so the attribution to a tracked, characterised group is unconfirmed. Treat "N0n" as the leak-site handle only. The listing is single-sourced (the leak site itself, indexed by ransomware.live); the data classes and the NOT PAID / EXPOSED status are the operator's claims and have not been independently verified.

## 4\. Mitigation & containment

P1 (within 24 hours)

- Treat every FIX session credential that Solid Trading held on your behalf as compromised. Contact each liquidity provider and venue directly and request immediate rotation of the session login for any FIX session configured through Solid Trading. Do not wait for the provider to confirm the breach.
- Ask each venue whether it enforces source-IP allow-listing or client-certificate binding on your FIX sessions. Where it does not, request that it be enabled before the rotated credentials go live, so that a leaked password alone is not sufficient to open a session.
- Reset platform passwords for every user account on the Solid Trading platform, and force a reset for any account whose credentials may have been reused elsewhere. Invalidate all active sessions.
- If you route orders through Solid Trading, suspend or tightly monitor new order flow through that provider until it confirms which sessions and accounts were affected.

P2 (within 72 hours)

- Review FIX session logs and platform access logs for the period before and after 2026-10-18 for logins from unexpected source IPs, sessions opened outside normal trading hours, or order submissions that do not match your expected flow.
- Reconcile your trade history and bank matching records against your own books for any orders or matches you do not recognise.
- Notify the banks and institutions named in your own trading records that their account identifiers and order data may be exposed, so they can watch for follow-on payment or trade-instruction fraud.

P3 (within 7 days)

- Assess your DORA Art. 28 third-party exposure to Solid Trading and document whether continuity arrangements cover loss of the provider's FIX connectivity.
- Review the contract with Solid Trading against DORA Art. 30 key contractual provisions, in particular breach notification, credential handling and audit rights.
- Where the platform used fast password hashes, assume the hashes are crackable and prioritise the password resets and reuse checks above accordingly.

## 5\. Indicators of compromise

No indicators of compromise available in the source material.

The source provides no hashes, domains, IP addresses, file names, or other atomic indicators. The only observable facts are the leak-site listing and the data classes it claims. There are no machine-pivotable indicators to place in a copyable block.

## 6\. Detection

Insufficient indicators to author detection rules.

The source contains no distinctive strings, command-line flags, file names, registry keys, or network artefacts from which a YARA or Sigma rule could be built. The only named entities are the victim organisation and the leak-site handle, which are not artefacts of the threat itself.

## 7\. Sources

- ransomware.live, "Victim: Solid Trading B.V. – N0n", https://www.ransomware.live/id/U29saWQgVHJhZGluZyBCLlYuQE4wbg==, published 2026-10-18.

## 8\. Adverse Trace position

This is a data-exposure and credential-compromise event with no associated CVE and no CISA KEV entry, so it is not a patching item; the severity rests on the exposure of FIX session credentials and client password hashes, which are reusable secrets rather than one-time data. The listing is single-sourced from the leak site and the data classes are the operator's claims, so we treat the specific contents as unverified while treating the credential exposure as live for planning purposes; the attribution to a characterised group is unconfirmed because no MITRE ATT&CK profile exists for "N0n". Client impact is concentrated in any EMEA institution that routes FX orders through Solid Trading or holds a platform account there: those clients should assume their FIX credentials and platform passwords are compromised and rotate them now rather than await provider confirmation. Adverse Trace will monitor the leak site and related channels for further N0n postings, attempt to corroborate the claimed data classes against independent reporting, and update this advisory if the provider confirms scope or if additional victims in the FX and trading-technology sector are listed.

---

[Read the original source →](https://www.ransomware.live/id/U29saWQgVHJhZGluZyBCLlYuQE4wbg==?ref=f4n6.co.uk)

*Published via PulseTrace — Adverse Trace threat intelligence.*