# Bạn Kết Nối Wi-Fi Khách Sạn, Kẻ Tấn Công Đã Vào Tài Khoản Microsoft 365 — Mà Bạn Không Nhấp Gì Cả

## Tổng Quan

Hãy hình dung kịch bản này: bạn vừa check-in khách sạn sau chuyến bay dài, mở laptop, bật Wi-Fi, mở Chrome và Chrome tự mở trang đăng nhập **Microsoft 365.** Trông quen thuộc. Bạn gõ mật khẩu, bấm "Next", MFA popup hiện ra, bạn approve. Xong - và bạn nghĩ mình vừa đăng nhập vào email công ty.

Bạn không đăng nhập vào email. Bạn vừa trao quyền truy cập tài khoản công ty cho kẻ tấn công đang ngồi ở đâu đó, đang theo dõi màn hình operator panel của mình sáng lên.

Không có link đáng ngờ nào để tránh. Không có file đính kèm nào để từ chối mở. Không có bước nào bạn làm sai - bởi vì **bước sai duy nhất là kết nối vào mạng Wi-Fi đó**.

Đây không phải kịch bản giả định. Kể từ tháng 6/2026, một chiến dịch tấn công đang khai thác các **captive portal** - hệ thống cổng mạng điều phối toàn bộ guest Wi-Fi của khách sạn - tại nhiều thành phố ở Mỹ, Ấn Độ và Ả Rập Xê Út. Kẻ tấn công xâm nhập thiết bị gateway, viết lại cấu hình DNS, rồi chờ. Một gateway bị kiểm soát duy nhất đủ để expose toàn bộ guest của khách sạn đó - không phân biệt thiết bị, không phân biệt hệ điều hành.

Phần khiến chiến dịch này khác với phishing thông thường nằm ở kỹ thuật bypass MFA: kẻ tấn công không cần đánh cắp mật khẩu. Chúng abuse **Microsoft Device Code Authentication flow** để nạn nhân vô tình cấp OAuth token hợp lệ - MFA đã được thỏa mãn, không có credential nào thực sự thay đổi tay, và password reset không đủ để thu hồi quyền truy cập.

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/3df89880-6475-4cbd-9d15-e33d9d04ed14.png align="center")

## **Timeline Sự Kiện**

| **Thời điểm** | **Sự kiện** |
| --- | --- |
| Tháng 4/2026 | FrostArmada bị disrupted — APT28 tấn công SOHO routers, thay đổi DNS để đánh cắp Microsoft login và OAuth token |
| Tháng 6/2026 | Phát hiện dấu hiệu ban đầu của chiến dịch DNS poisoning nhắm vào captive portal khách sạn |
| 23/7/2026 | ReliaQuest công bố Threat Spotlight: "DNS Poisoning Tactics Expand to Hospitality Wi-Fi" |
| 26/7/2026 | SecurityAffairs và BleepingComputer đưa tin rộng rãi |
| 30/7/2026 | SafeState phát hành phân tích bổ sung |
| 31/7/2026 | Chiến dịch **vẫn đang hoạt động** — attacker panel có page rotation và visitor tracking đang được maintain |

## Nhóm Tin Tặc Đứng Sau

### **APT28 — Nhóm Bị Nghi Ngờ Đứng Sau Chiến Dịch**

Mặc dù attribution chưa được xác nhận chính thức, mọi bằng chứng kỹ thuật đều trỏ về hướng **APT28** — hoặc ít nhất là một actor đã sao chép trực tiếp TTP của nhóm này.

### **APT28 Là Ai?**

**APT28** (Advanced Persistent Threat 28) là tên định danh do FireEye/Mandiant đặt. Nhóm này còn được biết đến với nhiều tên khác nhau tùy vendor:

| **Tên gọi** | **Đặt bởi** |
| --- | --- |
| **Fancy Bear** | CrowdStrike |
| **Forest Blizzard** (trước đây: STRONTIUM) | Microsoft |
| **Sofacy** | Kaspersky |
| **Pawn Storm** | Trend Micro |
| **Sednit** | ESET |
| **GRU Unit 26165** | Tên thực — Cục Tình báo Quân sự Nga (GRU) |

APT28 được cho là hoạt động dưới sự chỉ đạo của **GRU** (Главное разведывательное управление) — cơ quan tình báo quân sự của Liên bang Nga. Nhóm đã hoạt động từ ít nhất năm 2004 và là một trong những threat actor được nghiên cứu kỹ lưỡng nhất trong lịch sử an ninh mạng.

