# Knight Office: Bộ Phishing-as-a-Service Đánh Cắp Phiên Đăng Nhập Microsoft 365

## Tổng Quan

Ngày 02/09/2026, **Huntress** công bố phân tích về **Knight Office** — một kit phishing-as-a-service (PhaaS) mới phát hiện trong quá trình điều tra một sự cố tấn công **AiTM (Adversary-in-the-Middle)** ngày 18/08/2026 vào một tổ chức trong hệ thống khách hàng Huntress.

Knight Office thuộc thế hệ kit phishing **không cần đánh cắp mật khẩu**. Thay vào đó, nó tận dụng luồng xác thực thiết bị hợp pháp của Microsoft (`deviceauth`) để dụ người dùng hoàn thành toàn bộ quy trình đăng nhập — kể cả bấm xác nhận MFA trên điện thoại — trong khi hạ tầng của kẻ tấn công âm thầm đứng ở giữa, thu giữ **session token** đã được xác thực. Token bị đánh cắp sau đó được phát lại ngay lập tức từ hạ tầng data center, cho phép kẻ tấn công truy cập tài khoản như người dùng thật mà **không cần mật khẩu, không cần vượt qua MFA**.

Hệ quả nghiêm trọng hơn nữa: sau khi đăng nhập thành công, kẻ tấn công đăng ký một thiết bị giả do mình kiểm soát vào **Microsoft Entra ID** của nạn nhân và gắn một **khóa Windows Hello for Business (WHfB)** vào tài khoản — tạo ra một backdoor có thể dùng để đăng nhập lại **ngay cả sau khi token bị đánh cắp đã bị thu hồi**.

Huntress liên kết bảng điều khiển của Kit này với ít nhất **9 cuộc tấn công** trong vòng 2 tuần vào khách hàng Huntress, và phát hiện hơn **700 email mồi nhử** theo cùng một mẫu đã được báo cáo qua nền tảng Security Awareness Training của họ kể từ tháng 04/2026.

* * *

## Bối Cảnh: Xu Hướng Từ Bỏ Đánh Cắp Mật Khẩu

Knight Office không phải kit phishing đầu tiên theo hướng này — Huntress cũng đã theo dõi các kit tương tự trước đó là **EvilTokens** và **Kali365**, đều tập trung vào việc đánh cắp session token (AiTM) hoặc OAuth access token (device code phishing) thay vì mật khẩu.

**Lý do token theft ngày càng phổ biến:** MFA đã trở thành tiêu chuẩn bảo mật ở hầu hết doanh nghiệp — và các phương pháp tấn công cũ (phishing mật khẩu thông thường, password spray, brute force) đều bị chặn hoàn toàn khi MFA được bật. Token theft giải quyết vấn đề này theo cách khác: thay vì cố gắng vượt qua MFA, nó **đợi người dùng tự vượt qua MFA**, rồi thu giữ session đã được xác thực đầy đủ. Từ góc độ Microsoft, mọi thứ trông như một đăng nhập hợp lệ hoàn toàn.

| **Thế hệ tấn công** | **Kỹ thuật** | **Trạng thái khi MFA bật** |
| --- | --- | --- |
| Phishing mật khẩu truyền thống | Thu thập username/password | Bị vô hiệu hóa hoàn toàn |
| Password spray / brute force | Đoán mật khẩu | Bị vô hiệu hóa hoàn toàn |
| **AiTM (Knight Office)** | **Thu giữ session token sau khi người dùng hoàn thành MFA** | **MFA hoàn toàn vô dụng** |

* * *

## Phân Tích Kĩ Thuật

### 1\. Bảng Điều Khiển Knight Office — Phát Hiện Qua Sự Cố

Huntress phát hiện Kit này không phải qua tìm kiếm chủ động mà qua điều tra sự cố thực tế: khi điều tra hai sự kiện xác thực bất thường sau MFA trên một tài khoản Microsoft 365 ngày 18/08, SOC Huntress nhận ra IP `73.125.13[.]x` (đã redact) — đăng ký tên Comcast Cable nhưng bị Spur IP Intelligence đánh dấu là **callback proxy** liên quan đến nhiều nhà cung cấp proxy thương mại — là dấu hiệu đầu tiên của một cuộc tấn công AiTM.

