เมื่อคนร้ายไม่ได้ปลอมอีเมล แต่เข้ามาส่งอีเมลจากบัญชีจริงขององค์กร
หลายองค์กรเริ่มคุ้นเคยกับการระวัง Phishing Email ไม่ว่าจะเป็นการตรวจสอบชื่อผู้ส่ง ลิงก์ปลอม หรือไฟล์แนบที่น่าสงสัย
แต่การโจมตีที่ D SCAPE พบจากการเข้าช่วยตรวจสอบเหตุการณ์ให้ลูกค้าในช่วงที่ผ่านมา มีความซับซ้อนกว่านั้น เพราะผู้โจมตีไม่ได้เพียงส่งอีเมลปลอมเข้ามา แต่สามารถเข้าถึงบัญชีผู้ใช้งานขององค์กรได้สำเร็จ และใช้งานบัญชีนั้นเสมือนเป็นเจ้าของตัวจริง
เมื่ออีเมลถูกส่งออกจากบัญชีจริง ใช้ชื่อจริง มีประวัติการสนทนาเดิม และส่งถึงบุคคลที่ผู้ใช้งานติดต่ออยู่เป็นประจำ โอกาสที่ผู้รับจะหลงเชื่อย่อมสูงกว่า Phishing Email ทั่วไปอย่างมาก
การโจมตีลักษณะนี้เรียกว่าอะไร?
คำที่ใช้อธิบายเหตุการณ์นี้ได้ตรงที่สุดคือ Email Account Compromise (EAC) หรือ Email Account Takeover (ATO) หมายถึงการที่ผู้โจมตีสามารถยึดหรือเข้าถึงบัญชีอีเมลจริงของผู้ใช้งานได้
หากบัญชีดังกล่าวถูกนำไปใช้หลอกพนักงาน คู่ค้า หรือลูกค้า เช่น ขอให้โอนเงิน เปลี่ยนบัญชีรับชำระ ส่งเอกสารปลอม หรือขอข้อมูลสำคัญ เหตุการณ์นั้นจะเข้าข่าย Business Email Compromise (BEC)
ส่วนการใช้บัญชีที่ถูกยึดเพื่อส่ง Phishing Email ต่อไปยังพนักงานหรือผู้ติดต่อรายอื่น เรียกว่า Lateral Phishing เพราะผู้โจมตีกำลังขยายการโจมตีจากบัญชีหนึ่งไปสู่อีกบัญชีหนึ่ง โดยอาศัยความไว้วางใจที่มีอยู่แล้วภายในเครือข่ายธุรกิจ
พูดให้เห็นภาพง่าย ๆ Phishing ทั่วไปคือคนร้ายปลอมตัวมายืนหน้าประตู แต่ Account Takeover คือคนร้ายได้กุญแจจริง เปิดประตูเข้ามา และเริ่มติดต่อผู้อื่นในนามขององค์กร
รูปแบบการโจมตีที่พบบ่อย
จากการตรวจสอบเหตุการณ์ D SCAPE พบพฤติกรรมสำคัญสามส่วน
1. เปิดอ่านอีเมลภายใน Inbox
หลังจากเข้าถึงบัญชีได้ ผู้โจมตีอาจอ่านอีเมลย้อนหลังเพื่อทำความเข้าใจโครงสร้างองค์กร รายชื่อลูกค้า คู่ค้า ผู้บริหาร ตลอดจนรูปแบบการอนุมัติงานและรอบการชำระเงิน
ข้อมูลเหล่านี้ช่วยให้ผู้โจมตีสร้างข้อความที่ดูสมจริง เช่น อ้างอิงโครงการที่กำลังดำเนินอยู่ ส่งเอกสารต่อจากบทสนทนาเดิม หรือเลือกโจมตีในช่วงที่กำลังจะมีการจ่ายเงินจริง
ความเสียหายจึงไม่ได้จำกัดอยู่เพียง “อีเมลถูกอ่าน” แต่อาจรวมถึงการเปิดเผยข้อมูลธุรกิจ ข้อมูลส่วนบุคคล เอกสารแนบ และข้อมูลที่สามารถนำไปใช้โจมตีต่อได้
2. ส่ง Phishing Email จากบัญชีจริง
ผู้โจมตีอาจส่งอีเมลไปยัง Contact List ทั้งหมด หรือค้นหาผู้รับจากอีเมลที่เคยส่งและเคยได้รับ ก่อนตอบกลับจากบทสนทนาเดิม
วิธีหลังมีความอันตรายเป็นพิเศษ เพราะผู้รับเห็นทั้งชื่อผู้ส่ง ที่อยู่อีเมล และประวัติการสนทนาที่คุ้นเคย จึงอาจเปิดไฟล์ กดลิงก์ เปิดเผยรหัสผ่าน หรือทำตามคำขอโดยไม่ทันสงสัย
บัญชีหนึ่งที่ถูกยึดจึงสามารถกลายเป็นจุดเริ่มต้นของการโจมตีพนักงานทั้งองค์กร รวมถึงลูกค้าและบริษัทคู่ค้าหลายแห่งได้
3. สร้างหรือแก้ไข Mailbox Rules
ผู้โจมตีมักสร้าง Malicious Inbox Rules เพื่อควบคุมการไหลของอีเมลและซ่อนร่องรอย เช่น
- ส่งต่ออีเมลไปยังบัญชีภายนอก
- ย้ายอีเมลบางคำ เช่น “invoice”, “payment”, “phishing” หรือ “fraud” ไปยังโฟลเดอร์ที่ผู้ใช้ไม่ค่อยเปิด
- ลบคำเตือนหรืออีเมลตอบกลับจากผู้รับ
- ซ่อนข้อความไว้ใน Junk Email, RSS หรือ Deleted Items
- ทำให้เจ้าของบัญชีไม่เห็นว่ามีผู้ติดต่อแจ้งเตือนความผิดปกติ
Microsoft ระบุว่า Inbox Rules ที่เป็นอันตรายพบได้บ่อยในการโจมตีแบบ BEC และ Phishing เพราะช่วยทั้งขโมยข้อมูล ติดตามบทสนทนา และปิดบังการกระทำของผู้โจมตี
ทำไมการเปลี่ยนรหัสผ่านเพียงอย่างเดียวจึงอาจไม่พอ?
เมื่อพบเหตุการณ์ หลายองค์กรรีบเปลี่ยนรหัสผ่าน ซึ่งเป็นสิ่งที่ควรทำ แต่ยังไม่ใช่การแก้ไขทั้งหมด
ผู้โจมตีอาจยังมี Session หรือ Token ที่ใช้งานอยู่ อาจเพิ่มวิธี MFA ของตนเอง อนุญาตแอปพลิเคชันที่เป็นอันตราย หรือสร้างระบบ Forwarding และ Inbox Rules ทิ้งไว้
หากจัดการเฉพาะรหัสผ่านโดยไม่ตรวจสอบส่วนเหล่านี้ ผู้โจมตีอาจยังอ่านอีเมลต่อหรือกลับเข้ามาได้อีก
เมื่อสงสัยว่าบัญชีถูกยึด ควรทำอะไรทันที?
องค์กรควรดำเนินการตามกระบวนการ Incident Response โดยเร็วที่สุด
1. จำกัดการเข้าถึงบัญชี
ระงับบัญชีที่ได้รับผลกระทบชั่วคราว หรือบังคับเปลี่ยนรหัสผ่านเป็นรหัสที่ไม่ซ้ำกับบริการอื่น พร้อมยกเลิก Active Sessions และ Refresh Tokens ทั้งหมด
ไม่ควรส่งรหัสผ่านใหม่ผ่านอีเมลของบัญชีที่กำลังถูกตรวจสอบ
2. ตรวจสอบและลบช่องทางที่ผู้โจมตีสร้างไว้
ตรวจสอบอย่างน้อยในส่วนต่อไปนี้
- วิธี MFA อุปกรณ์ และเบอร์โทรศัพท์ที่ลงทะเบียน
- แอปพลิเคชันและสิทธิ์ที่ผู้ใช้เคยกดยินยอม
- Administrative Roles หรือสิทธิ์พิเศษของบัญชี
- Inbox Rules รวมถึงกฎที่ถูกซ่อน
- Mail Forwarding และการส่งต่อไปยัง External Address
- Delegate Access และสิทธิ์เข้าถึง Mailbox
- Sign-in Logs ตำแหน่ง อุปกรณ์ IP Address และพฤติกรรมที่ผิดปกติ
3. ตรวจสอบขอบเขตความเสียหาย
ใช้ Audit Logs, Sign-in Logs และ Message Trace เพื่อหาว่าเหตุการณ์เริ่มต้นเมื่อใด มีการเปิดหรือส่งอีเมลใดออกไป ดาวน์โหลดข้อมูลจาก OneDrive หรือ SharePoint หรือไม่ และมีบัญชีอื่นได้รับผลกระทบเพิ่มเติมหรือไม่
การตรวจสอบไม่ควรจำกัดเฉพาะ Sent Items เพราะผู้โจมตีสามารถลบข้อความหรือใช้กฎย้ายอีเมลเพื่อซ่อนหลักฐานได้
4. แจ้งเตือนผู้ที่อาจได้รับอีเมลอันตราย
องค์กรควรรีบแจ้งพนักงาน ลูกค้า และคู่ค้าที่ได้รับข้อความจากบัญชีดังกล่าวให้ทราบว่าอีเมลใดไม่ควรเปิด พร้อมระบุช่วงเวลา หัวข้ออีเมล ลิงก์ หรือไฟล์แนบที่เกี่ยวข้องอย่างชัดเจน
หากเกี่ยวข้องกับข้อมูลส่วนบุคคล ข้อมูลสำคัญ หรือธุรกรรมทางการเงิน ควรประสานทีมกฎหมาย ทีมความเป็นส่วนตัว และผู้บริหาร เพื่อประเมินหน้าที่ในการแจ้งเหตุที่เกี่ยวข้อง
5. ค้นหาบัญชีที่อาจถูกโจมตีต่อ
ตรวจสอบว่ามีพนักงานหรือคู่ค้ารายใดกดลิงก์ กรอกรหัสผ่าน เปิดไฟล์ หรืออนุมัติ MFA Prompt จากอีเมลที่ถูกส่งออกไปหรือไม่ เพราะเหตุการณ์อาจไม่ได้หยุดอยู่ที่บัญชีแรก
ป้องกันไม่ให้เหตุการณ์เกิดซ้ำได้อย่างไร?
เปิดใช้ MFA สำหรับผู้ใช้งานทุกคน
MFA ช่วยลดความเสี่ยงจากรหัสผ่านที่รั่วไหล แต่ควรเลือกวิธีที่ทนต่อ Phishing ได้ เช่น Passkey, FIDO2 Security Key, Windows Hello for Business หรือ Certificate-based Authentication โดยเฉพาะบัญชีผู้ดูแลระบบและบัญชีที่เข้าถึงข้อมูลสำคัญ
MFA แบบเดิมยังอาจถูกหลอกผ่าน MFA Fatigue หรือการขโมย Session Token ได้ จึงไม่ควรใช้ MFA เป็นมาตรการเพียงอย่างเดียว
ใช้ Conditional Access และ Risk-based Policies
องค์กรสามารถกำหนดเงื่อนไขการเข้าถึงตามระดับความเสี่ยง ตำแหน่ง อุปกรณ์ และลักษณะการ Sign-in เช่น บล็อกการเข้าใช้ที่มีความเสี่ยงสูง บังคับยืนยันตัวตนใหม่ หรืออนุญาตให้เข้าถึงข้อมูลสำคัญจากอุปกรณ์ที่องค์กรจัดการเท่านั้น
ปิดช่องทางที่ไม่จำเป็น
ควรปิด Legacy Authentication จำกัด External Email Forwarding ควบคุมการให้ Consent แก่แอปพลิเคชัน และใช้หลัก Least Privilege เพื่อลดผลกระทบหากบัญชีใดบัญชีหนึ่งถูกยึด
เฝ้าระวังพฤติกรรม ไม่ใช่ดูแค่มัลแวร์
ระบบควรแจ้งเตือนเมื่อพบการเข้าสู่ระบบที่ผิดปกติ การสร้าง Inbox Rule ที่น่าสงสัย การส่งอีเมลจำนวนมาก การเพิ่มวิธี MFA ใหม่ หรือการให้สิทธิ์แก่แอปพลิเคชันที่ไม่คุ้นเคย
เพราะในการโจมตีแบบนี้ ผู้โจมตีอาจไม่จำเป็นต้องติดตั้งมัลแวร์เลย เพียงใช้บัญชีและเครื่องมือที่องค์กรมีอยู่แล้วก็สามารถสร้างความเสียหายได้
เตรียม Incident Response Playbook ล่วงหน้า
องค์กรควรกำหนดให้ชัดเจนว่า เมื่อพบบัญชีต้องสงสัย ใครมีอำนาจระงับบัญชี ใครตรวจสอบ Logs ใครแจ้งลูกค้า และใครตัดสินใจเกี่ยวกับธุรกรรมที่อาจได้รับผลกระทบ
ความเร็วในการตอบสนองมีผลโดยตรงต่อจำนวนอีเมลที่ถูกอ่าน จำนวนผู้รับที่ถูกโจมตีต่อ และขอบเขตความเสียหายต่อชื่อเสียงขององค์กร
Identity Security คือเรื่องของความเชื่อมั่นทางธุรกิจ
เมื่อบัญชีองค์กรถูกยึด ความเสียหายไม่ได้เกิดขึ้นเฉพาะกับเจ้าของบัญชี แต่ลามไปถึงทุกคนที่เชื่อถือชื่อ Domain และตัวตนขององค์กรนั้น
การป้องกันจึงต้องครอบคลุมทั้ง Identity, Email, Endpoint, Data และกระบวนการตอบสนองต่อเหตุการณ์ ไม่ใช่พึ่งการอบรมผู้ใช้งานหรือเปลี่ยนรหัสผ่านเพียงอย่างเดียว
D SCAPE ช่วยองค์กรตรวจสอบเหตุการณ์ ประเมินขอบเขตความเสียหาย ปิดช่องทางการเข้าถึงของผู้โจมตี และวางมาตรการป้องกันสำหรับ Microsoft 365 และระบบ Cloud Identity ให้เหมาะกับความเสี่ยงของแต่ละองค์กร
หากพบการเข้าสู่ระบบผิดปกติ มีอีเมลถูกส่งออกโดยไม่ทราบสาเหตุ หรือพบ Mailbox Rules ที่ผู้ใช้งานไม่ได้สร้าง ควรเริ่มตรวจสอบทันที เพราะทุกนาทีที่ผ่านไป อาจหมายถึงข้อมูลและความไว้วางใจที่กำลังถูกนำไปใช้โจมตีต่อ