เปิด 5 เทคนิคที่แฮกเกอร์ใช้ “ข้าม 2FA” — ทำไมเปิดยืนยันตัวตนสองชั้นแล้ว ยังถูกยึดบัญชีได้?

หลายคนเข้าใจว่า เมื่อเปิดใช้งาน Two-Factor Authentication (2FA) หรือ Multi-Factor Authentication (MFA) แล้ว บัญชีจะปลอดภัยจากการถูกแฮกอย่างสมบูรณ์

ความจริงคือ 2FA ยังคงเป็นมาตรการรักษาความปลอดภัยที่สำคัญมาก เพราะช่วยลดความเสี่ยงจาก Password รั่ว การเดารหัสผ่าน และ Credential Stuffing ได้อย่างมีนัยสำคัญ แต่ 2FA ไม่ได้ทำให้บัญชีปลอดภัย 100%

ผู้โจมตีสมัยใหม่มักไม่ได้พยายาม “ถอดรหัส 2FA” โดยตรง แต่เปลี่ยนเป้าหมายไปโจมตีส่วนอื่นของกระบวนการพิสูจน์ตัวตน ได้แก่

• หลอกให้ผู้ใช้อนุมัติคำขอ MFA
• ดักข้อมูลระหว่างการเข้าสู่ระบบ
• ยึดหมายเลขโทรศัพท์ที่ใช้รับ OTP
• ขโมย Session Cookie หรือ Authentication Token หลังผู้ใช้ผ่าน MFA แล้ว
• ฝัง Malware บนอุปกรณ์เพื่อขโมยข้อมูลจาก Browser

ดังนั้น คำว่า “ข้าม 2FA” ในทางปฏิบัติไม่ได้หมายถึงการเจาะอัลกอริทึมของ 2FA เสมอไป แต่อาจหมายถึงการหลอกให้ 2FA ทำงานแทนผู้โจมตี หรือขโมย Session ที่ผ่านการยืนยันตัวตนเรียบร้อยแล้ว

Microsoft เคยวิเคราะห์แคมเปญ Adversary-in-the-Middle (AiTM) Phishing ที่ขโมยทั้งรหัสผ่านและ Session Cookie ก่อนนำ Session ไปใช้เข้าถึงบัญชี แม้บัญชีเป้าหมายจะเปิด MFA อยู่ก็ตาม (Microsoft Security)

1. ขโมย Session Cookie — ไม่ต้องรู้ Password หรือ OTP ก็อาจเข้าบัญชีได้

เมื่อผู้ใช้กรอก Username, Password และผ่าน MFA สำเร็จ เว็บไซต์มักออก Session Cookie หรือ Authentication Token เพื่อยืนยันว่า

“ผู้ใช้นี้ผ่านกระบวนการพิสูจน์ตัวตนแล้ว”

ระบบจึงไม่จำเป็นต้องถาม Password และ OTP ใหม่ทุกครั้งที่ผู้ใช้เปิดหน้าเว็บหรือเรียกใช้บริการใน Session เดิม

หากผู้โจมตีขโมย Cookie หรือ Token ที่ยังใช้งานได้สำเร็จ ผู้โจมตีอาจนำข้อมูลดังกล่าวไปสวมรอยเป็น Session ของผู้ใช้ โดยไม่ต้องย้อนกลับไปผ่านขั้นตอน Login และ MFA ใหม่ทั้งหมด

MITRE ATT&CK จัดพฤติกรรมนี้เป็นเทคนิค T1539: Steal Web Session Cookie และอธิบายว่า Cookie ที่ถูกขโมยสามารถใช้เข้าถึง Web Application ในฐานะผู้ใช้ที่ผ่านการยืนยันตัวตนแล้ว โดยไม่จำเป็นต้องมี Credential เดิม (MITRE ATT&CK)

ผู้โจมตีขโมย Session ได้อย่างไร

