1. Executive summary
A ransomware listing on 2026-09-28 named safescaffolding.net, a UK scaffolding contractor, as a victim of the group "threeam". The listing is a leak-site index entry only: no malware sample, no exploited CVE, no initial-access vector, no exfiltration evidence and no ransom demand are present in the source material. "threeam" has no MITRE ATT&CK profile in our verified reference data, so the attribution is unconfirmed and the group's tradecraft, tooling and victim-selection pattern cannot be characterised. The direct risk to EMEA financial services is low and indirect: the victim is a construction supplier, not a financial entity, and the exposure runs through third-party and supply-chain relationships rather than through any technical path described here. Clients should treat this as a supply-chain notification, not a technical threat requiring detection engineering.
2. Regulatory framing
| Article | Trigger (the fact in this item) | Practical impact |
|---|---|---|
| DORA Art. 28: ICT third-party risk, general principles | A named UK supplier appears on a ransomware leak site, which is the only signal in this item that a third party's ICT systems may be compromised. | Clients that contract this supplier, or that rely on it for physical works at a site hosting ICT assets, should run the standard third-party risk check: confirm whether the supplier is in the register, and whether the relationship carries ICT dependency. |
| NIS2 Art. 21(2)(d): supply chain security measures | Same trigger: the only supply-chain fact is the leak-site listing itself. | If the supplier sits in a client's supply chain and the client is in NIS2 scope, the supplier's security posture becomes a documented supply-chain consideration. No incident report is triggered by this item alone. |
No DORA Art. 17, 18, 19, 24, 29 or 30 trigger is present: there is no confirmed incident at a client, no classification data, no major-incident reporting obligation, no testing implication, no concentration-risk data and no contractual-provision fact in the source. UK NIS 2018 is not engaged: the victim is a construction contractor, not an OES or RDSP, and no UK competent-authority notification fact appears.
3. Technical analysis & attack chain
No confirmed attack chain can be written from this item. The source is a ransomware.live index entry containing a group name, a victim domain, a country code and a one-paragraph company description. It does not state an initial-access vector, an exploited vulnerability, a payload, a persistence mechanism, a privilege-escalation path, command-and-control infrastructure, lateral movement, data access, exfiltration volume or ransom demand.
What is confirmed:
- On 2026-09-28, ransomware.live indexed a listing attributed to the group "threeam" naming safescaffolding.net as a victim.
- The victim is recorded as GB (United Kingdom).
- The victim is described as a privately held contractor in commercial and residential construction, providing scaffolding infrastructure, materials and equipment setup for building and renovation work.
That is the full extent of the confirmed record. The related source page adds only that DNS records were enumerated for the victim domain and that a leak screenshot exists on the listing; the screenshot content is not reproduced in the material supplied to us, and no DNS values are given.
Unconfirmed and single-sourced: the entire attribution to "threeam" rests on the ransomware.live listing alone. We have no second source, no MITRE ATT&CK profile for the group, and no independent confirmation that the group is distinct from any known cluster. Do not treat "threeam" as an established tracked actor on the strength of this item. The claim that data was exfiltrated is implied by the leak-site context but is not stated in the source, and we do not assert it.
4. Mitigation & containment
This item does not describe a technical intrusion at a financial institution, so the actions below are supply-chain and third-party controls, not host containment.
P1 within 24h
- Search the third-party and vendor register for safescaffolding.net and any trading name of the same contractor. If the supplier is engaged, confirm with the relationship owner whether any contract covers works at a site that hosts or adjoins ICT infrastructure, and record the answer.
- If the supplier has any network, remote-access or credential relationship with client systems (for example a shared portal account, a VPN account issued for site work, or an email account on a client domain), disable those accounts and rotate any shared credentials pending confirmation from the supplier. This is the only technical containment step this item justifies.
- Do not contact the supplier through any channel published on the leak listing. Use the contact details already held in the vendor record.
P2 within 72h
- Ask the supplier, through the relationship owner, for a written statement of whether any client data or client-issued credentials were held on the affected systems. Record the response or the non-response.
- If the supplier holds client data under contract, review the security and breach-notification clauses against DORA Art. 30 expectations where the contract is an ICT contract, and against NIS2 Art. 21(2)(d) supply-chain expectations where the client is in scope.
P3 within 7 days
- Update the third-party risk register entry with the listing date, the unconfirmed attribution and the outcome of the P1 and P2 checks.
- No detection rule, EDR exclusion or firewall change is warranted by this item. There is no artefact to detect.
5. Indicators of compromise
No atomic indicators of compromise are available in the source material. The only network value present is the victim's own domain, which is not a malicious indicator and is not reproduced here as one. No hashes, IP addresses, URLs, filenames, registry keys or command lines appear in the source.
Behavioural indicators: none. The source describes no authentication pattern, device registration, process activity or network activity.
6. Detection
Insufficient indicators to author detection rules.
The source contains no distinctive strings, command-line flags, mutex names, scheduled-task or service names, file paths, registry keys, ransom-note text or hard-coded values. The group name and the victim domain are not threat artefacts and a rule built on them would detect reporting about the listing rather than any malicious activity.
7. Sources
- ransomware.live, "Victim: safescaffolding.net – threeam", https://www.ransomware.live/id/c2FmZXNjYWZmb2xkaW5nLm5ldEB0aHJlZWFt, published 2026-09-28.
- ransomware.live, "Ransomware: threeam named safescaffolding.net (GB)", https://www.ransomware.live/id/c2FmZXNjYWZmb2xkaW5nLm5ldEB0aHJlZWFt, published 2026-09-28.
Both sources are the same index entry. There is no independent corroboration for any fact in this advisory.
8. Adverse Trace position
We assess this as a low-severity, single-sourced supply-chain notification with unconfirmed attribution. The victim is a UK construction contractor, the only evidence is a leak-site index entry, and "threeam" has no MITRE ATT&CK profile in our reference data, so we do not treat the group as a characterised actor and we do not assert exfiltration, encryption or ransom demand. Client impact is limited to those with a direct supplier relationship, and the practical exposure is credential and data-holding review rather than technical compromise. We will monitor ransomware.live and other leak-site aggregators for further "threeam" listings to establish whether the group has a victim-selection pattern, and we will issue a follow-up if a second independent source confirms the attribution or if any client reports a direct supplier relationship with safescaffolding.net. Clients with such a relationship should tell their Adverse Trace contact so we can prioritise the check.
Published via PulseTrace — Adverse Trace threat intelligence.