Microsoft 365 ถูกโจมตีด้วย Vishing ได้อย่างไร และองค์กรควรป้องกันอย่างไร

Microsoft 365 ถูกโจมตีได้แม้มี MFA หากผู้โจมตีใช้ Vishing หลอกพนักงานและขโมย Session Token

ปัจจุบันองค์กรจำนวนมากย้ายระบบ Email, Document และ Collaboration ขึ้น Cloud ผ่านแพลตฟอร์มอย่าง Microsoft 365 ทำให้ Identity หรือ “ตัวตนของผู้ใช้งาน” กลายเป็นหนึ่งในเป้าหมายสำคัญของผู้โจมตี

หนึ่งในวิธีที่กำลังได้รับความสนใจคือ Vishing (Voice Phishing) หรือการหลอกลวงผ่านโทรศัพท์ โดยผู้โจมตีอาจปลอมตัวเป็นเจ้าหน้าที่ IT หรือ Help Desk แล้วสร้างสถานการณ์เร่งด่วนเพื่อให้พนักงานทำตามคำแนะนำ

กรณีล่าสุดที่ถูกติดตามในชื่อ PREY-0058 แสดงให้เห็นว่าการโจมตีสามารถต่อยอดจากการโทรหลอกลวงไปสู่ Adversary-in-the-Middle (AitM) และการขโมย Session Token เพื่อเข้าถึง Microsoft 365 และข้อมูลบน Cloud ได้ โดยไม่จำเป็นต้องติดตั้ง Malware บนเครื่องของเหยื่อ

ดังนั้นคำถามสำคัญจึงไม่ใช่เพียง “องค์กรมี MFA แล้วหรือยัง?”

แต่คือ

“หากผู้โจมตีหลอกให้พนักงานยืนยันตัวตนสำเร็จ องค์กรจะรู้ได้อย่างไรว่าผู้ที่กำลังใช้ Session นั้นไม่ใช่เจ้าของบัญชีตัวจริง?”

Vishing คืออะไร?

Vishing (Voice Phishing) คือรูปแบบหนึ่งของ Social Engineering ที่ผู้โจมตีใช้โทรศัพท์หรือการสื่อสารด้วยเสียงเพื่อหลอกให้เหยื่อเปิดเผยข้อมูล หรือดำเนินการบางอย่างที่เป็นประโยชน์ต่อผู้โจมตี

ตัวอย่างเช่น ผู้โจมตีอาจโทรหาเหยื่อและอ้างว่าเป็น

• IT Help Desk

• Microsoft Support

• Security Team

• ผู้ดูแลระบบ

• เจ้าหน้าที่ฝ่าย IT ของบริษัท

จากนั้นอาจสร้างสถานการณ์ เช่น

“เราพบ Login ที่ผิดปกติจากบัญชีของคุณ”

หรือ

“บัญชี Microsoft 365 ของคุณจำเป็นต้องลงทะเบียน MFA ใหม่”

หรือ

“ระบบพบปัญหากับ Security Authentication กรุณาดำเนินการตามขั้นตอนที่ส่งให้”

เป้าหมายไม่จำเป็นต้องเป็นการขอ Password โดยตรง

แต่ผู้โจมตีอาจหลอกให้เหยื่อ เปิดเว็บไซต์ เข้าสู่ระบบ อนุมัติ MFA หรือทำตามขั้นตอน Authentication ที่ผู้โจมตีควบคุม

นี่คือจุดที่ Vishing สามารถเชื่อมต่อกับการโจมตีทางเทคนิคที่ซับซ้อนมากขึ้น

Microsoft 365 ถูกโจมตีด้วย Vishing ได้อย่างไร?

รูปแบบการโจมตีสามารถอธิบายเป็นลำดับได้ดังนี้

1. ผู้โจมตีเลือกเป้าหมาย

ผู้โจมตีอาจเลือกบุคลากรที่มีสิทธิ์เข้าถึงข้อมูลสำคัญ เช่น

• ผู้บริหาร

• Director

• Vice President

• IT Administrator

• Finance

• Legal

• ผู้ที่มีสิทธิ์เข้าถึง SharePoint หรือ Cloud Storage

กรณี PREY-0058 มีการมุ่งเป้าไปยังบุคลากรระดับ Director, Vice President และผู้บริหารในหลายอุตสาหกรรม

