Chương 15 — Threat Intelligence & Khung tấn công

Tổng quan

Đọc log mà không có framework thì mỗi cảnh báo là một mảnh rời — thấy IP lạ gọi ra ngoài, nhưng không biết nó khớp giai đoạn nào trong một cuộc tấn công thật, và không nói chuyện được với đội threat intel bằng cùng một thuật ngữ. Chương này gom lại bộ "ngôn ngữ chung" mà dân SOC và threat intel dùng để mô tả, đo và phản ứng với hành vi kẻ tấn công.

Chương đi theo đúng trình tự một cuộc điều tra thật. Trước hết là khung tư duy: Cyber Kill Chain chia tấn công có chủ đích thành 7 giai đoạn tuyến tính — phá vỡ một mắt xích là gãy cả chuỗi; Diamond Model nhìn mỗi vụ xâm nhập qua 4 đỉnh (kẻ tấn công, năng lực, hạ tầng, nạn nhân) và cho phép pivot từ một manh mối nhỏ ra cả một nhóm APT. Kế đó là cách phân loại bằng chứng: IOC (dấu vết tĩnh, dễ đổi) so với IOA (chuỗi hành vi, khó né hơn), và Pyramid of Pain giải thích vì sao chặn một IP thì đối thủ đổi trong 5 phút, còn chặn một TTP thì chúng phải xây lại cả lối đánh.

MITRE ATT&CK là phần chi tiết nhất — knowledge base hành vi thật với định danh riêng cho từng technique (kiểu T1059.001), còn ATT&CK Navigator tô màu ma trận đó để nhìn ra khoảng trống phát hiện. Từ lý thuyết, chương xuống tới việc viết rule thật: Sigma cho log, YARA cho file/memory, Suricata cho traffic mạng — và cách chia sẻ tình báo đó ra ngoài qua STIX/TAXII/MISP. Phần cuối tách bạch các loại malware (virus, worm, trojan, ransomware, rootkit, RAT, botnet, fileless) và hai hướng mổ xẻ mẫu — tĩnh và động — hai khái niệm mình từng gộp chung trước khi phân biệt rõ ràng.

Cần tra nhanh? Bảng 15.15 nối từng giai đoạn tấn công với technique tiêu biểu, nguồn telemetry và rule phát hiện — dùng nó như mục lục thực hành của cả chương.

15.1. Vì sao cần Framework: từ "alert rời rạc" tới "ngôn ngữ chung"

Trước khi có các framework chuẩn hóa, mỗi đội bảo mật mô tả tấn công theo cách riêng: "có người login sai nhiều lần", "có file lạ chạy PowerShell". Vấn đề không phải thiếu dữ liệu mà là thiếu ngôn ngữ chung để:

1. Trao đổi giữa các đội/tổ chức (SOC nội bộ ↔ ISAC ↔ vendor).
2. Đo lường độ phủ phát hiện (detection coverage): ta phát hiện được bao nhiêu phần trăm hành vi mà đối thủ có thể làm?
3. Ưu tiên đầu tư: nên viết rule phát hiện gì trước?
4. Tái lập (reproducibility): cùng một hành vi luôn được gọi bằng cùng một định danh.

Các framework trong chương này giải các bài toán khác nhau nhưng bổ trợ nhau:

Vì sao cần nhiều framework? Kill Chain quá thô để viết detection; ATT&CK quá chi tiết để báo cáo cho lãnh đạo; Diamond Model giúp phân tích quan hệ nhưng không liệt kê kỹ thuật. Một SOC trưởng thành dùng cả ba: Kill Chain để kể chuyện, Diamond để pivot điều tra, ATT&CK để đo coverage và viết rule.

15.2. Cyber Threat Intelligence (CTI): định nghĩa, phân loại, vòng đời

15.2.1. CTI là gì và không là gì

Threat Intelligence = dữ liệu về mối đe dọa đã qua xử lý + phân tích + bối cảnh hóa để hỗ trợ ra quyết định. Điểm mấu chốt phân biệt với "data" thuần:

Data      → "IP 185.220.101.45 xuất hiện trong log"
Information→ "IP này là Tor exit node, kết nối lúc 03:00"
Intelligence→ "IP này được nhóm FIN7 dùng làm C2 trong chiến dịch
              nhắm ngành tài chính tháng 5; khuyến nghị chặn + hunt
              các host đã beacon tới nó"

Intelligence phải actionable (hành động được) và gắn bối cảnh (ai, mục tiêu gì, vì sao).

15.2.2. Bốn loại CTI

Vì sao chia tầng? Vì IOC kỹ thuật mau hỏng (đối thủ đổi IP/hash dễ dàng) còn TTP/strategic bền hơn. Đầu tư phát hiện nên dịch chuyển lên các tầng cao (xem Pyramid of Pain ở 15.6).

15.2.3. Vòng đời tình báo (Intelligence Lifecycle) — 6 pha

Mô hình kinh điển (gốc từ cộng đồng tình báo quân sự/CIA, áp dụng cho CTI):

   ┌────────────────────────────────────────────────────────────┐
   ▼                                                              │
1.Direction → 2.Collection → 3.Processing → 4.Analysis → 5.Dissemination → 6.Feedback
   │                                                                          │
   └──────────────────────────── vòng lặp khép kín ──────────────────────────┘

Admiralty Code (NATO) dùng để gán độ tin cậy hai chiều: độ tin nguồn (A–F) và độ tin thông tin (1–6). Ví dụ "B2" = nguồn thường đáng tin, thông tin có thể đúng.

15.3. Cyber Kill Chain (Lockheed Martin) — 7 bước

