Ransomware: rhysida named clicks digital GmbH Information (DE)

1. Executive summary

The rhysida ransomware group listed clicks digital GmbH Information, a Berlin-headquartered online marketing agency with offices in Dresden, Munich and Cologne, on its leak site on 2026-09-30. The listing is a claim of intrusion and data theft; no sample, hash, ransom note, or exfiltration evidence has been published alongside it, and the victim has not confirmed the incident in the source material. The verified reference data carries no MITRE ATT&CK profile for rhysida, so the attribution to that group rests on the leak-site listing alone and is unconfirmed. For EMEA financial services clients the direct exposure is third-party: agencies of this profile hold campaign assets, analytics tags, tracking pixels and client-side scripts that run on bank and insurer web properties, which is a supply-chain path into customer-facing channels rather than a core banking path. There is no CVE, no CVSS score and no CISA KEV entry associated with this item, so the risk is assessed on the third-party and brand-abuse dimensions, not on a patchable vulnerability.

2. Regulatory framing

DORA Art. 17, 18 and 19 are not engaged by this item as written: the source describes a leak-site listing, not a confirmed ICT-related incident at a financial entity, and no client of the agency is named. If a client confirms impact, Art. 17 through 19 become live and the classification and reporting clocks start from the client's own detection, not from this listing.

3. Technical analysis & attack chain

There is no attack chain in the source material. The item is a leak-site listing and nothing more. What follows is what the listing states, separated from what it does not.

Confirmed from the source:

1. The rhysida group posted a victim entry naming clicks digital GmbH Information.
2. The entry records the victim country as DE.
3. The victim is described as an agency with more than 40 employees that manages national and international online projects for companies across a range of industries.
4. The victim is described as based in Berlin, Dresden, Munich and Cologne, and as active in online marketing for more than twelve years.
5. The listing was published on 2026-09-30 at 12:07:42 UTC.

Not present in the source, and therefore not asserted here: initial access vector, exploited component or CVE, malware family or sample, file names, hashes, ransom note text, exfiltration volume, negotiation status, deadline, or any proof-of-data screenshot. The related source page carries a "Leak Screenshot" field label with no image or description content behind it, so no visual proof of stolen data is available to assess. The page also carries a standing disclaimer that ransomware.live indexes only publicly visible operator posts and does not access or host the underlying stolen content.

Attribution caveat. The verified reference data holds no MITRE ATT&CK profile for rhysida. The group name comes from the leak-site listing itself, which is a self-declared label and is trivially spoofable by a copycat or by an affiliate operating under a borrowed brand. Treat "rhysida" here as the name on the listing, not as a confirmed actor identity. This is single-sourced: one leak-site index, no victim statement, no independent vendor corroboration.

Why this matters to a financial services reader even without technical detail. An agency of this description typically holds or has held: content management system credentials for client sites, tag manager and analytics container access, ad platform accounts, DNS or CDN control for campaign subdomains, and the client-side JavaScript that gets injected into marketing pages. Compromise of that layer gives an intruder a route to modify what a bank's or insurer's customers load in their browser, which is a web skimming and brand-abuse path rather than a core banking path. The source does not state that any of these were taken. It states only that the agency was listed.

4. Mitigation & containment

P1, within 24 hours.

• Establish whether your entity has a live contract with clicks digital GmbH Information. If yes, treat the supplier as potentially compromised until the supplier states otherwise in writing. Do not wait for the supplier to volunteer a statement; the listing is public.
• Inventory every asset the agency can reach or change on your estate: CMS accounts, tag manager and analytics containers, ad accounts, DNS records, CDN configurations, and any third-party JavaScript loaded by customer-facing pages. This is the list that determines your exposure, and it is not derivable from the leak-site listing.
• Freeze changes from the supplier side. Suspend the agency's write access to tag managers, CMS, DNS and CDN until the supplier's status is confirmed. Read access can stay if you need it for continuity.
• If the agency injects scripts into customer-facing pages, capture the current served JavaScript for those pages and compare against your last known-good copy. A hash comparison of the served bundle against a stored baseline is the fastest check available and needs no vendor cooperation.
• Preserve evidence before remediation: web server access logs, CDN logs, tag manager change history, and CMS audit logs covering the period before the listing date.

