Giả mạo IT support qua Microsoft Teams: cách chiếm quyền nội bộ

Giả mạo IT support qua Microsoft Teams đang trở thành một kịch bản tấn công rất đáng lo với doanh nghiệp dùng Microsoft 365. Trong bài nghiên cứu công bố ngày 02/09/2026, Microsoft Security Blog cho biết threat actor đã lợi dụng tính năng cộng tác bên ngoài của Teams để đóng vai bộ phận helpdesk, lừa nạn nhân cấp quyền điều khiển từ xa, rồi cài chuỗi mã độc dựa trên MSI và Node.js để bám trụ lâu dài. Đây không phải lỗi sản phẩm kiểu CVE đơn lẻ, mà là một playbook xâm nhập kết hợp social engineering, remote support tool và lateral movement theo kiểu hands-on-keyboard.

Điểm nguy hiểm của chiến dịch này là nó bám vào đúng những gì người dùng doanh nghiệp đã quen: chat Teams, lời nhắc hỗ trợ kỹ thuật, Quick Assist hoặc yêu cầu chia sẻ màn hình. Một khi người dùng tin rằng đang làm việc với IT nội bộ, attacker có thể đưa nạn nhân sang một remote session hợp pháp, chạy PowerShell để tải gói MSI ngụy trang, rồi mở rộng truy cập sang Active Directory và các máy chủ giá trị cao qua WinRM. Với đội IT và SOC, đây là kiểu đe doạ phải xử lý như Security Threat Intel, vì nó đánh trực tiếp vào thói quen vận hành chứ không chỉ vào một lỗ hổng kỹ thuật riêng lẻ.

Tóm tắt mối đe doạ: giả mạo helpdesk trong Teams để mở cửa từ bên trong

Theo Microsoft Threat Intelligence, chiến dịch bắt đầu khi attacker từ một tenant bên ngoài chủ động chat hoặc gọi Teams, tự nhận là bộ phận IT hoặc helpdesk. Mục tiêu của chúng không phải gửi file đính kèm độc hại ngay, mà là khiến người dùng tự nguyện tham gia một phiên remote support. Sau khi giành được quyền tương tác trên máy nạn nhân, attacker dùng PowerShell tải một MSI từ cloud storage, cài đặt im lặng với msiexec /qn, rồi dựng một implant JavaScript chạy trên portable Node.js trong thư mục LocalAppData.

Microsoft nhấn mạnh đây là một chuỗi xâm nhập có độ trưởng thành cao hơn phishing thông thường. Sau giai đoạn foothold, attacker còn làm host reconnaissance, dò sản phẩm bảo mật, chụp ảnh màn hình định kỳ, truy vấn tài khoản miền và tiếp tục pivot qua WinRM tới domain controller, certificate authority và các server quan trọng khác. Nói cách khác, Giả mạo IT support qua Microsoft Teams không dừng ở việc lừa người dùng một lần, mà có thể leo thang thành chiếm quyền nội bộ diện rộng.

Phạm vi ảnh hưởng: tổ chức nào dùng Teams external collaboration đều phải cảnh giác

Phạm vi ảnh hưởng của chiến dịch này rộng vì điều kiện khởi đầu khá phổ biến: doanh nghiệp cho phép external collaboration trong Teams, người dùng có thể nhận chat/cuộc gọi từ tenant ngoài, và quy trình xác thực helpdesk chưa đủ chặt. Microsoft nói rõ đây không phải do Teams bị phá vỡ cơ chế bảo mật, mà do attacker thuyết phục người dùng bỏ qua những cảnh báo vốn đã được hiển thị. Chính vì vậy, tổ chức càng mở rộng cộng tác liên tenant, càng dùng remote support nhiều, càng phải xem đây là rủi ro vận hành thực tế.