• ใช้ AiTM Phishing ดัก Cookie ระหว่างการ Login
• ใช้ Infostealer ขโมย Cookie จาก Browser
• เข้าถึงเครื่องหรือ Browser Profile ของผู้ใช้
• ขโมย Token จาก Memory, Disk หรือ Application ที่จัดเก็บข้อมูลไม่ปลอดภัย
• ใช้ Extension หรือ Software อันตรายอ่านข้อมูลใน Browser

ประเด็นสำคัญ: Password ที่แข็งแรงและการเปิด 2FA อาจยังไม่เพียงพอ หาก Endpoint, Browser หรือ Session ถูกยึดไปแล้ว

2. MFA Fatigue หรือ Push Bombing — ส่งคำขอซ้ำจนผู้ใช้เผลอกดอนุมัติ

บัญชีบางประเภทใช้ Push Notification เป็นปัจจัยยืนยันตัวตน เช่น เมื่อมีการ Login ระบบจะส่งข้อความไปยังโทรศัพท์เพื่อให้ผู้ใช้กด Approve หรือ Deny

ผู้โจมตีที่มี Username และ Password แล้ว อาจพยายาม Login ซ้ำ ๆ เพื่อสร้างคำขอ MFA จำนวนมาก กระทั่งผู้ใช้

• กดอนุมัติโดยไม่ทันอ่าน
• เข้าใจผิดว่าเป็นความผิดพลาดของระบบ
• กดเพื่อหยุดการแจ้งเตือนที่รบกวน
• ถูกผู้โจมตีโทรศัพท์หรือส่งข้อความปลอมเป็นฝ่าย IT แล้วโน้มน้าวให้กดอนุมัติ

MITRE ATT&CK เรียกเทคนิคนี้ว่า T1621: Multi-Factor Authentication Request Generation และระบุกรณีที่กลุ่มภัยคุกคามใช้ MFA Fatigue หรือส่งคำขอซ้ำเพื่อหวังให้เหยื่ออนุมัติ (MITRE ATT&CK)

วิธีลดความเสี่ยง

• ห้ามกดอนุมัติคำขอที่ตนเองไม่ได้เป็นผู้เริ่ม Login
• ใช้ Number Matching แทนการกด Approve เพียงปุ่มเดียว
• จำกัดจำนวนและความถี่ของ MFA Request
• แจ้งเตือน SOC เมื่อพบ MFA Denial หรือ Push จำนวนผิดปกติ
• ใช้ Phishing-resistant MFA สำหรับบัญชีสำคัญและบัญชีผู้ดูแลระบบ

3. AiTM Phishing — หน้า Login ปลอมที่ดักทั้ง Password, MFA และ Session

Adversary-in-the-Middle (AiTM) Phishing อันตรายกว่าหน้า Phishing แบบเก่าที่สร้างแบบฟอร์มปลอมเพื่อเก็บ Password เพียงอย่างเดียว เพราะระบบของผู้โจมตีทำหน้าที่เป็นตัวกลางระหว่างเหยื่อกับบริการจริง

กระบวนการโดยทั่วไปมีลักษณะดังนี้

1. ผู้ใช้เปิดลิงก์ Phishing และพบหน้า Login ที่คล้ายของจริง
2. ผู้ใช้กรอก Username และ Password
3. ระบบของผู้โจมตีส่งข้อมูลต่อไปยังบริการจริงแบบทันที
4. เมื่อบริการจริงร้องขอ MFA หน้า Phishing ก็ส่งขั้นตอนนั้นกลับมาให้ผู้ใช้ดำเนินการ
5. หลัง Authentication สำเร็จ ผู้โจมตีดัก Session Cookie หรือ Token ที่ระบบจริงออกให้
6. ผู้โจมตีนำ Session ไปใช้สวมรอยเป็นผู้ใช้

Microsoft ระบุว่า AiTM สามารถดัก Credential และ MFA เพื่อให้ได้ Session Cookie จากกระบวนการ Login ที่สำเร็จ (Microsoft Security)

ในเชิงเทคนิค ผู้โจมตีไม่ได้ทำให้ MFA “หายไป” ในขั้นแรก แต่ หลอกให้เหยื่อผ่าน MFA บนเส้นทางที่ผู้โจมตีควบคุม แล้วขโมยผลลัพธ์ของการยืนยันตัวตนนั้นไปใช้ต่อ

