Ransomware: N0n named Dediserve Ltd (GB)

1. Executive summary

The extortion group tracked as N0n listed Dediserve Ltd, a GB-registered cloud infrastructure provider within the iomart group, on its leak site on 2026-09-28 with a settlement deadline of 2026-10-01 05:16 UTC. The listing claims theft of the complete FRA1 Frankfurt customer register (167 tenant accounts with infrastructure details), disk images of tenant servers belonging to a regulated forex broker, a payment services provider and a production real-estate platform, plus the provider's internal operations mailbox and monitoring configuration. The claimed tenant set includes a regulated forex broker's portal with payment gateway configuration and trading-account records, and a payment services provider's systems including an internal password vault. No CVE is referenced in this item and the VERIFIED REFERENCE DATA records no CISA KEV entry, so this is a data-theft and extortion event, not an exploitation of a named vulnerability. EMEA financial services clients hosting production workloads on Dediserve FRA1, or whose service providers do, should treat the tenant data described as potentially exposed and act on the assumption that credentials and payment configuration in those systems are compromised.

2. Regulatory framing

DORA Art. 17, Art. 18, Art. 24, Art. 29, Art. 30, NIS2 Art. 23 and UK NIS 2018 are not engaged by any fact specific to this item. Art. 18 classification and Art. 23 reporting are downstream of the client's own determination under Art. 19 and are not triggered by the listing alone.

3. Technical analysis & attack chain

The source material is a leak-site listing. It states what N0n claims to hold and what it demands. It does not describe initial access, tooling, or the intrusion method. No attack chain can be reconstructed from the available facts, and none is asserted here.

What the listing claims, in the operator's own framing:

1. N0n listed Dediserve Ltd (GB) on 2026-09-28 with an active deadline of 2026-10-01 05:16 UTC.
2. The claimed data set is the complete customer register of the FRA1 cloud: 167 tenant accounts with infrastructure details.
3. The claimed data set also includes disk images of tenant servers: a regulated forex broker's portal (payment gateway configuration, trading-account records), a payment services provider's systems including its internal password vault, and a production real-estate platform.
4. The claimed data set includes the provider's internal operations mailbox and monitoring configuration.
5. The operator states that all 46 FRA1 servers are paused and intact and restorable automatically within the hour of settlement.

The operational claim in item 5 is the one with the most direct consequence for defenders. If the operator can pause and restore 46 servers, it asserts control over the FRA1 hypervisor or management plane rather than only over data copies. That is a claim, not a verified capability, and the source provides no evidence either way. Clients should not treat "restorable within the hour" as reassurance: it describes the operator's leverage, not the provider's recovery posture.

The tenant data described is the material risk. A payment services provider's internal password vault and a forex broker's payment gateway configuration are credential and payment-path assets. If the disk images are genuine, the exposure is not limited to the listed tenants: any credential, key, or configuration in those images that reaches a shared service or a third-party API is in scope.

Attribution is unconfirmed. The VERIFIED REFERENCE DATA records no MITRE ATT&CK profile for the actor "N0n". The name is the operator's self-designation on the leak site. It should not be mapped to any tracked group, and no assessment of the actor's history, capability, or targeting is offered here.

The related source is a second N0n listing, STOKR, a Luxembourg digital securities platform, with a deadline of 2026-09-20 22:40 UTC. It claims a KYC investor register (full names, emails, countries, nationalities, wallet addresses and tax IDs where present), an identity-to-crypto-wallet mapping of KYC-accepted investors across FR, DE, CH, BE, NL, UK and others, and an internal platform admin directory with staff accounts and roles. The operator states the investor data will also be delivered to the tax authorities of the investors' countries. This is a separate victim and a separate claim. It is relevant only as an indicator of the actor's stated targeting of financial and digital-asset platforms and of a threat pattern that combines data publication with a regulatory-reporting threat. Both listings are single-sourced to the leak site; the underlying data has not been independently verified.

4. Mitigation & containment

P1 (within 24 hours)

