Skip to main content

Hit by ransomware? Isolate affected systems now. Do not reboot or reformat.

SheMo Noransom舍末无勒

Ransomware family

AuditTeam Ransomware Decryption & Data Recovery

  • Active
  • Medium
  • No public decryptor

AuditTeam is an emerging data-extortion crew active since February 2026 that dresses its demands in audit-and-remediation language and pressures victims through a Tor leak site. No encryptor sample is public, so response centres on exposure assessment, credential rotation and breach notification.

First seen
2026-02
File extensions
No public information
Ransom notes
[rand].README.txt
Affected platforms
Windows

Public information on this family is limited. What follows is compiled from the small amount of verified material available, so please contact us for a sample assessment before you act on it.

Family profile

File extensions
No public information
Ransom notes
  • [rand].README.txt
Contact patterns
  • Two Tor (.onion) sites: the leak site and negotiation portal named in the note (self-branded DATA EXPOSURE TERMINAL), plus a file-hosting site self-branded SYSTEM ERROR
  • Per-victim Audit ID, 16 hex characters judging by leak-site entry identifiers; the field is redacted in the published note
  • No mailbox, Telegram, TOX or other conventional channel appears in the note
  • A separate "Paid Victim" listing on the leak site is used as additional pressure
Aliases / versions
AUDITTEAM、Audit Team
First seen
2026-02
Status
Active
Operational status
Newly emerged
Threat level
Medium
Affected platforms
  • Windows
Tags
  • Emerging
  • Extortion-only
  • Active
Decryptor
No public decryptor

There is no free public decryptor for AuditTeam. The family is not listed by No More Ransom or by any vendor decryption programme.

One point deserves emphasis: as of 2026-09-11 no AuditTeam encryptor sample, hash or detection rule is publicly available, and the only visible ransom note text ([rand].README.txt) speaks solely of stolen data and imminent disclosure - it never mentions file encryption, keys or a decryption process. The premise behind "an AuditTeam decryptor" may therefore not hold at all.

If files in your estate really are encrypted and a [rand].README.txt is present, do not apply this page's conclusions directly. It is more likely that a separate encrypting family sits on the same intrusion chain, or that the crew has deployed a locker that has not yet been published. Re-identify the family from real encrypted samples and the original note before assessing any recovery path.

Latest activity

  1. A burst of new listings on 8-9 September covering Russia, Ukraine, South Korea, Japan and Germany marked the group's densest posting run to date.

    Sources

  2. Russian metal manufacturer Demidov Steel Group was listed on the leak site; from August the victim mix shifted noticeably from East and Southeast Asia toward Russia.

    Sources

  3. Senegal's Treasury directorate (DGCPT) suffered a wide systems disruption from 10 May, confirmed officially on 11 May with its continuity plan activated; AuditTeam listed the body on 18 May, though authorities never named an attacker.

    Sources

Overview

The earliest visible AuditTeam entry corresponds to an attack dated 21 February 2026; the Tor leak site was picked up by threat-intelligence trackers on 8 April 2026, and postings were still arriving in September 2026 (most recently around 10 September), which puts the crew in an early growth phase.

Read the scale carefully. Trackers list around thirty entries, but five of those are anonymous "Paid Victim + 16-hex identifier" placeholders and roughly six more are masked/unmasked duplicate records of the same victim. That leaves about nineteen identifiable organisations - use that figure rather than the entry count when citing victim numbers.

Its distinguishing feature is packaging. The leak site calls itself "DATA EXPOSURE TERMINAL", victims are indexed by an Audit ID, and the note is written in compliance language - audit log, remediation window, audit and consulting fee - recasting the ransom as a remediation expense, with a separate "Paid Victim" listing used for pressure. The framing targets legal and executive readers rather than IT.

Victim geography is not concentrated. The first cases were in East and Southeast Asia (named entries for South Korea and the Philippines; Thailand, Hong Kong and mainland China appear only as one anonymous "Paid Victim" entry each), after May 2026 Russia clearly dominates at roughly a third of all entries, and the remainder is scattered across Germany, Japan, Ukraine, Turkey, Argentina, Colombia and Senegal, spanning technology, manufacturing, retail, finance and government. The most-watched case is Senegal's Treasury directorate (DGCPT): the incident began on 10 May 2026 and its director general publicly confirmed on 11 May that much of the information systems had been disrupted and the continuity plan activated. AuditTeam listed the body on 18 May, but the authorities never named an attacker, so the link rests on the crew's own claim.

Public information is limited. As of 11 September 2026 no vendor or law-enforcement body has published a technical analysis, no sample or IOC set is available, and leak-site entries are not independently verified.

How to identify it

