ใครคือคนที่ Phishing องค์กรคุณ — อ่าน Threat Intelligence ให้เป็น
IOC feed สี่หมื่นบรรทัดไม่ได้บอกว่าใครโจมตีองค์กรคุณ วิธีอ่าน Threat Intelligence ให้ใช้ได้จริง ดูจากหน้า AI Threat Brief ของ zcrCTEM พร้อมข้อจำกัดที่ควรรู้
ใครคือคนที่ Phishing องค์กรคุณ — อ่าน Threat Intelligence ให้เป็น
สมมติผู้บริหารเดินมาถามคำถามเดียวว่า "ตอนนี้ใครกำลังจ้ององค์กรเราอยู่"
ถ้าคำตอบที่คุณหยิบมาได้คือไฟล์ CSV ที่มี IP กับไฟล์แฮชอยู่หลายหมื่นบรรทัด จาก feed ที่สมัครไว้ตั้งแต่ต้นปีและไม่เคยมีใครเปิดอ่านจริงจัง — นั่นแปลว่าคุณยังไม่มีคำตอบ คุณมีแค่ข้อมูล
ความต่างระหว่างสองอย่างนี้คือเรื่องที่ทีมความปลอดภัยส่วนใหญ่จ่ายเงินซื้อไปแล้วแต่ยังไม่ได้ใช้
IOC feed ไม่ได้ผิด แต่มันไม่ได้พูดถึงองค์กรคุณ
IOC (Indicator of Compromise) คือร่องรอยที่ผู้โจมตีทิ้งไว้ — IP ปลายทาง โดเมนที่ใช้ส่งอีเมลปลอม แฮชของไฟล์แนบ ตัวข้อมูลมักถูกต้องนะ ปัญหาอยู่ที่อายุของมันต่างหาก
โดเมน phishing ถูกจดขึ้นมาใช้แล้วทิ้งได้ในวันเดียว IP หมุนตาม hosting ที่เช่ารายชั่วโมง ส่วนแฮชของไฟล์เปลี่ยนทุกครั้งที่คนสร้างมัลแวร์กด build ใหม่ พอถึงเวลาที่ indicator เดินทางจาก feed มาถึง SIEM ของคุณ มันอาจตายไปแล้ว นี่คือแนวคิดที่ David Bianco เรียกว่า Pyramid of Pain — สิ่งที่ผู้โจมตีเปลี่ยนได้ง่ายที่สุดคือสิ่งที่มีประโยชน์กับฝ่ายตั้งรับน้อยที่สุด
แต่ปัญหาที่หนักกว่าเรื่องอายุคือเรื่องบริบท
feed ทั่วไปไม่รู้ว่าองค์กรคุณใช้ Palo Alto หรือ Fortinet ไม่รู้ว่าคุณเปิด Citrix ให้พนักงานรีโมตเข้ามาหรือเปล่า ไม่รู้ด้วยซ้ำว่าคุณอยู่ในธุรกิจอะไร มันจึงส่งทุกอย่างมาให้เท่ากันหมด แล้วปล่อยให้คนที่มีเวลาอ่านวันละยี่สิบนาทีเป็นคนคัดเอง ผลที่ตามมาแทบทุกที่เหมือนกัน คือ dashboard สวยๆ ที่ไม่มีใครเปิด
คำถามที่ว่า "ใคร" — คำตอบที่ใช้ได้จริงมักไม่ใช่ชื่อกลุ่ม
พอพูดถึง threat intelligence คนมักคาดหวังชื่อกลุ่มเท่ๆ แบบที่เห็นในข่าว ซึ่งอ่านสนุกจริง แต่ลองถามต่ออีกขั้นว่า แล้วพรุ่งนี้จะทำอะไรต่อ ชื่อกลุ่มมักตอบไม่ได้
สิ่งที่ตอบได้คือ วิธี ที่เขาเข้ามา ซึ่งเปลี่ยนช้ากว่าชื่อกลุ่มมาก และมักจะซ้ำกันจนน่าเบื่อ
อีเมล phishing แทบไม่เคยเป็นจุดจบของการโจมตี มันเป็นแค่ขั้นแรก เป้าหมายคือรหัสผ่านหรือ session ของพนักงานสักคน แล้วเอาสิ่งนั้นไปใช้กับ ประตูที่เปิดออกสู่อินเทอร์เน็ตอยู่แล้ว — VPN gateway, เครื่องมือรีโมตของทีม IT, ระบบ remote access ของผู้รับเหมา ประตูพวกนี้แหละที่ควรเป็นตัวตั้งต้นในการอ่าน intel ไม่ใช่ชื่อกลุ่ม
ถ้าอยากเข้าใจภาษากลางที่ใช้อธิบาย "วิธีเข้ามา" แบบเป็นระบบ อ่าน MITRE ATT&CK คืออะไร ควบคู่ไปด้วยจะเห็นภาพเร็วขึ้นเยอะ
หน้าตาจริงของ threat brief ที่อ่านแล้วทำงานต่อได้
หน้าจอด้านล่างนี้มาจากส่วน AI Threat Brief ของ zcrCTEM (ข้อมูลจากสภาพแวดล้อมสาธิต) ขอไล่ให้ดูว่าแต่ละส่วนบอกอะไร เพราะโครงของมันคือสิ่งที่ IOC feed ดิบไม่มี
แถบบนสุดของแต่ละสัปดาห์มีป้ายระดับความเร่งด่วนและตัวนับสองตัว — จำนวนช่องโหว่ที่ถูกใช้โจมตีจริงแล้ว (KEV) ที่ส่งผลต่อสภาพแวดล้อมของคุณ และมีของใหม่กี่รายการตั้งแต่บรีฟรอบก่อน — สามวินาทีก็รู้แล้วว่าสัปดาห์นี้เร่งด่วนแค่ไหนก่อนจะอ่านรายละเอียดสักบรรทัด ส่วนที่บรีฟหยิบมาขยายรายละเอียดข้างล่างคือ threat ที่สำคัญที่สุด (นี่คือสภาพแวดล้อมสาธิต จึงควรมองว่าเป็นการอธิบาย layout ว่าบรีฟติดตามอะไรได้ ไม่ใช่ตัวเลขของสัปดาห์ใดสัปดาห์หนึ่งจริง ๆ)
ถัดลงมาเป็นประโยคเดียวที่สรุปทั้งสัปดาห์ บอกว่ามีช่องโหว่ KEV ที่ถูกใช้โจมตีจริงในสภาพแวดล้อมของคุณกี่รายการที่ต้องแพตช์ทันที ทุกบล็อกมีบรรทัดภาษาไทยกำกับอยู่ใต้ข้อความอังกฤษ ส่วนมุมขวาบนมีปุ่มสลับ EN/TH กับปุ่ม Refresh — เรื่องเล็กแต่มีผลจริงเวลาต้องส่งต่อให้ทีมที่ไม่ได้อ่านอังกฤษทั้งวัน
ถัดมาคือ TOP THREATS THIS WEEK สามรายการ แต่ละรายการมีป้ายบอกความเร่งด่วนของมันเอง:
| ป้าย | รายการ | ประเด็นที่บรีฟระบุ |
|---|
| IMMEDIATE | PAN-OS Command Injection (CVE-2024-3400) | zero-day ระดับวิกฤตบน Palo Alto PAN-OS GlobalProtect gateway เปิดให้รันโค้ดจากระยะไกลโดยไม่ต้องยืนยันตัวตน กำลังถูกโจมตีจริงและอยู่ในรายการ CISA KEV ต้องแพตช์ไฟร์วอลล์ขอบเครือข่ายที่ได้รับผลกระทบทั้งหมดทันที |
| IMMEDIATE | ConnectWise ScreenConnect Auth Bypass (CVE-2024-1709) | ข้ามการยืนยันตัวตนจนควบคุมระบบได้ทั้งหมดโดยไม่ต้องใช้รหัสผ่าน อยู่ใน KEV และมีโค้ดโจมตีแพร่หลาย บรีฟแนะนำให้แพตช์หรือแยกเซิร์ฟเวอร์ remote access ที่ได้รับผลกระทบออกภายในสัปดาห์นี้ |
| THIS WEEK | Citrix Bleed Session Token Leak (CVE-2023-4966) | Citrix NetScaler ADC และ Gateway เปิดเผยข้อมูลจนดึง session token ได้ ทำให้ข้ามการยืนยันแบบหลายปัจจัยและยึด session ที่ล็อกอินแล้วได้ บรีฟแนะนำให้ติดตามอุปกรณ์ Citrix ทั้งหมดและบังคับหมุน session เป็นมาตรการชั่วคราว |
ปิดท้ายด้วยบรรทัดของนักวิเคราะห์: "Prioritize KEV-listed CVEs with available patches; use network segmentation to isolate unpatched systems until maintenance windows allow full remediation." — แปลเป็นภาษาคนคือ "อันไหนมีแพตช์ทำก่อน อันไหนยังทำไม่ได้ให้กันมันออกจากระบบอื่นไว้ก่อน"
ทำไมทั้งสามรายการนี้เกี่ยวกับ phishing
สังเกตว่าไม่มีรายการไหนพูดถึงอีเมลเลยสักคำ แต่ทั้งสามอันคือ ปลายทางของ phishing ทั้งหมด
สองรายการแรกคือระบบที่เปิดรับการเชื่อมต่อจากภายนอก — VPN gateway กับเครื่องมือ remote access ซึ่งเป็นที่ที่รหัสผ่านที่ถูกขโมยมาจะไปโผล่ ส่วนรายการที่สามน่าสนใจกว่านั้น เพราะบรีฟระบุตรงๆ ว่ามันทำให้ ข้ามการยืนยันแบบหลายปัจจัย ได้ — ซึ่งเป็นผลลัพธ์เดียวกันเป๊ะกับที่หน้า phishing สมัยใหม่ทำ คือไม่ขโมยรหัสผ่านแล้ว แต่ขโมย session ที่ผ่าน MFA ไปเรียบร้อยแล้ว
คนละทาง ปลายทางเดียวกัน
พอมองแบบนี้ คำถาม "ใครโจมตีเรา" ก็เปลี่ยนรูปเป็นคำถามที่ตอบได้ทันที: ประตูบานไหนของเราเปิดอยู่ และบานไหนกำลังมีคนพยายามงัดอยู่จริงในสัปดาห์นี้ ซึ่งเป็นคำถามเดียวกับที่ การทำ exposure management แบบต่อเนื่อง (CTEM) พยายามตอบ และเป็นเหตุผลที่ threat intel ตัวนี้อยู่ในแพลตฟอร์มเดียวกับงานสำรวจ พื้นที่โจมตีจากภายนอก
IOC feed ดิบ กับ intel ที่ผูกกับสินทรัพย์จริง — ต่างกันตรงไหน
| คำถาม | IOC feed ดิบ | Threat brief ที่ผูกกับสินทรัพย์ |
|---|
| เกี่ยวกับเราไหม | ไม่รู้ ต้องมาคัดเอง | บอกมาแล้วว่า "in your environment" |
| ควรทำอะไรก่อน | ไม่มีลำดับ | มีป้าย IMMEDIATE / THIS WEEK ให้ |
| ข้อมูลจะตายเมื่อไร | เร็ว โดยเฉพาะ IP กับแฮช | ผูกกับ CVE ซึ่งอยู่นานกว่ามาก |
| ส่งต่อให้ผู้บริหารได้ไหม | ต้องเรียบเรียงใหม่ทุกครั้ง | มีประโยคสรุปหนึ่งบรรทัดพร้อมใช้ |
ถ้าอยากเทียบว่าแพ็กเกจไหนครอบคลุมส่วนไหนบ้าง ดูรายละเอียดได้ที่ หน้าแพ็กเกจ
สิ่งที่หน้านี้ยังไม่ได้ทำให้คุณ
เล่าแต่ข้อดีอย่างเดียวก็คงไม่แฟร์ หน้า AI Threat Brief ที่เห็นข้างบนมีขอบเขตของมันชัดเจน:
- ไม่ได้บอกชื่อกลุ่มผู้โจมตี — ทั้งสามรายการในบรีฟระบุตัวด้วยหมายเลข CVE ไม่มีรายการไหนเอ่ยชื่อกลุ่มผู้โจมตีเลยสักอัน มันจัดลำดับตามช่องโหว่ที่กำลังถูกโจมตีจริง ไม่ได้ทำ attribution ถ้าองค์กรคุณต้องการรายงานที่ระบุชื่อกลุ่มผู้โจมตี นี่ยังไม่ใช่เครื่องมือนั้น
- ไม่ได้กรองอีเมล — zcrCTEM ไม่ใช่ mail security gateway ไม่ได้บล็อกอีเมล phishing ก่อนถึงกล่องจดหมาย มันดูแลฝั่ง "ถ้าหลุดเข้ามาแล้ว เขาจะเดินต่อไปทางไหน"
- นำเสนอเป็นรอบสัปดาห์ — หัวบรีฟระบุ Week of ชัดเจน มันคือจังหวะสำหรับวางแผนงานแพตช์ ส่วนการเฝ้าระวังแบบวินาทีต่อวินาทีเป็นหน้าที่ของ SIEM คนละเครื่องมือ คนละจังหวะ
- ต้องมี asset inventory ที่ตรงความจริงก่อน — ประโยค "in your environment" จะมีค่าก็ต่อเมื่อรายการสินทรัพย์ถูกต้อง ถ้ายังมีเซิร์ฟเวอร์ที่ไม่มีใครจำได้ว่าใครดูแล บรีฟก็จะยังมองไม่เห็นมันเหมือนกัน
ข้อสุดท้ายนี่แหละที่เจอบ่อยที่สุด และเป็นเหตุผลว่าทำไมงาน visibility ควรมาก่อนงานซื้อ intel
สัญญาณว่าเรื่องนี้ตรงกับองค์กรคุณ
- ตอบไม่ได้ทันทีว่าตอนนี้มีระบบอะไรของเราเปิดออกอินเทอร์เน็ตอยู่บ้าง
- มี feed หรือรายงาน intel ที่จ่ายเงินอยู่ แต่ไม่มีใครเปิดอ่านเกินเดือนละครั้ง
- เวลาข่าวช่องโหว่ใหญ่ๆ ออก ต้องใช้เวลาเป็นวันกว่าจะตอบได้ว่า "เรามีตัวนั้นไหม"
- ผู้รับเหมาภายนอกใช้เครื่องมือ remote access เข้ามาได้ แต่ไม่มีใครรู้ว่าเวอร์ชันไหน
- พนักงานเคยรายงานอีเมล phishing แต่ไม่มีขั้นตอนต่อจากนั้นที่เขียนไว้เป็นลายลักษณ์อักษร
เข้าข่ายสองข้อขึ้นไป จุดเริ่มที่คุ้มที่สุดคือทำให้รู้ก่อนว่ามีอะไรอยู่บ้าง แล้วค่อยเอา intel มาทาบทีหลัง การซื้อ feed เพิ่มตอนนี้ยังไม่ช่วยอะไร
ส่วนข้อสุดท้ายเรื่องขั้นตอนหลังพนักงานกดรายงานอีเมล — เขียนเป็น playbook ให้ทำงานอัตโนมัติได้ ลองดูตัวอย่างจริงที่ playbook ตอบสนอง phishing ด้วย SOAR และถ้าอยากรู้ว่ารหัสผ่านของพนักงานหลุดไปอยู่ที่ไหนแล้วบ้าง เรื่องนั้นอยู่ในฝั่ง การเฝ้าระวัง dark web ซึ่งเป็นคนละงานกับบรีฟหน้านี้
สรุปสั้นๆ สำหรับคนที่เลื่อนมาถึงตรงนี้
วิธีวัดว่า threat intelligence ตัวไหนใช้ได้จริง มีอยู่ข้อเดียว — อ่านจบแล้วเหลืองานที่ลงมือทำต่อได้กี่อย่าง
บรีฟตัวอย่างข้างบนให้มาสามอย่าง คือแพตช์ PAN-OS, แพตช์หรือแยก ScreenConnect ออก, และบังคับหมุน session บน Citrix — ไม่มีอันไหนต้องเดา ไม่มีอันไหนต้องนั่งคัดจาก CSV หลายหมื่นบรรทัด
นั่นคือมาตรฐานที่ควรใช้ตัดสิน feed ทุกตัวที่กำลังจ่ายเงินอยู่
ติดต่อทีมงาน
อยากรู้ว่าตอนนี้มีประตูบานไหนขององค์กรคุณเปิดอยู่บ้าง และมีบานไหนที่กำลังถูกโจมตีจริงในสัปดาห์นี้ คุยกับทีมเราได้ฟรี ไม่มีค่าใช้จ่าย
แหล่งที่มา