~/f4n6 $ grep -r "Ransomware: medusalocker named Aokkef (FR)" ./investigations/ --include="*.md"

Ransomware: medusalocker named Aokkef (FR)

Jeff Davies 23 Sep 2026 6 min read

1. Executive summary

On 2026-09-23 the ransomware.live aggregator indexed a claim by the group calling itself medusalocker naming Aokkef, a French organisation (aokkef.fr), as a victim, with 137 email addresses said to have been extracted. The listing carries no CVE, no malware sample, no ransom note and no technical detail, and the claim is unverified: ransomware.live republishes operator posts and states it does not hold or distribute the underlying data. medusalocker has no MITRE ATT&CK profile, so the name is an operator self-designation and attribution is unconfirmed. Direct risk to EMEA financial services is low unless a client has a contractual or supply-chain relationship with the named victim. The wider signal is that the same group listed at least six European organisations in the same window, which makes this a counterparty and third-party question rather than a technical emergency.

2. Regulatory framing

No specific DORA/NIS2 article is directly engaged by this item. The item is a third-party aggregator listing about a French organisation that is not identified as a financial entity, an ICT third-party provider to a financial entity, or an operator of essential services. Nothing in the source establishes an incident at a client, so no reporting clock starts on the basis of this listing alone.

One conditional point. If a client holds a contractual relationship with Aokkef or aokkef.fr, DORA Art. 28 (ICT third-party risk, general principles) becomes relevant because the trigger is specific: a named supplier appears on a ransomware leak site with a claimed data extraction. That is a supplier-risk review question, not an incident-reporting question, and it only applies to clients with that relationship.

3. Technical analysis & attack chain

There is no attack chain to reconstruct. The source material contains no initial access vector, no exploited component, no CVE, no payload, no persistence mechanism, no command-and-control detail and no lateral movement. What is confirmed is narrow:

  1. On 2026-09-23, ransomware.live published an entry for victim "Aokkef", country FR, website aokkef.fr, attributed to the group medusalocker.
  2. The entry states that 137 email addresses were extracted from the organisation and that the domain is aokkef.fr.
  3. The entry includes a leak screenshot placeholder and DNS records section, but the fetched content does not include the record values or any screenshot content.

No encryption event, ransom demand, negotiation, or data sample is described. The claim of email extraction is the operator's assertion as republished by the aggregator; neither Adverse Trace nor ransomware.live has verified it.

Pattern from the related listings. Six further medusalocker entries were indexed in the same period: Abv (BG, abv.bg, 583 emails), Sgs Gmbh (DE, sgs-gmbh.com, 933 emails), Dolrad (AE, dolrad.ae, 69 emails), Idex Group (DE, idex-group.com, 30 emails), T Online (DE, t-online.de, 823 emails) and Seznam (CZ, seznam.cz, 115 emails). The claimed extraction counts range from 30 to 933 addresses. Four of the seven victims including Aokkef are in the EU, two are in Germany. The consistent element across the set is a claim of bulk email address extraction rather than a described intrusion technique, which is what a defender would need to act on and which none of the listings provide.

Confidence caveat. Every fact above comes from ransomware.live, an aggregator that republishes operator posts. The related entries are the same source family, so they corroborate a posting pattern, not the underlying intrusions. The victim counts, the email counts and the group attribution are single-sourced and unverified. Treat the group name as a label of convenience: medusalocker has no MITRE ATT&CK profile, so no TTP set can be attached to it from the reference data.

4. Mitigation & containment

The absence of technical detail means the actions below are counterparty and credential hygiene measures, not patch instructions. There is no vendor fix to name because no product or vulnerability is identified.