Ransom note. The filename follows the pattern [rand].README.txt. It opens with a bracketed line reading "AUDIT LOG: SEVERE INFRASTRUCTURE COMPROMISE VERIFIED", is addressed to executive management and legal compliance teams, and offers two options: pay an "audit and consulting fee" through the Tor portal in exchange for data purging plus a vulnerability report, or have the archive released to clients, partners and regulators.

Audit ID. The note carries only an Audit ID and an .onion address - no mailbox, Telegram or TOX handle. The ID is redacted in the published note sample; the 16-hex-character shape is inferred from leak-site entry identifiers.

File extension. None has been publicly confirmed. Material about a .AUDIT extension refers to a 2018 Crysis/Dharma variant, unrelated to this group.

External signals. Leak-site entries carry a directory tree or screenshots as proof; most organisations learn of the incident from that posting, and only then find the intrusion traces.

Infection vectors

No technical analysis of AuditTeam's intrusion chain has been published, so treat the following as indicators rather than established facts:

  • Compromised credentials. Tracker statistics show matching infostealer credentials for every victim that has a domain on record - a correlation over a small base, not evidence that those credentials were the entry point, though it is consistent with buying access or signing in with stolen accounts.
  • Access surface. VPN, RDP, mail and file-transfer systems are the usual entry points.
  • Exfiltration first. The objective is packaging up file servers, OA/ERP, mail and finance archives rather than causing an outage.

So there may be no "files will not open" moment. What surfaces first is anomalous bulk outbound traffic, logins from unfamiliar geographies, or a credential leak on a supplier's side.

Encryption behavior

No encryptor observed. There is no public AuditTeam encryptor sample, algorithm description or file extension, and the note never mentions encryption or keys. On the available evidence this is closer to data-theft extortion than to a file-encrypting ransomware family.

Do not gauge severity by encryption artefacts. No renamed files and no shadow-copy alerts does not make the event minor - once data has left the network the loss has occurred and cannot be undone, unlike encryption incidents where restoring service largely ends the matter.

Keep the other possibility open. Emerging crews frequently add a locker later. If files are encrypted as well, treat it as a possible multi-family incident and identify that family independently from real samples.

Assess before you act

Recoverability assessment

With AuditTeam the work is not decryption - it is establishing the scope, impact and obligations created by a data breach. We do not pay ransoms and do not negotiate; we verify, assess and investigate.

1) Verify the claim. Compare the published directory trees and screenshots against real assets, naming conventions and timestamps, and judge whether the data came out of internal systems or was assembled from historical leaks, a supplier or public sources.

2) Assess exposure. Reconstruct the exfiltrated dataset from outbound traffic, cloud-storage and mail-egress logs, file-server access auditing and archiving artefacts, tagging each item for personal data, trade secrets, contracts and financial records, source code and credentials.

3) Notification obligations. Assess reporting duties, deadlines and wording under China's Cybersecurity Law, Data Security Law and PIPL plus sector regulator requirements, and regimes such as GDPR where cross-border operations are involved.

4) Rotate credentials and access paths. Work on an all-not-named basis: domain and service accounts, API keys and tokens, VPN and mail sessions, supplier accounts and remote maintenance channels all reset, sessions revoked.

5) If files really are encrypted, assess separately: independent family identification, backups and snapshots, shadow copies and version history, unencrypted copies and log replay, and low-level carving.

Once data has left the network no technique can ensure its deletion, and payment buys only an unverifiable promise.

Our response plan

Hit by AuditTeam ransomware? What to do

  1. Containment and evidence preservation

    Cut suspicious outbound channels without destroying the scene, and preserve memory and disk state - do not rush to rebuild or clean up. The priority is the exfiltration path: perimeter and proxy logs, VPN and mailbox sign-in records, file-server and cloud-storage access auditing, DLP and network-side retention. Preserve the original [rand].README.txt and screenshots of the leak-site entry including the Audit ID; both underpin verification and classification later.

  2. Family identification and claim verification

    Confirm AuditTeam from the note structure, the Audit ID format and the leak-site entry, and at the same time test the claim itself: do the published directory structures, filenames and screenshots match real assets, and was the data taken in this intrusion or assembled from older leaks? If encrypted files are also present, identify that family separately from real samples rather than assuming a single actor.

  3. Exposure and compliance assessment

    Reconstruct the exfiltrated dataset and classify it item by item: personal and sensitive personal data, trade secrets, contracts and financial records, source code and credential material, how many data subjects, and what period it covers. Use that to assess regulator reporting and individual notification duties and deadlines, assess overseas regimes in parallel where cross-border operations are involved, and produce one consistent internal and external position so departments do not contradict each other.

  4. Closure, rotation and any needed recovery

    Close the confirmed intrusion and exfiltration paths, reset domain and service accounts, API keys and tokens on an all-not-named basis, revoke existing sessions, and remove attacker-created accounts, mail forwarding rules and remote tooling. Keep monitoring the affected domains for new exposure in infostealer feeds. Where systems were encrypted or disrupted, run recovery from backups, snapshots and unencrypted copies in parallel, always working on copies with originals kept read-only.

  5. Attribution, hardening and handover

    Reconstruct the full chain: where the credentials leaked (employee endpoints, a supplier, historical dumps), which access surface lacked MFA, and when and how much data left the network. Drive enforced MFA on VPN and mail, egress controls and DLP policy, privileged-account governance and supplier credential hygiene, and set up routine monitoring of infostealer log feeds. Close with an incident report, a record of notifications made and a handover checklist, leaving a complete evidence trail for regulatory enquiries or litigation.

