หน้านี้อธิบายแนวทางการใช้ Indicators of Compromise (IoC) ที่เผยแพร่บน Cloud Thunder เพื่อให้นำไปใช้ได้อย่างปลอดภัยและรับผิดชอบ

ที่มาของ IoC

IoC ทั้งหมดถูกสกัดจาก ตารางในข่าวสาธารณะ ที่เราเผยแพร่ โดยอ้างอิงรายงานของผู้ผลิต ด้านความปลอดภัยและแหล่งข่าวต้นทาง เราจัดกลุ่ม ดีดูปลิเคต และทำ refang ค่าให้พร้อมใช้งาน แต่ ไม่ได้ตรวจสอบยืนยัน (validate) ความเป็นภัยของแต่ละค่าใหม่ด้วยตนเอง

ข้อควรระวังก่อนนำไปใช้

  • ประเมินบริบทก่อนเสมอ — IoC บางรายการอาจเก่า ถูกใช้ซ้ำ หรือเป็นโครงสร้างพื้นฐานที่ใช้ร่วมกัน (เช่น CDN, cloud, URL shortener) การบล็อกโดยไม่ตรวจสอบอาจกระทบบริการที่ถูกต้อง
  • ระวัง false positive — IP/โดเมนที่ใช้ร่วมกันอาจทำให้บล็อกผู้ใช้ที่ไม่เกี่ยวข้อง
  • ตรวจสอบความสดของข้อมูล — ใช้ตัวกรอง “90 วันล่าสุด” และดูคอลัมน์วันที่ประกอบ

แนวทางที่แนะนำ

  1. นำเข้า IoC สู่แพลตฟอร์มที่ควบคุมได้ก่อน เช่น MISP, SIEM, VirusTotal, EDR
  2. ใช้สำหรับ hunting / การตรวจจับ (detection) ก่อนพิจารณาบล็อกแบบอัตโนมัติ
  3. จัดลำดับตามกลุ่ม: รายการที่ติดป้าย “Block ได้” เหมาะกับการบล็อก ส่วน “Hunt เท่านั้น” เหมาะกับการค้นหาเชิงสืบสวน
  4. ทบทวนและถอนรายการ (expire) เป็นระยะ เพื่อลดภาระและ false positive

รูปแบบตาราง IoC ในข่าว

ระบบดึง IoC อัตโนมัติจากตาราง markdown ใต้หัวข้อ ## Indicators of Compromise (IoCs) (หรือ ## IoCs) โดย รวมทุกแถวในตารางเดียว — ห้ามแยกหลายตารางย่อยหรือใส่ใน code block

คอลัมน์ที่ต้องมี (3 คอลัมน์)

คอลัมน์ชื่อที่รองรับ
ประเภทประเภท หรือ type
ตัวบ่งชี้ตัวบ่งชี้ หรือ indicator
คำอธิบายคำอธิบาย, description, รายละเอียด, หมายเหตุ

ตัวอย่าง:

## Indicators of Compromise (IoCs)

| ประเภท | ตัวบ่งชี้ | คำอธิบาย |
|---|---|---|
| Domain | example-c2[.]com | เซิร์ฟเวอร์ C2 หลัก |
| SHA-256 | abc123... | ตัวอย่างมัลแวร์ |
| File Name | malware.dll | ไฟล์ที่ปลอมเป็น service |

ชนิด (ประเภท) ที่ระบบรู้จัก

Block ได้ (export ไป blocklist): Domain, IP Address, URL, Email, MD5, SHA-1, SHA-256

Hunt เท่านั้น: File Name, Registry Key, HTTP Header, HTTP Pattern, Mutex, User-Agent, Suricata Rule, YARA Rule, npm package, npm scope, npm account, Threat actor

Alias ที่ map อัตโนมัติ เช่น ipIP Address, sha256SHA-256, filenameFile Name

สิ่งที่ควรหลีกเลี่ยง

  • หลายตารางย่อยพร้อม header คนละแบบ (แถว header ตารางที่สองจะกลายเป็นข้อมูล)
  • คอลัมน์ไม่ตรง schema เช่น โดเมน | พบครั้งแรก | พบครั้งล่าสุด
  • ตาราง 2 คอลัมน์ (hash + รายละเอียด)
  • IoC ใน code block ``` `` แทนตาราง
  • metadata วันที่ในคอลัมน์แยก — ย้ายไปคอลัมน์ คำอธิบาย

การ tag กลุ่ม Threat Actors ในข่าว

Threat Actors (/actors/) ผูกข่าวและ IoC กับกลุ่มผ่าน tag = slug ใน data/apt-groups.yaml เท่านั้น ถ้าใส่หลาย actor tag ในข่าวเดียว ระบบจะคัดลอกข่าวและ IoC ไปทุกกลุ่ม — ทำให้โปรไฟล์หลายกลุ่มดูเหมือนมี IoC ชุดเดียวกัน

กฎที่แนะนำ

ประเภทtag ในข่าวหมายเหตุ
Actor หลัก (vendor ฟันธง)slug ตัวเดียว (+ apt ถ้าเป็น APT)เช่น cavern-manticore, muddywater
กลุ่มที่แค่อ้าง overlapไม่ tagอธิบายในเนื้อหา; ความสัมพันธ์แสดงในโปรไฟล์
ชื่อแคมเปญtag ธรรมดา (ไม่ใช่ slug ใน registry)เช่น unk-deaddrop — ยังไม่ขึ้น Threat Actors จนกว่าจะลงทะเบียน

ตัวอย่าง: ข่าว Cavern Manticore ใส่แค่ cavern-manticore ไม่ใส่ muddywater/oilrig แม้เนื้อหาจะพูดถึง overlap กับกลุ่มอื่น

รูปแบบไฟล์ที่ให้ดาวน์โหลด

  • CSV / JSON — ชุดข้อมูลเต็มพร้อม metadata (ชนิด, คำอธิบาย, วันที่, แหล่งข่าว)
  • Blocklist .txt แยกชนิดips.txt, domains.txt, urls.txt, hashes.txt, emails.txt เป็นรายการค่าอย่างเดียว (refang แล้ว) สำหรับนำเข้าระบบโดยตรง

ความรับผิดชอบ

การนำ IoC ไปใช้ถือเป็นความรับผิดชอบของผู้ใช้เอง โปรดอ่าน ข้อจำกัดความรับผิดชอบ ประกอบ Cloud Thunder และ TCS-CERT จะไม่รับผิดต่อความเสียหายที่เกิดจากการนำ IoC ไปใช้