• Người dùng đầu cuối: dễ bị tác động nhất nếu quen nhận hỗ trợ qua chat hoặc cuộc gọi bất ngờ.
• Máy Windows của nhân viên: là điểm đặt foothold đầu tiên khi remote session được chấp thuận.
• Hệ thống Active Directory: bị nhắm tới trong giai đoạn domain discovery và leo thang.
• Server giá trị cao: bao gồm file server, application server, domain controller và certificate authority mà attacker tiếp cận qua WinRM.
• Đội IT hỗ trợ người dùng: dễ bị giả danh nếu nội bộ chưa có quy tắc xác thực helpdesk rõ ràng.

Khác với một CVE có danh sách phiên bản bị ảnh hưởng cụ thể, chiến dịch này ảnh hưởng theo bề mặt vận hành. Nếu doanh nghiệp cho phép bên ngoài chat vào Teams, dùng công cụ hỗ trợ từ xa phổ biến và chưa kiểm soát chặt đường đi từ endpoint sang hạ tầng quản trị, nguy cơ sẽ cao hơn rõ rệt. Vì thế, câu hỏi quan trọng không phải là “máy nào đang thiếu bản vá nào”, mà là “người dùng nào có thể bị dụ cấp quyền điều khiển máy và sau đó từ máy đó attacker đi được tới đâu”.

Mức độ nghiêm trọng: không có CVSS, nhưng mức rủi ro doanh nghiệp là rất cao

Với Giả mạo IT support qua Microsoft Teams, không có điểm CVSS để trích dẫn vì đây là campaign threat intel chứ không phải lỗ hổng CVE. Tuy vậy, điều đó không làm giảm mức nghiêm trọng. Microsoft mô tả chuỗi tấn công này dẫn tới interactive, credential-backed access vào thiết bị nội bộ, cài implant bền vững, thực hiện reconnaissance miền và cuối cùng mở lateral movement tới tài sản cốt lõi. Chỉ riêng khả năng kết hợp social engineering với quyền điều khiển từ xa hợp pháp đã khiến chiến dịch này vượt xa các email phishing thông thường.

Nếu nhìn theo góc độ tác động, đây là đe doạ có thể dẫn đến data theft, extortion hoặc ransomware, đúng như Microsoft cảnh báo trong phần phân tích rủi ro. Khi một operator bên ngoài đã có quyền điều khiển thật trên desktop của nhân viên và tiếp tục dùng công cụ hệ thống sẵn có như PowerShell, WScript, cmd.exe, Node.js hay WinRM, việc phát hiện sẽ khó hơn nhiều so với các mẫu mã độc noisy. Đây là lý do bài toán phải được xử lý đồng thời ở lớp nhận thức người dùng, identity, endpoint và quản trị từ xa.

Chuỗi tấn công diễn ra như thế nào?

1. Initial access qua Teams: attacker chat hoặc gọi từ tenant ngoài, đóng vai IT/helpdesk và tạo áp lực tâm lý để nạn nhân hợp tác.
2. Remote support session: nạn nhân được hướng dẫn mở Quick Assist hoặc chấp thuận request control trong phiên chia sẻ màn hình.
3. Tải và cài MSI: attacker dùng PowerShell tải gói MSI từ cloud storage và cài đặt im lặng để tránh người dùng chú ý.
4. Dựng Node.js runtime và implant: MSI triển khai loader script, file implant mã hoá và nếu cần sẽ tải portable Node.js runtime hợp pháp từ nguồn chính thức.
5. Command and control: implant dùng HTTPS polling để nhận JavaScript task động từ máy chủ C2.
6. Discovery và screen capture: attacker kiểm tra môi trường, sản phẩm bảo mật, cấu hình hệ thống rồi chụp màn hình định kỳ.
7. Domain enumeration: dùng ADSI và công cụ gốc để dò tài khoản, server, user description và khả năng truy cập quản trị.
8. Lateral movement: tiến sang các máy quan trọng qua WinRM trên TCP 5985, đặc biệt là domain controller và certificate authority.

Điểm đáng chú ý là Microsoft quan sát thấy attacker lạm dụng công cụ hợp pháp xuyên suốt quá trình. Điều này khiến nhiều tổ chức dễ bỏ sót nếu chỉ săn theo IOC thô. Bằng chứng mạnh hơn nằm ở chuỗi hành vi: external Teams contact bất thường, remote support session ngoài quy trình, PowerShell tải MSI, Node.js chạy từ LocalAppData, rồi WinRM phát sinh từ user context không bình thường. Đây là nơi mà các đội SOC nên ưu tiên correlation thay vì chỉ dựa vào một alert đơn lẻ.

