ระวังแฮกเกอร์ใช้ระบบ OAuTH มาทำ Phishing หลอกปล่อยมัลแวร์ลงเครื่อง

Malwarebytes เตือน ระวังแฮกเกอร์ใช้ระบบ OAuTH มาทำ Phishing หลอกปล่อยมัลแวร์ลงเครื่อง

OAuTH หรือ Open Authorization อาจจะเป็นโปรโตคอล (Protocol) ที่ทำให้การใช้งานแอปพลิเคชันต่าง ๆ ที่ต้องเข้าถึงข้อมูลบนเครื่องมีความสะดวกโดยที่ไม่ต้องใช้งานรหัสผ่านใด ๆ เพียงแค่เลือกว่าจะอนุมัติ หรือไม่อนุมัติ แต่ระบบนี้ที่ดูเหมือนจะปลอดภัย ก็ได้ถูกแฮกเกอร์นำเอามาใช้งานเช่นเดียวกัน

จากรายงานโดยเว็บไซต์อย่างเป็นทางการของผู้พัฒนาเครื่องมือต่อต้านมัลแวร์ Malwarebyte ได้กล่าวถึงการที่ทางทีมวิจัยจากไมโครซอฟท์ได้ตรวจพบการที่แฮกเกอร์นำเอาระบบ OAuTh มาใช้ร่วมกับการหลอกลวงให้เหยื่อถูกหลอก Phishing หรือ ติดมัลแวร์ ด้วยการกลเม็ดอย่างการใช้ OAuth แบบเงียบเชียบ (Silent OAuth) เพื่อช่วยเปลี่ยนเป้าหมายในการเยี่ยมชมเว็บไซต์ (Redirect) พาเหยื่อเข้าสู่เว็บไซต์ที่เชื่อมโยงกับโครงสร้างพื้นฐาน (Infrastructure) ที่เกี่ยวข้องกับการก่ออาชญากรรมข้างต้นโดยที่เหยื่อไม่รู้ตัว ทำให้แฮกเกอร์ไม่ต้องขโมยโทเคน (Token) การใช้งานของเหยื่อแต่อย่างใด โดยขั้นตอนในการปฏิบัตินั้น จะประกอบด้วยองค์ประกอบหลายอย่าง ดั่งนี้

ขั้นแรกแฮกเกอร์จะส่งอีเมลหลอกลวงให้เหยื่อก่อน โดยอาจบอกว่ามาจากหน่วยงานรัฐ, ประกันสังคม, หน่วยงานด้านภาษี, หรือบริษัทต่าง ๆ ซึ่งจะมีลิงก์หลอกลวงพร้อมตัวหลอกว่าให้เปิดดูเอกสาร เช่น “View Document” หรือ “Review Report” หรืออาจเป็นไฟล์เอกสารแบบ PDF ที่แฝงลิงก์ไว้ภายในแทน

ต่อมาจะเป็นลิงก์ที่กล่าวถึงในข้อแรก ที่มักจะทำคล้ายลิงก์สำหรับล็อกอินใช้งานบริการของ Google หรือ ไมโครซอฟท์ โดยมักจะขึ้นต้นลิงก์คล้ายกับการเข้าหน้าล็อกอินทั่วไปของบริการทั้ง 2 เช่น https://login[.]microsoftonline[.]com/ or https://accounts[.]google[.]com/ ซึ่งในจุดนี้จะยังไม่มีสัญญาณว่าพารามิเตอร์ (Parameter) อย่าง prompt=none, odd หรือ empty scope, encoded state ที่ถูกใส่อยู่นั้นผิดสังเกตแต่อย่างใด

ทว่าในส่วนพารามิเตอร์ดังกล่าวของ URL นั้นจะมีการรวมกันระหว่างการทำ Silent OAuth (prompt=none) พร้อมพารามิเตอร์พิเศษที่จะทำให้ขั้นตอนดังกล่าวล้มเหลวอย่างแน่นอน (invalid หรือ missing scope) ซึ่งในจุดนี้จะทำให้ผู้ให้บริการ OAuth ต้องทำการตรวจสอบ Session ใหม่รวมถึงเงื่อนไขในการเข้าใช้งานของผู้ใช้งาน (Conditional Access) และตัวระบบจะคาดการณ์ว่าการทำ OAuth จะทำเงียบ ๆ แบบที่ร้องขอมาไม่ได้ แล้วทำการส่งแจ้งเตือนข้อผิดพลาดในการทำ OAuth กลับมายังผู้ใช้งาน เช่น interaction_required, access_denied, หรือ consent_required

