> ## 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.

# Ransomware: dragonforce named RÉSO (FR)
- URL: https://f4n6.co.uk/security-feed/ransomware-dragonforce-named-reso-fr/
- Published: 2026-10-08T08:34:47.000Z
- Updated: 2026-10-08T08:34:47.000Z
- Author: Jeff Davies
- Tags: #security-feed, dragonforce

## 1\. Executive summary

The dragonforce ransomware group listed RÉSO, a French commercial interiors and secondary works contractor, on its leak site on 2026-10-07, claiming theft of 676 GB of customer, partner and employee data and encryption of the entire corporate network including approximately 8 TB of Veeam backups. The victim has not reached an agreement with the operators, which places the data at risk of publication. Attribution to dragonforce rests on the leak-site listing alone; the VERIFIED REFERENCE DATA holds no MITRE ATT&CK profile for this actor, so the attribution is unconfirmed and the group's tooling, initial-access vector and infrastructure are not established by this item. No CVE, CVSS score or CISA KEV entry is associated with this item, so there is no patch action to prioritise. The direct risk to EMEA financial services clients is second-order: RÉSO is a construction-sector supplier, and the exposure sits with any client that holds RÉSO in its third-party register, shares data with it, or relies on it for facilities work.

## 2\. Regulatory framing

| Article                                                                 | Trigger (the fact in this item)                                                                                                                          | Practical impact                                                                                                                                                                                                               |
| ----------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| DORA Art. 28: ICT third-party risk, general principles                  | A supplier in the construction and facilities sector has had its network encrypted and 8 TB of backups destroyed, and clients may hold contracts with it | Clients must be able to identify RÉSO as an ICT third-party dependency, confirm whether any contract or data flow exists, and assess whether the loss of that supplier's availability affects a critical or important function |
| DORA Art. 30: key contractual provisions with ICT third-party providers | The victim's backups were destroyed, so any client relying on RÉSO to hold or process data cannot assume the supplier can restore it                     | Where a contract exists, check whether it carries exit, data-return and availability provisions, and whether the supplier can still meet them                                                                                  |
| NIS2 Art. 21(2)(d): supply chain security measures                      | The compromise is at a supplier, not at the client, and the client's exposure is through the supply relationship                                         | Clients in NIS2 scope should treat this as a supply-chain security event and record the assessment against their supplier risk process                                                                                         |

No DORA incident-reporting article is engaged for a client unless the client itself suffers an ICT-related incident as a result. A supplier's breach does not by itself trigger DORA Art. 19 reporting for the client.

## 3\. Technical analysis & attack chain

The source material is a leak-site listing. It gives the claimed outcome and the claimed volume of data, and nothing about how the intrusion was carried out. There is no initial-access vector, no exploited component, no CVE, no malware family, no persistence mechanism, no command-and-control detail and no lateral-movement path in the provided content. The attack chain below is limited to what the listing actually states.

1. The operators gained access to RÉSO's network. The method is not stated in the source.
2. They exfiltrated 676 GB of data described as confidential information belonging to customers, partners and employees.
3. They encrypted the entire network.
4. They also encrypted approximately 8 TB of Veeam backups, removing the victim's primary recovery path.
5. RÉSO did not reach an agreement with the operators, and the listing was published on 2026-10-07.

The two operationally significant facts are the data volume and the destruction of the backup tier. A 676 GB exfiltration is large enough that the operators had sustained access and sufficient bandwidth to move it, which implies a dwell time the source does not quantify. The encryption of 8 TB of Veeam backups indicates the operators reached the backup infrastructure, not just the production estate. Whether that was achieved through compromised backup credentials, a management console exposed to the network, or a flat trust relationship between production and backup systems is not stated. Defenders should treat all three as live possibilities when reviewing their own environments, because the listing does not distinguish between them.

The claim that the entire network was locked is the operators' assertion, published on their own leak site. It is not independently corroborated by any source in this item, and RÉSO has not issued a statement in the material provided. Treat the data volume, the backup figure and the scope of encryption as single-sourced claims from the operators until the victim or a national authority confirms them.

Attribution to dragonforce is single-sourced to the leak-site listing. The VERIFIED REFERENCE DATA contains no MITRE ATT&CK profile for this actor, so no TTPs, tooling or infrastructure can be attributed with confidence. The name appearing on a leak site is not, on its own, proof of who conducted the intrusion; leak sites are also used by affiliates, rebranded operations and, occasionally, by parties with no involvement in the original compromise.

