Ransomware .PIZ 2026: Từ Threat Intelligence đến 8 ca thực tế tại TUNGTEK

01 / NHẬN DIỆN

.PIZ là gì và tại sao đáng chú ý?

Trong những hồ sơ TUNGTEK tiếp nhận gần đây, .piz là phần mở rộng được thêm vào tên các tệp bị ransomware tác động, thường có dạng filename.ext.piz. Sự cố không chỉ dừng ở máy tính cá nhân mà liên quan tới Windows Server, File Server, cơ sở dữ liệu SQL/ERP, bản sao lưu và dữ liệu phục vụ trực tiếp hoạt động doanh nghiệp.

Trong nguồn CTI công khai năm 2026, 360 Security theo dõi từ khóa piz dưới họ Pizhon. Đây là điểm tham chiếu để nghiên cứu, không phải bằng chứng rằng mọi tệp có cùng đuôi đều do một mẫu mã độc hay một nhóm tấn công tạo ra. [1]

Fingerprint mà TUNGTEK đang theo dõi

Phải đọc các dấu hiệu cùng nhau. Extension, email hoặc mẫu ransom note có thể bị tái sử dụng. Muốn phân loại sâu hơn cần đối chiếu sample, cấu trúc file, hành vi và bằng chứng của chính hệ thống bị ảnh hưởng.

02 / PHẠM VI BẰNG CHỨNG

CTI công khai và dữ liệu thực chiến là hai lớp khác nhau

Threat Intelligence công khai cho biết một family hoặc hành vi đã được các đơn vị nghiên cứu mô tả ra sao. Hồ sơ tiếp nhận thực tế lại cho thấy tác động tới dữ liệu, yêu cầu tiền chuộc và điều kiện phục hồi của từng hệ thống. Hai lớp này bổ sung cho nhau, nhưng không thể thay thế nhau.

Những nhận định về cách attacker định giá, quan hệ giữa các sample hoặc khả năng còn dữ liệu nguyên vẹn được giữ ở mức giả thuyết cần kiểm chứng. Bài không đưa ra tỷ lệ phục hồi chung khi chưa có kết quả trích xuất và nghiệm thu tương ứng.

03 / ATTRIBUTION THẬN TRỌNG

Vì sao dùng tên PIZ-2026 / Pizhon-tracked?

TEKLab sử dụng PIZ-2026 / Pizhon-tracked như một định danh làm việc: “PIZ-2026” mô tả nhóm hồ sơ đang theo dõi; “Pizhon-tracked” ghi nhận cách một nguồn CTI phân loại. Đây không phải tuyên bố rằng mọi sample có cùng source code, cùng nhóm vận hành hoặc cùng cách triển khai mật mã.

Bản nghiên cứu gốc cũng lưu ý những tên gọi không thống nhất trên các trang tổng hợp, gồm “Rainbird” hay cách gán sang STOP/Djvu. TUNGTEK không dùng các nhãn này làm kết luận kỹ thuật nếu chưa có phân tích sample đủ sức chứng minh.

Pizhon năm 2020 không tự động đại diện cho .PIZ năm 2026

Antiy đã mô tả Pizhon từ năm 2020, với phần mở rộng bắt đầu bằng .pizhon, thông báo !!!README!!!.txt bằng tiếng Nga và cơ chế phát tán qua email. Đó là bối cảnh lịch sử khác với những dấu hiệu .piz, note tiếng Anh và thông tin liên hệ trong tập hồ sơ hiện tại. [2]

04 / CA THỰC TẾ TUNGTEK

8 ticket .PIZ: từ sự cố đến dữ liệu có thể kiểm tra

Các trường hợp trong tập hồ sơ liên quan tới hệ thống doanh nghiệp, Windows Server / File Server, SQL Database, ERP/FAST, backup và dữ liệu vận hành. Vấn đề cần giải quyết không chỉ là nhận diện malware: doanh nghiệp cần biết phần dữ liệu nào còn có thể dùng được và nên ưu tiên kiểm tra gì để khôi phục hoạt động.

Bài 3 ca thực tế ban đầu là ghi nhận theo mốc 23/09/2026. Bản chuyên sâu này mở rộng quy mô quan sát lên 8 ticket; các kết quả đánh giá riêng trên một mẫu ở bài trước không được chuyển thành tỷ lệ thành công cho toàn bộ tập hồ sơ.

TUNGTEK chỉ công bố dữ liệu tổng hợp cần thiết cho phân tích. Tên khách hàng, Victim ID đầy đủ, đường dẫn nội bộ và nội dung database được giữ ngoài bài viết.

05 / RANSOM DEMAND

Các mức 2k–12k USD nói lên điều gì?

Trong 8 ticket, tiền chuộc không cố định ở một mức duy nhất. TUNGTEK đã ghi nhận các mức 2.000, 3.000, 4.000 và 5.000 USD. Đặc biệt, có một trường hợp cùng một hệ thống gồm 4 máy được đưa ra các mức lần lượt 6.000, 8.000, 10.000 và 12.000 USD.