ในจุดนี้ หลังจากการส่งข้อผิดพลาดกลับมาดังกล่าว ทำให้โดยการออกแบบของกลไกนี้ ตัวระบบจะเปลี่ยนเป้าหมายของการเยี่ยมชมเว็บไซต์บนเว็บเบราว์เซอร์ ไปยัง URI ที่ตัวแอปพลิเคชันที่เกี่ยวข้องกับ OAuth ทำการลงทะเบียนไว้ พร้อมกับสถานะ (State) และตัวพารามิเตอร์แสดงข้อผิดพลาด ซึ่งในกรณีนี้จะเป็นการพาเหยื่อไปยังโดเมนหลอกลวงของแฮกเกอร์แทน แต่เมื่อมองจากมุมของผู้ใช้งานจะเหมือนการเปลี่ยนหน้าเยี่ยมชมจาก Google หรือ ไมโครซอฟท์ ไปหน้าใหม่เฉย ๆ โดยไม่เห็นค่าสตริง (String) ที่แสดงข้อผิดพลาดแต่อย่างใด

สำหรับส่วนหน้าเป้าหมาย (Landing Page) ที่เหยื่อถูกพามานั้นจะเป็นเว็บไซต์ที่ทำเลียนแบบหน้าล็อกอินจริง ๆ หรือหน้าเว็บไซต์ของแบรนด์ธุรกิจชื่อดัง ซึ่งจุดนี้เหยื่ออาจจะพบได้ 2 รูปแบบ

รูปแบบแรกจะเป็นหน้าเพจที่เป็นการหลอกลวงแบบ Phishing หรือ เป็นหน้าตัวกลางหลอกเก็บข้อมูล (Attacker in the Middle หรือ AitM) ที่จะมาพร้อมกับหน้าล็อกอินที่ดูไม่มีอะไรผิดสังเกต ในบางหน้ายังมาพร้อมกับระบบตรวจสอบแบบ Captcha เพื่อความสมจริง ซึ่งถ้าเหยื่อป้อนรหัสผ่าน พร้อมกับรหัสยืนยันตัวตนหลายชั้น (Multi-Factors Authentication หรือ MFA) ลงไป เครื่องมือ AitM ก็จะทำการเก็บข้อมูลต่าง ๆ รวมถึงข้อมูลในไฟล์ Session Cookies ทันที

หน้าเพจสำหรับดาวน์โหลดมัลแวร์ โดยจะมีทั้งการดาวน์โหลดแบบอัตโนมัติ และแบบที่ล่อให้เหยื่อดาวน์โหลดลงเครื่องด้วยปุ่มต่าง ๆ บนหน้าเพจ เช่น “Download the secure document” หรือ “Meeting resources” เป็นต้น

ซึ่งผลลัพธ์จากการที่ตกเป็นเหยื่อการหลอกลวงในรูปแบบดังกล่าวนั้น จะทำให้แฮกเกอร์ที่อยู่เบื้องหลังได้รหัสในการใช้งานบัญชีต่าง ๆ ของเหยื่อไป หรือ อาจจะมาในรูปแบบของการฝังมัลแวร์แบบเปิดประตูหลังของระบบ (Backdoor) ได้ ดังนั้นเพื่อความปลอดภัย ผู้ใช้งานต้องหลีกเลี่ยงการคลิกลิงก์ใด ๆ ก่อนคลิกต้องตรวจสอบให้แน่ใจก่อนทุกครั้ง และถ้าคลิกไปแล้วพบสิ่งใดที่ผิดสังเกต ให้ปิดแท็บ หรือ เว็บเบราว์เซอร์ในทันที รวมทั้งหมั่นอัปเดตระบบปฏิบัติการ, เว็บเบราว์เซอร์ และเครื่องมือรักษาความปลอดภัยไซเบอร์ต่าง ๆ อย่างสม่ำเสมอ เพื่อช่วยป้องกันอีกชั้นหนึ่ง