Mô hình do Lockheed Martin công bố (2011), mô tả tấn công có chủ đích (APT) như chuỗi tuyến tính. Triết lý phòng thủ: phá vỡ bất kỳ một mắt xích nào thì toàn chuỗi gãy → "intrusion kill chain".

 [1]            [2]             [3]          [4]             [5]            [6]            [7]
Recon ──▶ Weaponization ──▶ Delivery ──▶ Exploitation ──▶ Installation ──▶ C2 ──▶ Actions on Objectives
 dò la      ghép exploit     gửi tới      chạy code        cài đặt        kênh    đánh cắp / phá hoại /
 mục tiêu   + payload        nạn nhân     khai thác        persistence    điều khiển   lan ngang
                                                                            ▲
   ── chặn được BẤT KỲ một mắt xích nào ──▶ toàn chuỗi gãy ─────────────────┘

Sơ đồ cho thấy bản chất tuyến tính của mô hình: tấn công đi tuần tự từ trái sang phải, và phòng thủ chỉ cần làm gãy một bước là vô hiệu cả chiến dịch. Đây cũng là điểm yếu — mô hình giả định một dòng chảy một chiều, khó mô tả lateral movement lặp lại hay tấn công cloud không có khâu "delivery" malware.

Hạn chế: Kill Chain giả định tuyến tính và lấy "malware từ bên ngoài" làm trung tâm; yếu khi mô tả tấn công từ bên trong (insider), lateral movement lặp lại, hoặc tấn công cloud không có "malware delivery". ATT&CK ra đời để bù chỗ này (vòng lặp, phi tuyến, hành vi quan sát được).

Unified Kill Chain (Paul Pols, 2017) hợp nhất Kill Chain + ATT&CK thành 18 giai đoạn theo 3 cụm (In → Through → Out), khắc phục tính tuyến tính. Cần kiểm chứng số giai đoạn theo bản gốc nếu trích dẫn chính xác.

15.4. Diamond Model of Intrusion Analysis

Công bố 2013 (Caltagirone, Pendergast, Betz). Mỗi sự kiện xâm nhập (event) được mô hình hóa bằng 4 đỉnh kim cương, liên kết với nhau:

                 Adversary
                    /\
                   /  \
                  /    \
   Infrastructure ------ Capability
                  \    /
                   \  /
                    \/
                  Victim

Sức mạnh — Pivoting: khi nắm một đỉnh, ta lần ra đỉnh khác. Ví dụ: từ một domain C2 (infrastructure) → tra passive DNS ra IP dùng chung → tìm các domain khác trỏ cùng IP → suy ra capability/adversary khác của cùng nhóm.

Domain evil.com ─(passive DNS)→ 1.2.3.4 ─(reverse)→ bad2.com, bad3.com
       │                                                    │
   (whois)                                              (sandbox)
       ▼                                                    ▼
 email reg X ──────(pivot adversary)─────► cùng campaign

Các meta-feature mở rộng: timestamp, phase (gắn Kill Chain), result, direction, methodology, resources. Social-Political (động cơ adversary↔victim) và Technology (capability↔infrastructure) là hai trục bổ sung.

Diamond bổ trợ ATT&CK: ATT&CK điền vào Capability (TTP cụ thể), còn Diamond đặt nó trong quan hệ điều tra.

15.5. IOC vs IOA

Ví von cho dễ nhớ: IOC giống dấu vân tay tên trộm để lại sau khi đã đột nhập — bằng chứng tĩnh của việc đã xảy ra. IOA giống camera bắt được cảnh ai đó đang cạy cửa sổ — chuỗi hành vi đang diễn ra, can thiệp được trước khi mất đồ.

Ví dụ IOA (chuỗi nhân–quả) mà EDR phát hiện:

1. outlook.exe  → tạo tiến trình winword.exe (mở đính kèm)
2. winword.exe  → spawn cmd.exe /c powershell -enc <base64>
3. powershell   → kết nối ra 185.x (download)
4. powershell   → ghi file vào %APPDATA%\svchost.exe
5. file mới     → tạo registry Run key (persistence)

Không indicator đơn lẻ nào ở trên là "xấu tuyệt đối" — chính chuỗi mới là dấu hiệu tấn công. Đây là khác biệt cốt lõi: IOC = "cái gì đã thấy"; IOA = "đang định làm gì". ATT&CK technique về bản chất là cách chuẩn hóa IOA.

15.6. Pyramid of Pain (David Bianco, 2013)

Hình dung như đuổi một kẻ trộm: đổi khóa cửa thì hắn thử cửa sổ (rẻ, đổi trong vài phút); nhưng nếu ta khiến cả cách hắn đột nhập không còn dùng được thì hắn phải học lại nghề. Pyramid of Pain đo đúng "nỗi đau" đó.

Mô hình đo mức đau mà việc ta chặn một loại indicator gây ra cho đối thủ — tức chi phí họ phải bỏ ra để né tránh.

                    /\
                   /  \                    ← Tough!       (khó nhất cho attacker đổi)
                  / TTP \
                 /------\
                / Tools  \                 ← Challenging
               /----------\
              /  Network/   \              ← Annoying
             / Host Artifacts \
            /------------------\
           /   Domain Names     \          ← Simple
          /----------------------\
         /     IP Addresses       \        ← Easy
        /--------------------------\
       /        Hash Values         \      ← Trivial   (đổi 1 byte → hash mới)
      /------------------------------\

Bài học vận hành: đầu tư detection ở đỉnh tháp (TTP) cho lợi nhuận lâu dài; IOC ở đáy tháp rẻ nhưng chỉ chặn được đúng chiến dịch đã biết. Đây là lý do MITRE ATT&CK (catalog TTP) là trung tâm của detection engineering hiện đại.

