Inside a Zawoo Team Intrusion

Certainity — September 2026

Redaction: hostnames, domains and internal addresses are replaced with <domain>, <HOST>, 10.x.x.x, and the encryptor’s file extension with <EXT>. Details that would identify the victim organisation or its sector have been removed.

TL;DR

• Who: Zawoo Team, active by early August 2026 at the latest. No leak site until 30th August, when 19 victims went up at once — concentrated in the DACH region, ranked top-three trending on ransomlook.io. Almost nothing published on their tradecraft / TTP before this.
• This case: we worked it before the leak site existed, so we caught the group with no public reporting to compare against. Hands on keyboard throughout, with custom PowerShell tooling (G-*.ps1, Cp-*.ps1) we have not seen described anywhere else.
• Initial access: valid VPN credentials for an already-privileged account, no multi-factor authentication (MFA) enforced on that VPN — no exploitation or escalation chain observed. How the credentials themselves were obtained remains unknown; stealer-log exposure is a plausible route in general (11.1% of Zawoo victims show infostealer exposure per ransomware.live/Hudson Rock data) but unconfirmed for this engagement specifically.
• Bottom line: fast and direct rather than sophisticated — typos in console history, a tool downloaded mid-session that duplicated what was already installed, the staging host itself encrypted. Against that, a folder-naming pattern repeats across roughly half the group’s leak site entries, which points to a routine rather than improvisation at the group level. Our case falls outside that pattern, a reminder that one engagement does not establish a group’s habits.
• Full ATT&CK mapping and indicators are at the end of this post.

Zawoo Team encrypted some machines, took the data, and then had nowhere to publish it. We worked their intrusion at a point when the group was effectively invisible: no leak site, no public reporting, no name that meant anything to anyone. They have since surfaced. What we have is one engagement’s worth of evidence about how they actually operate — the tooling they brought, a set of custom PowerShell scripts we have not seen described anywhere else, and what console history preserved of their session.

Zawoo Team was active by early August 2026 at the latest, and quite possibly earlier, and ran without a leak site until 30 August, when they posted their first victims all at once. As of 30 August the site lists 19 victims, concentrated in the DACH region, and ransomlook.io ranks the group among its top three trending. There is still very little published about their tradecraft.

This is a single incident, so it is not a group profile. Where we say something about Zawoo more generally, it comes from their leak site or from public tracking, and we say so.

Initial access

Access came through the organisation’s VPN, using valid credentials for an already-privileged account. MFA was not enforced on that VPN. We saw no exploitation and no escalation chain — the account simply authenticated with the privileges it already had.

Firewall logs were not available (as is unfortunately so often the case - keep those damn logs!), so we could not establish how the credentials themselves were obtained;

There is one signal in the public data on where credentials for this group’s victims may come from: ransomware.live records infostealer exposure for 11.1% of Zawoo victims. That infostealer data is supplied by Hudson Rock under a partnership between the two, so it is one source rather than two. It makes stealer logs a plausible route in general. It says nothing about our case, where the route remains unknown.

Reconnaissance

The operators opened the netlogon scripts in SYSVOL, the .cmd files that mount file shares to drive letters. They read several, then copied one to a new name and edited it.

Netlogon scripts can be read by any authenticated domain user, and in most environments they list every share in one place. If you are working out what is worth taking, that is a useful list to have.

They also ran Everything (voidtools) for file and share discovery, and redirected the output of tree /a /f to a file. We strongly suspect that this output is what they place on their leak site after publishing.

Tooling

The intrusion was hands on keyboard throughout. We recovered the commands from PSReadLine console history (%APPDATA%\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt). It survived because the file is written per user and updated as commands are entered, so the attacker inherited the history of the account they had compromised. Their commands sit directly after the administrator’s own.

Alongside PsExec and RDP, they ran DSInternals against a domain controller and pulled a SAM-adjacent registry export. DSInternals is the more consequential of the two: run against a domain controller, it can extract domain-wide credential material — the same class of access as a DCSync-style NTDS dump — rather than the single host’s local accounts that a SAM export gives you. A successful run there is enough on its own to compromise the domain.

They also used a small set of custom PowerShell scripts:

G- for get, Cp- for copy. We have not found this naming convention in any public reporting.

The scripts did not delete themselves. Each was run and then removed by hand:

.\Cp-fs.ps1
del .\Cp-fs.ps1

For defence evasion they used HRSword, a legitimate commercial endpoint product from the Chinese vendor Huorong, delivered as a self-extracting archive and registering two kernel drivers. HRSword is a widely traded commodity EDR killer and has been documented in GlobeImposter and Phobos intrusions. Where the tool comes from says nothing about who used it here.

Staging