นี่คือเหตุผลว่า การมี OTP หรือ Push MFA ไม่ได้แปลว่า Phishing จะไม่สำเร็จ เพราะรหัสหรือการอนุมัติยังสามารถถูกส่งผ่านหน้าเว็บตัวกลางได้

วิธีลดความเสี่ยง

• ตรวจสอบ Domain ก่อนกรอก Credential
• หลีกเลี่ยงการ Login ผ่านลิงก์ในอีเมลหรือข้อความที่ไม่คาดคิด
• ใช้ Password Manager เพราะระบบมักไม่กรอกรหัสให้บน Domain ปลอม
• ใช้ FIDO2/WebAuthn, Security Key หรือ Passkey ที่ผูกกับ Domain
• ใช้ Conditional Access, Device Compliance และ Risk-based Authentication
• ตรวจจับ Token Reuse, Session Anomaly และ Sign-in จากอุปกรณ์หรือเครือข่ายผิดปกติ

4. SIM Swapping — ยึดเบอร์โทรเพื่อรับ SMS OTP

สำหรับบัญชีที่ใช้ SMS OTP เป็นปัจจัยที่สอง ผู้โจมตีอาจใช้วิธี SIM Swapping หรือ SIM Hijacking เพื่อทำให้หมายเลขโทรศัพท์ของเหยื่อถูกย้ายไปยัง SIM หรือ eSIM ที่ผู้โจมตีควบคุม

การโจมตีอาจอาศัย

• Social Engineering กับผู้ให้บริการโทรศัพท์
• ข้อมูลส่วนบุคคลที่รั่วไหลเพื่อผ่านการตรวจสอบตัวตน
• การปลอมเอกสารหรือสวมรอยเจ้าของหมายเลข
• การละเมิดบัญชีหรือระบบที่เกี่ยวข้องกับการจัดการ SIM

หากสำเร็จ สายโทรศัพท์ ข้อความ และ OTP บางประเภทที่ส่งมายังหมายเลขดังกล่าวอาจตกไปอยู่กับผู้โจมตี

CISA ระบุว่า MFA ที่ใช้ SMS หรือ Voice มีความเสี่ยงจาก SIM Swap และช่องโหว่ในระบบสื่อสาร ขณะที่ MFA แบบ FIDO/WebAuthn มีคุณสมบัติต้านทาน Phishing และไม่พึ่งพาการรับรหัสผ่านเครือข่ายโทรศัพท์ (CISA: Implementing Phishing-Resistant MFA)

วิธีลดความเสี่ยง

• เปลี่ยนจาก SMS OTP ไปใช้ Authenticator, Passkey หรือ Security Key เมื่อทำได้
• ตั้ง PIN หรือมาตรการป้องกันการย้าย SIM กับผู้ให้บริการ
• หลีกเลี่ยงการใช้หมายเลขโทรศัพท์เป็นช่องทางกู้คืนบัญชีเพียงช่องทางเดียว
• หากโทรศัพท์สูญเสียสัญญาณผิดปกติ ให้ติดต่อผู้ให้บริการทันที
• ปกป้องอีเมลหลักและข้อมูลส่วนบุคคลที่ใช้ในกระบวนการ Account Recovery

5. Infostealer Malware — ขโมยข้อมูลหลังจากผู้ใช้ผ่าน 2FA แล้ว

Information-Stealing Malware หรือ Infostealer ไม่จำเป็นต้องเดา OTP แต่สามารถมุ่งเป้าไปยังข้อมูลบน Endpoint หลังผู้ใช้ผ่าน Authentication แล้ว เช่น

• Browser Cookies และ Session Tokens
• Username และ Password ที่ Browser จัดเก็บไว้
• Autofill Data
• SSO และ Authentication Tokens
• Credential ของ VPN, Email Client หรือ Application
• Crypto Wallet และข้อมูลสำคัญอื่น