### **Lịch Sử Hoạt Động Nổi Bật**

APT28 không phải cái tên xa lạ — nhóm này để lại dấu vết trong nhiều sự kiện geopolitical lớn:

1.  **Chiến dịch bầu cử Mỹ 2016** Xâm nhập hệ thống email của Ủy ban Quốc gia Đảng Dân chủ (DNC) và chiến dịch tranh cử của Hillary Clinton. Tài liệu bị đánh cắp được rò rỉ qua WikiLeaks.
    
2.  **Tấn công WADA (2016)** Đánh cắp hồ sơ y tế của vận động viên Olympic từ Cơ quan Chống Doping Thế giới, công bố nhằm gây áp lực phản công sau khi Nga bị cấm tham dự.
    
3.  **Bầu cử Pháp 2017 (Macron Leaks)** Rò rỉ tài liệu nội bộ của chiến dịch tranh cử Emmanuel Macron 48 giờ trước bầu cử.
    
4.  **NotPetya (2017)** Cùng với Sandworm (APT44 — GRU unit khác), góp phần vào chuỗi tấn công phá hoại hạ tầng Ukraine, gây thiệt hại ước tính 10 tỷ USD toàn cầu.
    
5.  **Tấn công TV5Monde (2015)** Hạ toàn bộ hệ thống phát sóng của kênh truyền hình Pháp, giả danh "CyberCaliphate" để che giấu attribution.
    
6.  **DarkHotel / Operation Evil Twins (precursor)** APT28 có lịch sử nhắm vào khách sạn và môi trường travel. Chiến dịch nhắm executive traveler tại các khách sạn châu Á từ 2007-2014 được attributed cho nhiều nhóm liên quan.
    

## Chuỗi Tấn Công

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/e6e77205-36ec-4390-89b9-5813e8b9cd5f.png align="center")

### Giai đoạn 1: **Xâm Nhập Gateway (T1078 / T1190)**

Trước tiên chúng ta sẽ cần hiểu **captive portal là gì** và tại sao kiểm soát được nó đồng nghĩa với kiểm soát toàn bộ mạng của khách sạn.

**Captive portal là gì?**

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/10afb762-6440-404c-b4f3-e69b7dc2fbde.png align="center")

Bạn đã từng kết nối Wi-Fi khách sạn rồi thấy một trang web hiện ra yêu cầu nhập tên phòng, họ tên hoặc nhấn "Accept Terms"? Đó là captive portal. Đây là một thiết bị hoặc phần mềm đặt giữa thiết bị của bạn và internet, đóng vai trò là "cửa ngõ" của toàn bộ mạng guest:

*   Cấp địa chỉ IP cho mọi thiết bị kết nối vào (DHCP)
    
*   Trả lời mọi câu hỏi tên miền - "[login.microsoft.com](http://login.microsoft.com) ở đâu?" - trước khi thiết bị hỏi internet (DNS resolver)
    
*   Định tuyến toàn bộ traffic ra ngoài
    
*   Kiểm soát ai được vào mạng và ai bị block
    

Nếu kẻ tấn công kiểm soát captive portal, chúng kiểm soát cả ba thứ trên — và mọi thiết bị đang kết nối vào mạng đó đều nằm trong tầm tay.

**Làm thế nào kẻ tấn công xâm nhập được vào captive portal?**

Captive portal appliance - giống như bất kỳ thiết bị mạng nào khác - cần có giao diện quản trị để IT khách sạn cấu hình. Vấn đề là phần lớn các thiết bị này được cài đặt một lần rồi bỏ quên, với credential mặc định hoặc mật khẩu yếu không bao giờ được thay đổi.

Kẻ tấn công khai thác ba điểm yếu phổ biến:

1.  **SSH bị expose ra internet** - SSH (Secure Shell) là giao thức cho phép quản trị thiết bị từ xa qua dòng lệnh. Trên môi trường doanh nghiệp đúng chuẩn, SSH chỉ được mở trong mạng nội bộ. Nhưng nhiều captive portal của khách sạn có SSH mở thẳng ra internet - ai cũng có thể thử đăng nhập từ bất kỳ đâu. Kết hợp với mật khẩu admin là `admin123` hoặc mật khẩu mặc định từ nhà sản xuất chưa được đổi, kẻ tấn công có thể vào bằng brute-force hoặc credential stuffing trong vài phút.
    