## 4\. Mitigation & containment

This item contains no CVE, no vendor fix and no technical indicator, so the actions below address supply-chain exposure and the backup-destruction pattern the listing describes. They are not a patch response.

P1, within 24 hours

- Search the third-party and vendor register for RÉSO and any trading name, subsidiary or agency operating under it. Confirm whether any contract, data-sharing arrangement, facilities contract or purchase order exists. If nothing is found, record the negative result and close the item.
- Where a relationship exists, identify what data the client has shared with RÉSO and in which direction. Employee, customer and partner records are the categories the operators claim to hold.
- Confirm whether any client system authenticates to, integrates with, or is administered by RÉSO personnel, for example shared file shares, VPN accounts, or building-management or facilities platforms. Disable or rotate any credential that a RÉSO employee could hold.
- Treat any data the client has passed to RÉSO as potentially disclosed. Do not wait for publication to begin the assessment.

P2, within 72 hours

- Test backup restore for one production system and one directory service object from an isolated recovery environment. The RÉSO listing shows that a Veeam deployment with 8 TB of data was encrypted, so a backup that exists but has never been restored is not evidence of recoverability.
- Verify that the backup management plane is not reachable from the production network with the same credentials used in production. Check for shared service accounts between the two.
- Confirm that backup repositories are immutable or offline for at least one copy. If the backup tier is domain-joined and uses production credentials, that is the condition the RÉSO operators exploited and it should be corrected before anything else in this list.

P3, within 7 days

- Review the contract with RÉSO, if one exists, against DORA Art. 30 expectations: exit provisions, data return, availability commitments and breach notification. Where the contract is silent, record the gap.
- Add the supplier to the concentration-risk view under DORA Art. 29 if the client depends on it for a critical or important function.
- Where the client is in NIS2 scope, record the supply-chain assessment against NIS2 Art. 21(2)(d).

## 5\. Indicators of compromise

No indicators of compromise available in the source material. The listing provides no hashes, domains, IP addresses, file paths, registry keys or ransom-note text. The victim domain www.reso.fr is the victim's own public website, not an operator-controlled indicator, and is not reproduced here as an IOC.

Behavioural indicators

| behaviour                                                            | where to observe                                                             | confidence                                                                                               |
| -------------------------------------------------------------------- | ---------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
| Encryption of Veeam backup repositories alongside production systems | Backup server event logs, Veeam job history, repository file-system metadata | Medium. Stated in the leak-site listing; single-sourced to the operators and not independently confirmed |
| Large outbound data transfer in the region of 676 GB                 | Egress firewall and proxy logs, NetFlow or equivalent flow data              | Low. Volume is the operators' claim; no timeframe is given, so no rate or window can be derived          |
| Publication of victim data on a dragonforce leak site                | External threat-intel monitoring of the leak site                            | Medium. The listing is publicly visible; the underlying data has not been verified                       |

## 6\. Detection

Insufficient indicators to author detection rules. The source material contains 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. A rule built from the victim name, the actor name or the sector would detect reporting about this event rather than the threat itself, and is not emitted.

## 7\. Sources

- ransomware.live, "Victim: RÉSO – dragonforce", https://www.ransomware.live/id/UsOJU09AZHJhZ29uZm9yY2U=, published 2026-10-07\. Single source for all facts in this advisory; the technical claims within it originate from the operators' own leak-site post.

## 8\. Adverse Trace position

Adverse Trace assesses this as a confirmed ransomware and data-theft event against a French construction-sector supplier, with unconfirmed attribution to dragonforce and no technical indicators available for client enforcement. The severity to EMEA financial services clients is low to moderate and indirect: there is no exploitable vulnerability, no CVE and no KEV entry, so the exposure is confined to clients that hold RÉSO in their supply chain or have shared data with it. The backup-destruction detail is the part worth acting on regardless of the victim, because it describes a failure mode that recurs across ransomware incidents and is testable in any environment. We will monitor the dragonforce leak site for publication of the claimed data and for any technical detail that would allow indicator extraction, and we will reissue this advisory if the victim, a national authority or a second source corroborates the scope, the data volume or the attribution. Clients that identify a live RÉSO dependency should contact their Adverse Trace handler to scope the assessment.

---

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

*Published via PulseTrace — Adverse Trace threat intelligence.*