Một nhóm tác nhân đe dọa đã triển khai một đợt chiến dịch phishing mới nhằm mục đích giả mạo các sự kiện an ninh quan trọng ở Châu Âu. Mục tiêu chính của chiến dịch tấn công mạng này là đánh cắp thông tin đăng nhập đám mây một cách tinh vi.

Các thư mời dường như hợp lệ, thường liên quan đến các hội nghị như Belgrade Security Conference hoặc Brussels Indo-Pacific Dialogue, hướng mục tiêu đến các trang web đăng ký giả mạo được thiết kế chuyên nghiệp, mô phỏng các nhà tổ chức thực tế. Đây là một kỹ thuật thường thấy trong các chiến dịch phishing có mục tiêu cao, nơi kẻ tấn công cố gắng tạo dựng một môi trường giả mạo đáng tin cậy.

Kỹ Thuật Lừa Đảo và Lạm Dụng OAuth

Các nhà phân tích bảo mật của Volexity đã xác định các chiến dịch phishing này có liên hệ với nhóm tác nhân đe dọa được theo dõi là UTA0355.

Nhóm này đã liên tục cải tiến việc sử dụng và lạm dụng giao thức OAuth cùng với Device Code trong năm 2025, cho thấy một cấp độ tinh vi mới trong các chiến dịch phishing hiện đại.

Kỹ thuật này đặc biệt nguy hiểm vì nó tận dụng các quy trình xác thực hợp pháp, khiến việc phân biệt giữa yêu cầu chính hãng và yêu cầu độc hại trở nên khó khăn.

Ban đầu, nhóm UTA0355 không gửi các liên kết có vẻ độc hại rõ ràng. Thay vào đó, chúng xây dựng lòng tin qua email và các cuộc trò chuyện trên WhatsApp hoặc Signal.

Sau đó, chúng chuyển nạn nhân sang quy trình “đăng ký” trông giống như quy trình đăng nhập một lần (SSO) thông thường. Đây là một bước quan trọng để làm cho chiến dịch phishing này trở nên thuyết phục, đánh lừa người dùng rằng họ đang thực hiện một hành động hợp lệ.

Trong nhiều trường hợp, ngay cả các tài khoản gửi và ID Messenger cũng là danh tính bị xâm phạm từ các mạng lưới chính sách hoặc học thuật thực sự, làm tăng thêm độ tin cậy của chiến dịch phishing và gây khó khăn cho việc nhận diện ban đầu.

Khi mục tiêu nhấp qua, các trang web hội nghị giả mạo, chẳng hạn như bsc2025[.]org hoặc brussels-indo-pacific-forum[.]org, sẽ yêu cầu “email công ty”.

Sau đó, chúng chuyển hướng đến các trang đăng nhập Microsoft hoặc Google trông có vẻ xác thực hoàn toàn.

Kỹ thuật chính ở đây là các token OAuth và mã thiết bị (device codes) được thu giữ từ URL trình duyệt và được tác nhân tấn công sử dụng lại.

Điều này cho phép kẻ tấn công chiếm quyền điều khiển tài khoản mà không cần mật khẩu trực tiếp, đây là lõi của phương pháp khai thác trong chiến dịch phishing này.

Trong một số trường hợp, người dùng được yêu cầu dán toàn bộ URL trở lại cuộc trò chuyện dưới chiêu bài “hoàn tất đăng ký”, cung cấp trực tiếp các thông tin nhạy cảm cho kẻ tấn công.

Việc lạm dụng OAuth và Device Code cho phép kẻ tấn công bỏ qua các yếu tố xác thực truyền thống và duy trì quyền truy cập lâu dài mà không bị phát hiện.

Hành Vi Xâm Nhập Sau Chiếm Đoạt Thông Tin

Sau khi cuộc chiến dịch phishing thành công, hành vi xâm nhập diễn ra một cách lặng lẽ nhưng có phương pháp, cho thấy sự chuẩn bị kỹ lưỡng của tác nhân đe dọa.

Nhóm UTA0355 thường đăng ký một thiết bị mới trong Microsoft Entra ID (trước đây là Azure AD).

Chúng tái sử dụng tên thiết bị thực của nạn nhân để hòa nhập vào danh mục tài sản hiện có, gây khó khăn cho việc nhận diện các thiết bị bất hợp pháp.

Quyền truy cập sau đó đến từ các node proxy, đôi khi với chuỗi tác nhân người dùng (user-agent strings) của Android không khớp với phần cứng thực tế của nạn nhân.

Sự không khớp này làm cho việc xem xét nhật ký kỹ lưỡng trở nên cần thiết để phát hiện các dấu hiệu của rủi ro bảo mật này, bởi vì các truy cập có vẻ đến từ các thiết bị thông thường nhưng lại có nguồn gốc đáng ngờ.

Phát hiện Xâm Nhập và Chỉ Số Thỏa Hiệp (IOCs)

Để hỗ trợ phát hiện xâm nhập, dưới đây là một quy tắc phát hiện đơn giản có thể gắn cờ sự không khớp này trong nhiều nền tảng SIEM.

DeviceAuthEvents
| where Status == "success"
| where isnotempty(DeviceName) and isnotempty(UserAgent)
| extend DeviceType = iff(UserAgent contains "Android", "Android", iff(UserAgent contains "iOS", "iOS", "Other"))
| summarize FirstAuthTime=min(Timestamp), LastAuthTime=max(Timestamp) by UserPrincipalName, DeviceName, DeviceType
| join kind=leftouter (
    DeviceInfo // Assuming you have a table for Device Info
    | summarize FirstSeen=min(Timestamp), LastSeen=max(Timestamp) by DeviceName, HardwareType
) on DeviceName
| where DeviceType != HardwareType // Mismatch detected
| project UserPrincipalName, DeviceName, DeviceType, HardwareType, FirstAuthTime, LastAuthTime

