Truy vết một alert C2 beacon lúc 3 giờ sáng: từ SIEM đến kết luận

3:07 sáng, alert nhảy lên màn hình SOC: "Periodic Outbound Connection — Possible C2 Beaconing". Nguồn: một máy trạm trong VLAN kế toán, đích: một IP ở nước ngoài, chu kỳ gần như đều đặn mỗi 58–62 giây. Trên giấy tờ, đây là mô tả sách giáo khoa của command-and-control beacon.

Vì sao alert này đáng chú ý

Beacon C2 có ba đặc điểm hành vi kinh điển mà rule correlation trong SIEM của tụi mình được viết để bắt:

Chu kỳ đều (periodic) — kết nối lặp lại ở khoảng thời gian gần như cố định, thường có "jitter" nhỏ để né phát hiện.
Payload nhỏ, ổn định — request/response size không đổi nhiều giữa các lần.
Đích ít phổ biến — domain/IP không nằm trong danh sách allowlist hoặc không có traffic từ nguồn khác trong mạng.

Alert lúc 3:07 sáng khớp cả ba tiêu chí. Việc tiếp theo là kiểm chứng, không phải hoảng loạn.

Bước 1: Xác nhận log gốc, không tin alert đơn lẻ

Splunk — kiểm tra pattern kết nối trong 6 giờ qua

index=proxy src_ip=10.42.18.117
| eval minute=strftime(_time, "%H:%M")
| stats count by minute, dest_ip, dest_port
| sort minute

Kết quả xác nhận: đúng là có kết nối lặp lại mỗi ~60 giây, tới cùng một IP, cùng port 443, trong suốt 6 giờ liên tục — không phải nhiễu do một alert lẻ.

Bước 2: Nhìn vào tiến trình nào tạo ra kết nối

Đây là bước quyết định. SIEM chỉ cho biết máy nào, không cho biết process nào đứng sau kết nối. Sysmon Event ID 3 (Network Connection) trả lời câu hỏi đó:

Sysmon Event ID 3 — trích từ máy 10.42.18.117

UtcTime: 2026-07-05 03:04:12
Image: C:\Program Files\VendorSync\vsync-agent.exe
DestinationIp: 185.<redacted>
DestinationPort: 443
Protocol: tcp

vsync-agent.exe — không phải tên process quen mắt, và tên nghe hoàn toàn có thể là một binary độc được đặt tên nguỵ trang. Đây là lúc dễ nhảy tới kết luận sai nhất.

Bước 3: Xác minh danh tính thật của process

Kiểm tra chữ ký số và hash trên máy nạn nhân (qua EDR remote shell)

Get-AuthenticodeSignature "C:\Program Files\VendorSync\vsync-agent.exe" |
  Select-Object Status, SignerCertificate
 
Get-FileHash "C:\Program Files\VendorSync\vsync-agent.exe" -Algorithm SHA256

Kết quả: file có chữ ký số hợp lệ từ một nhà cung cấp phần mềm đồng bộ file mà phòng kế toán dùng để nộp báo cáo lên hệ thống ERP của công ty mẹ ở nước ngoài — đây chính là lý do đích kết nối là một IP nước ngoài với port 443. Hash khớp với bản build công khai trên trang chủ vendor, không có trong bất kỳ threat intel feed nào tụi mình có quyền truy cập (VirusTotal, AbuseIPDB).

Vậy tại sao vẫn giống C2 đến vậy?

Đây là phần thú vị nhất của case này. Phần mềm đồng bộ hợp lệ đôi khi có hành vi giống hệt beacon: kết nối định kỳ để kiểm tra cập nhật/đồng bộ trạng thái, giữ kết nối ngắn, payload nhỏ. Sự khác biệt giữa "beacon C2" và "heartbeat của phần mềm hợp lệ" ở tầng network gần như không tồn tại — nó chỉ lộ ra khi bạn nhìn xuống tầng process và tầng danh tính (signature, publisher, business context).

Tiêu chí	C2 Beacon	Heartbeat hợp lệ (case này)
Chu kỳ kết nối	Đều, có jitter nhỏ	Đều — giống nhau
Kích thước payload	Nhỏ, ổn định	Nhỏ, ổn định — giống nhau
Chữ ký số	Không có / tự ký	Có, hợp lệ, khớp vendor
Ngữ cảnh nghiệp vụ	Không giải thích được	Khớp với việc phòng kế toán dùng ERP
Threat intel	Domain/IP có trong feed	Không xuất hiện trong feed nào

Kết luận và hành động

Đóng case với phân loại false positive, kèm ba việc làm thêm:

Thêm hash + publisher của vsync-agent.exe vào allowlist nội bộ để giảm alert lặp lại.
Note lại trong runbook: "Kết nối định kỳ tới IP nước ngoài từ VLAN kế toán, port 443, process vsync-agent.exe → biết trước là ERP sync, kiểm tra hash trước khi escalate."
Đề xuất thêm rule correlation phụ: chỉ escalate beacon alert lên mức cao nếu process tạo kết nối không có chữ ký số hợp lệ — giảm được một lượng false positive tương tự trong tương lai mà không làm mất khả năng phát hiện C2 thật (vì malware C2 hiếm khi có chữ ký số hợp lệ từ publisher đã biết).

Không phải mọi alert lúc 3 giờ sáng đều là sự cố — nhưng mọi alert đều đáng một quy trình xác minh đầy đủ trước khi kết luận theo hướng nào.