Viết rule Sigma đầu tiên: từ log Windows thật đến detection không làm SOC ngập alert

Rule detection đầu tiên mình viết bắt đúng thứ mình muốn — và cũng bắt đúng khoảng 400 sự kiện vô hại mỗi ngày. Đây là câu chuyện về khoảng cách giữa "rule chạy được" và "rule đáng để chạy trong production".

Điểm khởi đầu: một kỹ thuật tấn công cụ thể

Mục tiêu: phát hiện PowerShell chạy với encoded command — kỹ thuật phổ biến để né antivirus dựa trên chữ ký, thường thấy trong giai đoạn execution của nhiều loại malware.

powershell.exe -EncodedCommand JABjAGwAaQBlAG4AdAAgAD0AIABOA...

Sysmon Event ID 1 (Process Creation) ghi lại đầy đủ command line này. Rule Sigma đầu tiên, viết trong 10 phút:

title: PowerShell Encoded Command Execution
status: experimental
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\powershell.exe'
    CommandLine|contains: '-EncodedCommand'
  condition: selection
level: high

Deploy lên SIEM, chờ 24 giờ. Kết quả: 412 alert, phần lớn từ các script quản trị hệ thống nội bộ và một tool backup thương mại — cả hai đều dùng -EncodedCommand cho mục đích hoàn toàn hợp lệ (đóng gói script dài, tránh lỗi escape ký tự đặc biệt trong command line).

Vòng tune thứ nhất: loại trừ theo publisher

Nhìn qua 412 alert, phần lớn process cha (ParentImage) là các publisher đã biết: công cụ quản lý hệ thống nội bộ, agent backup. Thêm điều kiện loại trừ:

title: PowerShell Encoded Command Execution
status: experimental
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\powershell.exe'
    CommandLine|contains: '-EncodedCommand'
  filter_known_tools:
    ParentImage|endswith:
      - '\BackupAgent.exe'
      - '\SCCMAgent.exe'
  condition: selection and not filter_known_tools
level: high

Kết quả sau 24 giờ tiếp theo: giảm từ 412 xuống 89 alert. Tốt hơn, nhưng vẫn quá nhiều để analyst xử lý thủ công từng cái.

Vòng tune thứ hai: nhìn vào cái mà attacker thực sự cần

Đây là bước thay đổi cách mình nghĩ về rule này. Thay vì cố loại trừ TỪNG công cụ hợp lệ một (danh sách sẽ không bao giờ hết), mình đặt câu hỏi ngược: encoded command của attacker có gì khác biệt về mặt cấu trúc so với encoded command của một script quản trị bình thường?

Câu trả lời: script quản trị thường gọi thêm các flag khác đi kèm (-ExecutionPolicy, -NoProfile, -File), còn payload của attacker thường chỉ có -EncodedCommand và thêm -WindowStyle Hidden hoặc -NoP (viết tắt) để tránh cửa sổ hiện lên — một combination hiếm khi xuất hiện trong automation hợp lệ vì admin không cần giấu cửa sổ của chính script mình.

title: Suspicious PowerShell Encoded Command with Hidden Window
status: stable
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\powershell.exe'
    CommandLine|contains: '-EncodedCommand'
  suspicious_flags:
    CommandLine|contains:
      - '-WindowStyle Hidden'
      - '-NoP '
      - '-W Hidden'
  filter_known_tools:
    ParentImage|endswith:
      - '\BackupAgent.exe'
      - '\SCCMAgent.exe'
  condition: selection and suspicious_flags and not filter_known_tools
level: high

Sau 48 giờ: 3 alert, cả ba đều là kết quả từ một bài pentest nội bộ đã lên kế hoạch trước (đội red team dùng đúng kỹ thuật này) — nghĩa là rule bắt đúng 100% trường hợp thật xảy ra trong giai đoạn test, và 0 false positive từ hoạt động bình thường.

So sánh ba phiên bản

Checklist trước khi đẩy một rule Sigma lên production

• Đã chạy thử ít nhất 24–48 giờ ở môi trường "chỉ log, không alert" để đo baseline false positive
• Có ít nhất một cách phân biệt hành vi độc với hành vi hợp lệ khác ngoài "công cụ nào chạy nó"
• Danh sách loại trừ (nếu có) được ghi lại vì sao — không loại trừ mù theo cảm giác
• Đã test rule bắt được ít nhất một mô phỏng tấn công thật (qua bài test nội bộ hoặc atomic test) trước khi tin vào nó

Rule đầu tiên dạy mình một điều: viết được rule bắt đúng thứ bạn muốn chỉ là 20% công việc. 80% còn lại là làm cho SOC không ghét cái rule đó.