เหตุผลสำคัญคือบัญชีของบุคคลเหล่านี้อาจมีสิทธิ์เข้าถึงข้อมูลที่มีมูลค่าสูง

2. ปลอมเป็น IT Help Desk

ขั้นตอนต่อมาคือการโทรหาเหยื่อและสร้างความน่าเชื่อถือ

ผู้โจมตีอาจรู้ข้อมูลเบื้องต้นเกี่ยวกับองค์กรหรือบุคคลเป้าหมาย ทำให้บทสนทนาดูสมจริงมากขึ้น

ตัวอย่างเช่น

“สวัสดีครับ ติดต่อจาก IT ครับ เราพบว่าบัญชี Microsoft 365 ของคุณมีการ Login ที่ผิดปกติ”

จากนั้นอาจแจ้งว่าต้องดำเนินการแก้ไขปัญหาทันที

สิ่งสำคัญคือผู้โจมตีไม่ได้พยายามทำให้เหยื่อ “เชื่อว่าเป็นเว็บไซต์ Microsoft”

แต่พยายามทำให้เหยื่อ เชื่อว่าคนที่กำลังโทรหาเป็นเจ้าหน้าที่ IT จริง

เมื่อเหยื่อเชื่อแล้ว การทำตามคำแนะนำถัดไปก็มีโอกาสสูงขึ้น

3. ส่งลิงก์สำหรับ Authentication

หลังจากสร้างความน่าเชื่อถือแล้ว ผู้โจมตีอาจส่ง URL ให้เหยื่อเปิด

จากข้อมูลของ Arctic Wolf พบโครงสร้างของเว็บไซต์หลอกลวงที่ใช้ชื่อเกี่ยวข้องกับ Authentication และ MFA เช่นเว็บไซต์ที่มีคำว่า passkey, mfa, sso หรือ register เพื่อทำให้เหยื่อเชื่อว่าเป็นกระบวนการด้านความปลอดภัยขององค์กร

ตัวอย่างเช่น

“เดี๋ยวผมส่ง Link สำหรับลงทะเบียน MFA ให้ครับ รบกวนเปิดแล้วทำตามขั้นตอน”

เมื่อเหยื่อเปิดเว็บไซต์ดังกล่าว การโจมตีจะเข้าสู่ขั้นตอนสำคัญ

4. ใช้ Adversary-in-the-Middle หรือ AitM

Adversary-in-the-Middle (AitM) คือเทคนิคที่ผู้โจมตีแทรกตัวอยู่ระหว่างผู้ใช้งานกับระบบที่ผู้ใช้งานกำลังพยายามเข้าสู่

ในกรณี Microsoft 365 ผู้โจมตีอาจสร้าง Authentication Flow ที่เลียนแบบกระบวนการ Login จริง เพื่อให้เหยื่อป้อน Credential และดำเนินการ MFA

จุดสำคัญคือผู้โจมตีไม่ได้จำเป็นต้อง “ปิด MFA”

แต่ใช้วิธี

หลอกให้เหยื่อทำ MFA ให้สำเร็จ แล้วขโมย Session ที่ได้รับการยืนยันแล้ว

นี่เป็นเหตุผลว่าทำไมการมี MFA เพียงอย่างเดียวจึงไม่สามารถรับประกันได้ว่า Account จะปลอดภัยจากทุกประเภทของ Phishing

5. ขโมย Session Token

หลังจาก Authentication สำเร็จ ผู้โจมตีอาจพยายามขโมย Session Token

Session Token เปรียบเสมือนหลักฐานว่าผู้ใช้งานได้ผ่านกระบวนการ Authentication แล้ว

หากผู้โจมตีสามารถนำ Token ดังกล่าวไปใช้ในสภาพแวดล้อมที่ยอมรับ Token นั้นได้ ก็อาจสามารถเข้าถึงบริการบางอย่างในฐานะผู้ใช้งานที่ถูกโจมตี

ดังนั้นการโจมตีจึงไม่ได้จบที่

Username + Password

แต่สามารถพัฒนาไปสู่

Identity → Authentication → Session → Cloud Data

ได้

6. ใช้ Residential Proxy เพื่อทำให้การ Login ดูสมจริง

อีกเทคนิคหนึ่งที่ทำให้การโจมตีตรวจจับได้ยากขึ้นคือการใช้ Residential Proxy

