Ransomware: safepay named meterex.com (DE)

1. Executive summary

On 2026-09-15, the ransomware leak-site indexer ransomware.live recorded a victim posting by a group calling itself "safepay", naming meterex.com (Germany) as a victim. The named entity is headquartered in Langenfeld, North Rhine-Westphalia, and is legally registered as Karl Kuntze (GmbH & Co.), HRA 16336. No CVE, CVSS score, exploitation state, malware family, or technical artefact is present in the source material, so no severity rating can be assigned from verified data and no attack chain can be reconstructed. The direct risk to EMEA financial services clients is contingent and currently unquantified: it materialises only if the named entity sits in a client's ICT supply chain or if the listing is a precursor to data publication. Attribution to "safepay" is unconfirmed — the actor has no MITRE ATT&CK profile in our verified reference data.

2. Regulatory framing

No specific DORA/NIS2 article is directly engaged by this item.

The source is a third-party leak-site listing naming a German legal entity. It contains no fact about any Adverse Trace client's own systems, no confirmed client exposure, and no confirmed supply-chain relationship. Mapping DORA Art. 17–19 or NIS2 Art. 23 to this item would require the incident to be the client's own, which the source does not establish.

One conditional note, not a table row: if the named entity (Karl Kuntze (GmbH & Co.), meterex.com) is confirmed as an ICT third-party provider in a client's vendor inventory, then DORA Art. 28 (ICT third-party risk — general principles) and Art. 29 (preliminary assessment of ICT concentration risk) become relevant to that client's own vendor-risk process, and Art. 30 (key contractual provisions with ICT third-party providers) becomes relevant to the incident-notification and cooperation clauses in the underlying contract. That determination is client-specific and cannot be made from this source.

3. Technical analysis & attack chain

Confirmed steps (all that the source supports)

1. A group operating under the name "safepay" posted a victim entry naming meterex.com.
2. The listing was indexed by ransomware.live on 2026-09-15T19:31:20Z.
3. The listing attributes the victim to Germany and identifies the operating entity as Karl Kuntze (GmbH & Co.), HRA 16336, headquartered in Langenfeld, North Rhine-Westphalia.
4. The indexer page carries a "Leak Screenshot" field and a DNS Records field; the fetched content does not include the contents of either.

Not present in the source — do not assume: initial access vector, exploited component or CVE, vulnerability mechanism, malware family or capabilities, persistence mechanism, privilege escalation, command-and-control infrastructure, lateral movement, exfiltration volume or method, encryption behaviour, ransom demand, negotiation status, or any proof-of-data sample. No file names, paths, registry keys, ports, protocols, or tooling are given. Any narrative filling these gaps would be fabrication.

Confidence caveats

• The entire item rests on a single source (ransomware.live, a leak-site indexer). Indexer entries are operator self-claims republished without verification. The claim that data was exfiltrated, or that the victim's systems were encrypted, is not corroborated by anything in the material provided.
• The page carries a sponsorship line for Hudson Rock's infostealer intelligence tooling. This is advertising on the indexer page, not a finding about this victim. It must not be read as evidence that an infostealer infection preceded this incident.
• Attribution to "safepay" is unconfirmed. The actor has no MITRE ATT&CK profile in our verified reference data; there is no corroborating reporting on the group's tradecraft, tooling, or victimology in the material supplied.
• The legal disclaimer on the indexer page confirms it does not access or distribute the underlying stolen data. Nothing here should be treated as validated evidence of a breach.

4. Mitigation & containment

Because the source provides no technical artefacts, the actions below are supply-chain and exposure-management steps, not incident containment. They are proportionate to what is actually known.

P1 — within 24h

• Search vendor and third-party inventories for meterex.com and for "Karl Kuntze" / "Karl Kuntze (GmbH & Co.)" / HRA 16336. If the entity is a supplier, sub-processor, or service provider to your organisation, escalate to the vendor-risk owner today.
• If a relationship exists, request written confirmation from the vendor on: whether production or customer-facing systems are affected, whether client data was in scope, and what their containment status is. Do not rely on the leak-site entry as the basis for a decision.
• Do not contact or engage the threat actor, and do not attempt to access any leak-site content. Monitor only.

P2 — within 72h

• If the entity is in your supply chain, run a data-flow review: what data of yours is held by or transmissible through that vendor, and under which contract clause is notification owed to you.
• Review the contract's incident-notification, audit-rights and cooperation provisions against DORA Art. 30 expectations if the vendor is an ICT third-party provider supporting an in-scope function.
• If the vendor provides any authentication, payment, or file-transfer function, review your own compensating controls for that dependency (alternate route, manual fallback, transaction verification).

P3 — within 7 days

• Update third-party risk register with the listing, the date, and the unverified status.
• If no relationship exists, close the item as not applicable and retain the record for supply-chain trend tracking.

No vendor patch, version pin, or configuration change can be recommended: the source names no product, version, or component.

5. Indicators of compromise

No indicators of compromise available in the source material.

The only domain in the source, meterex[.]com, is the named victim, not a malicious indicator. It is deliberately excluded from the indicator set and must not be blocked or actioned as an IOC.

No behavioural indicators are available either: the source records no authentication pattern, device registration, process activity, or network activity.

6. Detection

Insufficient indicators to author detection rules.

The source contains no file hashes, file names or paths, registry keys, scheduled-task or service names, mutexes, command-line flags, ransom-note text, or network artefacts. Authoring a rule from the actor name, the victim domain, or the indexer URL would detect reporting about this event, not the threat itself.

7. Sources

• ransomware.live — Victim: meterex.com – safepay — https://www.ransomware.live/id/bWV0ZXJleC5jb21Ac2FmZXBheQ== — published 2026-09-15T19:31:20Z (primary item; single source for all facts in this advisory)

8. Adverse Trace position

This is a low-information leak-site listing and we are treating it as such. No CVSS score, severity, or CISA KEV exploitation state can be assigned — the verified reference data contains no CVE for this item, and we will not manufacture a severity from a victim name. Attribution to "safepay" is unconfirmed: the actor has no MITRE ATT&CK profile in our reference data, and the sole source is an indexer republishing an operator's own claim. Client impact is contingent and, on current evidence, likely nil for most recipients; it becomes material only for clients with a confirmed vendor relationship to Karl Kuntze (GmbH & Co.) / meterex.com, and even then the scope of any data exposure is unverified. We will monitor ransomware.live and other leak-site trackers for corroboration, for any proof-of-data publication, and for any technical reporting on "safepay" tradecraft; if corroborating detail or a confirmed client supply-chain link emerges, we will reissue this advisory with a severity assessment and detection content. Clients with a confirmed relationship to the named entity should contact their Adverse Trace analyst directly.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.