Điều này gợi ý khả năng attacker định giá theo host, vai trò hệ thống, loại dữ liệu, mức độ quan trọng hoặc khả năng chi trả. Đây mới là giả thuyết vận hành, chưa đủ dữ liệu để khẳng định một quy tắc định giá cố định hay mô hình kinh tế hoàn chỉnh.

Dù là 2.000 hay 12.000 USD, doanh nghiệp vẫn cần trả lời những câu hỏi kỹ thuật: backup còn sạch không, attacker còn quyền truy cập không, phạm vi compromise đến đâu, có dấu hiệu lấy cắp dữ liệu không, tệp bị tác động toàn phần hay một phần, và có lựa chọn recovery độc lập với attacker không?

06 / PHÂN TÍCH TEKLab

Entropy cao là một tín hiệu, chưa phải kết luận

Entropy phản ánh mức độ khó dự đoán trong phân bố byte. Trong các sample .PIZ đã kiểm tra, TEKLab ghi nhận entropy cao tại những vùng dữ liệu bị tác động. Quan sát này phù hợp với dữ liệu đã trải qua biến đổi hoặc mã hóa, nhưng tự nó chưa chứng minh được cơ chế biến đổi.

ZIP, 7z, JPEG, MP4, backup nén hoặc dữ liệu đã được mã hóa hợp lệ cũng có thể có entropy cao. Một giá trị tổng hợp cho cả tệp còn có thể che khuất sự khác nhau giữa vùng nguyên vẹn và vùng bị tác động.

Vì vậy RFC kiểm tra theo vùng và cấu trúc

• Phân tích entropy theo từng block; so sánh đầu, giữa và cuối tệp.
• Đối chiếu file gốc / file bị tác động nếu có cặp mẫu phù hợp.
• Kiểm tra magic bytes, header, footer, kích thước và cấu trúc định dạng.
• Tìm pattern biến đổi, các block còn nguyên và khả năng tái dựng quan hệ dữ liệu.
• Với database, kiểm tra page và tính nhất quán; đối chiếu với khả năng mở, đọc và sử dụng kết quả trích xuất.

07 / TTP & FORENSICS

RDP, database và phần mềm điều khiển từ xa

Báo cáo 360 về tháng 6/2026 liên hệ từ khóa piz với RDP brute force hoặc database brute force; sau khi đăng nhập, attacker cài remote-control software để triển khai mã độc. Nguồn này cũng mô tả encryptor có code tự xóa. [1]

Đây là các hướng cần điều tra, chưa phải đường xâm nhập đã xác nhận của cả 8 ticket TUNGTEK. Phần mềm điều khiển từ xa có thể là công cụ hợp pháp bị lạm dụng sau xâm nhập; việc có một ứng dụng remote trên máy chưa đủ chứng minh nó là nguyên nhân sự cố.

Không còn encryptor vẫn cần tái dựng timeline

Khả năng self-delete có nghĩa việc không tìm thấy file malware sau sự cố không chứng minh nó chưa từng tồn tại. Khi điều kiện chứng cứ cho phép, TEKLab đối chiếu $MFT, $UsnJrnl:$J, Prefetch, Amcache, Shimcache, Windows Event Log, Terminal Services log, Defender/AV history, SRUM, lịch sử ứng dụng remote và timestamp liên quan.

Mục tiêu là kiểm tra các mắt xích initial access, remote control, privilege/execution, encryption và khả năng tự xóa. Mỗi mắt xích cần bằng chứng riêng; một artifact đơn lẻ có thể thiếu, bị ghi đè hoặc mang nhiều cách giải thích.

08 / TÌNH TRẠNG CÔNG CỤ

Chưa xác nhận decryptor công khai đáng tin cậy

Ở mốc biên tập ngày 26/09/2026, TUNGTEK chưa xác nhận được một decryptor công khai, độc lập và đáng tin cậy dành riêng cho PIZ-2026. Đối chiếu danh mục Decryption Tools của No More Ransom tại thời điểm này chưa thấy mục mang tên .PIZ / Pizhon. Đây là phạm vi kiểm tra có thể nêu rõ, không phải bằng chứng tuyệt đối rằng không có công cụ ở bất kỳ đâu. [4]

Cần thận trọng với website quảng cáo “PIZ decryptor” nhưng không công bố phạm vi sample, phân tích mật mã hoặc nguồn khóa có thể kiểm chứng. Không chạy executable không rõ nguồn trên dữ liệu gốc hoặc server vừa bị tấn công. Công cụ có tên giống phần mở rộng cũng chưa chắc tương thích với mẫu đang xử lý.

Việc chưa xác nhận decryptor không tự động kết luận mọi hướng recovery đều bế tắc. Những lựa chọn như backup sạch, bản sao còn lại, vùng chưa bị tác động hoặc tái dựng cấu trúc chỉ có thể được đánh giá sau khi kiểm tra hiện trạng. Với dữ liệu thực sự đã bị mã hóa an toàn và không còn nguồn thay thế, không nên hứa hẹn trích xuất bằng các cách này.

09 / RFC & RANSOMWARE RECOVERY