แทนที่จะให้การเชื่อมต่อมาจาก IP ของ Data Center ที่อาจดูผิดปกติ ผู้โจมตีสามารถใช้ IP ที่มีลักษณะใกล้เคียงกับการใช้งานอินเทอร์เน็ตทั่วไป

ในกรณี PREY-0058 มีการพบการ Replay Session จาก Proxy Infrastructure และบางกิจกรรมมีลักษณะสอดคล้องกับตำแหน่งทางภูมิศาสตร์และ ASN ของเหยื่อ

นี่ทำให้การตรวจจับโดยดูเพียงว่า

“Login มาจากประเทศไหน?”

อาจไม่เพียงพอ

7. จาก Account Takeover สู่การขโมยข้อมูล

เมื่อผู้โจมตีสามารถเข้าถึง Account ได้แล้ว เป้าหมายต่อไปอาจไม่ใช่การยึด Account เพียงอย่างเดียว

แต่คือ ข้อมูล

ในกรณีที่ถูกเปิดเผย ผู้โจมตีมีการสำรวจและเก็บข้อมูลจากบริการ เช่น

• SharePoint

• OneDrive

• Exchange

• Box

• Microsoft 365 และ SaaS อื่น ๆ

ก่อนนำข้อมูลออกจากระบบเพื่อใช้ในการข่มขู่หรือเรียกค่าไถ่

นี่ทำให้การโจมตีมีลักษณะเป็น

Vishing → Identity Compromise → Session Theft → Cloud Discovery → Data Exfiltration → Extortion

ทำไมการโจมตีรูปแบบนี้จึงน่ากังวล?

1. ไม่มี Malware ก็สามารถเกิดเหตุได้

หนึ่งในประเด็นที่น่าสนใจของ PREY-0058 คือไม่พบการติดตั้ง Endpoint Malware หรือ Network-based Lateral Movement ในรูปแบบที่คุ้นเคย

หมายความว่าองค์กรอาจมี Endpoint Security ที่ดี แต่ยังสามารถถูกโจมตีผ่าน Identity และ Cloud ได้

2. MFA ไม่ได้หมายความว่า Phishing จะเป็นไปไม่ได้

MFA ยังคงเป็นมาตรการสำคัญในการรักษาความปลอดภัย Account

แต่ MFA บางรูปแบบสามารถถูกโจมตีผ่าน Social Engineering และ AitM ได้

ดังนั้นองค์กรควรพิจารณา Phishing-Resistant MFA สำหรับ Account ที่มีความสำคัญสูง

3. ผู้โจมตีไม่จำเป็นต้องขโมย Password โดยตรง

ผู้โจมตีอาจไม่ได้ต้องการ Password เพียงอย่างเดียว

แต่ต้องการสิ่งที่สามารถนำไปใช้ต่อเพื่อเข้าถึง Session หรือ Cloud Resource ได้

จึงทำให้การป้องกันต้องขยายจาก

Password Security

ไปสู่

Identity & Session Security

องค์กรควรป้องกัน Microsoft 365 จาก Vishing อย่างไร?

การป้องกันควรทำเป็นหลายชั้น ไม่ใช่พึ่งพาเทคโนโลยีเพียงตัวเดียว

1. ใช้ Phishing-Resistant MFA

สำหรับผู้บริหาร ผู้ดูแลระบบ และ Account ที่มี Privilege สูง ควรพิจารณา Authentication ที่ออกแบบมาเพื่อต้าน Phishing

เป้าหมายคือทำให้ผู้โจมตีไม่สามารถนำ Authentication ที่เหยื่อทำสำเร็จไปใช้ต่อผ่าน Phishing Proxy ได้ง่าย

2. ใช้ Conditional Access

องค์กรควรกำหนด Policy สำหรับควบคุมว่า

ใครสามารถเข้าถึงอะไร จากอุปกรณ์ใด และภายใต้เงื่อนไขใด

ตัวอย่างปัจจัยที่ควรพิจารณา ได้แก่

• User Risk

• Sign-in Risk

• Device Compliance

• Location

• Application

• Authentication Strength

Conditional Access จึงเป็นอีกหนึ่งชั้นสำคัญในการลดความเสี่ยงของ Account Compromise

3. ตรวจจับ Session Token Anomaly

Security Team ไม่ควรตรวจสอบเฉพาะ Failed Login

