Ransomware .PIZ 2026: comparing eight cases recorded by TUNGTEK

01 / Field observations

Eight .PIZ tickets with different ransom demands

.PIZ is a ransomware case worth monitoring in 2026, especially across enterprise systems received by TUNGTEK. As of 25/09/2026, the original dataset records 8 ticket .PIZ, involving servers, file servers, SQL/databases, ERP and operational data.

The differences raise questions about attacker pricing. Server roles, data types and disruption pressure may matter, but there is insufficient data to establish a pricing rule. Ransom demands also do not indicate how much data can be recovered.

02 / Careful identification

Why use PIZ-2026 / Pizhon-tracked?

360's May and June 2026 ransomware reports link the keyword piz to Pizhon. [1, 2] TEKLab uses PIZ-2026 / Pizhon-tracked as a temporary tracking identifier.

Matching extensions do not establish common source code, key mechanisms or encryption algorithms. Compare samples, ransom notes, execution artifacts and behavior before assigning a family or linking an attacker group.

03 / Identification indicators

Read IOCs with context

IOCs support identification and investigation. This table is edited from TUNGTEK/TEKLab records; its value lies in the combination of indicators, not one isolated string.

This publication has no verified malware hashes, control IPs/domains or detection rules ready for release. Do not add speculative indicators to blocklists. See using ransomware IOCs.

04 / TTPs to correlate

RDP, databases and remote-control software

TTPs describe attackers' tactics, techniques and procedures. For piz, 360 describes RDP or database brute force followed by remote-control software installation to deploy malware. [1, 2]

These are investigative hypotheses for individual .PIZ cases, not proven causes for all eight TUNGTEK tickets.

360 also mentions possible encryptor self-deletion. [2] Failure to find an executable after an incident does not exclude malware. Correlate Event Logs, security history, Prefetch, Amcache and file artifacts such as $MFT, $UsnJrnl:$J if still available.

05 / Risks

Impact extends beyond files that will not open

• Operational disruption: unavailable databases or file servers can affect accounting, ERP and dependent services.
• Copies may not be safe: backups on the same system or managed by the same administrator account require separate integrity and restore checks.
• Artifacts may be lost: uncontrolled cleanup, overwrite, reinstall or rebuild can hinder investigation and extraction.
• Unauthorized access may persist: restoring files does not replace identifying compromised accounts, persistence and entry paths.

Possible data exfiltration must also be examined. This published dataset does not confirm exfiltration in all eight cases; do not infer data theft or its absence solely from the extension .piz.

06 / TEKLab observations

High entropy is a signal, not a conclusion

TEKLab observed high entropy in affected data regions of examined .PIZ samples. Entropy describes unpredictability in byte distributions; encrypted data can show this characteristic.

Compressed files, images, video and legitimately encrypted data can also have high entropy. It cannot alone identify a family, prove an algorithm, derive a key or predict a recovery percentage.

07 / Initial response

Preserve before changing systems

1. Isolate affected scope. Disconnect appropriate network connections to limit spread and protect backups. Coordinate response staff to control ongoing encryption and evidence collection.
2. Preserve valuable state. Keep ransom notes, Victim IDs, logs, file lists, timestamps and samples. Do not format, initialize disks, reinstall Windows, rebuild RAID or restore over original volumes before assessment.
3. Inventory all related assets. Review servers, SQL, file shares, workstations, VMs/NAS and backup repositories. Identify data priorities for operations.
4. Create working copies when appropriate. Qualified staff should image/clone devices and record hashes and collection details. Analyze, test tools and extract from copies; protect originals from overwriting.
5. Assess before selecting an approach. Check clean backups, intact structures and extraction prospects through RFC. Do not run unsourced “PIZ decryptors” on servers or originals.

Read more ransomware incident response guidance and selecting and testing decryptors safely.

08 / Recovery perspective

No verified decryptor: individual assessment still matters

At this article's update date, TUNGTEK had not confirmed a public, independent, trustworthy decryptor specifically for PIZ-2026. The directory No More Ransom is a reference to check; the family and supported scope must match the actual sample. [3]

No suitable decryptor does not close every recovery route. Depending on the case, inspect independent backups, older versions, remaining copies or unchanged structures. Correctly encrypted regions protected by strong mechanisms may nevertheless be unrecoverable without the right key.

Validate recovery through files that open, valid logical data and usable applications. Do not promise outcomes from an extension, ransom amount or small sample alone.

09 / Lessons learned

Turn incidents into testable controls

• Control remote access: limit Internet-exposed management/database services; use secure gateways with MFA, appropriate source restrictions and privileges.
• Manage accounts and support tools: separate privileged accounts, review remote-control software and revoke unnecessary access.
• Backups must restore: apply 3-2-1-1-0, with offline or immutable layers, separate administrator permissions and actual restore tests.
• Logs must survive for investigation: centralize logs, define retention and preserve RDP, database and remote-software artifacts.
• Rehearse the first decisions: who isolates machines, preserves evidence, prioritizes data and accepts restored data as usable?

NIST IR 8374 Rev.1 (June 2026) places ransomware risk management across CSF 2.0: Govern, Identify, Protect, Detect, Respond and Recover. [4] For operators, prepare defense and recovery capability before an incident.

10 / Sources & scope

Field observations and references

This version is edited from “Ransomware .PIZ 2026: From Threat Intelligence to Eight Real Cases at TUNGTEK”, updated 25/09/2026. Ticket counts, ransom demands, emails/notes and entropy observations were supplied by TUNGTEK/TEKLab. This is aggregated internal data; customer identities are not published.

1. 360 — May 2026 ransomware report. Reference for Pizhon identification and related TTPs piz.
2. 360 — June 2026 ransomware report. Reference for entry paths and possible encryptor self-deletion.
3. No More Ransom — Decryption Tools. An official tool directory for compatibility checks, not evidence that every variant is supported.
4. NIST IR 8374 Rev.1 — Ransomware Risk Management. Governance, response and recovery under CSF 2.0.

Read the in-depth eight-ticket article on CuuDuLieuMaHoa.com to compare the analytical foundation. The earlier .PIZ profile covers the initial received cases with its own scope and update date.