2.  **Web admin console không có bảo vệ** - Giao diện quản lý qua trình duyệt (thường trên port 8080 hoặc 443) của thiết bị đôi khi không yêu cầu xác thực đủ mạnh, không có rate limiting chống brute-force, hoặc đang chạy firmware cũ với lỗ hổng đã biết. Một số thiết bị thậm chí còn có tài khoản backdoor từ nhà sản xuất.
    
3.  **SNMP bị cấu hình sai** - SNMP (Simple Network Management Protocol) là giao thức giám sát thiết bị mạng. Với community string mặc định là `public` hoặc `private`, kẻ tấn công có thể đọc - và trong một số phiên bản - ghi cấu hình vào thiết bị mà không cần mật khẩu admin.
    

### Giai đoạn 2: **Viết Lại Gateway Config**

Sau khi có quyền truy cập vào gateway, việc tiếp theo kẻ tấn công làm chỉ mất vài phút: **viết lại bảng DNS** bên trong thiết bị.

**DNS hoạt động như thế nào - và tại sao nó là điểm kiểm soát quan trọng nhất?**

Hãy hình dung DNS như một **cuốn danh bạ điện thoại** của internet. Khi bạn gõ [`login.microsoftonline.com`](http://login.microsoftonline.com) vào trình duyệt, máy tính không biết địa chỉ IP của server đó là gì và nó cần hỏi DNS: *"Số điện thoại (IP) của* [`login.microsoftonline.com`](http://login.microsoftonline.com) *là bao nhiêu?"*

Trong môi trường bình thường, quá trình đó trông như sau:

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/99941a51-a903-40b8-8fc5-a6956d7fb497.png align="center")

Sau khi kẻ tấn công viết lại cấu hình DNS trên gateway, cùng quá trình đó diễn ra như sau:

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/f4820028-737f-4d56-8fd8-807787a9692d.png align="center")

**Điểm mấu chốt:** Kẻ tấn công không cần đụng vào thiết bị của bạn. Chúng không cần gửi email phishing. Chúng không cần bạn tải gì cả. Chúng chỉ cần thay một con số trong bảng danh bạ — từ địa chỉ IP thật của Microsoft thành địa chỉ IP của server giả mạo do chúng kiểm soát.

Trong thực tế đã ghi nhận một số IP DNS poisoning của kẻ tấn công như: **31.57.243\[.\]154, 38.146.28\[.\]75**

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/327393b5-15d9-4059-84a6-0ce8d34772c8.png align="center")

### Giai đoạn 3: **Mở Rộng Phạm Vi (~1/3 Số Trường Hợp)**

Trong khoảng một phần ba số trường hợp quan sát được, kẻ tấn công tận dụng thêm cơ chế **Web Proxy Auto-Discovery (WPAD)** — giao thức cho phép thiết bị Windows tự động tải cấu hình proxy khi tham gia mạng mới. WPAD kiểm tra cả DHCP lẫn DNS — và gateway đang kiểm soát cả hai.

Một WPAD hijack thành công sẽ đẩy file cấu hình proxy độc hại xuống thiết bị victim. Sau đó, Chrome, các thành phần xác thực của Windows và phần lớn enterprise application đều route traffic qua proxy của kẻ tấn công. Traffic log hiện ra giống HTTPS connection bình thường — rất dễ bị bỏ qua trong quá trình điều tra.

### Giai đoạn 4: Trang đăng nhập giả

Victim mở trình duyệt và được chuyển hướng đến **trang đăng nhập Microsoft 365 giả mạo**. Trang này được thiết kế để trông hợp lệ. Credential nhập vào bị thu thập và gửi về infrastructure của attacker.

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/8a77caf0-2167-4d54-bc05-e3ace8469d2c.png align="center")

### Giai đoạn 5: **MFA Bypass**

Đây là kỹ thuật nguy hiểm nhất trong chiến dịch. Thay vì chỉ thu thập password, kẻ tấn công paired redirect với abuse **Microsoft Device Code Authentication flow**:

1.  Kẻ tấn công khởi tạo một device-code authentication session từ phía mình
    
2.  Victim thấy một màn hình đăng nhập Microsoft trông hoàn toàn hợp lệ
    