• Determine whether Dediserve or iomart appears in your ICT third-party register and whether any production workload, tenant, or managed service runs in FRA1. If yes, treat the tenancy as compromised and open an incident record.
• Rotate every credential, API key, TLS private key, and payment gateway secret that has ever been stored on or served from a Dediserve FRA1 host. The claimed exposure of a payment services provider's internal password vault means secrets held in that vault must be assumed disclosed. Rotation is the priority action; do not wait for provider confirmation.
• If you operate a payment gateway or trading platform on FRA1, disable outbound payment initiation from affected hosts until gateway configuration has been reviewed and re-issued by the gateway provider.
• Preserve evidence before any rebuild: capture disk images, hypervisor and management-plane logs, and authentication logs for the FRA1 tenancy. The listing claims the servers are paused and intact; if the provider restores them, volatile evidence may be lost.
• Notify your competent authority if your own classification process under DORA Art. 18 concludes this is a major ICT-related incident.

P2 (within 72 hours)

• Review the provider's contractual position against DORA Art. 30: what access the provider holds to your systems, what it can do at the hypervisor or management plane, and what notification and audit rights you have. If the contract does not cover this, that gap is the finding.
• Assess concentration: how many of your critical or important functions depend on this provider or on the iomart group, and what the exit path is. DORA Art. 29 applies if the dependency is material.
• Review authentication logs for the affected tenancy for access from unexpected source addresses or at unexpected times, and for use of service accounts that should not have interactive sessions.
• If you are a payment services provider or a forex broker with systems in FRA1, run a retrospective review of payment instructions and trading-account changes for the period the operator claims to have held the data. The listing does not state a dwell time; the review window should be set from your own log retention.

P3 (within 7 days)

• Require the provider to confirm in writing which tenants are affected, what data was taken, and what management-plane access the operator had. Treat the provider's statement as one input, not as closure.
• Review whether tenant isolation at the provider meets your requirements. The claimed access to multiple tenants' disk images from a single operator position is the control failure to test.
• Update your third-party risk assessment and, if the provider supports a critical or important function, your exit and substitution plan.

5. Indicators of compromise

No atomic indicators of compromise are available in the source material. The sources contain no file hashes, domains, IP addresses, email addresses, or file paths.

The sources do describe observable behaviours and claimed data sets. These are listed below as behavioural indicators. They are claims made by the operator on a leak site and are single-sourced; verify before enforcement.

6. Detection

Insufficient indicators to author detection rules.

The sources provide no distinctive strings, command-line flags, mutex names, scheduled-task or service names, file names or paths, registry keys, ransom-note text, or hard-coded values. The only artefacts present are victim names, a group name, and claimed data-set descriptions, none of which are artefacts of the threat itself. A rule built on those would detect reporting about the incident, not the incident.

Detection effort for this item belongs in the behavioural layer described in §5: management-plane audit logging for the FRA1 tenancy, secret-store access monitoring, and payment gateway configuration change alerting. Those are controls to verify, not signatures to deploy.

7. Sources

• Ransomware.live, "Ransomware: N0n named Dediserve Ltd (GB)", https://www.ransomware.live/id/RGVkaXNlcnZlIEx0ZEBOMG4=, published 2026-09-28.
• Ransomware.live, "Ransomware: N0n named STOKR (digital securities platform) (LU)", https://www.ransomware.live/id/U1RPS1IgKGRpZ2l0YWwgc2VjdXJpdGllcyBwbGF0Zm9ybSlATjBu, date not stated in the source.

Both sources are leak-site index entries. Ransomware.live states it indexes publicly visible operator posts and does not access or hold the underlying stolen data. No independent verification of either claim is available in the source material.

8. Adverse Trace position

Adverse Trace assesses this as a high-impact data-theft and extortion event for any client with production workloads in Dediserve FRA1, and a supply chain exposure for clients whose service providers host there. The severity rests on the claimed tenant set, not on any CVE: the VERIFIED REFERENCE DATA records no CISA KEV entry and no CVSS score for this item, and none is asserted. The attribution to "N0n" is unconfirmed; the VERIFIED REFERENCE DATA holds no MITRE ATT&CK profile for that name, and we do not map it to a tracked group. Every claim in this advisory traces to a single leak-site listing and has not been independently verified; clients should verify before enforcement. We will monitor for provider confirmation, for publication of the claimed data set after the 2026-10-01 05:16 UTC deadline, and for further N0n listings naming financial entities, and will issue an update if the provider confirms scope or if the deadline passes without settlement. Clients who identify FRA1 dependencies should contact their Adverse Trace analyst to scope the third-party and regulatory exposure.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.