15.7. MITRE ATT&CK — kiến trúc và mô hình dữ liệu

ATT&CK = Adversarial Tactics, Techniques, and Common Knowledge. Là knowledge base các hành vi đối thủ quan sát được trong thực tế (curated từ báo cáo công khai). Không phải framework tuyến tính như Kill Chain — nó là ma trận các hành vi.

15.7.1. Phân cấp khái niệm

Tactic  = MỤC TIÊU chiến thuật ("VÌ SAO" — attacker muốn đạt gì)
   └─ Technique = CÁCH chung để đạt mục tiêu ("LÀM GÌ")   → ID  Txxxx
        └─ Sub-technique = biến thể cụ thể ("LÀM NHƯ THẾ NÀO") → ID Txxxx.xxx
              └─ Procedure = hiện thực CỤ THỂ của một nhóm/malware

Cấu trúc ID — phân tích từng phần:

Ví dụ đầy đủ: T1059.001 = Technique 1059 (Command and Scripting Interpreter), sub-technique 001 (PowerShell).

15.7.2. Mô hình quan hệ (ATT&CK STIX data model)

ATT&CK được phát hành dưới dạng STIX 2.1 bundle (JSON) trên GitHub mitre/cti. Các object type chính và ánh xạ:

Trích một attack-pattern (rút gọn, đúng cấu trúc STIX):

{
  "type": "attack-pattern",
  "id": "attack-pattern--0a3ead4e-6d47-4ccb-854c-a6a4f9d96b22",
  "spec_version": "2.1",
  "name": "PowerShell",
  "x_mitre_is_subtechnique": true,
  "kill_chain_phases": [
    { "kill_chain_name": "mitre-attack", "phase_name": "execution" }
  ],
  "external_references": [
    { "source_name": "mitre-attack",
      "external_id": "T1059.001",
      "url": "https://attack.mitre.org/techniques/T1059/001" }
  ],
  "x_mitre_platforms": ["Windows"],
  "x_mitre_data_sources": ["Command: Command Execution",
                           "Process: Process Creation",
                           "Module: Module Load"],
  "x_mitre_detection": "Monitor for execution of powershell.exe with..."
}

Lưu ý quan trọng: technique ID đặt trong external_references (nơi source_name == "mitre-attack"), KHÔNG phải trường id (đó là STIX UUID). Đây là điểm hay nhầm khi viết script parse ATT&CK.

15.7.3. Lấy và truy vấn dữ liệu ATT&CK — ví dụ chạy được

Tải bundle Enterprise và đếm số technique bằng jq:

# Tải STIX bundle Enterprise ATT&CK
curl -sSL -o enterprise-attack.json \
  https://raw.githubusercontent.com/mitre/cti/master/enterprise-attack/enterprise-attack.json