3.  Victim approve — vô tình ủy quyền cho session do attacker khởi tạo
    
4.  Microsoft cấp valid **OAuth access token** và **refresh token** cho software do attacker kiểm soát
    
5.  Kẻ tấn công có quyền truy cập đầy đủ vào tài khoản — MFA đã được thỏa mãn
    

**Không có credential nào thay đổi tay.** Password reset không đủ để chấm dứt quyền truy cập nếu attacker-enrolled device vẫn còn active trong tenant.

## **Phân Tích Kỹ Thuật Chi Tiết**

### **Tại Sao DNS Hard-Coded Không Giúp Được**

Một misconception phổ biến: "Tôi đã set DNS cố định là 8.8.8.8 hoặc 1.1.1.1, vậy tôi an toàn."

Sai. Một DNS query gửi đến `8.8.8.8` vẫn rời thiết bị dưới dạng **plaintext UDP packet trên port 53**. Gateway nằm giữa thiết bị và internet — nó có thể đọc query đó, forge một reply hợp lệ và trả về trước khi packet thực sự đến được Google DNS. Từ góc độ của thiết bị, mọi thứ trông hoàn toàn bình thường.

### **Giới Hạn Của Encrypted DNS**

DNS over HTTPS (DoH) và DNS over TLS (DoT) có thể ngăn chặn tấn công này — nhưng **chỉ khi cấu hình ở strict mode**. Phần lớn công cụ hiện tại mặc định chạy ở **opportunistic mode**: khi encrypted resolution thất bại (ví dụ bị gateway block), hệ thống tự động fallback về plaintext DNS.

Chính fallback này là thứ gateway bị poison khai thác. Thiết bị mà người dùng tin rằng đang được bảo vệ thực ra đang giao tiếp DNS hoàn toàn không mã hóa — và bị chuyển hướng.

Hai cấu hình ngăn chặn được tấn công này:

*   **Strict-mode DoH hoặc DoT** — loại bỏ hoàn toàn fallback plaintext
    
*   **Full-tunnel VPN** — mọi traffic bao gồm DNS đều đi qua corporate network trước khi gateway có cơ hội can thiệp
    

### **Kiến Trúc Operator Panel**

Đội ngũ phân tích phát hiện một attacker domain có host **operator panel** với các tính năng:

*   Page rotation (luân phiên giao diện giả mạo)
    
*   Visitor tracking
    
*   IP allowlisting (cloaking — ẩn khỏi security researcher)
    

Sự tồn tại của cơ sở hạ tầng vận hành này chứng minh operation vẫn đang được **maintain tích cực** — không phải chiến dịch spray-and-pray bỏ mặc sau khi triển khai.

## **IOC & Artifacts**

### **Malicious IP**

*   **38.146.28\[.\]75**
    
*   **31.57.243\[.\]154**
    
*   **104.194.159\[.\]150**
    

### Malicious Domain

*   **m365-owa\[.\]com**
    
*   **owa-ms365\[.\]com**
    
*   **ms365-device\[.\]com**
    
*   **ms365-live\[.\]com**
    
*   **chikolimdrid\[at\]gmail\[.\]com**
    

## **MITRE ATT&CK Mapping**

| **Tactic** | **Technique ID** | **Technique Name** | **Ghi Chú** |
| --- | --- | --- | --- |
| Initial Access | T1078 | Valid Accounts | Admin credential yếu/tái sử dụng trên gateway |
| Initial Access | T1190 | Exploit Public-Facing Application | Exposed SSH, SNMP, web admin |
| Defense Evasion | T1557 | Adversary-in-the-Middle | DNS poisoning tại captive portal |
| Defense Evasion | T1562 | Impair Defenses | Bypass encrypted DNS qua fallback exploitation |
| Credential Access | T1556 | Modify Authentication Process | Device code flow abuse |
| Credential Access | T1528 | Steal Application Access Token | OAuth token thu thập qua device code |
| Collection | T1056.003 | Web Portal Capture | Fake Microsoft 365 login page |
| Lateral Movement | T1185 | Browser Session Hijacking | WPAD proxy redirect |
| Command & Control | T1071.001 | Web Protocols | Traffic qua attacker-controlled proxy |
| Command & Control | T1090 | Proxy | WPAD-pushed malicious proxy config |

## **Nhận Định**

