Phishing สำเร็จแล้วไง? ตามรอย Account Takeover ใน Log ของคุณ
Phishing ไม่จบที่คลิกลิงก์ รหัสผ่านหลุดแล้วเกิดอะไรต่อ ดูว่า Log จับสัญญาณ Account Takeover ได้บ้าง พร้อมวิธีอ่าน Threat Incidents ของ zcrLog และตอบสนองให้ทัน
พนักงานคนหนึ่งเปิดอีเมล เห็นโลโก้ระบบที่ใช้ประจำ กดลิงก์ กรอกรหัสผ่านโดยไม่ทันสังเกตว่า URL ผิดไปหนึ่งตัวอักษร — แค่นี้ Phishing ก็สำเร็จแล้ว แต่คำถามที่องค์กรส่วนใหญ่ไม่ค่อยถามต่อคือ "แล้วไงต่อ" รหัสผ่านที่หลุดไปไม่ได้จบอยู่แค่กล่องข้อความของแฮกเกอร์ มันจะถูกเอาไปลองล็อกอินจริง และนั่นคือจุดที่ทีม Security ต้องเริ่มมองหา — ไม่ใช่อีเมลต้นทางที่จับได้ยาก แต่คือสัญญาณ Account Takeover ที่ตามมาหลังจากนั้น ซึ่งจับได้จริงในระบบ Log
"Phishing" ไม่ใช่ Incident Type ที่ Log เห็นตรงๆ
SIEM ทั่วไปไม่มีปุ่ม "ตรวจพบ Phishing" เพราะการหลอกเกิดขึ้นนอกระบบ — ใน Mail Client หรือ Browser ของเหยื่อ — ก่อนจะกลายเป็น Log Event ที่ตรวจสอบได้ สิ่งที่ Log เห็นจริงคือพฤติกรรม หลังจาก รหัสผ่านหลุดไปแล้ว: การเดา/ยิงรหัสผ่านซ้ำๆ (brute force), การยกระดับสิทธิ์เมื่อเข้าระบบได้แล้ว (privilege escalation), การเคลื่อนตัวข้ามเครื่อง (lateral movement), และการดึงข้อมูลออก (data exfiltration)
ผมลองไล่ดูหน้า Threat Incidents กับ Detection Rules ใน Demo Environment ของ zcrLog ว่าพฤติกรรมเหล่านี้ไปโผล่ตรงไหนบ้าง Incident ที่ยกมาในบทความนี้ไม่มีอันไหนเป็นของลูกค้าจริง ตัวอย่างทุกอันเป็นสถานการณ์สมมติ สิ่งที่ได้จากบทความนี้จึงเป็นวิธีอ่านหน้าจอและความหมายของแต่ละสัญญาณ (ดูรายละเอียด zcrLog — Demo ตัวจริงต้องล็อกอินด้วยบัญชีเดโม demo / demo)
วิธีอ่านตาราง Threat Incidents
หน้า Threat Analysis > Threat Incidents แสดง Incident แถวละหนึ่งรายการ และมีไม่กี่คอลัมน์ที่ต้องดูเป็นหลักเวลาไล่หาร่องรอยการยึดบัญชี:
- Type — ประเภทของ Incident เช่น
brute_force, privilege_escalation, lateral_movement หรือ data_exfiltration
- Status — Incident อยู่ในสถานะไหน เช่น ยังเปิดอยู่หรือปิดไปแล้ว
- Threats — จำนวนสัญญาณย่อยที่ Incident นั้นรวมไว้ด้วยกัน
- Username — บัญชีที่เกี่ยวข้องกับ Incident นั้น ในกรณีที่ Log ระบุมา ถ้าบัญชีเดียวกันโผล่ในหลาย Incident นั่นคือเบาะแสที่ควรไล่ตามต่อ
- Source IP และ Destination IP — กิจกรรมมาจากไหนและไปลงที่ไหน รายละเอียดอยู่ในหัวข้อถัดไป
ลองดูจากสถานการณ์สมมติว่าคอลัมน์เหล่านี้อ่านรวมกันยังไง มี Incident brute_force อันหนึ่งที่ระบุบัญชีเดียว ต้นทางอยู่นอกบริษัทและปลายทางอยู่ในเครือข่ายภายใน นั่นคือขั้นเดารหัสผ่าน ถ้าหลังจากนั้น Username เดิมไปโผล่ใน Incident แบบ privilege_escalation แปลว่าการเดาอาจได้ผลแล้ว และมีคนกำลังพยายามเอาสิทธิ์มากกว่าที่บัญชีนี้ควรมี ถ้าบัญชีเดิมมี lateral_movement ตามมาอีก ก็หมายความว่ากำลังขยับไปหาเครื่องอื่น ลำพังรายการใดรายการหนึ่งพิสูจน์อะไรได้ไม่มาก แต่บัญชีเดียวที่ไต่ตามลำดับแบบนี้เป็นรูปแบบที่ควรถือว่าโดน Account Takeover ไว้ก่อน จนกว่าจะมีใครยืนยันได้ว่าไม่ใช่
Incident ในตารางอาจมี Tag ของ MITRE ATT&CK กำกับอยู่ด้วย ในกรอบของ MITRE นั้น T1110 (Brute Force) คือการเดารหัสผ่าน จัดอยู่ใน Tactic TA0006 (Credential Access) ส่วน T1021 (Remote Services) คือวิธีแพร่ไปยังเครื่องอื่น จัดอยู่ใน Tactic TA0008 (Lateral Movement) เทคนิคที่อธิบาย Account Takeover ตรงตัวที่สุดคือ T1078 (Valid Accounts) — ผู้โจมตีไม่ได้เจาะเข้ามา แต่ล็อกอินด้วย Credential ของจริง Tag ของ ATT&CK บอกได้แค่ชื่อ Tactic หรือ Technique ไม่ได้ยืนยันว่าพฤติกรรมนั้นเกิดขึ้นจริง จึงควรตรวจ Event ที่อยู่เบื้องหลัง Incident ก่อนจะเชื่อตาม Tag
อ่าน Source IP → Destination IP ให้เป็น
ให้อ่าน Source IP กับ Destination IP เป็นคู่ ไม่ใช่ดูที่อยู่ตัวใดตัวหนึ่งเดี่ยวๆ รูปแบบที่ต้องมองหาคือ IP ต้นทางที่หน้าตาเหมือนที่อยู่สาธารณะจากภายนอก จับคู่กับ IP ปลายทางที่อยู่ในเครือข่ายภายในองค์กร (ช่วง RFC1918 อย่าง 10.x.x.x, 172.16-31.x.x, 192.168.x.x) ซึ่งตรงกับสถานการณ์ Account Takeover จริง: คนที่ถือรหัสผ่านที่หลุดจาก Phishing มักล็อกอินจากนอกองค์กร แล้วพยายามเข้าถึงทรัพยากรภายในทันทีที่เข้าได้
ข้อควรระวังมีสองข้อ ข้อแรก IP ต้นทางจากนอกองค์กรอาจเป็นพนักงานที่ทำงานจากบ้านหรือเดินทางอยู่ก็ได้ ดูจาก IP อย่างเดียวจึงบอกไม่ได้ว่าใครล็อกอินเข้ามา ต้องมีข้อมูลอื่นมาประกอบด้วย เช่น Username หรือประเภทของ Incident ข้อสอง คู่ที่ทั้งสองฝั่งเป็น IP ภายในอาจแปลว่ามีคนอยู่ข้างในแล้วและกำลังขยับไปมา ไม่ใช่กำลังเข้ามาจากข้างนอก แต่ถ้าล็อกอินเข้ามาผ่าน VPN ก็อาจเห็นเป็น IP ภายในได้เหมือนกัน คู่แบบนี้จึงยังฟันธงไม่ได้ว่าใช่หรือไม่ใช่
พอเห็นคู่ IP อยู่แถวเดียวกับบัญชีและประเภทของ Incident ภาพที่ได้ก็ต่างจากการนั่งไล่ Log ทีละบรรทัด และนี่คือสิ่งที่ zcrLog ถูกออกแบบมาให้ทำโดยอัตโนมัติ คือเก็บ Log แล้วเชื่อมโยงพฤติกรรมพวกนี้ให้เห็นเป็นภาพเดียวในตารางเดียว ทีม SOC ไม่ต้องมานั่งไล่ Correlate เองทีละไฟล์
Rule ที่ครอบคลุมพฤติกรรมหลัง Phishing สำเร็จ
ในหน้า Detection Rules Management > Rule Templates ของ zcrLog มี Rule สำเร็จรูปให้เลือกใช้ เช่น Brute Force (SSH), Privilege Escalation และ Anomalous Login Location
ในกลุ่มนี้ ตัวที่เกี่ยวกับ Account Takeover ตรงที่สุดคือ Anomalous Login Location — Rule ที่จับสัญญาณเวลาบัญชีเดียวล็อกอินจากตำแหน่งที่ผิดปกติเมื่อเทียบกับพฤติกรรมปกติของบัญชีนั้น ซึ่งเป็นสัญญาณคลาสสิกของ Session ที่ถูกขโมยไปหลัง Phishing สำเร็จ ส่วน Brute Force (SSH) เหมาะกับขั้นเดารหัสผ่านเมื่อการเดาพุ่งไปที่ SSH และ Privilege Escalation เหมาะกับสิ่งที่ตามมาหลังล็อกอินผ่านไปแล้ว ไม่ว่าจะเลือกใช้ Rule ตัวไหน ให้เช็กด้วยว่าเปิดใช้งาน (Active) อยู่ เพราะ Rule ที่ไม่ได้รันก็จับอะไรไม่ได้
ทำไม MFA อย่างเดียวไม่พอ
MFA ช่วยตัดปัญหารหัสผ่านหลุดแบบตรงไปตรงมาได้เยอะ แต่ Phishing Kit สมัยนี้หลายตัวเป็นแบบ Adversary-in-the-Middle คือ Proxy หน้า Login จริงพร้อมขโมย Session Token ตอน MFA ผ่านไปแล้ว ทำให้ MFA อย่างเดียวไม่ใช่เกราะกันขาด — ต้องมีชั้นตรวจจับพฤติกรรมความผิดปกติหลังล็อกอินสำเร็จมาเสริมด้วย อย่าง Anomalous Login Location ที่พูดถึงข้างบน
รหัสผ่านที่หลุดจาก Phishing มักถูกเอาไปลองยิงซ้ำที่หน้า Login สาธารณะขององค์กรด้วยเช่นกัน ไม่ใช่แค่ระบบภายใน — เรื่องนี้อธิบายละเอียดไว้ใน บทความเรื่อง Credential Stuffing หลัง Phishing ว่าทำไมจุดที่บล็อกได้ตั้งแต่ต้นทางคือหน้าเว็บสาธารณะ ไม่ใช่แค่รอจับที่ในองค์กรอย่างเดียว
ตอบสนองอัตโนมัติเมื่อเจอสัญญาณ
เจอ Rule Trigger แล้วขั้นตอนต่อไปคือใครกดปุ่มอะไร ไม่ใช่แค่ "ระบบแจ้งเตือน" แล้วจบ — เรื่องการวางขั้นตอนตอบสนองอัตโนมัติแบบมี Human Approval คั่นตรงจุดสำคัญ เขียนไว้ละเอียดใน Playbook รับมือ Phishing ที่ไม่ต้องทำมือทุกขั้นตอน ส่วนใครอยากรู้ว่า Tactic/Technique อย่าง TA0006 หรือ T1110 ที่พูดถึงข้างบนคืออะไรกันแน่ อ่านพื้นฐานเพิ่มได้ที่ MITRE ATT&CK คืออะไร
สรุปสัญญาณที่ต้องดูหลัง Phishing เกิด
| สัญญาณเชิงพฤติกรรม | Incident Type ใน Log | สัญญาณนี้บอกอะไร |
|---|
| เดา/ยิงรหัสผ่านซ้ำๆ | brute_force | มีคนกำลังลองรหัสผ่านกับบัญชี ซึ่งอาจเป็นรหัสที่หลุดมาจาก Phishing |
| ยกระดับสิทธิ์หลังเข้าระบบได้ | privilege_escalation | คนที่เข้ามาได้แล้วกำลังพยายามเอาสิทธิ์มากกว่าที่บัญชีนี้ควรมี |
| เคลื่อนตัวข้ามเครื่อง/ระบบ | lateral_movement | บัญชีถูกใช้เข้าถึงเครื่องหรือระบบอื่น |
| ดึงข้อมูลออกจากระบบ | data_exfiltration | เป็นขั้นปลายๆ ข้อมูลกำลังไหลออกจากระบบ |
องค์กรที่ไม่มีระบบเก็บ Log เชื่อมโยงสัญญาณพวกนี้ให้เห็นเป็นภาพเดียว มักรู้ตัวว่าโดน Account Takeover ตอนที่สายเกินไปแล้ว — เจอทีข้อมูลออกไปแล้ว (data_exfiltration) ไม่ใช่ตอนที่ยังเป็นแค่การเดารหัสผ่าน (brute_force) ซึ่งเป็นขั้นที่แก้ทันง่ายกว่ากันมาก
ดูแพ็กเกจ zcrLog ทั้งหมดพร้อมราคา →
แหล่งข้อมูลอ้างอิง
- Microsoft Security Blog — From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud — ยืนยันกลไก Adversary-in-the-Middle phishing ที่ขโมย Session Cookie หลัง MFA ผ่านแล้ว ทำให้ผู้โจมตีข้าม MFA ได้
- MITRE ATT&CK — T1078 Valid Accounts, T1110 Brute Force และ T1021 Remote Services — คำอธิบาย Technique ที่บทความอ้างอิงตลอดทั้งบทความ
อยากรู้ว่าองค์กรของคุณจะเห็นสัญญาณพวกนี้ได้เร็วแค่ไหน?
คุยกับทีมเราได้ฟรี ไม่มีค่าใช้จ่าย