P1 (within 24 hours)

  • Search supplier, vendor and counterparty registers for "Aokkef" and the domain aokkef.fr. If a match exists, open a third-party risk case and request the supplier's own incident statement in writing before relying on the aggregator listing.
  • If any client mailbox, shared drive or application exchanges data with aokkef.fr, review mail flow logs and file-transfer logs for outbound traffic to that domain over the last 30 days.
  • For any account that has authenticated to a service hosted on aokkef.fr, or that uses an aokkef.fr address as a recovery or notification contact, force a credential reset and revoke active sessions and refresh tokens.
  • Check mail audit logs (for example the Microsoft 365 unified audit log, or the equivalent for the client's mail platform) for bulk mailbox export, New-MailboxExportRequest, New-InboxRule, Set-Mailbox forwarding changes, and OAuth application consent grants in the preceding 30 days.

P2 (within 72 hours)

  • Confirm that phishing-resistant MFA is enforced on all remote access, mail and VPN entry points, and that legacy authentication protocols are disabled. The claimed extraction of email addresses is consistent with either a mail-side compromise or a downstream credential-stuffing path; both are reduced by removing password-only authentication.
  • Verify that backups for any system holding client correspondence are immutable or offline, and run one restore test. A leak-site claim with no described encryption is not evidence of encryption capability, but restore capability is the control that determines impact if the claim is followed by an encryption event.
  • Review EDR and mail security alerting for mass address-book or contact enumeration, which is the observable precursor to the kind of extraction claimed here.

P3 (within 7 days)

  • Add the domain aokkef.fr to the supplier watchlist so that any future listing, DNS change or certificate issuance on it raises a review.
  • Where a client has an existing DORA Art. 30 contract with a supplier that appears on a leak site, confirm the contract carries breach-notification and audit clauses that would let the client obtain the supplier's own account of the event.

5. Indicators of compromise

No indicators of compromise available in the source material. The listing contains no hashes, no domains beyond the victim's own website, no IP addresses, no file paths, no registry keys and no ransom-note text. The DNS records section of the source page is present as a heading but the fetched content does not include any record values, so nothing can be reproduced from it.

The source does describe one claimed outcome that has an observable counterpart. It is listed below as a behavioural indicator, inferred from the operator's claim rather than observed by any party to this advisory.

Behavioural indicators

behaviour where to observe confidence
Bulk extraction of email addresses from a mail environment (137 addresses claimed for this victim) Mail platform audit logs: mailbox export requests, inbox rule creation, forwarding configuration changes, OAuth consent grants, and contact or address-book enumeration events Low. Derived from an unverified operator claim republished by ransomware.live; no technical detail, sample or log evidence accompanies it

6. Detection

Insufficient indicators to author detection rules.

7. Sources

  • Ransomware.live, "Ransomware: medusalocker named Aokkef (FR)", https://www.ransomware.live/id/QW9ra2VmQG1lZHVzYWxvY2tlcg==, published 2026-09-23. Primary item.
  • Ransomware.live, "Ransomware: medusalocker named Abv (BG)", https://www.ransomware.live/id/QWJ2QG1lZHVzYWxvY2tlcg==
  • Ransomware.live, "Ransomware: medusalocker named Sgs Gmbh (DE)", https://www.ransomware.live/id/U2dzIEdtYmhAbWVkdXNhbG9ja2Vy
  • Ransomware.live, "Ransomware: medusalocker named Dolrad (AE)", https://www.ransomware.live/id/RG9scmFkQG1lZHVzYWxvY2tlcg==
  • Ransomware.live, "Ransomware: medusalocker named Idex Group (DE)", https://www.ransomware.live/id/SWRleCBHcm91cEBtZWR1c2Fsb2NrZXI=
  • Ransomware.live, "Ransomware: medusalocker named T Online (DE)", https://www.ransomware.live/id/VCBPbmxpbmVAbWVkdXNhbG9ja2Vy
  • Ransomware.live, "Ransomware: medusalocker named Seznam (CZ)", https://www.ransomware.live/id/U2V6bmFtQG1lZHVzYWxvY2tlcg==
  • Ransomware.live, "Victim: Aokkef – medusalocker", https://www.ransomware.live/id/QW9ra2VmQG1lZHVzYWxvY2tlcg==

All sources are the same aggregator. No independent vendor report, victim statement, law-enforcement notice or sample analysis was available for this item.

8. Adverse Trace position

Adverse Trace assesses this item as low direct severity for EMEA financial services clients and moderate as a supply-chain signal. There is no CVSS score to report because no vulnerability is identified, and no CISA KEV entry applies. The attribution to medusalocker is unconfirmed: the group has no MITRE ATT&CK profile, and the only evidence of its activity is a set of self-published leak-site posts republished by a single aggregator, so we do not treat the name as a reliable indicator of a specific toolset or intrusion method. Clients should not act on the listing as a technical alert; they should act on it as a counterparty question, which is why the P1 steps above are register searches and credential resets rather than blocking rules. We will monitor for a victim statement from Aokkef, for any sample or ransom note tied to this group, and for further medusalocker listings against EU financial entities, and we will reissue this advisory with a full technical section if either appears.


Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.

Post this to LinkedIn
Formatting is converted automatically — headings, bullets, a link back & hashtags. Paste straight in.
J
Jeff Davies