Microsoft ระบุว่า Infostealer สามารถเก็บ Password, Cookie และ Session Token ก่อนส่งข้อมูลไปยังระบบของผู้โจมตี และ Session ที่ขโมยจากอุปกรณ์ส่วนตัวของพนักงานอาจนำไปสู่ความเสี่ยงต่อระบบองค์กรได้ (Microsoft Security)

ตัวอย่าง Lumma Stealer ที่ Microsoft วิเคราะห์ สามารถขโมย Password, Session Cookie และ Autofill Data จาก Browser หลายตระกูลได้ (Microsoft Security)

Infostealer มักถูกเผยแพร่ผ่าน

• โปรแกรมเถื่อนและ Software Crack
• โปรแกรมติดตั้งปลอมและ Fake Update
• ไฟล์แนบหรือลิงก์ Phishing
• โฆษณาหรือผลการค้นหาที่นำไปยังเว็บไซต์ปลอม
• Browser Extension ที่เป็นอันตราย
• เกม เครื่องมือ AI หรือ Utility ที่ดาวน์โหลดจากแหล่งไม่น่าเชื่อถือ

ดังนั้น หากอุปกรณ์ถูกยึดได้สำเร็จ การมี 2FA เพียงอย่างเดียวอาจไม่สามารถป้องกันการขโมย Session ที่ผ่านการ Authentication ไปแล้ว

แล้ว Cloud Sync ของ Authenticator อันตรายหรือไม่?

Authenticator บางประเภทสามารถ Sync รหัสยืนยันระหว่างอุปกรณ์ผ่าน Cloud Account เพื่อช่วยลดปัญหาเมื่อผู้ใช้เปลี่ยนหรือทำโทรศัพท์สูญหาย

Google ระบุว่า Verification Code ที่ Sync ผ่าน Google Authenticator ได้รับการเข้ารหัสทั้งระหว่างส่งข้อมูลและขณะจัดเก็บ ดังนั้น การกล่าวว่า “แฮก Google Account ได้เท่ากับได้รหัส 2FA ทุกบัญชีทันที” จึงเป็นข้อสรุปที่กว้างและไม่ควรนำเสนอเป็นข้อเท็จจริงโดยไม่มีเงื่อนไขเพิ่มเติม (Google Account Help)

อย่างไรก็ตาม บัญชีหลักที่ใช้ Sync Authenticator ยังคงเป็น บัญชีที่มีความสำคัญสูง และควรได้รับการป้องกันอย่างเข้มงวด ได้แก่

• ใช้ Password ที่ยาวและไม่ซ้ำกับบริการอื่น
• ใช้ Passkey หรือ Security Key กับบัญชีหลัก
• ตรวจสอบอุปกรณ์และ Session ที่ Login อยู่เป็นประจำ
• ปกป้องช่องทาง Account Recovery
• เก็บ Backup Code ในพื้นที่ปลอดภัยและไม่เก็บร่วมกับ Password

Cloud Sync จึงควรถูกมองเป็น ความเสี่ยงจากการรวมศูนย์บัญชีสำคัญที่ต้องบริหารจัดการ มากกว่าจะเรียกว่าเป็นหนึ่งในเทคนิคข้าม 2FA โดยตรง

เปรียบเทียบความเสี่ยงของ 2FA แต่ละประเภท

วิธี Authentication	ความเสี่ยงหลัก	ระดับการต้านทาน Phishing โดยทั่วไป
SMS/Voice OTP	SIM Swap, SS7, Phishing, Social Engineering	ต่ำ
Email OTP	Email Account ถูกยึด, Phishing	ต่ำ
TOTP Authenticator	AiTM Phishing, Malware, Recovery Risk	ปานกลาง แต่ยังถูก Phishing ได้
Push Notification	MFA Fatigue, Push Bombing, Social Engineering	ปานกลาง; ดีขึ้นเมื่อมี Number Matching
Passkey / FIDO2 / WebAuthn	Device หรือ Recovery Process ถูกยึด	สูง และออกแบบให้ต้านทาน Phishing
Hardware Security Key	อุปกรณ์สูญหาย, Recovery Process, Physical Access	สูงมากเมื่อกำหนดค่าอย่างเหมาะสม

