0‑Day .ICS Attack — chiến dịch spearphish sử dụng file lịch định dạng `.ICS` làm vector để khai thác lỗ hổng **CVE‑2025‑27915**

Tóm tắt sự việc

Vào năm 2025, StrikeReady phát hiện một chiến dịch spearphish sử dụng file lịch định dạng .ICS làm vector để khai thác lỗ hổng CVE‑2025‑27915 trên Zimbra Collaboration Suite. Kẻ tấn công giả mạo người gửi (IP 193.29.58.37) — mạo danh Văn phòng Nghi lễ Hải quân Libya — gửi tệp .ICS chứa JavaScript obfuscated, nhắm vào mục tiêu quân sự ở Brazil. Khi file được hiển thị trong preview pane của webmail Zimbra, script bên trong được thực thi và triển khai một stealer toàn diện chuyên thu thập thông tin từ hộp thư.

---

1. Tại sao đây là trường hợp đặc biệt

• .ICS (iCalendar) là định dạng lịch phổ biến và ít khi bị xét là nguy hiểm so với các định dạng thực thi.
• File .ICS chứa JavaScript là hiếm; StrikeReady đặt ngưỡng phát hiện là file .ICS lớn hơn 10 KB có chứa javascript — đây là một chỉ báo mạnh để bắt đầu phân tích thủ công.
• Khai thác ứng dụng collaboration trực tiếp thông qua đính kèm email (rendering preview) khác biệt với những chiến dịch lừa đảo thông thường — nó tận dụng một lỗ hổng thực thi trong phần render/preview của webmail thay vì chỉ lừa người dùng mở file.

---

2. Từ file đính kèm đến mã chạy: quy trình phân tích

1. Nhận file .ICS nghi vấn: phát hiện qua gateway/mail scanner hoặc bằng mắt nếu file vượt ngưỡng kích thước.
2. Carve & decode: tách phần payload base64 trong nội dung .ICS, decode để lấy chuỗi JavaScript obfuscated.
3. Deobfuscation sơ bộ: dùng công cụ (ví dụ Obfuscator.io Deobfuscator) để phục hồi một phần cấu trúc và tên hàm; sau đó manual rename để dễ đọc.

4. Local test harness: tạo một file HTML đơn giản chèn script vào <script> header để chạy trong trình duyệt và debug bằng DevTools (sources, breakpoints) — cách này giúp quan sát luồng thực thi và network calls mà không cần môi trường Zimbra thực.

---

3. Kiến trúc payload — async IIFE pattern

Payload không phải là một khối mã tuyến tính duy nhất — tác giả chia thành nhiều Immediately Invoked Function Expressions (IIFE) chạy bất đồng bộ. Thiết kế này mang lại lợi ích:

• Tính module: mỗi IIFE đảm nhiệm một capability riêng (credential capture, email harvesting, rule creation, …).
• Evasion: nhỏ hóa bề mặt phân tích; một số module chỉ chạy khi điều kiện nhất định thỏa.
• Scheduling: các tác vụ có thể được định thời (delay, periodic) để tránh tạo ra nhiều sự kiện đột biến trong logs.

---

4. Phân tích từng module (IIFE) — hành vi chi tiết

Dưới đây là mô tả chức năng các IIFE chính dựa trên phân tích của StrikeReady.

A. Credential Theft & Activity Monitoring

Chức năng chính: thu thập username/password và quan sát tương tác người dùng.

• Tạo trường ẩn (hidden inputs): chèn hidden input vào login form để capture dữ liệu khi người dùng submit. Những field này vô hình với người dùng nhưng được serialize cùng form.
• Hook submit / override XHR: gắn listener submit hoặc override XMLHttpRequest.prototype.send để chụp payload trước khi browser gửi đi.
• Giám sát hoạt động: theo dõi mouse/keyboard activity; nếu người dùng không tương tác trong một khoảng thời gian, module sẽ kích hoạt chế độ exfil và force logout nhằm tránh nghi ngờ trực tiếp.
• Persist flag: lưu flag trong localStorage/sessionStorage để kiểm soát tần suất thu thập (kết hợp với logic 3-day).

B. Email Harvesting (Search & Fetch)

Chức năng chính: tìm và gửi nội dung email từ các thư mục.