แต่ควรให้ความสำคัญกับ พฤติกรรมหลัง Login สำเร็จ

เช่น

• Session ถูกใช้งานจาก Network ที่ผิดปกติ

• Token Replay

• Residential Proxy Activity

• Login Pattern ที่เปลี่ยนแปลง

• การเข้าถึงข้อมูลจำนวนมากอย่างรวดเร็ว

กรณี PREY-0058 นักวิจัยแนะนำให้ตรวจจับพฤติกรรมอย่าง anomalous residential-proxy token replay รวมถึง SharePoint Discovery และ Bulk Access

4. จำกัดสิทธิ์การเข้าถึง SharePoint และ OneDrive

หาก Account ใด Account หนึ่งถูกยึด การจำกัดสิทธิ์สามารถช่วยลดผลกระทบได้

องค์กรควรทบทวนว่า

พนักงานแต่ละคนจำเป็นต้องเข้าถึงข้อมูลทั้งหมดที่สามารถเข้าถึงได้จริงหรือไม่?

แนวทางสำคัญ ได้แก่

• Least Privilege

• Role-Based Access Control

• จำกัดสิทธิ์ SharePoint

• ตรวจสอบ External Sharing

• แยกข้อมูลสำคัญตามระดับความอ่อนไหว

• ตรวจสอบ Guest Access

ยิ่ง Account มีสิทธิ์เข้าถึงข้อมูลมากเท่าไร ผลกระทบจาก Account Takeover ก็อาจสูงขึ้นเท่านั้น

5. ฝึกพนักงานให้รับมือ Vishing

Security Awareness ไม่ควรสอนเฉพาะเรื่อง

“อย่าคลิกลิงก์ Phishing”

เพราะ Vishing อาจเริ่มจากโทรศัพท์ก่อน

พนักงานควรรู้ว่า IT Help Desk ที่แท้จริงไม่ควรขอให้ผู้ใช้งาน

• บอก Password

• เปิดเผย MFA Code

• อนุมัติ MFA ที่ไม่ได้เป็นผู้เริ่มต้น

• ติดตั้งโปรแกรมที่ไม่ทราบแหล่งที่มา

• เปิด Link ที่ไม่สามารถตรวจสอบได้

• ปิดระบบรักษาความปลอดภัยเพื่อแก้ปัญหา

และควรมีขั้นตอนสำหรับ Verify ตัวตนของผู้โทรกลับไปยัง IT ผ่านช่องทางที่องค์กรกำหนด

6. สร้างกระบวนการ Help Desk ที่ปลอดภัย

องค์กรควรมองอีกมุมหนึ่งว่า

Help Desk เองอาจถูกใช้เป็นเครื่องมือของ Social Engineering

จึงควรมีขั้นตอนยืนยันตัวตนสำหรับคำขอสำคัญ เช่น

• Reset Password

• Reset MFA

• เพิ่ม Authentication Method

• เปลี่ยน Recovery Information

• เปลี่ยนสิทธิ์ Account

• เพิ่ม Device ใหม่

โดยเฉพาะ Account ของผู้บริหารและ Privileged User

7. Monitor Microsoft 365 และ Cloud อย่างต่อเนื่อง

การป้องกัน Cloud ไม่ควรหยุดที่การตั้งค่า Security Policy

องค์กรควรมี Visibility และ Monitoring ที่สามารถตรวจจับพฤติกรรมผิดปกติ เช่น

Identity

• Suspicious Sign-in

• Impossible Travel

• Token Anomaly

• Authentication Changes

Cloud

• SharePoint Discovery

• Bulk File Access

• Bulk Download

• OneDrive Activity

• Mailbox Access

Account

• เพิ่ม MFA Method ใหม่

• เพิ่ม Device ใหม่

• เปลี่ยนสิทธิ์

• OAuth/Application Consent ที่ผิดปกติ

ข้อมูลเหล่านี้ช่วยให้ Security Team มองเห็นสิ่งที่เกิดขึ้น หลังจากผู้โจมตีผ่าน Authentication แล้ว

MFA อย่างเดียวอาจไม่เพียงพออีกต่อไป

กรณีการโจมตี Microsoft 365 ผ่าน Vishing สะท้อนให้เห็นการเปลี่ยนแปลงที่สำคัญของ Cybersecurity

ในอดีต เราอาจตั้งคำถามว่า