P2, within 72 hours.

• Review tag manager and CMS change history for the preceding 90 days for modifications you did not authorise. Prioritise changes to script tags, custom HTML, and anything that loads from a domain you do not recognise.
• Check DNS records for campaign subdomains for unauthorised additions or changed targets.
• If your contract with the agency is an ICT third-party arrangement, run the DORA Art. 28 review: does the contract require the supplier to notify you of an incident within a defined window, does it give you audit rights, and does it cover exit. The source gives no contract terms, so this is a check against your own paperwork.
• Ask the supplier directly, in writing, for: confirmation or denial of the incident, the date of any intrusion, what data categories were affected, and whether your assets were in scope. Record the response and the response time.

P3, within 7 days.

• If the supplier confirms compromise or fails to respond credibly, execute the exit or substitution plan for the affected services. For marketing script injection this is usually a matter of moving the tag container in-house or to an alternate provider, which is a configuration change rather than a re-platforming.
• Add the supplier to your third-party risk register with the listing date and the unresolved status, and set a review date.
• Where the agency holds personal data of your customers, assess whether the incident is notifiable under your own obligations. The source does not establish that personal data was taken, so this is a contingency, not a current requirement.

No vendor fix exists for this item. There is no CVE, no patch, and no version to pin. Any advisory that offers one for a leak-site listing is inventing it.

5. Indicators of compromise

No indicators of compromise available in the source material.

The source provides no hashes, domains, IP addresses, file paths, registry keys, email addresses, or ransom-note text. The only atomic value present is the leak-site listing URL itself, which is a pointer to the operator's post and not an indicator of the intrusion.

Behavioural indicators. The source describes no authentication patterns, device registrations, process activity, or network activity. There is no behavioural material to tabulate. The one observable that a client can act on is the supplier relationship itself: a public leak-site listing naming a contracted supplier, which is a trigger for the P1 checks in §4 rather than a detection signature.

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 names or paths, registry keys, ransom-note text, or hard-coded values. The only strings present are the victim's name, the group name, the country code, and the listing URL. A rule built from those would detect reporting about the incident, not the incident. No YARA or Sigma rule is emitted.

If the supplier confirms an intrusion and shares artefacts, detection content can be authored against them. Until then, the detection task for this item is monitoring the supplier relationship, not the endpoint.

7. Sources

• ransomware.live, "Ransomware: rhysida named clicks digital GmbH Information (DE)", https://www.ransomware.live/id/Y2xpY2tzIGRpZ2l0YWwgR21iSCBJbmZvcm1hdGlvbkByaHlzaWRh, published 2026-09-30.
• ransomware.live, "Victim: clicks digital GmbH Information – rhysida", https://www.ransomware.live/id/Y2xpY2tzIGRpZ2l0YWwgR21iSCBJbmZvcm1hdGlvbkByaHlzaWRh, retrieved 2026-09-30.

Both sources are the same leak-site index page. There is no independent corroboration of the listing, the victim's identity as stated, or the attribution to rhysida.

8. Adverse Trace position

We assess this as a low-severity item for most EMEA financial services clients and a moderate one for any client that has clicks digital GmbH Information in its marketing supply chain. The severity is not driven by a vulnerability: there is no CVE, no CVSS score and no CISA KEV entry here, and the verified reference data holds no MITRE ATT&CK profile for rhysida, so the attribution is unconfirmed and we do not treat it as established. The exposure that matters is the supplier relationship and what that supplier can change on customer-facing web properties. The listing is single-sourced to one leak-site index with no victim statement and no independent vendor corroboration; verify before acting on the attribution, and act on the supplier relationship regardless. Adverse Trace will monitor for a victim statement, for any proof-of-data release, and for independent vendor reporting that names the intrusion vector, and will reissue this advisory if the supplier confirms compromise or if a client of the agency is identified. Clients that hold a contract with this supplier should complete the P1 checks in §4 today and report back so we can scope the exposure across the client base.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.