# Đếm số attack-pattern chưa bị deprecated/revoked
jq '[.objects[]
      | select(.type=="attack-pattern")
      | select((.revoked // false)|not)
      | select((.x_mitre_deprecated // false)|not)] | length' \
   enterprise-attack.json

# Liệt kê technique ID + tên cho tactic "credential-access"
jq -r '.objects[]
        | select(.type=="attack-pattern")
        | select(.kill_chain_phases[]?.phase_name=="credential-access")
        | (.external_references[]
            | select(.source_name=="mitre-attack").external_id)
          + "  " + .name' \
   enterprise-attack.json | sort | head

Giải thích tham số: select(.type=="attack-pattern") lọc đúng technique; .kill_chain_phases[]?.phase_name truy cập tactic (dấu ? tránh lỗi khi mảng vắng); .external_references[] | select(.source_name=="mitre-attack").external_id rút technique ID.

Truy vấn ở tầng Python với thư viện chính thức mitreattack-python:

from mitreattack.stix20 import MitreAttackData

mad = MitreAttackData("enterprise-attack.json")

# Lấy technique theo ATT&CK ID
t = mad.get_object_by_attack_id("T1003.001", "attack-pattern")
print(t.name)                       # LSASS Memory

# Nhóm nào dùng technique này?
groups = mad.get_groups_using_technique(t.id)
for g in groups:
    print(g["object"].name)         # vd: APT28, ...

15.7.4. 14 Tactic Enterprise (Reconnaissance → Impact)

Thứ tự cột trong ma trận Enterprise (đây là thứ tự logic, không bắt buộc tuyến tính khi tấn công thật):

Vì sao 2 tactic "Reconnaissance" và "Resource Development" được thêm sau (PRE-ATT&CK gộp vào): ban đầu ATT&CK Enterprise bắt đầu từ Initial Access. Các hoạt động trước xâm nhập (recon, mua hạ tầng) xảy ra ngoài mạng nạn nhân nên khó telemetry, được tách thành PRE-ATT&CK rồi (2020) tích hợp lại làm 2 cột đầu.

15.8. Đào sâu các Technique trọng yếu (cơ chế + dấu hiệu phát hiện)

15.8.1. T1110 — Brute Force (Credential Access)

Là gì: thử nhiều cặp credential cho tới khi đúng. Sub-techniques:

Vì sao password spraying nguy hiểm: chính sách lockout thường khóa sau N lần sai trên một tài khoản. Spray thử Summer2024! lần lượt cho 5000 user → mỗi user chỉ 1 lần sai → không kích hoạt lockout.

Ví dụ thực tế — spray SMB/RDP bằng crackmapexec (dùng trong lab có phép):

# Một mật khẩu, nhiều user, có --continue-on-success để gom hết hit
crackmapexec smb 10.0.0.0/24 -u users.txt -p 'Summer2024!' \
    --continue-on-success

Lưu ý công cụ: crackmapexec (CME) đã ngừng bảo trì từ ~2023; bản kế thừa được cộng đồng phát triển tiếp là NetExec (nxc), cú pháp gần như tương đương (nxc smb 10.0.0.0/24 -u users.txt -p 'Summer2024!' --continue-on-success). Với môi trường mới nên dùng nxc.

Dấu hiệu Blue Team (Windows Security log):

Detection logic (pseudo-SIEM):
  COUNT(distinct TargetUserName) WHERE EventID=4625
  GROUP BY SourceIP, time_bucket(5m) > 20  → cảnh báo password spraying

15.8.2. T1059 — Command and Scripting Interpreter (Execution)

Ví dụ payload PowerShell mã hóa — giải thích từng phần:

powershell.exe -nop -w hidden -enc SQBFAFgAIAAoAE4AZQB3AC0ATwBi...

Lưu ý mã hóa: chuỗi sau -enc là Base64 của text UTF-16 Little Endian, không phải UTF-8. Giải mã đúng:

# Lệnh thực: giải mã encoded command
echo 'SQBFAFgAIAAoAE4AZQB3AC0ATwBi' | base64 -d | iconv -f UTF-16LE -t UTF-8
# → "IEX (New-Ob..."   (Invoke-Expression — tải & chạy từ bộ nhớ)

Dấu hiệu Blue Team: - Script Block Logging (Event ID 4104) ghi lại nội dung script đã giải mã — bật qua GPO Administrative Templates → Windows PowerShell → Turn on PowerShell Script Block Logging. - Process creation (4688 / Sysmon 1) với CommandLine chứa -enc, -e, FromBase64String, IEX, DownloadString. - Parent–child bất thường: winword.exe → powershell.exe (IOA).

15.8.3. T1003 — OS Credential Dumping (Credential Access)

Vì sao LSASS là mục tiêu: Local Security Authority Subsystem Service giữ credential material để hỗ trợ SSO. Mimikatz sekurlsa::logonpasswords mở handle tới lsass.exe, đọc các cấu trúc bộ nhớ và giải mã.

Ví dụ thực tế (lab):

mimikatz # privilege::debug          # bật SeDebugPrivilege
mimikatz # sekurlsa::logonpasswords  # dump credential từ LSASS

Dump bằng công cụ living off the land (LOLBIN — lợi dụng công cụ có sẵn của hệ điều hành) khó bị AV chú ý hơn:

:: Tạo minidump LSASS bằng comsvcs.dll (LOLBIN)
rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump <PID_lsass> C:\temp\l.dmp full

Dấu hiệu Blue Team: - Sysmon Event ID 10 (ProcessAccess) với TargetImage = lsass.exe và GrantedAccess = 0x1010/0x1410/0x143A (quyền đọc bộ nhớ) từ tiến trình không phải hệ thống. - Credential Guard (VBS) cô lập LSASS secrets → vô hiệu mimikatz logonpasswords. - PPL (Protected Process Light) cho LSASS: RunAsPPL=1 ở HKLM\SYSTEM\CurrentControlSet\Control\Lsa.

Sysmon config phát hiện đọc LSASS:

<Sysmon schemaversion="4.90">
  <EventFiltering>
    <RuleGroup name="lsass-access" groupRelation="or">
      <ProcessAccess onmatch="include">
        <TargetImage condition="image">lsass.exe</TargetImage>
      </ProcessAccess>
    </RuleGroup>
  </EventFiltering>
</Sysmon>

15.8.4. T1021 — Remote Services (Lateral Movement)

Logon Type — bảng tra (Windows Event 4624):

Ví dụ thực tế — pass-the-hash qua SMB (impacket):

# Dùng NTLM hash thay vì mật khẩu để thực thi từ xa (T1021.002 + T1550.002)
impacket-psexec -hashes :32ed87bdb5fdc5e9cba88547376818d4 \
    Administrator@10.0.0.5

Dấu hiệu: chuỗi 4624 (Type 3) → tạo service "PSEXESVC" (Event 7045) → tiến trình con cmd.exe trên host đích.

15.8.5. T1041 — Exfiltration Over C2 Channel (Exfiltration)

Là gì: tuồn dữ liệu ra qua chính kênh C2 đang dùng (HTTP/HTTPS/DNS) thay vì mở kênh riêng — để hòa lẫn lưu lượng.

Dấu hiệu Blue Team — phát hiện C2/beacon ở mức gói tin: - Beaconing: kết nối định kỳ đều đặn (vd mỗi 60s ± jitter) tới cùng host. Phát hiện qua phân tích periodicity của NetFlow. - Tỷ lệ upload/download bất thường (bytes_out >> bytes_in cho exfil). - JA3/JA3S fingerprint của TLS client hello khớp Cobalt Strike/Metasploit. - DNS exfil: subdomain dài, entropy cao, nhiều query TXT/NULL.

Beacon pattern (NetFlow nhìn theo thời gian):
  10:00:00  client → C2  220 bytes
  10:01:00  client → C2  240 bytes   ← chu kỳ ~60s
  10:02:01  client → C2  225 bytes
  ...  (độ lệch nhỏ = jitter)  → cảnh báo regular beaconing

15.9. Các Matrix: Enterprise, Mobile, ICS

ATT&CK có nhiều "domain" với tactic/technique riêng phù hợp môi trường:

Cloud (nằm trong Enterprise): ví dụ technique đặc thù cloud: - T1078.004 Valid Accounts: Cloud Accounts - T1098 Account Manipulation (thêm credential/role IAM) - T1530 Data from Cloud Storage (đọc S3 bucket public) - T1526 Cloud Service Discovery

ICS — vì sao tách riêng: trong OT, "Impact" có thể là gây thiệt hại vật lý (đóng/mở van, làm hỏng tua-bin — như Stuxnet/Triton). Tactic Inhibit Response Function mô tả việc vô hiệu hệ thống an toàn (Safety Instrumented System) — không có khái niệm tương đương trong IT. Technique ví dụ: T0816 Device Restart/Shutdown, T0831 Manipulation of Control.

15.10. ATT&CK Navigator: map detection & đo coverage

Navigator là ứng dụng web (chạy được offline) tô màu các ô technique trên ma trận để trực quan hóa: coverage phát hiện, hoạt động của một nhóm APT, gap analysis. Dữ liệu lưu dưới layer file (JSON).

15.10.1. Cấu trúc layer JSON — từng trường

{
  "name": "SOC Detection Coverage Q2",
  "versions": { "attack": "17", "navigator": "5.0.0", "layer": "4.5" },
  "domain": "enterprise-attack",
  "description": "Độ phủ rule SIEM hiện tại",
  "techniques": [
    {
      "techniqueID": "T1059.001",
      "tactic": "execution",
      "score": 100,
      "color": "",
      "comment": "Phủ bởi Sigma rule win_susp_powershell_enc",
      "enabled": true,
      "metadata": [
        { "name": "rule_id", "value": "SIGMA-0421" }
      ]
    },
    {
      "techniqueID": "T1003.001",
      "tactic": "credential-access",
      "score": 50,
      "comment": "Chỉ có rule Sysmon EID10, chưa cover comsvcs"
    }
  ],
  "gradient": {
    "colors": ["#ff6666", "#ffe766", "#8ec843"],
    "minValue": 0, "maxValue": 100
  },
  "legendItems": [],
  "showTacticRowBackground": true,
  "tacticRowBackground": "#dddddd",
  "selectTechniquesAcrossTactics": true
}

Vì sao cần tactic trên từng technique: một technique như T1078 Valid Accounts xuất hiện ở nhiều cột (Initial Access, Persistence, Privilege Escalation, Defense Evasion). Trường tactic chỉ định tô ô nào.

15.10.2. Quy trình đo coverage thực tế

1. Liệt kê toàn bộ detection rule (Sigma/SIEM) hiện có.
2. Gán mỗi rule → một/nhiều technique ID (qua trường tags: attack.txxxx trong Sigma — xem 15.11).
3. Sinh layer JSON (script), score=100 cho technique có rule, 0 cho chưa.
4. Mở Navigator → import layer → nhìn vùng đỏ = detection gap.
5. So với layer của các APT nhắm vào ngành mình (MITRE cung cấp sẵn layer theo group) → kết hợp 2 layer bằng phép toán để ưu tiên.

Script sinh layer từ kho Sigma (rút gọn):

import glob, yaml, json, re

techs = {}
for f in glob.glob("rules/**/*.yml", recursive=True):
    doc = yaml.safe_load(open(f, encoding="utf-8"))
    for tag in (doc.get("tags") or []):
        m = re.fullmatch(r"attack\.(t\d{4}(?:\.\d{3})?)", tag, re.I)
        if m:
            techs[m.group(1).upper()] = techs.get(m.group(1).upper(), 0) + 1

layer = {
  "name": "Sigma coverage", "domain": "enterprise-attack",
  "versions": {"attack": "17", "navigator": "5.0.0", "layer": "4.5"},
  "techniques": [
     {"techniqueID": t, "score": min(100, c*25),
      "comment": f"{c} rule(s)"} for t, c in techs.items()
  ],
  "gradient": {"colors": ["#ff6666","#8ec843"], "minValue":0, "maxValue":100}
}
json.dump(layer, open("coverage.json","w"), indent=2)

Navigator hỗ trợ layer arithmetic: ví dụ tạo layer mới = a - b để tìm technique APT dùng (a) mà ta chưa cover (b).

15.11. Detection Engineering: Sigma, YARA, Suricata gắn ATT&CK

15.11.1. Sigma — rule SIEM-agnostic

Là gì: định dạng YAML mô tả detection trên log một cách trung lập, rồi sigma-cli chuyển sang truy vấn Splunk/Elastic/Sentinel...

[PROD] Cấu trúc rule — từng trường (rule này khớp theo hành vi trên CommandLine, thuộc tầng cao Pyramid of Pain — xem Chương 10 về detection engineering và Chương 8 về telemetry endpoint):

title: PowerShell EncodedCommand Suspicious
id: f7d4c3b2-1a2b-4c3d-9e8f-0a1b2c3d4e5f
status: experimental
description: Phát hiện powershell.exe chạy với tham số -EncodedCommand
references:
  - https://attack.mitre.org/techniques/T1059/001
author: Blue Team
date: 2026/06/19
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\powershell.exe'
    CommandLine|contains:
      - ' -enc '
      - ' -EncodedCommand '
      - ' -e '
  condition: selection
falsepositives:
  - Một số script quản trị hợp lệ dùng -enc
level: high
tags:
  - attack.execution
  - attack.t1059.001

Modifier (|): endswith, contains, startswith, re (regex), all. Vì sao có modifier: log thực tế đường dẫn đầy đủ → cần endswith thay vì so khớp tuyệt đối.

Biên dịch sang backend (lệnh thật):

pip install sigma-cli pysigma-backend-splunk
sigma convert -t splunk -p splunk_windows powershell_enc.yml
# Output (SPL):
# Image="*\\powershell.exe" (CommandLine="* -enc *" OR CommandLine="* -e *" ...)

15.11.2. YARA — pattern matching trên file/bộ nhớ

Là gì: ngôn ngữ rule khớp chuỗi/byte/regex trong file hoặc process memory → phân loại malware (mức "Tools" trên Pyramid of Pain).

[PROD] Cấu trúc rule (khớp chuỗi đặc trưng của công cụ — tầng "Tools", tương đối bền vì buộc đối thủ đổi công cụ):

import "pe"

rule Mimikatz_Strings
{
    meta:
        author      = "BlueTeam"
        description = "Phát hiện chuỗi đặc trưng Mimikatz"
        attack      = "T1003.001"
        reference   = "https://attack.mitre.org/software/S0002/"

    strings:
        $s1 = "sekurlsa::logonpasswords" ascii wide
        $s2 = "privilege::debug"          ascii wide
        $s3 = { 6D 69 6D 69 6B 61 74 7A }      // "mimikatz" hex
        $re = /gentilkiwi|benjamin delpy/ nocase

    condition:
        uint16(0) == 0x5A4D and          // MZ header (PE file)
        pe.number_of_sections > 1 and
        2 of ($s*) and $re
}

Vì sao uint16(0)==0x5A4D: file PE bắt đầu bằng signature "MZ" (0x4D 0x5A) — little-endian đọc 2 byte đầu thành 0x5A4D. Điều kiện này loại sớm file không phải PE → rule nhanh hơn.

Lệnh quét thật:

yara -r -w mimikatz.yar /path/to/scan        # -r đệ quy, -w tắt warning
yara mimikatz.yar --scan-list pids.txt        # quét theo PID (memory)

15.11.3. Suricata — IDS/IPS phát hiện network (C2/exfil)

Là gì: IDS/IPS chữ ký + phân tích giao thức. Rule khớp gói/flow, gắn metadata ATT&CK.

[DEMO] Cấu trúc rule — từng phần (chỉ minh hoạ cơ chế, KHÔNG dùng thẳng production): IOC kiểu chuỗi User-Agent/URI cố định nằm ở đáy Pyramid of Pain — đối thủ đổi User-Agent hoặc URI trong vài phút nên rule này kém bền, dễ né và dễ false positive. Khi triển khai thật, hãy ưu tiên phát hiện theo hành vi/TTP (xem Chương 10) và bổ sung telemetry mạng tương quan với endpoint (xem Chương 8).

alert http $HOME_NET any -> $EXTERNAL_NET any ( \
    msg:"ATT&CK T1071.001 Suspicious User-Agent CobaltStrike default"; \
    flow:established,to_server; \
    http.user_agent; content:"Mozilla/5.0 (compatible; MSIE 9.0"; \
    http.uri; content:"/__utm.gif"; \
    classtype:trojan-activity; \
    metadata: attack_target Client_Endpoint, mitre_technique_id T1071; \
    sid:9000001; rev:1; )

Vì sao dùng sticky buffer (http.user_agent): giới hạn việc tìm content đúng vào trường cần, tránh false positive và tăng tốc (không scan toàn payload).

Chạy thật trên file pcap:

suricata -r capture.pcap -S local.rules -l ./out/
# Kết quả alert ở ./out/fast.log và eve.json (JSON, đầy đủ field)
cat ./out/fast.log
# 06/19/2026-10:00:01  [**] [1:9000001:1] ATT&CK T1071.001 ... [**] ...

15.12. Chia sẻ tình báo: STIX, TAXII, MISP

15.12.1. STIX 2.1 — ngôn ngữ mô tả CTI

STIX (Structured Threat Information eXpression) dùng JSON; mọi thứ là SDO (STIX Domain Object), SRO (Relationship Object), hoặc SCO (Cyber-observable Object).

[DEMO] STIX Indicator (SDO) — từng trường (minh hoạ cấu trúc; bản thân IOC domain đơn lẻ thuộc đáy Pyramid of Pain, mau hỏng — không nên là trụ cột phát hiện):

{
  "type": "indicator",
  "spec_version": "2.1",
  "id": "indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",
  "created": "2026-06-19T08:00:00.000Z",
  "modified": "2026-06-19T08:00:00.000Z",
  "name": "Malicious C2 domain",
  "indicator_types": ["malicious-activity"],
  "pattern": "[domain-name:value = 'update-msft.com']",
  "pattern_type": "stix",
  "valid_from": "2026-06-19T00:00:00Z"
}

STIX Pattern là một mini-ngôn ngữ: [file:hashes.'SHA-256' = 'abc...' AND file:size > 1024]. Toán tử: AND OR FOLLOWEDBY, qualifier WITHIN, REPEATS. Vì sao tách pattern riêng: cho phép biểu diễn điều kiện phức hợp, không chỉ một IOC đơn.

15.12.2. TAXII 2.1 — giao thức vận chuyển STIX

TAXII (Trusted Automated eXchange of Indicator Information) là API HTTPS REST để trao đổi STIX. Mô hình: Server → API Roots → Collections → Objects.

# Phải set Accept đúng media type TAXII 2.1
curl -s -H "Accept: application/taxii+json;version=2.1" \
     -u user:pass \
     "https://taxii.example.org/api1/collections/<id>/objects/?added_after=2026-06-18T00:00:00Z"

Header Accept: application/taxii+json;version=2.1 là bắt buộc — server dùng nó để negotiate phiên bản; thiếu thì trả 406.

15.12.3. MISP — nền tảng chia sẻ thực dụng

MISP dùng mô hình Event → Attribute → Object → Tag/Galaxy.

Trường to_ids quan trọng: true = IOC đủ tin cậy để đẩy thành rule IDS/SIEM; false = chỉ ngữ cảnh, không tự động chặn (tránh false positive).

TLP (Traffic Light Protocol) điều khiển chia sẻ:

Ví dụ thật — tạo event + thêm attribute qua REST API (PyMISP):

from pymisp import PyMISP, MISPEvent, MISPAttribute

misp = PyMISP("https://misp.local", "<AUTH_KEY>", ssl=False)

ev = MISPEvent()
ev.info = "FIN7 phishing campaign June 2026"
ev.distribution = 1          # 1 = This community only
ev.threat_level_id = 2       # 1=High,2=Medium,3=Low,4=Undefined
ev.analysis = 1              # 0=Initial,1=Ongoing,2=Completed
ev.add_tag("tlp:amber")
ev.add_tag('misp-galaxy:mitre-attack-pattern="OS Credential Dumping - T1003"')

ev.add_attribute("domain", "update-msft.com", to_ids=True,
                 category="Network activity")
ev.add_attribute("sha256",
                 "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
                 to_ids=True, category="Payload delivery")

created = misp.add_event(ev, pythonify=True)
print(created.id)

Hoặc thuần HTTP:

curl -s https://misp.local/events/add \
  -H "Authorization: <AUTH_KEY>" \
  -H "Accept: application/json" -H "Content-Type: application/json" \
  -d '{"Event":{"info":"Test","distribution":"0","threat_level_id":"2",
        "analysis":"0",
        "Attribute":[{"type":"ip-dst","value":"185.220.101.45","to_ids":true}]}}'

15.13. Phân loại Malware

Hình dung như bệnh dịch: virus phải bám vào "vật chủ" mới lây (như cảm cúm bám người), worm tự bò sang máy khác không cần ai mở (như dịch lây trong không khí), còn trojan thì giả dạng món quà vô hại để ta tự rước vào nhà. Gọi đúng "bệnh" mới chọn đúng "thuốc".

Vì sao fileless khó phát hiện: không có file để AV quét hash/signature → phải phát hiện ở mức hành vi (IOA): PowerShell tải code vào RAM, WMI event subscription làm persistence, registry chứa payload base64. Đây minh họa trực tiếp Pyramid of Pain — buộc Blue Team lên tầng TTP.

15.14. Phân tích Malware cơ bản

15.14.1. Static Analysis (không chạy mẫu)

Strings — trích chuỗi ASCII/Unicode để tìm dấu vết (URL, IP, lệnh, mutex):

strings -n 8 sample.exe | grep -Ei 'http|\.exe|powershell|HKEY|cmd'
strings -e l sample.exe          # -e l = little-endian 16-bit (Unicode/UTF-16)

-n 8 chỉ lấy chuỗi ≥ 8 ký tự (giảm nhiễu); -e l cần thiết vì Windows hay dùng chuỗi UTF-16LE mà mặc định strings bỏ qua.

PE Header — cấu trúc file thực thi Windows (đào tới byte):

Một file PE bố cục như sau (offset từ đầu file):

Offset 0x00  ┌──────────────────────────────────────────┐
             │ DOS Header (IMAGE_DOS_HEADER, 64 bytes)    │
             │   e_magic  = "MZ" (0x4D5A)                 │  ← 2 bytes, offset 0x00
             │   e_lfanew = offset tới PE header           │  ← 4 bytes, offset 0x3C
0x3C ───────►│                                            │
             ├──────────────────────────────────────────┤
e_lfanew ──► │ PE Signature "PE\0\0" (0x50450000)          │  ← 4 bytes
             ├──────────────────────────────────────────┤
             │ COFF File Header (IMAGE_FILE_HEADER, 20B)  │
             │   Machine          (2B)  0x8664=x64        │
             │   NumberOfSections (2B)                    │
             │   TimeDateStamp    (4B)  epoch compile     │
             │   SizeOfOptionalHeader (2B)                │
             │   Characteristics  (2B)                    │
             ├──────────────────────────────────────────┤
             │ Optional Header (PE32: 224B / PE32+: 240B) │
             │   Magic (2B) 0x10B=PE32, 0x20B=PE32+       │
             │   AddressOfEntryPoint (4B) RVA             │
             │   ImageBase, SectionAlignment, ...         │
             │   Subsystem (2B) 2=GUI, 3=CUI              │
             │   DataDirectory[16] (Import, Export...)    │
             ├──────────────────────────────────────────┤
             │ Section Table (mỗi entry 40 bytes)         │
             │   .text  .data  .rdata  .rsrc              │
             └──────────────────────────────────────────┘

Vì sao đọc PE header có giá trị forensic: - TimeDateStamp lệch vô lý (tương lai/quá khứ xa) → có thể bị giả mạo (anti-forensics). - Section có RawSize ≈ 0 nhưng VirtualSize lớn + entropy cao → dấu hiệu packed (UPX, themida). - Imports nghèo nàn (chỉ LoadLibrary+GetProcAddress) → import resolution động → packed/obfuscated.

# Phân tích PE bằng pefile (Python)
python3 - <<'PY'
import pefile, math
pe = pefile.PE("sample.exe")
print("Machine:", hex(pe.FILE_HEADER.Machine))
print("Compile time:", pe.FILE_HEADER.TimeDateStamp)
print("EntryPoint RVA:", hex(pe.OPTIONAL_HEADER.AddressOfEntryPoint))
for s in pe.sections:
    data = s.get_data()
    ent = 0
    if data:
        from collections import Counter
        for c in Counter(data).values():
            p = c/len(data); ent -= p*math.log2(p)
    print(s.Name.decode(errors='replace').strip('\x00'),
          "vsize=%#x rawsize=%#x entropy=%.2f" %
          (s.Misc_VirtualSize, s.SizeOfRawData, ent))
PY

Entropy > ~7.0 trên một section thực thi gợi ý dữ liệu nén/mã hóa (packed). Đây là heuristic quan trọng trong triage.

Hashing & lookup:

sha256sum sample.exe                # hash để tra VirusTotal/MISP
# Import hash (imphash) – đặc trưng theo bảng import, gom biến thể cùng builder
python3 -c "import pefile;print(pefile.PE('sample.exe').get_imphash())"

imphash (import hash) bền hơn file hash vì các mẫu cùng "builder" thường có cùng thứ tự import → gom được biến thể (mức Tools trên Pyramid of Pain).

15.14.2. Dynamic Analysis (chạy trong sandbox)

Là gì: chạy mẫu trong môi trường cô lập (VM snapshot, không có route ra Internet thật hoặc dùng INetSim giả lập), thu hành vi: tiến trình tạo, file ghi, registry, kết nối mạng, API call.

Setup an toàn — vì sao: - VM không nối mạng sản xuất; snapshot để revert. - INetSim/FakeNet giả lập DNS/HTTP để mẫu "tin" là online → lộ C2 mà không thật sự kết nối ra ngoài. - Tránh sandbox-aware malware: nhiều mẫu kiểm tra VMware, số CPU, sbiedll.dll, sleep dài để né.

Công cụ & lệnh thật:

# 1. Giả lập dịch vụ mạng (Linux phân tích)
inetsim                          # log DNS query, HTTP request mẫu gửi đi

# 2. Theo dõi hệ thống call (Linux ELF)
strace -f -e trace=network,file ./sample 2>strace.log

# 3. Procmon (Windows) — lọc:
#    Operation = Process Create / RegSetValue / WriteFile
#    → xuất CSV để map sang ATT&CK

Đầu ra mẫu (Procmon) → map ATT&CK:

winword.exe → Process Create powershell.exe -enc ...   → T1059.001
powershell  → WriteFile %APPDATA%\Microsoft\svchost.exe → T1105 Ingress Tool Transfer
powershell  → RegSetValue HKCU\...\Run\Updater          → T1547.001 Registry Run Key
svchost.exe → TCP Connect 185.220.101.45:443            → T1071.001 / T1041

Báo cáo Cuckoo/CAPE Sandbox tự động hóa: chạy mẫu, hook API, trả JSON gồm danh sách hành vi + đã tự map sang ATT&CK technique (ttps trong report). CAPE còn dump payload đã giải nén (unpacked) từ bộ nhớ — hữu ích vì static analysis trên mẫu packed vô dụng.

15.15. Tổng hợp: vòng đời tấn công ↔ dấu hiệu phát hiện

Bảng tra cứu nhanh nối giai đoạn → technique → telemetry → detection:

Nguyên tắc detection engineering: 1. Map mọi rule → ATT&CK ID (cho đo coverage trong Navigator). 2. Ưu tiên TTP (đỉnh Pyramid) hơn IOC (đáy). 3. Một technique nên có nhiều rule ở nhiều data source (defense in depth detection) — vd LSASS dump phát hiện cả qua Sysmon 10 lẫn EDR memory scan. 4. Theo dõi false positive qua trường falsepositives của Sigma; rule không tinh chỉnh sẽ bị bỏ qua (alert fatigue). 5. Đóng vòng lặp: dùng feedback từ IR thực tế (Diamond Model pivot) để tạo PIR mới → cập nhật collection (CTI lifecycle).

15.16. Lưu ý bảo mật & vận hành tổng kết

• IOC mau hỏng: tự động hết hạn IOC technical (qua valid_from/TTL trong STIX, hoặc decay model của MISP) để tránh phình danh sách block và FP.
• to_ids phải có người duyệt: đừng auto-block mọi IOC nhận từ feed — một domain hợp lệ bị gắn nhầm có thể gây outage.
• TLP nghiêm ngặt: rò rỉ tình báo tlp:red có thể tiết lộ nguồn/nạn nhân; thực thi TLP ở cả con người và hệ thống chia sẻ.
• ATT&CK không phải checklist tuân thủ: "100% coverage" là ảo tưởng — technique luôn mở rộng và procedure vô hạn; coverage chỉ là công cụ ưu tiên, không phải đích.
• Phân tích malware = hoạt động rủi ro: luôn cô lập mạng, dùng VM throwaway, không phân tích mẫu live trên máy nối mạng sản xuất.
• Threat-informed defense: chọn các nhóm APT thực sự nhắm ngành mình (qua report/ISAC), lấy layer ATT&CK của họ, ưu tiên detection theo đó thay vì cố phủ toàn ma trận.

Tài liệu nên kiểm chứng khi trích dẫn chính xác

• Số tactic/technique và ID cụ thể thay đổi theo từng phiên bản ATT&CK — luôn đối chiếu attack.mitre.org và versions.attack trong layer.
• Số giai đoạn Unified Kill Chain (18) và chi tiết STIX media types nên kiểm lại theo bản đặc tả gốc (OASIS STIX/TAXII 2.1) trước khi dùng trong tài liệu chính thức.

Ghi chú của mình

Khu vực ghi chú cá nhân: những điểm từng hiểu sai, phần còn đang tìm hiểu, hoặc kinh nghiệm rút ra khi thực hành — cập nhật dần.