Tấn công Teams giả mạo: từ chat IT support đến chiếm quyền domain
Tấn công Teams giả mạo là dạng phishing IT support trong đó kẻ tấn công sử dụng tài khoản Teams thuộc tenant bên ngoài, tự nhận là IT hoặc help desk nội bộ, dụ người dùng cấp quyền điều khiển từ xa rồi triển khai MSI độc hại và implant Node.js để duy trì hiện diện, thực hiện khám phá Active Directory và dùng WinRM lateral movement nhằm tiếp cận domain controller và tài nguyên nhạy cảm trong tổ chức. Đây không phải lỗ hổng kỹ thuật của Microsoft Teams mà là sự lạm dụng chức năng cộng tác và công cụ quản trị hợp pháp kết hợp xã hội kỹ thuật tinh vi. Thông điệp quan trọng là: một "phiên hỗ trợ" trên Teams, nếu người dùng tin nhầm, có thể trở thành cầu nối trực tiếp cho hacker vào môi trường domain controller. Microsoft đã quan sát chiến dịch do con người điều khiển, trong đó attacker giả mạo IT hoặc help desk thông qua chức năng cộng tác bên ngoài của Teams để thuyết phục người dùng cấp phiên điều khiển tương tác. Điều này cho thấy Microsoft Teams bảo mật không chỉ là câu chuyện vá lỗi, mà là quản trị cách người dùng giao tiếp với bên ngoài và cách tổ chức cho phép remote support hoạt động.
Chuỗi tấn công: remote control → MSI độc hại → Node.js implant
Giai đoạn đầu của tấn công Teams giả mạo luôn xoay quanh việc chiếm được một phiên điều khiển từ xa hợp pháp. Kẻ tấn công khởi tạo chat hoặc call từ một tenant Teams khác, dùng tên và avatar trông giống tài khoản IT nội bộ, đưa ra các lý do quen thuộc như kiểm tra tài khoản, cập nhật bảo mật, xử lý lỗi spam filter hoặc đe dọa khóa tài khoản để tạo áp lực. Trong cuộc gọi, chúng yêu cầu người dùng chấp thuận yêu cầu điều khiển trên phiên chia sẻ màn hình Teams hoặc mở Quick Assist và đọc lại mã kết nối. Khi remote control được cấp, bàn phím và chuột của nạn nhân trở thành công cụ triển khai mã độc trong chính môi trường đã đăng nhập sẵn. Theo quan sát, kẻ tấn công dùng PowerShell để tải gói MSI độc hại từ cloud storage và cài đặt âm thầm bằng Windows Installer, sử dụng tên file mang chủ đề cập nhật để phù hợp với kịch bản hỗ trợ. MSI này thả một loader dạng script và implant mã hóa vào thư mục LocalAppData của người dùng hiện tại, sau đó tải một runtime Node.js portable hợp pháp rồi dùng Node.js – hoặc bản đã đổi tên nhưng vẫn lộ metadata gốc – để giải mã và chạy JavaScript implant. Implant thiết lập persistence per-user bằng khóa Run trong HKEY_CURRENT_USER hoặc shortcut trong thư mục Startup, dùng tên EdgeUpdate để tiếp tục ngụy trang. Điều đáng sợ: toàn bộ chuỗi này tận dụng công cụ hợp pháp và đặc quyền người dùng tự tay cấp trong phiên hỗ trợ. Nếu bạn nghĩ "IT bảo làm" là đủ, bạn đang biến mọi endpoint thành điểm đặt backdoor mà không cần bất kỳ lỗ hổng Teams nào.
Từ một máy người dùng thành bản đồ domain rồi WinRM lateral movement
Sau khi implant hoạt động, máy người dùng không còn là đích cuối mà trở thành cửa ngõ khám phá toàn bộ domain. Implant sử dụng HTTPS long polling ngẫu nhiên để nhận task JavaScript, từ đó sinh các tiến trình cmd và PowerShell sống ngắn nhằm thu thập thông tin host, phần cứng, locale, đĩa, môi trường ảo hóa và sản phẩm bảo mật đã cài. Đồng thời, kẻ tấn công chụp desktop nhiều lần, resize và mã hóa Base64 để chuẩn bị exfiltration. Tiếp đó, chúng chuyển sang khám phá Active Directory: dùng lệnh native để enumerate tài khoản domain và truy vấn Active Directory Service Interfaces để tìm các máy chủ Windows Server và người dùng, giải địa chỉ server và thử khả năng quản trị, qua đó xây dựng bản đồ hệ thống có giá trị trong bối cảnh identity và quyền truy cập. Khi đã có bức tranh, chúng sử dụng implant Node.js làm điểm xuất phát cho WinRM lateral movement: gửi lệnh qua Windows Remote Management trên TCP 5985 tới các hệ thống đã join domain, gồm server file, database, application và cả domain controller lẫn certificate authority. Việc WinRM bắt nguồn từ workstation người dùng hoặc tiến trình không có vai trò quản trị là dấu hiệu intrusion đã vượt khỏi mức persistence cục bộ để tiến vào lateral movement dựa trên credential. Về bản chất, bảo mật domain controller không thể coi WinRM là "bình thường" nếu nguồn là mọi endpoint văn phòng. "Chỉ workstation quản trị được cấp phép mới được khởi tạo phiên WinRM tới hạ tầng nhạy cảm" là nguyên tắc kiểm soát mạng duy nhất đủ hẹp để cắt đứt bước chuyển từ implant sang quyền domain.
Vấn đề gốc: Teams external access bật sẵn – và cách khóa lại đúng mức
Lý do tấn công Teams giả mạo hiệu quả là vì kẻ tấn công không phải phá cửa, chỉ cần bước qua cửa đang mở sẵn. External access của Microsoft Teams được bật mặc định, cho phép người dùng trong tổ chức chat và họp với tài khoản ở tenant khác hoặc quản lý ngoài. Khi đó, một tài khoản Teams bên ngoài dùng tên IT nội bộ vẫn có thể hiện diện như thành viên "hợp lý" trong khung chat của người dùng. Nếu doanh nghiệp mặc định để mọi domain bên ngoài đều được phép, bạn đang cho phép bất kỳ tenant nào trở thành "help desk" giả mạo. Cần chuyển từ thế bị động sang chủ động bằng cách: hạn chế Teams external access chỉ còn những domain đối tác tin cậy, giữ hiển thị cảnh báo rõ ràng cho người gửi bên ngoài, và giới hạn bộ công cụ remote-support được phép sử dụng. Theo hướng dẫn cấu hình, external domain hiện được cho phép toàn bộ, và khi thiết lập danh sách cho phép (allow list), các domain không có trong đó sẽ bị chặn; ngược lại, block list chỉ chặn những gì được liệt kê, các domain còn lại vẫn thông. Giải pháp hợp lý không phải đóng sạch, mà là đồng bộ chính sách theo ba tầng: (1) Chỉ cho phép những external domain có nhu cầu làm việc thường xuyên; (2) Chặn chiều khởi tạo cuộc trò chuyện từ tài khoản Teams quản lý ngoài nếu bạn chỉ cần liên hệ một chiều; (3) Dùng external access policy theo người dùng để chỉ cấp quyền cộng tác với bên ngoài cho những chức danh cần, như sales hay procurement, trong khi phần còn lại thừa hưởng thiết lập chặt hơn. Đây chính là nền tảng của Microsoft Teams bảo mật ở cấp tổ chức: kiểm soát đường liên lạc trước khi nói đến detection hay response.
Doanh nghiệp nên làm gì ngay: quy trình xác thực IT support và hạn chế WinRM
Ở thời điểm chiến dịch phishing IT support qua Teams đang diễn ra thay vì giả thuyết, bảo mật domain controller không thể chờ thêm một vòng update. Có vài việc bạn nên làm ngay, và chúng đều là thay đổi hành vi và cấu hình chứ không phụ thuộc vào bản vá. Với người dùng: mọi liên hệ hỗ trợ không được yêu cầu trước – kể cả đến từ Teams, kể cả xưng danh IT – phải được xác minh qua kênh nội bộ đã biết (portal IT, số điện thoại help desk, ticket system) trước khi cấp bất kỳ quyền remote control nào. Không đọc mã Quick Assist, không bấm Accept điều khiển màn hình, không chạy file "cập nhật" nếu chưa xác thực danh tính. Một quy tắc đơn giản: "IT hỗ trợ chỉ bắt đầu từ kênh chính thức, không từ chat bất ngờ". Với đội ngũ hạ tầng: cấu hình Teams external access ở mức chỉ cho phép domain đối tác tin cậy, xem xét tắt chiều liên lạc xuất phát từ tài khoản Teams quản lý ngoài, và dùng policy theo vai trò để giới hạn ai được quyền chat với bên ngoài. Đồng thời, giới hạn bộ công cụ remote-support được phê duyệt, bật giám sát cho mọi phiên remote trên endpoint, và thiết lập rule phát hiện chuỗi hành vi: process remote support sinh PowerShell, cài MSI âm thầm, Node.js chạy từ LocalAppData với extension bất thường, truy vấn AD dày đặc, chụp màn hình liên tục. Cuối cùng, siết WinRM lateral movement: đảm bảo chỉ workstation quản trị được phép mở kết nối WinRM tới server nhạy cảm, đặc biệt là domain controller và certificate authority. Bất kỳ lưu lượng WinRM xuất phát từ máy người dùng thông thường hoặc từ context không quản trị phải được xem như tín hiệu intrusion và xử lý bằng cô lập host. Nếu không thiết lập biên giới này, mọi nỗ lực bảo vệ ở lớp Teams chỉ là bức tường đẹp phía trước một hành lang mở thẳng vào trung tâm domain.