Chiến dịch này đánh dấu một bước leo thang đáng chú ý trong TTP của DNS poisoning: lần đầu tiên kỹ thuật này được triển khai **có hệ thống** trên hospitality-grade captive portal infrastructure — không phải SOHO router ở văn phòng nhỏ như FrostArmada trước đó.

**Về attribution:** Overlap kỹ thuật với APT28/FrostArmada là rõ ràng — cùng cơ chế DNS poisoning để đánh cắp Microsoft credential, cùng abuse device code authentication. Tuy nhiên, domain và IP infrastructure không match với những gì đã biết về APT28. Cách kẻ tấn công redirect **toàn bộ DNS query** thay vì lọc có chọn lọc theo keyword cũng gợi ý đây là một operator kém tinh vi hơn — có thể là copycat financially-motivated, có thể là actor khác đã học TTP từ báo cáo FrostArmada. Đội ngũ phân tích của chúng tôi không đủ cơ sở để gán attribution tại thời điểm này.

**Điều thực sự đáng lo ngại hơn attribution** là tốc độ lan rộng của attack surface. FrostArmada nhắm SOHO routers — thiết bị có hàng triệu đơn vị nhưng phân tán. Captive portal khách sạn tập trung hơn: một gateway duy nhất của hotel tại hội nghị quốc tế có thể expose hàng trăm corporate executive trong 2-3 ngày.

**Góc nhìn từ thị trường Việt Nam:** Hà Nội và TP.HCM đang là điểm đến MICE (Meetings, Incentives, Conferences, Exhibitions) tăng trưởng mạnh của khu vực Đông Nam Á. Khách sạn 4-5 sao phục vụ đông đảo corporate traveler từ tập đoàn tài chính, công nghệ và năng lượng — đúng profile nạn nhân của chiến dịch này. Các hội nghị lớn (APEC, ASEAN-related events, các summit ngành) tập trung hàng nghìn executive vào cùng một mạng guest network. Đây là mục tiêu có giá trị cao.

Theo quan sát của chúng tôi qua hoạt động SOC, **outbound DNS anomaly từ traveling endpoints** thường không được ưu tiên trong triage — bởi vì DNS traffic từ endpoint đang ở ngoài office network vốn đã "bất thường" theo định nghĩa. Đây chính xác là lý do kỹ thuật này hoạt động hiệu quả: nó khai thác blind spot trong monitoring logic của phần lớn SOC team.

Pattern lớn hơn cần theo dõi: sau khách sạn, attack surface tự nhiên tiếp theo là airport lounge Wi-Fi, conference center network và co-working space — tất cả đều sử dụng captive portal architecture tương tự, thường với tiêu chuẩn bảo mật thấp hơn.

## **Khuyến Nghị**

### **Dành cho nhân viên đi công tác**

**Bật VPN TRƯỚC khi kết nối Wi-Fi khách sạn - không phải sau**

*   Đây là thói quen quan trọng nhất. Thứ tự đúng là: Kết nối Wi-Fi → BẬT VPN NGAY → sau đó mới dùng internet
    
*   **Tại sao thứ tự này quan trọng?** Bởi vì DNS poisoning xảy ra ngay khi thiết bị của bạn kết nối vào mạng và gửi DNS query đầu tiên. Nếu VPN chưa bật, DNS query đó đã đi qua gateway bị poison rồi — dù bạn bật VPN sau vài giây.
    

**Không approve bất kỳ MFA prompt nào mà bạn không tự khởi tạo**

*   Nếu đang ngồi ở khách sạn và đột nhiên có màn hình Microsoft yêu cầu xác nhận đăng nhập mà bạn không nhớ là mình vừa đăng nhập vào gì — **từ chối ngay**.
    
*   Kỹ thuật Device Code abuse hoạt động bằng cách khiến bạn approve một session mà chính kẻ tấn công đã khởi tạo. Nếu bạn không chủ động mở ứng dụng hoặc đăng nhập vào gì, thì không có lý do gì để có MFA popup cả.
    
*   Quy tắc đơn giản: **Không nhớ mình vừa làm gì → Không approve.**
    

**Kiểm tra URL và chứng chỉ trước khi nhập mật khẩu**

*   Trước khi gõ bất kỳ mật khẩu nào, nhìn lên thanh địa chỉ:
    