• Sử dụng API nội bộ (SOAP/REST): gọi helper functions để gửi request tới endpoint Zimbra (ví dụ SOAP Search, GetMsg, GetFolder) thay vì chỉ dựa vào DOM scraping — điều này cho phép thu thập sâu hơn và có cấu trúc.
• Chunking & rate control: nội dung lớn được cắt nhỏ, mã hóa (base64) và gửi theo nhiều POST, có backoff và jitter để tránh pattern detection.
• Lịch trình: module lập job chạy lặp (khoảng mỗi 4 giờ) để đảm bảo thu thập liên tục mà không quá thường xuyên.

C. Malicious Email Filter / Forward Rule

Chức năng chính: tạo rule lọc/forward nhằm chuyển tiếp email tới attacker-controlled mailbox.

• Tạo rule: tạo rule có tên “Correo” (forward tất cả mail) tới [email protected].
• Cách tạo: có thể thực hiện thông qua API quản lý filter (SOAP CreateFilter) hoặc thao tác DOM trên trang cấu hình rule.
• Mục đích: nhận các bản sao email mới/reply trực tiếp tại tài khoản attacker mà không cần tương tác tiếp từ nạn nhân.

D. Steal Scratch Codes, Trusted Devices, App‑Specific Passwords

Chức năng chính: lấy các artifacts liên quan đến MFA và phương tiện xác thực phụ.

• Target pages: phần cài đặt bảo mật tài khoản, trang MFA, danh sách thiết bị tin cậy.
• Mechanism: scrape nội dung hiển thị hoặc gọi API chứa thông tin này; exfil các mã scratch, danh sách thiết bị, mật khẩu ứng dụng.
• Hậu quả: kẻ tấn công có thể dùng những artifact này để vượt qua MFA, đăng nhập lại hoặc tạo backdoor lâu dài.

E. Contacts, Distribution Lists & Shared Folders

Chức năng chính: thu thập contact book, mailing lists, and shared folders metadata.

• Lý do: xây dựng danh sách mục tiêu phụ/spearphish mới, mở rộng phạm vi tấn công nội bộ và pivot lateral.
• Phương pháp: query thông qua API hoặc lấy từ DOM nếu nội dung được render.

---

5. Evasion & anti‑analysis techniques (chi tiết)

• Execution delay: chờ 60 giây trước khi bắt đầu thực thi nhằm vượt qua sandboxes fai‑fast.
• 3‑day window: kiểm tra thời điểm thực thi — module chỉ chạy nếu đã ≥ 3 ngày kể từ lần trước, giảm frequency và khó correlate logs.
• UI hiding: ẩn các component như InvHeaderTable để giảm bớt dấu hiệu hiển thị khi payload hoạt động.
• Environment fingerprinting: kiểm tra DOM selectors, endpoints, hoặc object signatures để chỉ thực thi trong môi trường Zimbra cụ thể.
• Obfuscation layers: nhiều tầng mã obfuscated (string concat, base64/hex encode, flattened control flow) khiến phân tích bằng công cụ bị hạn chế.

---

6. Exfiltration mechanics — kỹ thuật mạng

• Primary exfil: HTTP POST tới https://ffrk.net/apache2_config_default_51_2_1 với mode: 'no-cors' để tránh lỗi CORS và giảm visibility của response.
• Chunk & assemble: dữ liệu lớn bị cắt thành các mảnh nhỏ, gắn session id, gửi nhiều request để server ghép lại.
• Alternative channels: báo cáo không thấy DNS exfil cụ thể, tuy nhiên các biến thể có thể dùng Image beacons, navigator.sendBeacon, hay thậm chí DNS/ICMP tunneling.
• Header & timing mimicry: sửa đổi user‑agent/referrer và timing để giống request của người dùng hợp lệ.

---

7. Indicators of Compromise (IoC) — trực tiếp từ báo cáo

• Attacker C2: https://ffrk.net/apache2_config_default_51_2_1
• Sender IP: 193.29.58.37
• Email forwarding destination: [email protected]
• Attachment SHA256: ea752b1651ad16bc6bf058c34d6ae795d0b4068c2f48fdd7858f3d4f7c516f37

Lưu ý: IoC khớp vào thời điểm phân tích — attacker có thể thay đổi domain/IP/hashes rất nhanh, vì vậy luôn kết hợp IoC với behavioral detection.

---

8. Hunting & detection — câu truy vấn mẫu và chiến lược SOC