Khái niệm tương tự có thể được chuyển đổi thành quy trình phân tích nhật ký dựa trên Python để tự động hóa việc rà soát và gắn cờ các bất thường:

import json

def analyze_device_auth_logs(logs):
    detections = []
    # In a real-world scenario, device_info_map would be populated from an MDM or asset inventory system.
    # For demonstration, assume it contains known devices and their hardware types.
    device_info_map = {
        "Laptop-User": {"hardware_type": "Other"}, # e.g., Windows Laptop
        "Mobile-User-iPhone": {"hardware_type": "iOS"},
        "Tablet-Android": {"hardware_type": "Android"}
    }

    for log in logs:
        # Example log structure (simplified for clarity):
        # log = {"timestamp": "2025-01-01T10:00:00Z", "user_principal_name": "[email protected]", "device_name": "Laptop-User", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/...", "status": "success"}

        if log.get("status") == "success":
            user_principal_name = log.get("user_principal_name")
            device_name = log.get("device_name")
            user_agent = log.get("user_agent", "")

            if not user_principal_name or not device_name:
                continue

            detected_device_type = "Other"
            if "Android" in user_agent:
                detected_device_type = "Android"
            elif "iOS" in user_agent:
                detected_device_type = "iOS"

            # Check against known device inventory
            if device_name in device_info_map:
                actual_hardware_type = device_info_map[device_name].get("hardware_type")
                if detected_device_type != actual_hardware_type:
                    detections.append({
                        "type": "Device Type Mismatch",
                        "description": "Detected a device type mismatch between User-Agent and known hardware type.",
                        "user": user_principal_name,
                        "device_name": device_name,
                        "detected_type": detected_device_type,
                        "actual_type": actual_hardware_type,
                        "log_entry": log
                    })
            else:
                # Optionally, flag unknown devices for further investigation
                # detections.append({"type": "Unknown Device", "device_name": device_name, "log_entry": log})
                pass
    return detections

# Example usage with dummy data
# sample_logs = [
#     {"timestamp": "2025-01-01T10:00:00Z", "user_principal_name": "[email protected]", "device_name": "Laptop-User", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/...", "status": "success"},
#     {"timestamp": "2025-01-01T10:05:00Z", "user_principal_name": "[email protected]", "device_name": "Laptop-User", "user_agent": "Mozilla/5.0 (Linux; Android 10) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/...", "status": "success"} # Mismatch
# ]
# detected_issues = analyze_device_auth_logs(sample_logs)
# print(json.dumps(detected_issues, indent=4))

Các Chỉ Số Thỏa Hiệp (IOCs)

Để hỗ trợ phát hiện xâm nhập và ứng phó sự cố, dưới đây là các chỉ số thỏa hiệp (IOCs) liên quan đến chiến dịch phishing này:

• Tên miền giả mạo: Các tên miền được sử dụng để giả mạo trang đăng ký hội nghị, ví dụ:
  • bsc2025[.]org
  • brussels-indo-pacific-forum[.]org
• Mẫu User-Agent bất thường: Các truy cập từ các node proxy có user-agent strings của Android không khớp với phần cứng thực tế của nạn nhân. Sự khác biệt này là một dấu hiệu mạnh mẽ của hoạt động độc hại.
• Hành vi đăng ký thiết bị: Đăng ký thiết bị mới trong Microsoft Entra ID với tên thiết bị tương tự thiết bị hợp pháp của nạn nhân để tránh bị phát hiện.
• Giao thức bị lạm dụng: Lạm dụng các quy trình OAuth và Device Code workflows để thu thập token truy cập.
• Phương thức liên lạc ban đầu: Email, WhatsApp, Signal từ các danh tính đã bị xâm phạm để xây dựng lòng tin.

Bản Chất của Mối Đe Dọa: Không Phải Mã Độc Truyền Thống

Một phân tích kỹ thuật đầy đủ cho thấy “mã độc” thực sự ở đây không phải là một tệp nhị phân truyền thống hay một phần mềm độc hại có thể cài đặt trên hệ thống.

Thay vào đó, nó là một quy trình làm việc OAuth và Device Code bị vũ khí hóa, đại diện cho một hình thức chiến dịch phishing nâng cao, tập trung vào việc thao túng các cơ chế xác thực.

Tải trọng (payload) chính của cuộc tấn công không phải là mã độc, mà là sự đồng ý của người dùng và các token truy cập mà họ đã giao nộp.

Những token này cấp cho kẻ tấn công quyền truy cập cấp API sâu rộng vào hộp thư, tệp và dữ liệu nhận dạng của nạn nhân.

Điều này cho phép chúng hoạt động mà phần lớn vẫn vô hình đối với các công cụ bảo mật điểm cuối (endpoint detection and response – EDR tools) truyền thống, vì chúng đang lợi dụng các quyền truy cập hợp lệ.

Sự tinh vi của các chiến dịch phishing như vậy đặt ra thách thức đáng kể cho các biện pháp bảo mật truyền thống và yêu cầu một cách tiếp cận đa chiều, bao gồm cả việc giám sát chặt chẽ các hành vi xác thực và truy cập.