Zombie ZIP – Kỹ Thuật Mới Giúp Mã Độc Qua Mặt Hầu Hết Công Cụ Bảo Mật
Vào đầu tháng 3/2026, cộng đồng bảo mật thế giới chấn động trước một phát hiện đáng lo ngại: kẻ tấn công có thể giấu mã độc bên trong một file ZIP bị biến dạng có chủ ý — gọi là Zombie ZIP — và qua đó vô hiệu hóa hoàn toàn hầu hết các công cụ antivirus (AV) lẫn hệ thống phát hiện và phản hồi điểm cuối (EDR) hiện hành. Kỹ thuật này không đòi hỏi mã hóa phức tạp, không cần obfuscation tinh vi — chỉ cần thao túng vài byte trong phần header của file ZIP là đủ để "tàng hình" trước con mắt của 50 trong số 51 engine bảo mật được thử nghiệm trên VirusTotal.
Bối Cảnh: Ai Phát Hiện và Tại Sao Quan Trọng?
Kỹ thuật Zombie ZIP được phát hiện và công bố bởi Chris Aziz, nhà nghiên cứu bảo mật đến từ công ty Bombadil Systems. Sau khi báo cáo đến CERT Coordination Center (CERT/CC), lỗ hổng này được gán định danh chính thức là CVE-2026-0866. Tiếp theo, chuyên gia Didier Stevens từ SANS Internet Storm Center (ISC) đã công bố phân tích kỹ thuật độc lập, xác nhận mức độ nghiêm trọng và cung cấp các công cụ để phát hiện.isc.sans+2
Điều khiến CVE-2026-0866 đặc biệt đáng chú ý không chỉ là tính hiệu quả của nó — mà còn là lịch sử của nó. CERT/CC ghi nhận rằng đây là vấn đề đã tồn tại từ rất lâu, gợi nhớ đến CVE-2004-0935 — một lỗ hổng tương tự trong phần mềm ESET phát hiện từ hơn 20 năm trước. Điều đó đặt ra câu hỏi lớn: liệu cách tiếp cận mà các AV engine tin tưởng header ZIP có phải là một "lỗ hổng thiết kế" đã bị bỏ qua suốt hai thập kỷ?
Cấu Trúc File ZIP: Nền Tảng Kỹ Thuật Cần Hiểu
Để hiểu Zombie ZIP, cần nắm rõ cấu trúc cơ bản của định dạng ZIP:
Một file ZIP bao gồm các thành phần chính:
Local File Header (LFH): Header cục bộ đứng ngay trước từng file được lưu trong archive; chứa metadata quan trọng như tên file, ngày giờ, phương pháp nén (
Compression Method), kích thước dữ liệu nén (compressedSize), kích thước dữ liệu gốc (uncompressedSize), và giá trị kiểm tra CRC-32File Data: Dữ liệu thực tế của từng file (có thể ở dạng thô hoặc đã nén)
Central Directory (CD): Một mục lục tổng hợp nằm ở cuối file ZIP, chứa danh sách tất cả các file trong archive; các công cụ thường đọc Central Directory trước khi đọc LFH
End of Central Directory Record (EOCD): Dấu hiệu kết thúc file ZIP, chứa vị trí của Central Directory
Trường Compression Method là trọng tâm của kỹ thuật Zombie ZIP. Hai giá trị phổ biến nhất là:
0= STORED: Dữ liệu lưu nguyên trạng, không nén8= DEFLATE: Dữ liệu được nén bằng thuật toán DEFLATE
Các công cụ xử lý ZIP, kể cả AV engine, thường tin tưởng vào giá trị này để quyết định cách đọc và giải mã dữ liệu theo sau. Đây chính là điểm khai thác của Zombie ZIP.
Cơ Chế Hoạt Động Chi Tiết
Bước 1: Chuẩn Bị Payload Hợp Lệ
Kẻ tấn công bắt đầu bằng cách tạo một file ZIP thông thường chứa payload mã độc (ví dụ: file thực thi, script PowerShell, DLL độc hại…). Ở trạng thái ban đầu, file ZIP này hoàn toàn hợp lệ và sẽ bị các AV engine phát hiện nếu quét thông thường.
Bước 2: Thao Túng Header — "Giết" File ZIP
Đây là bước cốt lõi tạo nên kỹ thuật Zombie ZIP:
Kẻ tấn công dùng một hex editor hoặc script tùy chỉnh để thay đổi trường Compression Method trong cả Local File Header (LFH) lẫn Central Directory từ 8 (DEFLATE) sang 0 (STORED). Tuy nhiên, dữ liệu thực tế không bị thay đổi — payload vẫn ở dạng DEFLATE compressed như cũ.
Đồng thời, giá trị CRC-32 được cập nhật thành checksum của payload chưa giải nén (tức là checksum của blob dữ liệu nén), thay vì checksum của dữ liệu gốc. Điều này tạo ra một mâu thuẫn nội tại: khi các công cụ ZIP thông thường (7-Zip, WinRAR, unzip…) cố giải nén file, chúng đọc Method=STORED, lấy dữ liệu thô ra nhưng kiểm tra CRC thất bại — báo lỗi "file bị hỏng" hoặc "unsupported method".
Kết quả: về mặt kỹ thuật, đây là một file ZIP không hợp lệ — nhưng payload bên trong hoàn toàn nguyên vẹn và có thể khôi phục.
Bước 3: AV Engine Bị Đánh Lừa
Khi một AV engine hoặc EDR quét file ZIP này, nó đọc header và thấy Method = 0 (STORED). Theo logic thông thường, điều đó có nghĩa là dữ liệu bên trong là byte thô chưa nén. Engine sẽ quét trực tiếp các byte đó bằng cơ sở dữ liệu chữ ký mã độc.
Thế nhưng các byte đó thực ra là dữ liệu DEFLATE đã nén — trông giống như "nhiễu ngẫu nhiên", không khớp với bất kỳ chữ ký nào. Không có chữ ký nào khớp → AV kết luận file sạch.
Bước 4: Thực Thi Payload Bằng Loader Tùy Chỉnh
Kẻ tấn công chuẩn bị sẵn một loader tùy chỉnh — có thể là một script Python, Go, hay một executable nhỏ — được lập trình để:
Đọc file ZIP "Zombie"
Bỏ qua trường
Compression Methodtrong headerTrực tiếp áp dụng thuật toán DEFLATE để giải nén dữ liệu
Ghi file đã giải nén ra bộ nhớ hoặc đĩa và thực thi
Loader không cần dùng thư viện ZIP chuẩn của hệ điều hành — chính điều này cho phép nó "hồi sinh" payload mà hệ thống không hay biết.
Sơ Đồ Tóm Tắt
text
[File ZIP thông thường - AV phát hiện]
↓ Thay đổi Method: 8 → 0, giữ nguyên dữ liệu DEFLATE, chỉnh CRC
[Zombie ZIP - trông như "file hỏng"]
↓ AV đọc Method=0, quét dữ liệu thô = nhiễu DEFLATE → Không tìm thấy chữ ký
[AV: "File sạch ✓"]
↓ Loader tùy chỉnh bỏ qua header, giải nén DEFLATE trực tiếp
[Payload mã độc được khôi phục và thực thi]
Kết Quả Kiểm Tra Thực Tế
Chris Aziz đã tải file Zombie ZIP chứa EICAR test file — một file giả mã độc chuẩn quốc tế dùng để kiểm tra AV — lên VirusTotal. Kết quả:x+1
50/51 engine AV không phát hiện được file
Chỉ duy nhất 1 engine gắn cờ cảnh báo
Tỷ lệ vượt qua: ~98%
Đây là một con số cực kỳ ấn tượng, đặc biệt khi kỹ thuật này không hề dùng đến mã hóa, packing, hay bất kỳ thủ thuật obfuscation phức tạp nào. Chỉ một thao tác đơn giản trên header là đủ để "tàng hình" trước gần như toàn bộ hệ sinh thái bảo mật thương mại hiện tại.
Phân Tích Kỹ Thuật Độc Lập Từ SANS ISC
Chuyên gia Didier Stevens từ SANS Internet Storm Center đã tiến hành phân tích độc lập và xác nhận kỹ thuật hoạt động đúng như mô tả. Ông công bố một loạt công cụ dòng lệnh tùy chỉnh để phát hiện Zombie ZIP: search-for-compression.py
Script này quét nội dung file ZIP, tìm kiếm các blob dữ liệu được nén thực sự (dựa trên đặc điểm entropy cao và magic bytes của DEFLATE) ngay cả khi header khai báo là STORED. Đây là cách tiếp cận heuristic — không tin tưởng header mà phân tích dữ liệu thực tế.
zipdump.py v0.0.35 với tùy chọn -f l
Công cụ này phân tích trực tiếp các record trong file ZIP mà không dùng thư viện ZIP chuẩn của Python. Khi chạy với tùy chọn -f l, nó hiển thị chi tiết từng Local File Header, cho phép phát hiện bất thường khi:
compressedSize ≠ uncompressedSize (trong khi Method = STORED)
Theo chuẩn ZIP, nếu Method = STORED thì compressedSize phải bằng uncompressedSize. Bất kỳ sai lệch nào đều là dấu hiệu của Zombie ZIP.
Tùy Chọn -s forcedecompress
Sau khi phát hiện sự bất thường, chuyên gia có thể dùng tùy chọn này để buộc giải nén bất kể giá trị compressiontype khai báo là gì. Kết quả sẽ tiết lộ nội dung thực sự của payload. Trong thử nghiệm của Didier Stevens, dùng tùy chọn này trên file Zombie ZIP chứa EICAR đã thành công khôi phục file EICAR gốc — xác nhận kỹ thuật hoạt động.
Tại Sao Vấn Đề Này Tồn Tại Lâu Đến Vậy?
Câu hỏi tự nhiên đặt ra là: tại sao một kỹ thuật đơn giản như vậy lại qua mặt được cả ngành bảo mật trong nhiều năm?
Có một số lý giải:
Niềm tin vào chuẩn định dạng: Các nhà phát triển AV engine có xu hướng tin tưởng vào các trường header đúng theo chuẩn ZIP (PKZIP App Note), thay vì thực hiện kiểm tra chéo giữa header và nội dung thực tế
Hiệu năng: Thực sự giải nén toàn bộ mọi file ZIP để quét nội dung tốn tài nguyên hơn nhiều so với chỉ đọc header và quét byte thô. Trong môi trường doanh nghiệp xử lý hàng triệu file mỗi ngày, đây là đánh đổi quan trọng
File "hỏng" thường bị bỏ qua: Khi một archive báo lỗi, nhiều hệ thống bảo mật chọn cách bỏ qua thay vì xử lý sâu hơn — vô tình tạo ra điểm mù
Lịch sử lặp lại: CVE-2004-0935 đã cảnh báo vấn đề này từ năm 2004, nhưng bài học không được áp dụng rộng rãi.
Khả Năng Lợi Dụng Trong Thực Tế
Kỹ thuật Zombie ZIP có thể được tích hợp vào nhiều vector tấn công khác nhau:
Phishing email: Đính kèm file ZIP "Zombie" vào email lừa đảo; email gateway và AV đọc được qua vì không phát hiện mã độc
Malware dropper: Loader tùy chỉnh được nhúng trong một executable vô hại, khi chạy sẽ tải và giải nén Zombie ZIP để thả payload thực sự
Supply chain attack: Nhúng Zombie ZIP vào gói phần mềm hoặc update giả mạo
Bypass sandbox: Nhiều sandbox phân tích tự động cũng có thể bị qua mặt nếu dựa vào cùng logic tin tưởng header ZIP
Web shell delivery: Tải Zombie ZIP lên server thông qua upload form, bypass các bộ lọc file phía servercrowdstrike+1
Chris Aziz đã công bố Proof-of-Concept (PoC) đầy đủ trên GitHub kèm file mẫu, giải thích từng bước, và loader mẫu. Điều này có nghĩa là bất kỳ kẻ tấn công nào cũng có thể tái tạo kỹ thuật này mà không cần kỹ năng đặc biệt cao.
Khuyến Nghị
Không tin tưởng blindly vào header: Luôn xác thực chéo
Compression Methodvới dữ liệu thực tế — nếu Method=STORED nhưngcompressedSize ≠ uncompressedSize, đây là dấu hiệu đỏ cần điều tra sâu hơn.Phát hiện magic bytes nén: Kiểm tra byte đầu của phần data — blob DEFLATE có magic bytes đặc trưng (
0x78 0x9C,0x78 0xDA,0x78 0x01…)Thực hiện "force decompress": Bổ sung logic thử giải nén bằng DEFLATE ngay cả khi header khai báo STORED
Nâng cao heuristic cho archive bị hỏng: Thay vì bỏ qua archive lỗi, nên xem đây là tín hiệu đáng ngờ và phân tích sâu hơn.
Đối Với Quản Trị Viên
Triển khai chính sách "reject malformed archives" tại email gateway và web proxy: từ chối tất cả file ZIP không tuân theo chuẩn thay vì cho qua
Sử dụng công cụ
zipdump.pycủa SANS ISC để kiểm tra định kỳ các file ZIP nhận từ bên ngoài.Theo dõi các bản vá từ nhà cung cấp AV/EDR và cập nhật ngay khi có bản vá liên quan đến CVE-2026-0866.
Xem xét triển khai Content Disarm and Reconstruction (CDR) — công nghệ tái tạo lại file sau khi loại bỏ tất cả thành phần không cần thiết
Đối Với Người Dùng
Không mở file ZIP từ nguồn không rõ ràng, đặc biệt là qua email, tin nhắn, hoặc link tải xuống đáng ngờ
Nếu cố giải nén mà nhận thông báo lỗi "unsupported method", "bad CRC", hoặc "file bị hỏng" — hãy xóa ngay lập tức và không thực thi bất kỳ file nào đi kèm
Báo cáo các file đáng ngờ cho bộ phận IT/bảo mật thay vì tự xử lý