*   Hợp lệ:
    
    *   [https://login.microsoftonline.com](https://login.microsoftonline.com) (khóa xanh, URL chính xác)
        
*   Giả mạo:
    
    *   [https://login.microsoftonline.com.verify-now.net](https://login.microsoftonline.com.verify-now.net)
        
    *   [https://m1crosoft-login.com](https://m1crosoft-login.com)
        
    *   http:// (không có "s" sau http)
        

**Ưu tiên dùng dữ liệu di động (4G/5G) thay vì Wi-Fi khách sạn khi làm việc nhạy cảm**

*   Khi cần truy cập email công ty, hệ thống nội bộ hoặc tài liệu quan trọng - dùng hotspot từ điện thoại cá nhân sẽ an toàn hơn nhiều so với Wi-Fi khách sạn. Kẻ tấn công không thể poison DNS trên kết nối 4G của bạn.
    

### **Dành cho IT / Security Team**

**Ưu tiên cao — Làm trong tuần này**

*   **Enforce always-on VPN với full-tunnel cho traveling devices:** Full-tunnel đảm bảo 100% traffic - kể cả DNS - đi qua hạ tầng công ty trước khi thiết bị "nhìn thấy" mạng bên ngoài. Split-tunnel mở exception cho một số domain là đủ để attacker khai thác.
    
*   Kiểm tra VPN hiện tại có đang split-tunnel không: Get-VpnConnection | Select-Object Name, SplitTunneling, Routes
    
*   Nếu SplitTunneling = True → cần review và loại bỏ exception không cần thiết
    
*   **Block Device Code Authentication Flow trong Microsoft Entra ID**
    
*   **Disable WPAD trên toàn bộ endpoint qua Group Policy**
    

**Ưu tiên trung bình — Làm trong tháng này**

*   **Rà soát Entra ID logs sau mỗi chuyến công tác dài ngày**  
      
    `// Microsoft Sentinel — Hunt for suspicious Device Code sign-ins`
    
    `SigninLogs`
    
    `| where AuthenticationProtocol == "deviceCode"`
    
    `| where ResultType == 0 // Thành công`
    
    `| extend Country = tostring(LocationDetails.countryOrRegion)`
    
    `| project TimeGenerated, UserPrincipalName, IPAddress, Country, AppDisplayName`
    
    `| where Country !in ("Vietnam") // Thay bằng danh sách quốc gia baseline của org`
    
    `| order by TimeGenerated desc`
    
*   **Kiểm tra proxy artifact trên máy sau khi nhân viên về từ công tác**
    
*   **Review Entra ID registered devices — thu hồi device lạ**
    

**Dài hạn — Cải thiện kiến trúc**

*   **Cập nhật Travel Security Policy** — Quy định rõ ràng: Wi-Fi công cộng = **untrusted by default**. VPN phải bật trước khi kết nối. Không dùng Wi-Fi khách sạn cho công việc nhạy cảm nếu không có VPN.
    
*   **Strict-mode DNS over HTTPS (DoH)** — Chromium-based browsers đã hỗ trợ. Deploy policy để enforce strict mode, loại bỏ fallback về plaintext DNS khi encrypted resolution thất bại.
    
*   **Đưa nội dung tấn công này vào Security Awareness Training** — Thay vì nói chung chung "cẩn thận Wi-Fi công cộng", đưa kịch bản cụ thể này vào: *"Bạn kết nối Wi-Fi khách sạn, không nhấp gì, vẫn bị mất tài khoản. Đây là lý do bạn phải bật VPN trước."*
    

## **Tài Liệu Tham Khảo**

[Hackers Hijack Hotel Wi-Fi to Steal Microsoft 365 Credentials](https://securityaffairs.com/196017/security/hackers-hijack-hotel-wi-fi-to-steal-microsoft-365-credentials.html)

[DNS Poisoning Tactics Expand to Hospitality Wi-Fi | ReliaQuest Threat Spotlight](https://reliaquest.com/blog/threat-spotlight-dns-poisoning-tactics-expand-to-hospitality/)

[Hotel Wi-Fi DNS Poisoning Attacks Hijack Microsoft 365 Accounts](https://www.safestate.com/post/hotel-wi-fi-dns-poisoning-attacks-hijack-microsoft-365-accounts)

[Hackers hijack hotel Wi-Fi DNS to steal Microsoft 365 accounts](https://www.bleepingcomputer.com/news/security/hackers-hijack-hotel-wi-fi-dns-to-steal-microsoft-365-accounts/)