Data was copied into a local staging folder and packed into split 7z archives. We did not observe the collection itself. What points to it is a large volume of writes on that host at that point in the logs, the staging folder, and the cleanup that followed — consistent with bulk collection rather than proof of it.

Partway through the session they downloaded Bandizip rather than using what was already installed. The archive format does not tell you which tool wrote them, since both Bandizip and 7-Zip produce 7z.

Exfiltration

We do not have confirmation that data left the network. As mentioned above firewall logs where not retained long enough.

What we have is a deleted archive fragment recovered from one host, and a matching filename on the group’s leak site. That makes exfiltration highly likely, but we cannot prove it from our own telemetry.

Timeline

From what we could see, collection happened early in the intrusion and encryption came several days later. Our visibility was limited, so the real dwell time may well be longer than the dates we have. The earliest activity we found is not necessarily the earliest activity there was.

The host they had staged from was also encrypted.

Encryption and extortion

We did not recover the encryptor, and we could not establish how it was distributed to the hosts it ran on. A sample is on VirusTotal (dd21e22e…e337e). Encrypted files were renamed to a 16-character hex string with a new extension appended, e.g. a1b2c3d4e5f6a7b8.<EXT>.

The ransom note was How to restore your files.txt, with contact over Session using a victim-specific ID and zawooorestore@onionmail.org as fallback.

The note we recovered is not the note in public reporting. PCrisk documented a Zawooo sample on 12 August 2026 with the address zawooorecover@onionmail.org, a differently capitalised filename, and markedly different rhetoric — that variant presents the group as “a ransomware that prioritizes reputation” and threatens to mail stolen files and mailbox contents to the victim’s customers. Ours makes neither argument. The file renaming scheme matches across both, which is the more durable indicator. Treat the note wording and the contact address as variant-specific, and do not use either to rule a Zawoo case in or out.

Our note, with the victim ID and one sector-identifying line removed:

-- Hello, From Zawoo Team
your ID : [REDACTED]
Your network/system was encrypted.
Encrypted files have new extension.

-- Compromising and sensitive data
We have downloaded compromising and sensitive data from you system/network
If you refuse to communicate with us and we do not come to an agreement, your data will be published.
Data includes:
- Employees personal data, CVs, DL , SSN.
- Complete network map including credentials for local and remote services.
- Financial information including clients data, bills, budgets, annual reports, bank statements.
- [REDACTED — line naming file formats specific to the victim's sector]
- And more...

-- Warning
1) If you modify files - our decrypt software won't able to recover data
2) If you use third party software - you can damage/modify files (see item 1)
3) You need cipher key / our decrypt software to restore you files.
4) The police or authorities will not be able to help you get the cipher key.
   We encourage you to consider your decisions.

-- How to contact us ?
1) Download Session: https://getsession.org/download and Click New Messages,
   Contact with ID : [REDACTED]
2) Send email     : zawooorestore@onionmail.org

Spelling and grammar errors are reproduced as found.

What we took away from it

The work was hands on keyboard and not particularly careful. The console history has typos, a command for software that was not installed, and a pasted line repeated three times. They encrypted the host they had staged from. At the time of the incident the group had no leak site, so they were threatening publication without anywhere to publish.

The leak site as a whole is more organised than the session we reconstructed. Our own case sits outside that layout, which is a useful reminder of how little one engagement tells you about a group’s habits. We would not draw conclusions about their overall capability from it. But they’re new in the game, they might “improve” from there.

Detection

Things worth hunting for, based on what we saw:

• G-*.ps1 and Cp-*.ps1 script names, run and then manually deleted
• BrowsingAudit_<timestamp>.txt
• Everything.exe or bandizip.exe on a server
• HRSword artifacts: sysdiag.sys, hrwfpdrv.sys, usysdiag.exe
• PSEXESVC service installation, Event ID 7045
• DSInternals module load on a domain controller
• Changes to netlogon scripts in SYSVOL, which are auditable and rarely monitored
• PSReadLine console history, before it rolls over

Appendix

Indicators

Variant-specific indicators are marked. Do not treat those as reliable on their own.

# SHA-256
11B262C936FFA8EB83457EFD3261578376D49D6E789C7C026F1FA0B91929E135   sysdiag.sys (HRSword)
dd21e22e2c4fffc5939dc6e42ee42ed497138d17245b59dcf4b0aca9739e337e   Zawoo encryptor (VirusTotal, not recovered by us)

# Email
zawooorestore@onionmail.org
zawooorecover@onionmail.org

ATT&CK mapping

Mapped to what we directly observed in this engagement. Initial access and exfiltration are included because they matter for detection coverage, even though we could not confirm the mechanism in either case.

Sources: CERTAINITY case data · ransomware.live · ransomlook.io · PCrisk · Hudson Rock