![](https://cdn.hashnode.com/uploads/covers/669e2578c18c3baa1b4fc070/ac32aa85-3d7c-460a-ab69-2b857dd3da55.png align="center")

Tiếp tục truy vết từ IP phát lại token `104.37.188[.]94`, phân tích trên Validin tiết lộ **bảng điều khiển vận hành (operator console) của Knight Office** — một dashboard web đầy đủ chức năng được xây dựng bằng **Python Flask** (với add-on Flask-WTF), bảo vệ bằng **Cloudflare Turnstile** (kiểm tra bot), và trang đăng nhập được đặt tên tường minh `Login — KNIGHT OFFICE`.

**Tính năng được quảng cáo trên dashboard:**

*   *"Capture & Management from Single place"* — quản lý toàn bộ nạn nhân và token đánh cắp từ một màn hình
    
*   *"Webmail access & auto-refresh"* — truy cập email nạn nhân ngay trong console
    
*   *"Deploy custom links"* — triển khai link phishing tùy chỉnh
    
*   *"Real-time visitor statistics"* — thống kê khách truy cập theo thời gian thực
    

**Điểm quan trọng cần phân biệt:** Huntress nhấn mạnh rằng **console** này là interface dành cho kẻ vận hành (operator-facing) — khác với **mã nguồn kit** là phần dành cho nạn nhân (victim-facing), bao gồm các HTML template trang đăng nhập giả, script thu thập credential, v.v. Họ tiếp cận được console, không phải mã nguồn đầy đủ của kit.

Việc xem xét IP `104.37.188[.]94` trên Validin và VirusTotal phát hiện **ít nhất 25 domain** dùng TLD `.vu` phục vụ làm trang phishing.

* * *

### 2\. Email Mồi Nhử — Tự Giả Mạo Chính Địa Chỉ Người Nhận

Email khởi đầu cuộc tấn công được thiết kế theo phong cách **DocuSign signature request** với các yếu tố tạo áp lực hành động ngay. Điểm đặc biệt nhất là kỹ thuật **tự giả mạo (self-spoofing)**: header `From`, `To`, và `Return-Path` đều bị giả mạo sao cho email **trông như được gửi từ chính địa chỉ email của người nhận** — tạo cảm giác đây là một thông báo nội bộ hoặc hệ thống tự phát, không phải email từ người lạ.

![](https://cdn.hashnode.com/uploads/covers/669e2578c18c3baa1b4fc070/d80faf97-2388-4b2e-bdcf-9bfb7c077d52.png align="center")

IP gửi email trong vụ cụ thể Huntress điều tra: `154.127.53[.]78`. Xem xét IP này trên VirusTotal phát hiện thêm **14 email liên quan** cùng nội dung và template.

**Các biến thể tiêu đề email đã xác nhận:**

```plaintext
Reminder: Signature Required - Approval Pending Your Review!!! Ref ID-<10 ký tự ngẫu nhiên>
You Missed (2) lmportant VoiceMessage; Please Review Now!!! REF-<10 ký tự>
Sjc Shared an lmportant Document with you that required your Attention and Slgnature!! - REF-<10 ký tự>
VERlVIED: Caller left <số ngẫu nhiên> minutes <số ngẫu nhiên> seconds REF-<10 ký tự>
lmportant: (3) Playback-MSG Arrived from <tên> - Listen Now
```

**Dấu hiệu nhận dạng đặc trưng của chiến dịch:** chữ "l" viết thường được thay thế cho chữ "i" trong các từ như `lmportant` (Important), `Slgnature` (Signature), `VERlVIED` (VERIFIED). Đây là kỹ thuật cố tình để né các bộ lọc spam quét từ khóa theo khớp chính xác.

* * *

### 3\. Chuỗi Chuyển Hướng — Ẩn Đích Cuối Sau Nhiều Lớp Hợp Pháp

Nút nhấn trong email đưa nạn nhân qua một chuỗi chuyển hướng nhiều bước, mỗi bước dùng một nền tảng/website hợp pháp để che khuất đích thực sự khỏi các bộ quét bảo mật email:

```plaintext
Link trong email
└─► Monday.com (nền tảng quản lý công việc hợp pháp — dùng làm tracking redirect)
 └─► Website Joomla bị xâm phạm (relay trung gian — đã bị gỡ khi Huntress điều tra)
  └─► Trang phishing giả mạo Microsoft SharePoint hoặc Teams
```

Việc đi qua **Monday.com hợp pháp** là bước then chốt: nhiều giải pháp bảo mật email kiểm tra uy tín của domain đích theo đường dẫn trực tiếp — Monday.com có uy tín rất cao, nên link không bị gắn cờ ngay. Website Joomla bị xâm phạm đóng vai là "relay" trung gian, tiếp tục che khuất domain phishing cuối.

* * *

### 4\. Kỹ Thuật "Device Auth" — Dùng Chính Microsoft Để Lừa Người Dùng

Đây là phần tinh vi nhất của Knight Office. Trang phishing cuối không hiển thị form đăng nhập giả để lấy username/password như phishing truyền thống. Thay vào đó, nó:

**Bước 1:** Trình bày nạn nhân với một **mã xác thực thiết bị (device authentication code)** và yêu cầu **"Sign In With Microsoft"**. Nội dung trang giả dạng một tài liệu SharePoint hoặc tin nhắn thoại Teams đang chờ xem.

**Bước 2:** Khi nạn nhân nhấp "Sign In With Microsoft", trang mở **một tab mới tới trang** `deviceauth` **thật của Microsoft** (`https://microsoft.com/devicelogin` hoặc tương đương). Đây là trang Microsoft dùng để xác thực thiết bị trong các ứng dụng như TV, máy in, hay ứng dụng di động.

**Bước 3:** Nạn nhân được hướng dẫn **dán mã 9 ký tự** mà trang phishing đã cung cấp vào form của trang Microsoft thật. Trang Microsoft thật thậm chí tự cảnh báo người dùng: ***"don't enter codes from sources you don't trust"*** — nhưng điều này thường bị bỏ qua trong bối cảnh.

**Bước 4:** Sau khi nạn nhân điền mã và nhấn Next, Microsoft yêu cầu đăng nhập bằng **thông tin thật** và **phê duyệt MFA** trên điện thoại — đúng như một đăng nhập thật sự.

**Bước 5:** Người dùng hoàn thành toàn bộ quy trình xác thực hợp lệ. Microsoft cấp **session token** — và token này được hạ tầng của kẻ tấn công thu giữ, bơm vào console Knight Office để dùng ngay lập tức.

**Tại sao cơ chế này đánh bại MFA?** Vì MFA **không bị vượt qua** — MFA được người dùng tự phê duyệt một cách hoàn toàn hợp lệ. Vấn đề là mã xác thực thiết bị mà nạn nhân đã nhập vào trang Microsoft thật **là mã do kẻ tấn công kiểm soát**, nên session được cấp sau đó thuộc về hạ tầng kẻ tấn công, không phải thiết bị của người dùng. Toàn bộ quá trình trông hoàn toàn bình thường trong log của Microsoft — **không có lần nhập mật khẩu sai, không có cảnh báo nào kích hoạt**.

* * *

### 5\. Phát Lại Token Và Né Phát Hiện

Sau khi thu được session token, kẻ tấn công phát lại (replay) từ **hạ tầng data center** với User-Agent đặc trưng:

```plaintext
python-requests/2.34.2, OAuth2:Token
```

Vì token đã được xác thực đầy đủ (kể cả MFA), authentication log của Microsoft ghi nhận **zero lần nhập sai mật khẩu**. Các cảnh báo dựa trên mật khẩu (failed login alert, password spray detection) **không bao giờ kích hoạt**. Các lần thất bại duy nhất trong log là do token hết hạn hoặc thiếu device key — không phải dấu hiệu tấn công theo định nghĩa thông thường.

Đây là lý do AiTM token theft **vô hình với các công cụ giám sát truyền thống**: không có anomaly trong quá trình xác thực, không có mật khẩu sai, không có brute force — chỉ có một phiên đăng nhập thành công từ một IP lạ, mà nhiều tổ chức không cấu hình cảnh báo cho trường hợp này.

* * *

### 6\. Persistence — Cửa Hậu Tồn Tại Sau Khi Thu Hồi Token

Đây là phần nguy hiểm nhất của Knight Office sau khi chiếm được tài khoản. Kẻ tấn công không chỉ dừng lại ở việc dùng session token bị đánh cắp — chúng thực hiện thêm một chuỗi bước để đảm bảo quyền truy cập **lâu dài, ngay cả sau khi đội ngũ bảo mật phát hiện và thu hồi token**:

**Bước 1 (thất bại):** Từ IP `104.37.188[.]94`, kẻ tấn công thực hiện hai lần xác thực OAuth 2.0 bằng token đã phát lại nhắm vào **Microsoft Authentication Broker app** — cả hai đều thất bại vì **NGC key** (khóa cần thiết cho Windows Hello for Business) chưa tồn tại.

**Bước 2:** Đăng ký một **host không được phép** vào tenant **Microsoft Entra ID** (trước đây gọi là Azure AD) của nạn nhân và hoàn thành **đăng ký thiết bị giả do kẻ tấn công kiểm soát**.

**Bước 3:** Gắn một **khóa Windows Hello for Business (WHfB)** vào tài khoản nạn nhân (xác nhận qua User-Agent `Dsreg/10.0 (Windows 10.0.19044.1826)`).

**Bước 4 (thành công):** Đăng nhập lại lần nữa — lần này dùng **WHfB passwordless authentication**. Thành công.

**Ý nghĩa:** WHfB là tính năng Microsoft thiết kế để tăng cường bảo mật cho người dùng hợp pháp (đăng nhập không cần mật khẩu bằng khóa mã hóa gắn với thiết bị). Nhưng khi kẻ tấn công đăng ký **khóa WHfB của thiết bị họ** vào tài khoản nạn nhân, chính tính năng này trở thành **backdoor bền vững**: họ có thể đăng nhập lại bất kỳ lúc nào ngay cả khi mật khẩu được đổi, MFA được reset, hay session token gốc bị thu hồi — **miễn là khóa WHfB giả vẫn còn gắn vào tài khoản**.

* * *

### 7\. Quy Mô Chiến Dịch

**Từ telemetry nội bộ của Huntress:**

*   Tối thiểu **9 cuộc tấn công** token replay trên các tài khoản M365/Google Workspace trong mạng lưới khách hàng Huntress, liên kết với IP `104.37.188[.]94` **trong vòng 2 tuần**.
    
*   Hơn **700 email** dùng cùng template và mẫu đã được báo cáo qua nền tảng Security Awareness Training (SAT) của Huntress **kể từ tháng 04/2026** — gợi ý chiến dịch đã hoạt động ít nhất 5 tháng trước khi bị phát hiện.
    

**Từ OSINT:**

*   Phân tích IP `104.37.188[.]94` trên Validin/VirusTotal phát hiện **ít nhất 25 domain phishing** dùng TLD `.vu`.
    
*   14 email liên quan đến cùng chiến dịch phát hiện từ việc phân tích IP gửi email `154.127.53[.]78`.
    

* * *

## Tóm Tắt Rủi Ro

| **Chiều Rủi ro** | **Mức độ** | **Lý do** |
| --- | --- | --- |
| **Khả năng vượt qua MFA** | Nghiêm trọng | MFA không bị "vượt qua" theo nghĩa kỹ thuật — người dùng tự phê duyệt; session token bị đánh cắp ngay sau khi xác thực thành công |
| **Khả năng ẩn mình** | Rất cao | Zero bad password attempt; log Microsoft ghi nhận đăng nhập thành công bình thường; phát lại từ data center thay vì IP bất thường ngay lập tức |
| **Tính bền vững của quyền truy cập** | Rất cao | WHfB backdoor tồn tại sau khi thu hồi token; cần rà soát và xóa thiết bị + khóa WHfB giả |
| **Độ khó phát hiện bằng công cụ truyền thống** | Cao | Các cảnh báo dựa trên mật khẩu sai, brute force, hay password spray đều không kích hoạt |
| **Quy mô triển khai** | Cao | 25+ domain phishing, callback proxy, Tencent Cloud hosting; chiến dịch chạy ít nhất 5 tháng |
| **Thiệt hại tiềm tàng** | Nghiêm trọng | Toàn quyền truy cập M365: email, Teams, SharePoint, OneDrive, ứng dụng doanh nghiệp; có thể leo thang sang BEC/chiếm quyền tenant |

* * *

## IOC & Artifacts

### Network Indicators

| **Indicator** | **Loại** | **Mô tả** |
| --- | --- | --- |
| `104.37.188[.]94` | IP | Địa chỉ IP của console Knight Office; cũng dùng để đăng ký thiết bị giả vào Entra ID |
| `154.127.53[.]78` | IP | IP gửi email mồi nhử trong vụ điều tra cụ thể |
| `73.125.13[.]x` | IP (redact) | Callback proxy AiTM — IP Comcast bị Spur đánh dấu là proxy thương mại |
| `idoej[.]com` | Domain | Domain lưu trữ console Knight Office (phát hiện qua reverse IP lookup) |
| Tencent Cloud ranges: `43[.]x`, `170.106[.]x`, `162.62[.]x`, `49.51[.]x` | IP ranges | Hạ tầng phát lại token (replay infrastructure) |

### Phishing Domains (TLD .vu)

```plaintext
advancedplacyncement[.]vu
amstardmzsmc[.]vu
arandasoftzfdware[.]vu
avisoretentiunionllc[.]vu
capitalflwxinancialpartners[.]vu
certififiycationedge[.]vu
connectivnqzityltd[.]vu
crrbcearegroup[.]vu
digitaltrafwwrficsystems[.]vu
exceltecbusinessbwpsolutions[.]vu
genamewwgdiamarketing[.]vu
globaieflsoftinc[.]vu
globalmixeucbdmodetechnologyinc[.]vu
globalprojectspvtltd[.]vu
joinbusinessmanagementconsdjeulting[.]vu
kentmanqhfufacturingcompany[.]vu
kleepxrnlinecorporation[.]vu
knsinternacshtional[.]vu
monttmmlrustcompany[.]vu
mtprormtductions[.]vu
realestatecotblrp[.]vu
siottxgroup[.]vu
summitcapitaltrapojininggroup[.]vu
techcompositnkoes[.]vu
techromixsolutionlonsinc[.]vu
```

### Behavioral / Forensic Indicators

*   **User-Agent phát lại token:** `python-requests/2.34.2, OAuth2:Token`
    
*   **User-Agent đăng ký WHfB:** `Dsreg/10.0 (Windows 10.0.19044.1826)`
    
*   **Cloudflare Turnstile Sitekey của console:** `0x4AAAAAADrkE-VuOnNDfr6W`
    
*   **Tiêu đề trang console:** `Login — KNIGHT OFFICE`
    
*   **Tiêu đề email:** Mẫu `Reminder: Signature Required - Approval Pending Your Review!!! Ref ID-<10 ký tự>` và các biến thể (xem mục 2)
    
*   **Đặc điểm văn bản:** Chữ "l" thay cho "i" trong `lmportant`, `Slgnature`, `VERlVIED`
    
*   **Dấu hiệu trong Entra ID:** Thiết bị mới đăng ký từ IP lạ sau một phiên đăng nhập thành công; khóa WHfB mới không được người dùng hoặc IT chủ động tạo
    

* * *

## MITRE ATT&CK Mapping

*(Theo MITRE ATT&CK mapping do Huntress công bố trong báo cáo gốc)*

| **Tactic** | **Technique ID** | **Technique Name** | **Mô tả trong chiến dịch** |
| --- | --- | --- | --- |
| **Resource Development** | T1608.005 | Stage Capabilities: Link Target | Dùng tham số redirect mở trên Monday.com để che khuất đích thực sự; dùng website Joomla bị xâm phạm làm relay |
| **Initial Access** | T1566.002 | Phishing: Spearphishing Link | Email mồi nhử kiểu DocuSign với link `href` thay vì file đính kèm |
| **Execution** | T1204.001 | User Execution: Malicious Link | Social engineering thúc đẩy người dùng nhấp link trong email |
| **Persistence** | T1098.005 | Account Manipulation: Device Registration | Đăng ký thiết bị giả vào Entra ID; gắn khóa WHfB vào tài khoản nạn nhân |
| **Defense Evasion** | T1078.004 | Valid Accounts: Cloud Accounts | Dùng session token hợp lệ đã bị đánh cắp — né hoàn toàn các cảnh báo dựa trên mật khẩu |
| **Defense Evasion** | T1684.002 | Social Engineering: Email Spoofing | Self-spoofing kỹ thuật — email giả mạo chính địa chỉ của người nhận |
| **Credential Access** | T1111 | MFA Interception | Relay thu giữ session token ngay khi người dùng phê duyệt MFA |
| **Credential Access** | T1557 | Adversary-in-the-Middle | Hạ tầng AiTM đứng giữa nạn nhân và Microsoft để thu giữ session token theo thời gian thực |
| **Credential Access** | T1528 | Steal Application Access Token | Thu giữ và thu thập session token hợp lệ để truy cập trái phép M365 |
| **Command and Control** | T1090.003 | Proxy: Multi-hop Proxy | Nhiều lớp routing — Monday.com, Joomla bị xâm phạm, callback proxy — để ẩn nguồn gốc thật sự |
| **Command and Control** | T1665 | Hide Infrastructure | Ẩn máy chủ vận hành sau các nền tảng hợp pháp, website bị xâm phạm, và proxy network |

* * *

## Nhận Định

Knight Office là ví dụ rõ ràng nhất trong năm 2026 cho thấy **MFA đơn lẻ không còn là biện pháp phòng thủ đủ mạnh trước các tấn công phishing thế hệ mới**. Điều quan trọng cần nhấn mạnh: đây không phải vì MFA bị "vượt qua" theo nghĩa kỹ thuật thông thường — không có lỗ hổng nào trong giao thức MFA bị khai thác. Người dùng được yêu cầu phê duyệt một yêu cầu MFA **hoàn toàn hợp lệ về mặt kỹ thuật** — họ chỉ không biết rằng đó là yêu cầu do kẻ tấn công kiểm soát. Đây là một thất bại về **nhận thức người dùng và thiết kế trải nghiệm**, không phải thất bại kỹ thuật của MFA.

**Kỹ thuật "device auth" là điểm tinh vi nhất** của Knight Office so với các kit AiTM truyền thống. Thay vì tạo một trang đăng nhập Microsoft giả hoàn toàn (dễ bị phát hiện bởi các công cụ kiểm tra trang web giả), Knight Office dùng chính **trang** `deviceauth` **thật của Microsoft** làm nơi người dùng nhập thông tin. Điều này có nghĩa: người dùng kiểm tra URL bar sẽ thấy `microsoft.com` — một tên miền hoàn toàn hợp lệ. Không có gì giả ở trang họ đang nhìn vào — thứ giả duy nhất là **mã 9 ký tự mà họ đã được cung cấp từ trang trước đó**.

**Persistence qua WHfB là bước leo thang nghiêm trọng nhất.** Nhiều tổ chức khi phát hiện tài khoản bị xâm phạm sẽ đổi mật khẩu và thu hồi session — và tin rằng vấn đề đã được giải quyết. Nhưng nếu không rà soát và xóa **thiết bị Entra ID đã đăng ký giả** và **khóa WHfB đã gắn**, kẻ tấn công có thể đăng nhập lại ngay lập tức. Đây là bước mà nhiều đội IR bỏ sót, vì nó yêu cầu kiểm tra trong Microsoft Entra admin center — không phải chỉ trong Microsoft 365 admin.

**Đối với các tổ chức tại Việt Nam đang triển khai Microsoft 365**, đây là một cảnh báo thực tế: hầu hết các chiến lược phòng thủ hiện tại tập trung vào **ngăn chặn đăng nhập thất bại** (failed login monitoring, MFA enforcement). Knight Office cho thấy kẻ tấn công thế hệ mới đã chuyển sang đánh cắp **đăng nhập thành công** — và làm như vậy mà **không để lại bất kỳ dấu hiệu thất bại nào trong log**. Nếu tổ chức không có cảnh báo cho các đăng nhập M365 từ IP lạ (đặc biệt là data center và callback proxy) **sau khi MFA đã được phê duyệt**, họ có thể không bao giờ biết mình đã bị xâm phạm.

* * *

## Khuyến Nghị

### Phát Hiện AiTM Token Theft

1.  **Chuyển trọng tâm giám sát từ "đăng nhập thất bại" sang "đăng nhập thành công bất thường":** Cảnh báo khi có sự kiện xác thực sau MFA (post-MFA authentication) từ:
    
    *   IP thuộc data center range không liên quan đến người dùng (người dùng ở Việt Nam nhưng token được phát lại từ Tencent Cloud ở Singapore)
        
    *   IP được Spur hoặc các IP intelligence service đánh dấu là **callback proxy** hoặc **residential proxy**
        
    *   User-Agent bất thường như `python-requests/x.x.x` trong context xác thực M365
        
2.  **Phát hiện phiên đăng nhập "hai địa chỉ":** Trong AiTM, bước đăng nhập ban đầu (victim IP) và bước callback nhận token (attacker proxy IP) thường khác nhau — cảnh báo khi IP của bước token callback **không nhất quán với địa chỉ đăng nhập ban đầu** trong cùng một phiên.
    
3.  **Giám sát Microsoft Entra ID Sign-in Logs** tìm User-Agent `python-requests` liên quan đến OAuth Token grant — đây là dấu hiệu phát lại token tự động.
    

### Rà Soát Và Khắc Phục Sau Sự Cố

1.  **Rà soát thiết bị Entra ID đăng ký:** Sau bất kỳ sự cố M365 nào, kiểm tra ngay trong **Entra ID → Devices** xem có thiết bị nào đăng ký từ IP lạ hoặc không được IT phê duyệt. Xóa thiết bị không được phép.
    
2.  **Rà soát và xóa khóa WHfB không được ủy quyền:** Trong **Entra ID → Users → Authentication Methods** của tài khoản bị ảnh hưởng, kiểm tra và xóa mọi khóa Windows Hello for Business không được người dùng hay IT tạo.
    
3.  **Thu hồi toàn bộ active session** qua **"Revoke all sessions"** trong Entra ID — không chỉ đổi mật khẩu. Đổi mật khẩu không tự động hủy session token đang hoạt động.
    
4.  **Vô hiệu hóa tài khoản đã đồng bộ trong on-premises identity system** nếu có, để ngăn kẻ tấn công tái lấy session từ on-premises.
    

### Phòng Ngừa

1.  **Triển khai Conditional Access Policies nhạy cảm với vị trí và thiết bị:** Chặn xác thực từ IP data center hoặc không phải thiết bị compliant (Intune-managed) đối với các ứng dụng nhạy cảm.
    
2.  **Bật Entra ID Protection** để phát hiện token replay từ IP bất thường (tính năng "Anomalous token" detection).
    
3.  **Dùng FIDO2 security key hoặc passkey thay vì MFA truyền thống (SMS/authenticator app):** Các phương thức này bị gắn với domain cụ thể và **không thể bị phishing** ngay cả qua AiTM — đây là biện pháp phòng thủ thật sự chống lại loại tấn công này, không phải chỉ MFA thông thường.
    
4.  **Đào tạo nhận thức người dùng:** Hướng dẫn nhân viên **không bao giờ nhập mã từ một trang web vào một tab khác** — ngay cả khi tab thứ hai là Microsoft thật. Quy tắc đơn giản: nếu không phải bạn tự mở yêu cầu đăng nhập, đừng phê duyệt.
    
5.  **Chặn domain** `.vu` **và IP trong danh sách IOC** tại email gateway và proxy.
    

* * *

## Tham Khảo

*   [Inside Knight Office, a New M365 AiTM Phishing Kit — Huntress (Andrew Brandt, Andrea Hatcher, Lindsey O'Donnell-Welch, 02/09/2026)](https://www.huntress.com/blog/inside-knight-office-m365-aitm-attack)
    

* * *