Risk warning

What not to do

  • Do not visit the .onion portal or query the Audit ID yourself - contact starts the negotiation clock and confirms both your identity and your level of urgency to the actor.
  • Do not pay the so-called audit and consulting fee. It buys an unverifiable deletion promise and a worthless vulnerability report; it stops neither resale of the data nor your notification obligations.
  • Do not publish statements such as "no data was leaked" or "fully remediated" before verification. If the leak-site entry is later confirmed, contradictory statements sharply increase regulatory and reputational exposure.
  • Do not reset only the named accounts. Credentials typically come from infostealer logs, and a single compromised endpoint can leak dozens to hundreds of credential pairs, so rotate everything and revoke sessions.
  • Do not skip forensics and exposure assessment because "all files still open". Pure exfiltration incidents produce no visible failure, and by the time data is published the forensic window has usually closed.
  • Do not resume business or reconnect backup media in an uncleaned environment; until the intrusion path is closed, any restoration can be re-exploited.

Emergency response

Data already encrypted? Stop and let an engineer look first

We do not pay ransoms and we do not negotiate with attackers. Engineers run a free assessment first, then propose a recovery plan and a firm quote.

+86 15639272850See contact details

Related scenarios

Related industries

Similar families

FAQ

AuditTeam Frequently asked questions

  • Can files encrypted by AuditTeam be decrypted?

    The premise may not hold. As of 11 September 2026 no AuditTeam encryptor sample or file extension is public, and the note never mentions encryption or keys - the behaviour looks like pure data-theft extortion. If your files really are encrypted and a [rand].README.txt is present, treat it as a possible multi-family incident: keep three to five encrypted files and the original note for independent identification, and classify before discussing recovery. Note also that material about a .AUDIT extension refers to a 2018 Crysis/Dharma variant, not to this group.

  • We were listed on the AuditTeam leak site but nothing is broken - is this still an incident?

    Yes, and it should not be deprioritised. In data-theft extortion the damage sits in the data itself: once personal data, contracts, financial records or source code have left the network, the legal and reputational loss already exists and cannot be offset by restoring systems. The right order is to verify the claim against real assets, then assess the exfiltrated scope and notification duties, and in parallel rotate credentials and close the intrusion path. Systems running normally often means the actor's access is still open.

  • The note promises data deletion and a vulnerability report after payment - is that credible?

    No, and it cannot be verified. Phrases like "audit and consulting fee" and "remediation window" are deliberate packaging designed to recast extortion as a compliance expense and lower the barrier for executives. There is no technical way to confirm that copies were deleted, and data has repeatedly been resold or re-extorted after payment across the industry. The promised vulnerability report is usually a generic paragraph with no operational value. Our position is no payment and no negotiation; resources go into exposure assessment, closing the access path and the compliance response.

  • How do we tell a genuine listing from one recycled out of old leaks?

    Judge on comparable detail. First, do the directory structures and filenames match the real conventions of your internal systems? Second, do timestamps, version numbers and document reference numbers in the screenshots reconcile with actual records? Third, does the data include material that could only come from inside (internal approval flows, unreleased contract versions)? In parallel, review outbound traffic, bulk downloads and anomalous sign-ins for the same period. A mismatch does not automatically mean the claim is fake - more often the data came from a supplier or an employee endpoint infected by an infostealer rather than from your own network.

  • Does AuditTeam target organisations in mainland China?

    The evidence is thin and should not be over-read. The leak site does carry one entry tagged mainland China and one tagged Hong Kong, but both are unnamed "Paid Victim" placeholders with no organisation name and no proof material, which is not enough to establish a real mainland Chinese victim. The crew's named victims were in South Korea and the Philippines early on, and after May 2026 activity shifted toward Russia and elsewhere; there is no evidence of a targeted campaign against mainland China. That said, the entry model - stolen credentials plus an exposed access surface - is just as common domestically, and overseas subsidiaries and cross-border operations are more directly exposed. The defensive priority is not a family signature but enforced MFA on VPN and mail, egress controls, supplier credential hygiene and routine monitoring of infostealer log feeds.

Sources

External links are provided for reference only. The content is published by third parties and does not represent our position.

Updated