Tại sao Microsoft lại chuyển hướng lưu lượng truy cập của example.com đến một công ty ở Nhật Bản

Tác giả dangkhoa 06/02/2026 13 phút đọc

Tại sao Microsoft lại chuyển hướng lưu lượng truy cập của example.com đến một công ty ở Nhật Bản?

Tính năng tự động phát hiện của công ty đã khiến thông tin đăng nhập thử nghiệm của người dùng bị gửi ra ngoài mạng lưới của Microsoft.    

error-message-1000x648
 
Nguồn ảnh: Getty Images

Từ Phòng Điều tra các Hiện tượng Bất thường: Microsoft đã ngăn chặn một hiện tượng bất thường không rõ nguyên nhân trên mạng của mình, khiến lưu lượng truy cập hướng đến example.com—một tên miền dành riêng cho mục đích thử nghiệm—bị chuyển hướng đến một nhà sản xuất cáp điện tử đặt tại Nhật Bản.

Theo RFC2606 —một tiêu chuẩn chính thức do Lực lượng Đặc nhiệm Kỹ thuật Internet (Internet Engineering Task Force) duy trì—tên miền example.com không thể được bất kỳ bên nào đăng ký. Thay vào đó, nó được phân giải thành các địa chỉ IP được gán cho Cơ quan Tên miền được Gán trên Internet (Internet Assigned Names Authority). Việc chỉ định này nhằm mục đích ngăn chặn các bên thứ ba bị quá tải lưu lượng truy cập khi các nhà phát triển, chuyên gia kiểm thử xâm nhập và những người khác cần một tên miền để thử nghiệm hoặc thảo luận các vấn đề kỹ thuật. Thay vì đặt tên cho một tên miền có thể định tuyến trên Internet, họ phải chọn example.com hoặc hai tên miền khác là example.net và example.org.

Lỗi cấu hình đã biến mất, nhưng liệu vấn đề đã được khắc phục hoàn toàn chưa?

Kết quả từ lệnh cURL trên terminal cho thấy các thiết bị bên trong Azure và các mạng khác của Microsoft đã định tuyến một số lưu lượng truy cập đến các tên miền phụ của sei.co.jp, một tên miền thuộc về Sumitomo Electric. Hầu hết văn bản kết quả đều đúng như mong đợi. Ngoại lệ là phản hồi dựa trên JSON. Đây là đầu ra JSON từ thứ Sáu:

{"email":"email@example.com","services":[],"protocols":[{"protocol":"imap","hostname":"imapgms.jnet.sei.co.jp","port":993,"encryption":"ssl","username":"email@example.com","validated":false},{"protocol":"smtp","hostname":"smtpgms.jnet.sei.co.jp","port":465,"encryption":"ssl","username":"email@example.com","validated":false}]}

Tương tự, kết quả khi thêm tài khoản mới cho test@example.com trong Outlook trông như sau:

 

microsoft-example-com-01

 

 

microsoft-example-com-02

 

Trong cả hai trường hợp, kết quả cho thấy Microsoft đang định tuyến lưu lượng email đến hai tên miền phụ sei.co.jp: imapgms.jnet.sei.co.jp và smtpgms.jnet.sei.co.jp. Hành vi này là kết quả của dịch vụ tự động phát hiện của Microsoft .

“Tôi thừa nhận mình không phải chuyên gia về hoạt động nội bộ của Microsoft, nhưng đây dường như chỉ là một lỗi cấu hình đơn giản,” Michael Taggart , một nhà nghiên cứu an ninh mạng cấp cao tại UCLA Health, cho biết. “Kết quả là bất kỳ ai cố gắng thiết lập tài khoản Outlook trên tên miền example.com đều có thể vô tình gửi thông tin đăng nhập thử nghiệm đến các tên miền phụ sei.co.jp đó.”

Khi được hỏi vào đầu giờ chiều thứ Sáu lý do tại sao Microsoft lại làm như vậy, một đại diện không ó câu trả lời và yêu cầu thêm thời gian. Đến sáng thứ Hai, việc định tuyến sai không còn xảy ra nữa, nhưng đại diện đó vẫn không có câu trả lời.

Cập nhật: Trong một email được gửi sau khi bài đăng này được công bố, người đại diện đã xác nhận rằng Microsoft đã “cập nhật dịch vụ để không còn cung cấp thông tin máy chủ được đề xuất cho example.com nữa”. Như đã được báo cáo ở đây, sự cố này chỉ ảnh hưởng đến những người cấu hình tài khoản email thông qua tính năng tự động cấu hình của Outlook. Người đại diện cho biết thêm rằng Microsoft đang điều tra vấn đề này.