Bảo toàn dữ liệu trước, đánh giá khả năng trích xuất sau

Một sai lầm sau ransomware là thấy file không mở được rồi format ổ, cài lại Windows, initialize disk, rebuild RAID hoặc restore đè lên volume cũ. Những thao tác đó có thể phá hủy phần dữ liệu hoặc chứng cứ còn khai thác được. Khi điều kiện cho phép, TUNGTEK ưu tiên tạo image/clone byte-to-byte trước thao tác có khả năng thay đổi dữ liệu gốc.

Một tệp .MDF.PIZ, .BAK.PIZ, .VHDX.PIZ hay datastore bị tác động cần được kiểm tra về mức biến đổi, vùng còn nguyên và khả năng tái dựng. Đổi đuôi file hoặc nhìn dung lượng còn đầy đủ không trả lời được các câu hỏi này.

RFC – Ransomware Fast Check kiểm tra gì?

1. Dữ liệu đã bị biến đổi đến đâu? Kiểm tra mẫu đại diện, entropy theo block, cặp mẫu đối chiếu, cấu trúc header/footer và pattern tác động.
2. Còn nguồn dữ liệu nào có thể khai thác? Rà soát block nguyên vẹn, database page, mức fragmentation, bản copy, backup và dữ liệu đã xóa nếu còn điều kiện phục hồi.
3. Có thể tái dựng cấu trúc logic không? Thử nghiệm trên bản sao phù hợp, đánh giá quan hệ giữa các thành phần dữ liệu và ghi rõ giới hạn theo từng loại tệp.
4. Kết quả trích xuất có dùng được không? Kiểm tra nội dung bằng ứng dụng tương ứng và tiêu chí vận hành đã thống nhất; có file xuất ra chưa đồng nghĩa có dữ liệu sử dụng được.

RFC không phải decryptor. Đây là bước đánh giá kỹ thuật giúp doanh nghiệp biết còn những lựa chọn nào trước khi quyết định hướng Ransomware Recovery. Phạm vi, chi phí và điều kiện nghiệm thu được xác định từ kết quả đánh giá, không dựa vào lời hứa tỷ lệ chung.

Khi vừa phát hiện .PIZ

• Cô lập hệ thống khỏi Internet/LAN theo tình huống ứng cứu; cân nhắc bảo toàn chứng cứ dễ mất trước các thao tác nguồn điện.
• Không format, reinstall, initialize disk, rebuild RAID hoặc restore đè lên dữ liệu gốc trước khi đánh giá.
• Bảo toàn ransom note, Victim ID, log, mẫu tệp và timestamp; ghi nhận các ổ, VM và bản sao lưu liên quan.
• Xác định server, NAS, workstation, database, backup và tài khoản đặc quyền trong phạm vi sự cố; kiểm tra RDP, database và ứng dụng remote.
• Ưu tiên dữ liệu cần cho vận hành; khi có thể, thực hiện thử nghiệm recovery trên image/bản sao và kiểm tra độ sạch của backup trước khi khôi phục.

NIST IR 8374 Rev.1 (2026) đặt ransomware trong chu trình Govern – Identify – Protect – Detect – Respond – Recover. Góc nhìn này nhấn mạnh rằng recovery phải đi cùng ứng phó và kiểm soát rủi ro, không dừng ở câu hỏi mua key hay không. [3]

Xem thêm quy trình RFC của CuuDuLieuMaHoa.com và ca NAS bị ransomware .encrypt về bảo toàn hiện trạng và kiểm chứng dữ liệu sau trích xuất.

10 / KẾT LUẬN TEKLab

Quyết định dựa trên mẫu, cấu trúc và dữ liệu dùng được

.PIZ là một nhóm hồ sơ đáng theo dõi trong năm 2026. CTI công khai liên hệ từ khóa này với Pizhon, nhưng attribution và cách triển khai mật mã của các sample đang gặp vẫn cần kiểm chứng. PIZ-2026 / Pizhon-tracked thể hiện đúng mức thận trọng đó.

Ở mốc tổng hợp 25/09/2026, TUNGTEK đã ghi nhận 8 ticket, với các mức ransom demand 2.000–5.000 USD và một hệ thống 4 máy có các mức 6.000 / 8.000 / 10.000 / 12.000 USD. Tập dữ liệu chưa đủ để suy ra quy tắc định giá hay kết quả recovery cho một ca mới.

Entropy cao ở vùng bị tác động là một phần của chuỗi phân tích TEKLab. Giá trị thực tế của RFC nằm ở việc xác định mức biến đổi, nguồn dữ liệu còn lại, khả năng tái dựng và chất lượng sau trích xuất. Kết luận cuối cùng phải gắn với dữ liệu có thể sử dụng, không phải tên ransomware hay số tiền bị đòi chuộc.

Những nội dung cần tiếp tục theo dõi gồm sample/hash, IOC, ransom note, hạ tầng liên quan, TTP, hành vi mật mã, ransom demand và công cụ recovery. Khi có thêm bằng chứng, từng nhận định cần được cập nhật theo đúng phạm vi mà bằng chứng đó hỗ trợ.