Dưới đây là các bước và mẫu truy vấn (pseudo) để áp dụng trong SIEM, mail gateway và web proxy.

8.1 Mail gateway / attachment scanning

• Rule: tag .ics attachments larger than 10KB.
• Scan: perform base64 carve and search for <script> tokens or long base64 blobs inside calendar bodies.
• Alert: khi .ics từ domain lạ/mạo danh tổ chức chính phủ nhưng IP không khớp.

8.2 Zimbra server / webmail logging

• Detect SOAP calls: alert khi session client thực hiện nhiều Search, GetMsg, GetFolder liên tiếp từ UI session bất thường.
• Filter rule creation: log/generate alert khi có CreateFilter/ModifyFilter action và destination email nằm ngoài tổ chức (e.g., proton.me).

8.3 SIEM query examples

• Splunk pseudo:

index=mail attachment_ext=ics | where attachment_size>10240 | table _time, sender, subject, attachment_hash

• Elastic/Kibana:

http.request.method:POST and url.domain:ffrk.net

• Azure Sentinel (KQL) for rule changes:

AuditLogs
| where OperationName contains "Create" or OperationName contains "Update"
| where TargetResources contains "InboxRules" or TargetResources contains "Filters"
| where tostring(AdditionalFields) contains "[email protected]"

8.4 Endpoint / RUM instrumentation

• Detect overrides: instrument front-end to detect if XMLHttpRequest.prototype.send or fetch has been monkey-patched.
• Mutation observers: log DOM mutations that insert hidden inputs into login forms.

---

9. Forensic response playbook (chi tiết)

1. Giữ nguyên artifacts: chụp file .ics gốc, attachment hash, browser HAR file, server logs, và snapshot mailbox filters.
2. Session & credential containment: revoke active sessions, force password reset, và rotate app‑specific passwords / scratch codes.
3. Rule remediation: dump và xóa các filter/forward rules lạ; đánh dấu mailbox bị compromise.
4. Network hunting: tìm POST request pattern tới ffrk.net hoặc các domain mới, xác định IP/ASN của C2.
5. Scope & notify: enumerate toàn bộ mailbox có cùng rule/traffic patterns, thông báo providers (ví dụ ProtonMail) hoặc bên thứ ba khi cần.
6. Preserve chain of custody: lưu metadata logs và evidence để hỗ trợ phân tích forensics hoặc báo cáo pháp lý.

---

10. Remediation & hardening kỹ thuật (ưu tiên)

1. Patch ngay: vá CVE‑2025‑27915 — ưu tiên cao cho Zimbra servers.
2. Disable/Restrict script execution in preview panes: whitelist rendering hoặc fully sanitize calendar HTML bodies; block inline script.
3. Attachment sandboxing: decode và sandbox .ics attachments; inspect for base64/js tokens.
4. Monitor & alert for rule changes: build automated verification flow (e.g., trigger owner confirmation) khi rule forward được tạo.
5. Implement CSP: cho webmail, tránh inline script execution; X‑Content‑Type‑Options để ngăn MIME sniffing.
6. Network egress filtering: block/monitor outbound traffic to newly seen domains; inspect no-cors POSTs for exfil patterns.
7. User awareness: đào tạo người dùng về .ICS bất thường, không mở file hoặc báo cáo email lạ.

---

11. Những bài học rút ra (operational)

• Mở rộng tầm nhìn: định dạng “vô hại” như .ics, .vcf, .rtf có thể mang payload; mail scanners/EDR phải mở rộng detect beyond executables.
• Behavioral detection > IoC only: IoC hữu ích nhưng dễ thay đổi; kết hợp phát hiện hành vi (unexpected SOAP calls, forward rule creation, outbound POSTs).
• Hunting low frequency events: giữ logs dài hơn để correlate các sự kiện tần suất thấp (>=90 ngày nếu có thể).

---

12. Tài nguyên & chỉ dẫn thêm

• StrikeReady đã cung cấp các file liên quan (deobfuscated JS, sample artifacts) trên GitHub theo bài viết gốc.
• Các vendor khác (Proofpoint, ESET, Palo Alto Unit42) có tài liệu liên quan về preview-pane XSS và kỹ thuật tương tự; tham khảo để bổ sung detection rules.

---

Source link: https://strikeready.com/blog/0day-ics-attack-in-the-wild