Phản hồi JSON mới cho thấy rằng, tính đến sáng thứ Hai, Microsoft vẫn chưa khắc phục được sự cố định tuyến lưu lượng truy cập điểm cuối đến máy chủ Sumitomo Electric. Thay vào đó, phản hồi JSON không còn xuất hiện nữa. Trong khi trước đây vào thứ Sáu, lệnh vẫn hiển thị thông báo lỗi, thì giờ đây nó chỉ đứng yên và treo trong 10 hoặc 20 giây rồi kết thúc với lỗi "không tìm thấy". Hành vi này có thể được thấy trong kết quả đầu ra sau:

> GET /autodetect/detect?app=outlookdesktopBasic HTTP/2
> Máy chủ: prod.autodetect.outlook.cloud.microsoft
> Ủy quyền: Cơ bản ZW1haWxAZXhhbXBsZS5jb206cGFzc3dvcmQ=
> User-Agent: curl/8.14.1
Chấp nhận: */*
>
* Yêu cầu đã được gửi hoàn toàn
* TLSv1.3 (IN), bắt tay TLS, Vé Newsession (4):
* TLSv1.3 (IN), bắt tay TLS, Vé Newsession (4):
< HTTP/2 204
< ngày: Thứ Hai, ngày 26 tháng 1 năm 2026 18:23:55 GMT
< máy chủ: Kestrel
< strict-transport-security: max-age=2592000
< x-olm-source-endpoint: /detect
< x-provider-id: Không xác định
< x-debug-support: eyJkZWNpc2lvbiI6ImF1dG9EdjIgPiBhdXRvRHYxID4gZml4ZWQgZGIgcHJvdmlkZXIgPiBmaXhlZCBkYiBkb21haW4gcHJvdG9jb2xzID4gZGIgcHJvdmlkZXIgPiBkYiBkb21haW4gcHJvdG9jb2xzIiwiYXV0b0QiOnsi djIiOm51bGwsInYxIjpudWxsfSwiZGIiOnsicHJvdmlkZXIiOm51bGwsImRvbWFpbiI6eyJmaXhlZCI6ZmFsc2UsImF1dG9EdjJFbmRwb2ludCI6bnVsbCwicHJvdmlkZXJJZCI6bnVsbCwicHJvdG9jb2xzIjpudWxsfX19
< x-autodv2-error: ENOTFOUND

“Có vẻ như họ đã loại bỏ hoàn toàn điểm cuối xác thực email, vì tôi thấy lỗi 'không tìm thấy',” Dan Tentler , người sáng lập Phobos Group, cho biết. Như được chỉ ra bởi ENOTFOUND, lỗi này “cho thấy [các quản trị viên của Microsoft] đã loại bỏ hoàn toàn thứ gì đó liên quan đến thành phần này.”

Hiện vẫn chưa rõ làm thế nào tên miền của Sumitomo Electric lại bị cuốn vào mớ hỗn độn này. Năm ngoái, Microsoft cho biết công ty mẹ của Sumitomo Electric, Sumitomo Corp., đang triển khai Microsoft 365 Copilot, nhưng điều đó vẫn không giải thích được tại sao tên miền của một công ty con lại được thêm vào cấu hình mạng của Microsoft.

Các câu hỏi được gửi đến Microsoft bao gồm: Các bản ghi tự động phát hiện được thêm vào tại Microsoft như thế nào; việc định tuyến này có phải là cố ý hay không; và hiện tượng này đã xảy ra trong bao lâu? (Tinyapps.org, trang web đã ghi nhận hành vi định tuyến kỳ lạ này vào đầu tháng, cho biết nó đã kéo dài năm năm.) Dường như không có gì bất chính về việc định tuyến không đúng cách này, và miễn là những người bên trong mạng lưới của Microsoft không gửi thông tin đăng nhập thực trong các thử nghiệm, thì sẽ không có nguy hiểm nào xảy ra.

Vẫn còn lý do để lo ngại. Năm 2024, Microsoft tiết lộ rằng một trong những quản trị viên của họ đã cấp quyền quản trị cho một tài khoản thử nghiệm trên mạng nội bộ công ty rồi quên mất. Các hacker nhà nước Nga đã lợi dụng sơ suất này để giành quyền truy cập ban đầu vào hệ thống của Microsoft. Sau đó, họ đã xâm nhập mạng lưới và theo dõi email của các giám đốc điều hành cấp cao trong hai tháng. Lỗi cấu hình định tuyến đối với example.com đặt ra câu hỏi: Liệu còn những lỗi nghiêm trọng nào khác có thể tiềm ẩn trên mạng lưới hay không?

Tác giả dangkhoa Admin
Bài viết trước Tiện ích mở rộng trình duyệt với 8 triệu người dùng thu thập các cuộc hội thoại AI mở rộng

Tiện ích mở rộng trình duyệt với 8 triệu người dùng thu thập các cuộc hội thoại AI mở rộng

Bài viết tiếp theo

Không nên tự build PC gaming 1.000 USD vào năm 2026

Không nên tự build PC gaming 1.000 USD vào năm 2026
Viết bình luận
Thêm bình luận

Bài viết liên quan

Thông báo

0917111899