ตารางนี้เป็นการเปรียบเทียบเชิงหลักการ ระดับความปลอดภัยจริงขึ้นอยู่กับการติดตั้ง นโยบาย Account Recovery การจัดการอุปกรณ์ และวิธีสำรองที่ระบบยังอนุญาตให้ใช้ด้วย

วิธีป้องกันสำหรับผู้ใช้งานทั่วไป

สำหรับบัญชีสำคัญ เช่น Email, Cloud, Banking, Social Media และบัญชีที่ใช้กู้คืนบริการอื่น ควรดำเนินการดังนี้

1. เปิด 2FA ต่อไป เพราะยังปลอดภัยกว่าการใช้ Password เพียงอย่างเดียวอย่างมาก
2. เลือกวิธีที่แข็งแรงที่สุดที่บริการรองรับ โดยให้ความสำคัญกับ Passkey หรือ Security Key
3. ไม่กดอนุมัติ MFA ที่ตนเองไม่ได้ร้องขอ และรายงานเหตุผิดปกติทันที
4. ตรวจสอบ URL และ Domain ก่อน Login โดยเฉพาะลิงก์จากอีเมล ข้อความ และโฆษณา
5. อัปเดต OS, Browser และ Application ให้เป็นเวอร์ชันที่ได้รับการสนับสนุน
6. หลีกเลี่ยงโปรแกรมเถื่อน Software Crack และไฟล์จากแหล่งไม่น่าเชื่อถือ
7. ตรวจสอบ Active Session และอุปกรณ์ที่ Login อยู่ พร้อม Logout หรือ Revoke รายการที่ไม่รู้จัก
8. ปกป้อง Account Recovery เพราะช่องทางสำรองที่อ่อนแออาจลดทอนความแข็งแรงของ MFA หลัก

FIDO Alliance อธิบายว่า Passkey ใช้ Public-key Cryptography และผูก Credential เข้ากับ Domain ของบริการ จึงช่วยต้านทานเว็บไซต์ Phishing ที่ใช้ Domain อื่นได้ (FIDO Alliance)

แนวทางสำหรับองค์กร: ปกป้องมากกว่า Password และ MFA

องค์กรควรใช้แนวคิด Identity, Device, Authentication และ Session Security ร่วมกัน ไม่ควรถือว่าการบังคับใช้ MFA เพียงข้อเดียวเพียงพอแล้ว

Identity & Access Control

• บังคับใช้ Phishing-resistant MFA กับผู้ดูแลระบบ ผู้บริหาร และบัญชีความเสี่ยงสูง
• ปิด Legacy Authentication และวิธี Login ที่อ่อนแอเมื่อไม่จำเป็น
• ใช้ Conditional Access และ Risk-based Authentication
• จำกัดสิทธิ์ตามหลัก Least Privilege
• แยกบัญชี Administrator ออกจากบัญชีใช้งานทั่วไป

Session & Token Protection

• กำหนด Session Lifetime ตามระดับความเสี่ยง
• ใช้ Continuous Access Evaluation หรือกลไกประเมินความเสี่ยงระหว่าง Session เมื่อระบบรองรับ
• ตรวจจับ Token Reuse จาก IP, Device หรือ Location ที่ผิดปกติ
• Revoke Session และ Refresh Token เมื่อสงสัยว่าบัญชีถูกบุกรุก
• พิจารณา Device-bound Token หรือ Token Protection เมื่อเทคโนโลยีรองรับ

Endpoint Security

• ใช้ Endpoint Protection หรือ EDR
• ตรวจจับการอ่าน Cookie Store, Browser Process Memory และ Credential Store ที่ผิดปกติ
• ควบคุม Browser Extension และ Software Installation
• แยกการใช้งานบัญชีองค์กรออกจากอุปกรณ์ส่วนตัวที่ไม่ได้รับการจัดการ
• บังคับใช้ Patch Management และ Device Compliance