Doanh nghiệp nên làm gì ngay để chặn giả mạo IT support qua Microsoft Teams?

Bài Microsoft không chỉ dừng ở phân tích mà còn đưa ra khuyến nghị rất thực dụng. Ở lớp Teams, doanh nghiệp cần rà lại external collaboration policies và chỉ cho phép trusted domains khi có thể. Đồng thời, nên áp dụng thêm các security best practices for Microsoft Teams để người dùng luôn thấy tín hiệu External rõ ràng và hiểu rằng một cuộc chat hỗ trợ bất ngờ phải được xác minh qua kênh nội bộ khác.

• Thiết lập quy tắc xác thực helpdesk: có câu xác thực nội bộ, ticket ID hoặc quy trình callback riêng trước khi bất kỳ phiên remote support nào được chấp thuận.
• Siết external chat trong Teams: chỉ mở cho miền đáng tin, hạn chế tài khoản bên ngoài tự do tiếp cận người dùng.
• Ép điều kiện truy cập bằng identity: dùng Microsoft Entra Conditional Access để giảm giá trị của các phiên truy cập dựa vào tài khoản bị lộ hoặc máy không compliant.
• Bật ASR rules: theo hướng dẫn Attack Surface Reduction để chặn script interpreter, payload tải xuống và hành vi thực thi đáng ngờ.
• Giám sát WinRM: cảnh báo khi WinRM xuất phát từ user context hoặc tiến trình không phải management workstation hợp lệ.
• Kiểm soát công cụ hỗ trợ từ xa: chỉ cho phép danh sách remote support tool được phê duyệt và theo dõi chặt việc dùng ngoài giờ hoặc ngoài quy trình ticket.

Ngoài các lớp kỹ thuật, yếu tố quyết định vẫn là nhận thức của người dùng. Ảnh chụp màn hình trong bài của Microsoft cho thấy Teams đã hiển thị rất rõ cảnh báo người gửi là external, kèm khuyến nghị không chia sẻ thông tin tài khoản hay chấp thuận yêu cầu đáng ngờ. Nếu nhân viên được đào tạo tốt để coi đó là tín hiệu đỏ thay vì chỉ là một bước bấm Accept cho xong, toàn bộ chuỗi tấn công có thể bị chặn từ rất sớm.

Checklist 24 giờ cho IT và SOC

• Rà lại cấu hình external access của Teams và danh sách trusted domains.
• Xem lại quy trình helpdesk để bảo đảm mọi remote support session đều có bước xác minh độc lập.
• Hunt các phiên Quick Assist hoặc screen-sharing request bất thường đi kèm PowerShell, cmd.exe hoặc msiexec.
• Kiểm tra endpoint nào chạy node.exe từ LocalAppData hoặc thư mục người dùng không bình thường.
• Giám sát WinRM từ máy người dùng sang domain controller, certificate authority hoặc server quản trị.
• Nhắc người dùng không Accept chat hỗ trợ từ external tenant nếu chưa xác minh qua kênh nội bộ.

Kết luận

Giả mạo IT support qua Microsoft Teams cho thấy attacker không nhất thiết phải bắt đầu bằng exploit kỹ thuật để chiếm quyền nội bộ. Chỉ cần kết hợp social engineering đúng ngữ cảnh, một phiên remote support tưởng như hợp pháp và vài công cụ hệ thống sẵn có, chúng đã có thể mở đường đến Active Directory và các server quan trọng. Với tổ chức đang phụ thuộc mạnh vào Microsoft 365, đây là lúc phải xem lại cách vận hành Teams, helpdesk, endpoint hardening và WinRM monitoring như một bài toán thống nhất. Bạn có thể theo dõi thêm các bài Security thực chiến khác tại Office365Vietnam.info.