“องค์กรมี MFA หรือยัง?”

แต่ในปัจจุบันคำถามควรขยับไปอีกระดับ

“MFA ขององค์กรสามารถต้าน Phishing ได้หรือไม่?”

และ

“ถ้า Account ถูกยึด Security Team จะตรวจพบพฤติกรรมผิดปกติได้เร็วแค่ไหน?”

เพราะผู้โจมตีไม่ได้จำเป็นต้องทำลายระบบหรือเจาะ Firewall เสมอไป

บางครั้งพวกเขาเพียงแค่

หลอกให้คนที่มีสิทธิ์ เปิดประตูให้

Cybersecurity ต้องมอง Beyond the Endpoint

การโจมตีรูปแบบนี้เป็นตัวอย่างที่ชัดเจนว่า Cybersecurity ในยุค Cloud ไม่สามารถมองเฉพาะ Endpoint ได้อีกต่อไป

องค์กรควรมี Visibility อย่างน้อย 4 ส่วน

1. User

รู้ว่าผู้ใช้งานกำลังทำอะไร

2. Identity

รู้ว่าใครกำลังเข้าถึงระบบ

3. Cloud

รู้ว่าบัญชีดังกล่าวกำลังเข้าถึงข้อมูลอะไร

4. Behavior

รู้ว่าพฤติกรรมนั้นสอดคล้องกับพฤติกรรมปกติหรือไม่

เมื่อทั้ง 4 ส่วนถูกนำมาวิเคราะห์ร่วมกัน Security Team จะสามารถมองเห็นความผิดปกติได้มากกว่าการตรวจสอบ Login เพียงอย่างเดียว

Checklist: Microsoft 365 ควรตรวจสอบอะไรบ้าง?

องค์กรสามารถใช้ Checklist นี้เป็นจุดเริ่มต้นในการประเมินความพร้อม

☐ มี Phishing-Resistant MFA สำหรับ Privileged และ Executive Accounts

☐ มี Conditional Access Policy

☐ มีการตรวจสอบ Sign-in Risk และ User Risk

☐ มีการ Monitor Session และ Token Activity

☐ ตรวจสอบ Authentication Method ที่ถูกเพิ่มใหม่

☐ จำกัดสิทธิ์ SharePoint และ OneDrive ตาม Least Privilege

☐ Monitor Bulk Download และ Data Access

☐ มีการฝึกอบรม Vishing และ Social Engineering

☐ มีขั้นตอน Verify IT Help Desk

☐ มี Monitoring สำหรับ Microsoft 365 และ Cloud

☐ มี Incident Response Plan สำหรับ Account Takeover

☐ สามารถตรวจจับและตอบสนองต่อ Cloud Account Compromise ได้อย่างรวดเร็ว

สรุป

Vishing ไม่ใช่เพียงการโทรหลอกให้เปิดเผยข้อมูลอีกต่อไป

แต่สามารถเป็นจุดเริ่มต้นของการโจมตีที่ซับซ้อน ตั้งแต่ Social Engineering ไปจนถึง AitM, Session Token Theft, Cloud Discovery และ Data Exfiltration

กรณี PREY-0058 แสดงให้เห็นว่าผู้โจมตีสามารถใช้การปลอมตัวเป็น IT Help Desk เพื่อหลอกเป้าหมาย ก่อนใช้ AitM และ Session Token เพื่อเข้าถึง Microsoft 365 และข้อมูลบน Cloud โดยไม่จำเป็นต้องติดตั้ง Malware บน Endpoint

ดังนั้นองค์กรจึงไม่ควรมอง Microsoft 365 Security เป็นเพียงเรื่องของ Password และ MFA

แต่ควรสร้างแนวทางป้องกันแบบหลายชั้นที่ครอบคลุม

People + Identity + Cloud + Data + Detection & Response

เพราะในยุคที่ข้อมูลสำคัญขององค์กรอยู่บน Cloud

“การปกป้อง Identity ก็คือการปกป้องข้อมูลขององค์กร”

และคำถามที่องค์กรควรถามวันนี้ไม่ใช่เพียง

“เราจะป้องกันไม่ให้คนร้ายเข้ามาได้อย่างไร?”

แต่คือ

“ถ้าคนร้ายเข้ามาได้แล้ว เราจะรู้ได้เร็วแค่ไหน และหยุดเขาได้อย่างไร?”