Lừa đảo qua điện thoại Okta: Vì sao MFA vẫn bị bẻ khóa dễ dàng?

[Duy Linh]

Các hacker đang chuyển từ lừa đảo email sang tấn công trực tiếp vào Okta và các nhà cung cấp định danh bằng kỹ thuật xã hội qua giọng nói, còn gọi là “lừa đảo qua điện thoại Okta” (vishing).

Xu hướng này biến các vụ chiếm quyền tài khoản riêng lẻ thành vi phạm dữ liệu đám mây trên diện rộng thông qua cơ chế Đăng nhập một lần (SSO).

Thay vì gửi link độc hại, kẻ tấn công giữ nạn nhân trên điện thoại và hướng dẫn từng bước để chuyển giao quyền kiểm soát tài khoản định danh.

Trong các cuộc gọi, chúng gây áp lực buộc nhân viên:

• Đặt lại xác thực đa yếu tố (MFA)
• Đăng ký thiết bị xác thực mới
• Cung cấp mã OTP
• Chấp nhận thông báo đẩy
• Chia sẻ mật khẩu hoặc thông tin phiên

Đây là hình thức giả mạo nhân viên CNTT hoặc người dùng hợp pháp nhằm thao túng MFA và cấu hình tài khoản Okta.

Sau khi chiếm quyền Okta, kẻ tấn công lập tức khai thác SSO để truy cập hàng loạt nền tảng như Microsoft 365, SharePoint, OneDrive, Google Workspace, Salesforce, Slack, VPN và hệ thống nhân sự mà không cần tấn công từng ứng dụng riêng lẻ.

Vì sao các cuộc tấn công này ngày càng gia tăng?​

Tin tặc nhận ra rằng MFA thường thất bại ở yếu tố con người, không phải công nghệ. Thay vì vượt qua lớp bảo mật kỹ thuật, chúng thuyết phục người dùng tự làm suy yếu hệ thống xác thực.

Một số yếu tố thúc đẩy xu hướng này:

• Áp lực xử lý nhanh yêu cầu hỗ trợ
• Môi trường làm việc từ xa khiến sự cố truy cập phổ biến
• Dễ dàng thu thập thông tin nhân viên, sơ đồ tổ chức từ LinkedIn, website doanh nghiệp và dữ liệu rò rỉ

Chuỗi tấn công lừa đảo qua điện thoại Okta (Nguồn: LevelBlue).
Chuỗi tấn công thường diễn ra theo các bước:

1. Thu thập thông tin: lấy tên, vai trò, số điện thoại, quy trình hỗ trợ từ nguồn mở và dữ liệu rò rỉ
2. Giả mạo cuộc gọi: đóng vai nhân viên bị khóa tài khoản, lãnh đạo đang công tác, nhà thầu hoặc người gặp sự cố thiết bị
3. Tạo áp lực khẩn cấp: thúc ép bỏ qua quy trình xác minh
4. Thao túng MFA: yêu cầu reset, thêm thiết bị, chia sẻ OTP hoặc phê duyệt truy cập
5. Chiếm quyền Okta: kiểm soát tài khoản định danh
6. Khai thác SSO: truy cập toàn bộ hệ thống SaaS
7. Đánh cắp dữ liệu: tải dữ liệu từ SharePoint, OneDrive, xuất email, tạo token API, đăng ký OAuth, thiết lập chuyển tiếp

Khi nhà cung cấp định danh trở thành trung tâm truy cập SaaS, việc xâm nhập Okta đồng nghĩa với xâm nhập toàn bộ môi trường đám mây.

Dấu hiệu nhận biết và biện pháp phòng chống​

Dấu hiệu cảnh báo cho đội DFIR​

Ở lớp xác thực danh tính:

• Đặt lại MFA bất thường
• Đăng ký thiết bị mới
• Thay đổi phương thức MFA kèm đăng nhập lạ
• Đăng nhập từ ASN không quen thuộc
• Yêu cầu hỗ trợ xuất hiện ngay trước hành vi đáng ngờ

Trong Microsoft 365 và SaaS:

• Tải dữ liệu SharePoint/OneDrive bất thường
• Đăng nhập từ IP mới trên nhiều ứng dụng
• Chấp thuận OAuth đột ngột
• Truy cập nhiều dịch vụ ngay sau khi thay đổi MFA

Cách phòng chống hiệu quả​

Doanh nghiệp cần tập trung bảo mật quy trình xác thực danh tính, không chỉ riêng email:

• Áp dụng quy trình xác minh nghiêm ngặt cho reset MFA và mật khẩu
• Yêu cầu kiểm tra bổ sung với thay đổi rủi ro cao
• Đào tạo đội hỗ trợ nhận diện vishing
• Triển khai MFA chống lừa đảo như FIDO2 hoặc passkey

Ngoài ra:

• Vô hiệu hóa phương thức xác thực cũ
• Hạn chế quyền cấp OAuth
• Kiểm tra định kỳ cấu hình MFA
• Đưa nhật ký IdP vào hệ thống SIEM để đối soát với dữ liệu SaaS, VPN và endpoint

Cuối cùng, SOC và MDR cần có kịch bản riêng cho tấn công dựa trên danh tính, cho phép:

• Thu hồi phiên truy cập nhanh
• Đặt lại thông tin đăng nhập
• Loại bỏ phương thức MFA giả mạo khi phát hiện dấu hiệu vishing liên quan đến Okta

Đọc chi tiết tại đây: gbhackers​

 

Được phối hợp thực hiện bởi các chuyên gia của Bkav, cộng đồng An ninh mạng Việt Nam WhiteHat và cộng đồng Khoa học công nghệ VnReview