Monitoring & Incident Response

• ตรวจจับ Impossible Travel และ Sign-in Anomaly
• ตรวจจับ MFA Fatigue, MFA Denial และคำขอ Push จำนวนผิดปกติ
• ตรวจจับ AiTM Phishing, Suspicious Inbox Rule และพฤติกรรม BEC
• ตรวจจับ Infostealer และ Credential จากอุปกรณ์ที่ติด Malware
• เก็บ Authentication, Application และ Endpoint Log ไว้ในระบบส่วนกลาง
• มี Playbook สำหรับ Account Takeover และ Token Theft โดยเฉพาะ

หากสงสัยว่าบัญชีถูกยึด ต้องทำอะไรทันที?

การเปลี่ยน Password เพียงอย่างเดียวอาจไม่เพียงพอ หากผู้โจมตียังถือ Session Cookie, Refresh Token หรือมี Malware อยู่บนเครื่อง

ควรดำเนินการตามลำดับดังนี้

1. ใช้อุปกรณ์ที่เชื่อถือได้เปลี่ยน Password
2. Logout หรือ Revoke ทุก Active Session
3. Revoke Token, App Password และสิทธิ์ของ Application ที่ไม่รู้จัก
4. ตรวจสอบและลบอุปกรณ์ วิธี MFA และ Recovery Method ที่ไม่ได้เป็นของตนเอง
5. ตรวจสอบ Email Forwarding, Inbox Rule และการเปลี่ยนแปลง Security Setting
6. สแกนและกักกันอุปกรณ์ที่สงสัยว่าติด Malware
7. แจ้งฝ่าย IT, SOC, ธนาคาร หรือผู้ให้บริการที่เกี่ยวข้องตามลักษณะบัญชี
8. ตรวจสอบกิจกรรมย้อนหลังและเปลี่ยน Credential ของบริการอื่นที่อาจได้รับผลกระทบ

บทสรุป

ประเด็นสำคัญไม่ใช่ว่า “2FA ไม่ปลอดภัย” แต่คือ 2FA ต้องเป็นส่วนหนึ่งของระบบป้องกันหลายชั้น

ผู้โจมตีพัฒนาเทคนิคจากการขโมย Password ไปสู่การโจมตีทั้งตัวผู้ใช้ อุปกรณ์ กระบวนการ Authentication และ Session หลังการ Login สำเร็จแล้ว

แนวคิดด้าน Cybersecurity จึงต้องเปลี่ยนจาก

Protect the Password

ไปสู่

Protect the Identity + Device + Authentication + Session

เพราะเมื่อ Password ได้รับการป้องกันด้วย MFA แล้ว Session และ Token ที่ผ่านการยืนยันตัวตนอาจกลายเป็นเป้าหมายที่มีค่ามากกว่า Password

แหล่งอ้างอิง

• Microsoft Security — From cookie theft to BEC: Attackers use AiTM phishing sites
• Microsoft Security — Detecting and mitigating a multi-stage AiTM phishing and BEC campaign
• MITRE ATT&CK — T1539: Steal Web Session Cookie
• MITRE ATT&CK — T1621: Multi-Factor Authentication Request Generation
• Microsoft Security — StealC and Amadey: Breaking down infostealers
• Microsoft Security — Lumma Stealer
• CISA — Implementing Phishing-Resistant MFA
• Google Account Help — Get verification codes with Google Authenticator
• FIDO Alliance — User Authentication Specifications

เกี่ยวกับผู้เขียน

อาจารย์ปรเมศร์ เพียรสกุล ผู้เชี่ยวชาญด้านความมั่นคงปลอดภัยไซเบอร์ (Cybersecurity) และปัญญาประดิษฐ์ (AI) ปัจจุบันดำรงตำแหน่งประธานเจ้าหน้าที่บริหาร (CEO) และผู้ก่อตั้ง บริษัท อินเทลลิเจนท์ ดาต้า อนาไลติค จำกัด

#Cybersecurity #2FA #MFA #Phishing #CyberSecurityAwareness