# Forg365: Bộ Kit Phishing Giá 400 USD Có Thể Chiếm Tài Khoản Microsoft 365 Ngay Cả Khi Bạn Đổi Mật Khẩu

## Tóm tắt tổng quan

**Forg365** là một nền tảng phishing-as-a-service nhắm Microsoft 365, bán qua Telegram với giá **$400/tháng hoặc $3,800/năm**, kèm **5 ngày dùng thử miễn phí**. ZeroBEC công bố phân tích ngày 09/07/2026 sau khi đăng ký được vào panel của chính operator.

Điều làm Forg365 đáng chú ý không phải một kỹ thuật đơn lẻ, mà là **mức độ sản phẩm hoá**. Nó đóng gói toàn bộ chuỗi tấn công identity vào một môi trường subscription:

*   **AI sinh mồi ngay trong panel** — operator không cần công cụ ngoài, viết và tinh chỉnh email phishing trong cùng dashboard quản lý SMTP, link và mailbox nạn nhân
    
*   **Hai nhánh tấn công song song**: device-code phishing (nạn nhân nhập mã trên trang Microsoft thật) và AiTM (proxy để bắt session cookie)
    
*   **AntiBot**: SVG redirector mã hoá AES, debugger trap, sandbox check, polymorphic code; traffic từ VPN bị chuyển hướng sang một trang mồi nhử vô hại
    
*   **Token Vault, Account Intel, Keyword Listener, Viewer Links** — hạ tầng khai thác mailbox sau khi chiếm được
    
*   **ForgCookie** — extension trình duyệt tự làm mới Microsoft SSO cookie, giữ quyền truy cập lâu dài
    

Câu quan trọng nhất cho SOC nằm ở đây: **ForgCookie chạy trên trình duyệt của kẻ tấn công, không phải của nạn nhân**. Nó tự động refresh refresh-token credential, nghĩa là **session của attacker có thể sống sót qua việc reset mật khẩu** nếu bạn không revoke ở tầng identity. Đây là chi tiết dễ hiểu sai nhất trong toàn bộ vụ này, và tôi sẽ quay lại ở phần riêng.

Với MSSP: nếu tenant khách hàng của bạn chưa chặn device code flow bằng Conditional Access thì đây là món nợ kỹ thuật đang đến hạn. Microsoft xếp device code flow là **phương thức xác thực rủi ro cao** và khuyến nghị chặn ở mọi nơi có thể; CISA cũng khuyến nghị tương tự.

## Bối cảnh: 2026 là năm device-code phishing lên ngôi

Trước khi đi vào Forg365, cần hiểu tại sao nó không phải hiện tượng đơn lẻ.

Device code flow là cơ chế OAuth 2.0 hợp pháp (RFC 8628), sinh ra cho thiết bị không có bàn phím: smart TV, màn hình phòng họp, máy in, công cụ CLI. Thiết bị hiển thị một mã ngắn, người dùng nhập mã đó trên trang Microsoft thật từ một máy khác, Microsoft cấp token cho thiết bị đang chờ.

Kẻ tấn công lật ngược thiết kế này: **chúng khởi tạo luồng trên hạ tầng của mình, gửi mã cho nạn nhân, và thuyết phục nạn nhân nhập mã đó vào trang Microsoft thật**. Nạn nhân hoàn thành MFA đầy đủ, trên đúng domain của Microsoft, với SSL hợp lệ. Token được cấp cho attacker.

Hậu quả kỹ thuật rất khó chịu:

*   **Không có mật khẩu nào bị đánh cắp**
    
*   **Không có prompt MFA bất thường nào** — nạn nhân tự thoả mãn MFA
    
*   **Không có trang giả nào để bắt** — trang cuối là trang Microsoft thật
    
*   Mọi lời khuyên kiểu "kiểm tra URL" đều vô dụng
    

Push Security ghi nhận số trang device-code phishing họ phát hiện trong năm 2026 tăng **37,5 lần**, và đã đếm được **hơn 14 kit khác nhau** đang lưu hành, trong đó EvilTokens phổ biến nhất. Xu hướng rõ ràng: các kit AiTM sẵn có đang bổ sung device-code phishing — Tycoon2FA, kit dẫn đầu mảng AiTM tội phạm, gần đây đã thêm tính năng này bên cạnh AiTM truyền thống.

Mốc thời gian đáng nhớ: khai thác thực tế đầu tiên được ghi nhận tháng 8/2024 với **Storm-2372** (Microsoft và Volexity theo dõi, liên hệ Nga), nhắm mục tiêu tình báo chiến lược. Từ đầu 2026, kỹ thuật này chuyển sang **mainstream tội phạm**.

Điều đáng nói với đội SOC: MFA không hỏng. Nhưng như một nhà phân tích diễn đạt rất chính xác — **device-code phishing không cần đánh bại mật mã, nó chỉ cần đánh bại nghi thức**. Nếu nạn nhân tin rằng mã đến từ một dịch vụ chia sẻ tài liệu đáng tin, kẻ tấn công cưỡi trên chính quy trình xác thực hợp pháp để đi vào tài khoản.

## Thông tin nền tảng

| Thuộc tính | Chi tiết |
| --- | --- |
| Tên | Forg365 |
| Phân loại | Kali365-class Microsoft 365 token-focused PhaaS |
| Công bố | ZeroBEC, 09/07/2026 |
| Phân phối | Telegram (onboarding, thanh toán, support) |
| Giá | Trial 5 ngày, $400/tháng, $3,800/năm |
| Panel chính | `hxxps://logfriend[.]com/login` |
| Backend liên kết chiến dịch | `xoday[.]sbs` / `139[.]28[.]38[.]129` (Kyiv, Ukraine) |
| Nhánh tấn công | Device-auth phishing + AiTM |
| Delivery | Amazon SES, SendGrid (tracking), Gophish |
| Landing | Cloudflare Pages / Workers (`*.pages[.]dev`) |
| Extension | ForgCookie 1.0.21, Manifest V3 |
| Attribution | Chưa xác định operator |
| Liên hệ Kali365/Sneaky 2FA | **Cùng lớp (class), KHÔNG kết luận chung chủ sở hữu** |

**Về attribution, cần nói rõ.** ZeroBEC viết thẳng: *họ không đánh giá Forg365 có chung chủ sở hữu với Kali365 hay Sneaky 2FA dựa trên bằng chứng hiện có*. BleepingComputer đưa tin cũng nhất quán: nhiều tính năng trùng với Kali365 và Sneaky2FA nhưng không thiết lập được liên hệ. Cách diễn đạt an toàn: Forg365 **kết hợp workflow device-auth/token kiểu Kali365 với AiTM và evasion kiểu Sneaky 2FA** — trùng lặp về vận hành và kiến trúc, không phải bằng chứng cùng chủ.

## Mô hình thương mại: Telegram và $400/tháng

![Forg365 primary panel welcome message](https://zerobec.com/blog/forg365_panel_welcome.png align="center")

*Hình 1. Welcome message của panel Forg365 — quảng cáo full inbox access, cookie generation, automatic session refresh, real-time inbox sync, và "no need to re-authenticate"*

Đọc kỹ dòng quảng cáo này. Đây không phải một trang phishing. Đây là **bản mô tả tính năng của một sản phẩm SaaS** — chỉ khác là sản phẩm bán quyền truy cập vào hộp thư của người khác.

![Telegram-based operator setup and bot-management flow](https://zerobec.com/blog/forg365_telegram_setup.png align="center")

*Hình 2. Luồng onboarding và quản lý bot qua Telegram*

| Tín hiệu thương mại | Quan sát | Ý nghĩa |
| --- | --- | --- |
| Phân phối | Telegram onboarding + support | Khớp mô hình PhaaS hiện đại |
| Dùng thử | 5 ngày miễn phí | Phễu chuyển đổi kiểu SaaS |
| Giá tháng | $400 | Mức giá của dịch vụ được duy trì |
| Giá năm | $3,800 | Ngụ ý subscription dài hạn có hỗ trợ |
| Support | Panel dẫn sang Telegram | Nền tảng được bảo trì, không chỉ phát tán code |

Mức $400/tháng đặt Forg365 **thấp hơn một chút** so với tầng trên của thị trường (EvilTokens ~$500/tháng cộng $1,500 phí setup) nhưng **cao hơn Kali365** ($250/tháng, $2,000/năm theo Arctic Wolf). Nó không phải kit rẻ tiền dùng một lần.

Panel được tổ chức như một sản phẩm thật. Navigation trái gồm Home, Accounts, Links, Send, Activity, Others, Settings. Mục Links có Invitations, OAuth App, Redirect Link, SVG Generator.

| Module | Năng lực |
| --- | --- |
| Invitations | Mồi device-auth và verification, có live preview và Persistent Mode |
| OAuth App | Workflow OAuth consent phishing cấu hình được |
| Redirect Link | Routing redirect theo chiến dịch |
| SVG Generator | SVG redirector mã hoá AES kèm anti-bot |
| Send | Campaign, email group, SMTP profile, template, scheduling |
| AI Generate | Sinh email và mồi phishing ngay trong panel |
| Token Vault | Giám sát, import, export, quản lý token đã bắt |
| Account Intel | Tình báo tài khoản sau khi chiếm |
| Keyword Listener | Giám sát từ khoá trong mailbox và cảnh báo |
| Viewer Links | Chia sẻ quyền đọc mailbox có mật khẩu và hạn dùng |
| ForgCookie | Sinh và refresh Microsoft SSO cookie phía trình duyệt |

![Forg365 Invitations module](https://zerobec.com/blog/forg365_invitations_module.png align="center")

*Hình 3. Module Invitations — template dựng sẵn gồm Adobe Acrobat Sign, DocuSign, Voicemail, Email Quarantine, Password Reset, Calendar Invite, SharePoint, OneDrive và eFax*

Danh sách template này đáng để đội security awareness đọc. Đây chính xác là **những loại thông báo mà nhân viên xử lý mỗi ngày mà không nghĩ ngợi**. Không có gì kỳ lạ, không có tiếng Anh sai ngữ pháp, không có deadline giả tạo áp lực.

## Kill chain: từ email đến mailbox

### Bước 1: Email mồi qua hạ tầng hợp pháp

![Initial email lure observed by ZeroBEC](https://zerobec.com/blog/forg365_lure_email.png align="center")

*Hình 4. Email mồi ban đầu — pretext business-document, khởi động chuỗi redirect*

```plaintext
Bằng chứng delivery
Kiểu người gửi:  business-document / remittance approval lure
Tầng gửi:        Amazon SES trong message header
Nội dung nhúng:  ảnh/tracking host trên SendGrid trong HTML body
Chuỗi tiếp theo: security wrapper -> redirect chain -> nhánh AiTM hoặc device-auth
```

Điểm này quan trọng với đội email security: **Amazon SES và SendGrid đều là dịch vụ hợp pháp có danh tiếng IP tốt**. SPF, DKIM, DMARC đều hợp lệ. Reputation-based filtering gần như không có gì để bám vào. ZeroBEC lưu ý rõ: các dịch vụ security-wrapping xuất hiện trong chuỗi URL **không nên bị coi là độc hại chỉ vì có mặt ở đó**.

### Bước 2: Phân loại traffic và cloaking

Đây là nơi Forg365 quyết định bạn là ai. Nhánh AiTM dùng PHP session state, cookie `preload`, và một **route token dạng chuỗi từ-số dài** lưu trong cookie `rt`:

```plaintext
PHPSESSID=<session>
preload=1
rt=frog1_cat2_horse9_light4_soil6_branch7_milk10_paper10_village9_evening4_
   fox3_galaxy5_rock8_fish9_seed1_bread5_ocean7_stone9
```

Khi link được truy cập từ **NordVPN egress**, luồng chuyển hướng sang một **trang mồi nhử vô hại về SpaceX** thay vì hiển thị nội dung phishing.

![Post-classification redirect evidence](https://zerobec.com/blog/forg365_aitm_vpn_decoy.png align="center")

*Hình 5. Traffic từ VPN hoặc nguồn ít tin cậy bị chuyển sang nội dung decoy*

**Bài học vận hành cho analyst**: nếu bạn mở link đáng ngờ qua VPN công ty hoặc sandbox và thấy nội dung vô hại, **đừng kết luận link sạch**. ZeroBEC nói thẳng: hành vi VPN-to-decoy là bằng chứng của anti-analysis, không phải bằng chứng link lành tính. Đây là lỗi triage rất dễ mắc trong môi trường MSSP xử lý hàng trăm báo cáo phishing mỗi ngày.

Lớp evasion còn có SVG Generator, quảng cáo: redirector mã hoá AES, bot detection, debugger trap, kiểm tra headless/automation, fingerprint sandbox và VM, polymorphic code.

![SVG AntiBot Generator](https://zerobec.com/blog/forg365_svg_antibot.png align="center")

*Hình 6. SVG AntiBot Generator trong panel*

Đây là thiết kế để **sống sót qua detonation của email security gateway**, không phải một kit phishing cơ bản.

### Bước 3a: Nhánh device-auth

![Forg365 device-auth phishing branch](https://zerobec.com/blog/forg365_device_auth_landing.png align="center")

*Hình 7. Nhánh device-auth — trang hiển thị mã xác minh và hướng dẫn nạn nhân đăng nhập Microsoft Authentication Broker trên thiết bị khác*

Nạn nhân thấy giao diện Microsoft, nhập mã trên trang Microsoft thật, hoàn thành MFA. Session được cấp phép là của attacker. **Không có gì để người dùng đánh giá** — bề mặt xác thực cuối cùng là hợp pháp ngay cả khi session được uỷ quyền thì không.

### Bước 3b: Nhánh AiTM

![Forg365 AiTM authentication-interception branch](https://zerobec.com/blog/forg365_aitm_branch.png align="center")

*Hình 8. Nhánh AiTM — giao diện đăng nhập kiểu Microsoft để bắt hoặc relay xác thực bằng mật khẩu*

Nhánh này **tách biệt** với nhánh device-auth. Nó proxy request xác thực giữa Microsoft và nạn nhân, bắt session cookie trong quá trình đó. Nhánh AiTM cũng nạp telemetry Cloudflare và duy trì Socket.IO qua một WebSocket host riêng (`manlivep[.]org/socket.io/`).

### Bước 4: Hạ tầng tách vai trò

![Role-separated Forg365 operating model](https://zerobec.com/blog/forg365_role_separated.png align="center")

*Hình 9. Mô hình vận hành tách vai trò của Forg365*

| Vai trò | Hạ tầng |
| --- | --- |
| Panel chính | `logfriend[.]com/login` |
| Panel variant / backend | `xoday[.]sbs` / `139[.]28[.]38[.]129` |
| AntiBot admin | `panel.ructus[.]site`, `panel.incogxray[.]sbs`, `185[.]174[.]101[.]1` |
| Campaign delivery | `go.incogxray[.]sbs` (Gophish) |
| Victim landing | `*.pages[.]dev` |
| Session persistence API | `logfriend[.]com/api/extension/*` |

Việc tách vai trò này có ý nghĩa phòng thủ: **block một domain không đủ**. Landing page trên Cloudflare Pages có thể xoay vòng trong vài phút, trong khi API persistence và panel nằm ở nơi khác hoàn toàn.

Một chi tiết thú vị: hạ tầng lộ ra một **trang login Gophish** trên `go.incogxray[.]sbs`, với branding mặc định, logo stock, và cookie `_gorilla_csrf` cùng `gophish`.

![Gophish delivery component](https://zerobec.com/blog/forg365_gophish_login.png align="center")

*Hình 10. Thành phần delivery Gophish*

ZeroBEC cẩn thận ở đây và tôi đánh giá cao: **điều này không có nghĩa Forg365 được xây từ Gophish**. Nó có nghĩa hệ sinh thái operator dùng Gophish mã nguồn mở làm thành phần gửi campaign bên cạnh nền tảng Forg365 tuỳ chỉnh. Một công cụ red team hợp pháp bị tái sử dụng — không phải lần đầu và sẽ không phải lần cuối.

### Bước 5: Khai thác sau xâm nhập

![Forg365 Token Vault page](https://zerobec.com/blog/forg365_token_vault.png align="center")

*Hình 11. Token Vault — giám sát access token đã chiếm*

![Forg365 Keyword Listener module](https://zerobec.com/blog/forg365_keyword_listener.png align="center")

*Hình 12. Keyword Listener — giám sát từ khoá trong mailbox và cảnh báo*

![Forg365 Viewer Links module](https://zerobec.com/blog/forg365_viewer_links.png align="center")

*Hình 13. Viewer Links — chia sẻ quyền đọc mailbox có mật khẩu, hạn dùng và ngữ nghĩa "ghost mode"*

Đọc bộ ba này cùng nhau và mô hình kinh doanh hiện ra rõ ràng. **Token Vault** giữ quyền truy cập. **Keyword Listener** quét mailbox tìm từ khoá định trước (hãy đoán: "invoice", "wire", "payment", "bank details") và báo động khi khớp. **Viewer Links** cho phép **bán lại hoặc chia sẻ quyền đọc mailbox** cho bên thứ ba, có mật khẩu và hạn dùng.

Đây không phải công cụ ăn cắp credential. Đây là **hạ tầng BEC**. Nạn nhân không phải endpoint của chuỗi tấn công — nạn nhân là **tài sản được kiếm tiền dài hạn**.

Panel còn có AI mailbox context: operator nạp ngữ cảnh email vào workflow AI để soạn phản hồi hoặc phân tích.

![Forg365 AI mailbox context workflow](https://zerobec.com/blog/forg365_ai_mailbox_context.png align="center")

*Hình 14. AI mailbox context workflow*

## ForgCookie: điểm quan trọng nhất và dễ hiểu sai nhất

![ForgCookie extension workflow](https://zerobec.com/blog/forg365_forgcookie_workflow.png align="center")

*Hình 15. ForgCookie trong panel — định vị là tự động refresh SSO cookie cho dịch vụ Microsoft*

Static analysis cho ra:

```plaintext
Name:        ForgCookie
Version:     1.0.21
Manifest:    V3
Description: Auto-refresh Microsoft SSO cookies for Forg365
API base:    hxxps://logfriend[.]com
Endpoints:   /api/extension/login
             /api/extension/accounts
             /api/extension/generate-cookie
Cookie đích: x-ms-RefreshTokenCredential trên login.microsoftonline[.]com
Silent SSO:  Microsoft Authentication Broker / prompt=none / substrate.office[.]com
```

Vòng lặp hoạt động: ForgCookie xin dữ liệu tài khoản từ backend Forg365 → gọi endpoint sinh cookie cho tài khoản được chọn → **xoá session cookie Microsoft hiện tại** → **inject refresh-token credential cookie đã sinh vào domain login của Microsoft** → kích hoạt luồng OAuth im lặng → bắt cookie Microsoft mới trên các domain Microsoft → lặp lại chu kỳ qua Chrome alarms.

### Chỗ dễ sai

**ForgCookie chạy trên trình duyệt của kẻ tấn công, không phải nạn nhân.**

ZeroBEC nói điều này rất rõ ràng, và nó thay đổi hoàn toàn cách hunt. Nếu bạn đi tìm extension `ForgCookie` trong inventory trình duyệt được quản lý của tổ chức, **bạn sẽ không bao giờ tìm thấy và sẽ kết luận sai là sạch**.

Thay vào đó, hunt **dấu vết nó để lại trong tenant của bạn**:

*   Silent `prompt=none` sign-in lặp đi lặp lại tới `substrate.office[.]com` và các resource Microsoft khác
    
*   Traffic Graph non-interactive từ IP không liên quan gì đến người dùng
    
*   **Session sống sót qua reset mật khẩu** — vì refresh-token material đang được replay từ trình duyệt của attacker
    

Điểm cuối là điểm đau nhất. Trong playbook IR truyền thống, reset mật khẩu là bước một và người ta thở phào. Với Forg365, **reset mật khẩu không làm gì cả**. Phải **revoke session và refresh token ở tầng identity**.

> **Một mâu thuẫn trong chính báo cáo gốc, đáng lưu ý.** Phần "Example hunting logic (conceptual)" của ZeroBEC có dòng *"Browser extension inventory containing ForgCookie"* — mâu thuẫn trực tiếp với lời giải thích rõ ràng của chính họ rằng extension chạy trên máy attacker. Nếu bạn copy checklist đó vào playbook mà không đọc phần thân, bạn sẽ triển khai một detection không bao giờ fire. Hãy theo phần giải thích, bỏ dòng đó.

Chi tiết `hasDeviceRegistration` trong code extension khớp với telemetry Entra cho thấy các device object mang tên Forg365 — nghĩa là extension và luồng device registration là hai phần của cùng một hệ thống persistence.

## Telemetry Entra: bằng chứng thật trong tenant

Đây là phần giá trị nhất của báo cáo với người làm detection, vì nó không dừng ở panel mà nối được sang **telemetry xác thực thật**.

### Địa chỉ Comcast/Xfinity trong luồng device-code

Nhánh device-code sinh ra hoạt động Microsoft Authentication Broker từ `67[.]190[.]46[.]128` — một địa chỉ Comcast/Xfinity cố định tại Mỹ, không thuộc môi trường test của nạn nhân, xuất hiện trong chuỗi Authentication Broker/Microsoft Graph với `originalTransferMethod = deviceCodeFlow`.

Ý nghĩa: **cuộc tấn công không chỉ dựa vào server cloud hay proxy chung chung**. Một mạng cố định dân dụng ở Mỹ xuất hiện trong đường xác thực. Điều đó làm giảm nghi ngờ trong identity telemetry và **phá vỡ việc chặn tự động dựa trên reputation**. Nếu detection của bạn dựa trên "sign-in từ IP hosting/VPS đáng ngờ", nó sẽ im lặng ở đây.

Tiếp theo là hoạt động non-interactive từ **cùng địa chỉ đó** với user agent `node-fetch` — token activity tự động sau khi được uỷ quyền.

### Backend tại Kyiv

Shodan xác định host liên kết chiến dịch là `xoday[.]sbs` trên `139[.]28[.]38[.]129`, đặt tại Kyiv, Ukraine, chạy Ubuntu với nginx, HTTP title là `Forg365`.

![Campaign-linked Forg365 panel variant at xoday.sbs/login](https://zerobec.com/blog/forg365_xoday_panel.png align="center")

*Hình 16. Panel variant tại* `xoday[.]sbs/login`*, Shodan title* `Forg365`

Telemetry Entra non-interactive từ cùng địa chỉ cho thấy hoạt động Microsoft Office/Graph với user agent kiểu node và `originalTransferMethod = deviceCodeFlow`. Audit log ghi nhận **device-registration activity** từ cùng địa chỉ, và tên device có **prefix** `Forg365`.

![Entra device-registration evidence](https://zerobec.com/blog/forg365_entra_device_registration.png align="center")

*Hình 17. Ba thiết bị Microsoft Entra joined được tạo với tên mang prefix Forg365*

**Đây là món quà cho defender.** Operator không buồn đổi tên device mặc định. Huntress từng ghi nhận điều tương tự: một số attacker lười và để nguyên tên máy mặc định, khiến việc phát hiện dễ hơn hẳn. Một query tìm device name khớp `Forg365-*` là detection rẻ và chính xác gần như tuyệt đối.

**Cảnh báo về diễn giải, ZeroBEC nêu rõ:** đừng mô tả *toàn bộ* hạ tầng Forg365 là hosted ở Ukraine. `139.28.38.129` là **node backend liên kết với chiến dịch cụ thể này**, không phải toàn bộ nền tảng. Panel chính hiện tại là `logfriend[.]com`, và `panel.logfriend[.]com` phân giải về cùng IP Ukraine trong test DNS — nối được namespace thương mại hiện hành với backend variant.

## So sánh hệ sinh thái PhaaS Microsoft 365

| Nền tảng | Công bố bởi | Giá | Kỹ thuật chính | Điểm đặc trưng |
| --- | --- | --- | --- | --- |
| **Sneaky 2FA** | Sekoia (12/2024) | Bán license qua Telegram bot | AiTM, harvest session cookie | Chứa code từ W3LL Panel OV6; host trên WordPress bị chiếm |
| **EvilTokens** | Sekoia (03/2026) | $1,500 setup + $500/tháng | Device code + PRT persistence | ~500 Cloudflare Workers domain, 1,000+ trang phishing; pipeline BEC dùng AI chấm điểm rủi ro tài chính |
| **Kali365** | FBI IC3 (21/05/2026) | $250/tháng, $2,000/năm | Device code + AiTM | 3 tầng: Client/Agent/Admin; hỗ trợ 14 ngôn ngữ |
| **ARToken** | Cisco Talos (07/2026) | (build affiliate) | Device code + PRT | 80+ API endpoint; 7 lớp anti-analysis; affiliate của EvilTokens |
| **Forg365** | ZeroBEC (09/07/2026) | $400/tháng, $3,800/năm | Device code + AiTM | AI trong panel; ForgCookie extension; Viewer Links |

Nhìn bảng này thì bức tranh rõ: **đây là một thị trường**, không phải một nhóm. Có phân khúc giá, có tầng đại lý, có affiliate build riêng, có dịch vụ AntiBot bán tách rời như sản phẩm phụ. Các kit clone và fork lẫn nhau — Push Security ghi nhận có kit trông giống EvilTokens đến mức có thể là clone nhưng backend hoàn toàn khác.

**Suy luận của người viết, không phải khẳng định từ vendor nào:** việc Forg365 xuất hiện chỉ ~7 tuần sau cảnh báo FBI về Kali365, với bộ tính năng tương đương và giá cao hơn 60%, gợi ý thị trường này **đang cạnh tranh bằng tính năng chứ không phải bằng giá**. ForgCookie và Viewer Links là những thứ Kali365 không có trong mô tả công khai. Nếu xu hướng này tiếp tục, hướng phát triển tiếp theo hợp lý là **tự động hoá sâu hơn phần kiếm tiền sau xâm nhập**, không phải cải tiến khâu phishing.


## Detection và Threat Hunting

### Kiểm soát mạnh nhất: chặn device code flow

Đây là control có tỷ lệ hiệu quả trên công sức cao nhất trong toàn bộ bài này. Microsoft đã bổ sung điều kiện **Authentication Flows** trong Conditional Access:

```json
{
  "displayName": "Block Device Code Flow",
  "state": "enabled",
  "conditions": {
    "clientAppTypes": ["all"],
    "applications": { "includeApplications": ["All"] },
    "users": { "includeUsers": ["All"] },
    "authenticationFlows": { "transferMethods": "deviceCodeFlow" }
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": ["block"]
  }
}
```

**Nhưng đừng bật mù.** Lời khuyên đúng không phải "chặn device code flow ở mọi nơi vào ngày mai" — một số tenant có phụ thuộc hợp pháp: Azure CLI, PowerShell, Teams Rooms, thiết bị dùng chung, môi trường lab. **Kiểm kê trước, rồi khoét lỗ cho vài workflow thực sự cần, rồi mới chặn phần còn lại.**

Query kiểm kê ai đang dùng device code flow (nguồn: Cloudbrothers, được nhiều nghiên cứu khác dẫn lại):

```kql
SigninLogs
| where TimeGenerated > ago(90d)
| where AuthenticationProtocol == "deviceCode"
| summarize by AppDisplayName, UserId
```

Đáng lo: Huntress ghi nhận khoảng **25% khách hàng đã trả tiền cho Conditional Access nhưng chưa cấu hình**. Với MSSP, đây là câu hỏi đầu tiên nên hỏi mỗi tenant.

Ngoài ra FBI khuyến nghị thêm: **chặn authentication transfer policies** để ngăn người dùng chuyển trạng thái xác thực từ máy tính sang thiết bị di động.

### Hunt trong Entra sign-in log

Query khảo sát cơ bản (nguồn: EtcSec, tham chiếu tài liệu Microsoft):

```kql
SigninLogs
| where TimeGenerated > ago(30d)
| where AuthenticationProtocol == "deviceCode"
      or OriginalTransferMethod == "deviceCodeFlow"
| project TimeGenerated, UserPrincipalName, AppDisplayName, ResourceDisplayName,
          IPAddress, Location, DeviceDetail, UserAgent, ConditionalAccessStatus,
          RiskLevelDuringSignIn, ResultType, SessionId, UniqueTokenIdentifier
| order by TimeGenerated desc
```

Đây là **điểm khởi đầu điều tra, không phải detection hoàn chỉnh**. Một developer xác thực CLI quen thuộc từ mạng quen thuộc là tín hiệu khác hẳn một nhân viên tài chính đột nhiên uỷ quyền device code từ quốc gia mới rồi sinh ra hoạt động Graph.

Tín hiệu tương quan mạnh hơn — so hai chân của luồng device code:

```kql
SigninLogs
| where AuthenticationProtocol == "deviceCode"
      or OriginalTransferMethod == "deviceCodeFlow"
| project CorrelationId, UserPrincipalName, IPAddress, UserAgent,
          IsInteractive, TimeGenerated, AppDisplayName
```

Join theo `CorrelationId` và so sánh hai chân cạnh nhau. **IP hoặc user-agent lệch nhau giữa chân interactive và chân polling chính là tín hiệu cốt lõi** — nạn nhân nhập mã từ IP của họ, attacker poll token từ IP của attacker.

### IOC đặc thù Forg365

**Ưu tiên cao, chi phí thấp:**

*   Device name khớp `Forg365-*` trong Entra devices
    
*   Sign-in với `originalTransferMethod = deviceCodeFlow` từ `67[.]190[.]46[.]128` hoặc `139[.]28[.]38[.]129`
    
*   User agent `node-fetch` hoặc kiểu node trong hoạt động Graph non-interactive
    
*   DNS/proxy log tới `logfriend[.]com`, `xoday[.]sbs`, `incogxray[.]sbs`, `ructus[.]site`
    
*   Request tới đường dẫn `/api/extension/login`, `/api/extension/accounts`, `/api/extension/generate-cookie`
    

**Chuỗi hành vi (giá trị cao nhất):**

*   Device-code sign-in → **theo sau bởi Graph non-interactive từ IP mới**
    
*   Microsoft Authentication Broker thành công → **theo sau bởi device registration**
    
*   Silent `prompt=none` sign-in lặp lại tới `substrate.office[.]com` từ IP không liên quan người dùng
    
*   Sau sự kiện device-code: inbox rule mới, forwarding, OAuth grant, keyword search bất thường
    

**Về môi trường Splunk:** các trường trên đến từ schema Entra sign-in log (`authenticationProtocol`, `originalTransferMethod`, `correlationId`, `uniqueTokenIdentifier`). Nếu tenant khách hàng đẩy Entra log vào Splunk, logic tương quan giữ nguyên — chỉ khác cú pháp. Một lưu ý từ nghiên cứu Cloudbrothers cần kiểm chứng lại trong môi trường của bạn: `originalTransferMethod` **có thể không được forward sang Microsoft Sentinel** trong một số cấu hình. Kiểm tra xem trường này có thực sự đến được SIEM của bạn không **trước khi** viết rule dựa vào nó — nếu không bạn sẽ có một rule không bao giờ fire.

### Forensic: theo dấu token

Microsoft đã GA **linkable token identifiers** từ 07/2025. Cách làm (nguồn: Eye Security):

1.  Tải cả UAL (Unified Audit Log) và **non-interactive sign-in log** từ Entra — UAL chỉ chứa sign-in interactive
    
2.  Đánh dấu mọi sign-in có `originalTransferMethod = deviceCodeFlow`
    
3.  Dùng `uniqueTokenIdentifier` tương ứng để lọc UAL → thu được toàn cảnh hoạt động Exchange của attacker
    
4.  Nếu người dùng cũng dùng device code hợp pháp, phân biệt bằng IP hoặc user-agent
    

**Lưu ý quan trọng về revoke:** revoke refresh token **không** vô hiệu hoá access token đã cấp — chúng vẫn hợp lệ đến khi hết hạn. Nếu tenant có Continuous Access Evaluation (CAE), force re-evaluation để flush token cached.

## Khuyến nghị

*   Kiểm kê device code flow usage 90 ngày qua trên mọi tenant quản lý
    
*   Query Entra devices tìm tên khớp `Forg365-*` hoặc pattern tên bất thường khác
    
*   Tìm sign-in `deviceCodeFlow` từ các IP trong danh sách IOC
    
*   Nếu nghi compromise: **revoke session và refresh token ở tầng identity**, không chỉ reset mật khẩu
    
*   Triển khai Conditional Access chặn device code flow — sau khi kiểm kê, với exclusion hẹp và có tài liệu
    
*   Chặn authentication transfer policies (khuyến nghị FBI)
    
*   Xác minh `originalTransferMethod` và `uniqueTokenIdentifier` thực sự đến được SIEM
    
*   Xây detection cho chuỗi: device-code → Graph non-interactive từ IP mới → device registration
    
*   Audit inbox rule, forwarding và OAuth grant trên các tài khoản có device-code event gần đây
    

*   Coi device-code và authentication-transfer là **identity-risk control**, không phải vấn đề nhận thức người dùng. Không có khoá đào tạo nào dạy được nhân viên phân biệt trang Microsoft thật với trang Microsoft thật
    
*   Yêu cầu compliant device cho device code flow ở nơi buộc phải bật
    
*   Hạn chế quyền đăng ký device — enrollment restriction giới hạn ai được join thiết bị vào tenant
    
*   Playbook IR cho account takeover phải có bước **revoke session + audit device registration + audit OAuth grant**, đặt trước bước reset mật khẩu về mức ưu tiên
    
*   Với analyst triage: **VPN thấy nội dung sạch ≠ link sạch**. Ghi điều này vào quy trình
    

## Indicators of Compromise

**Panel và API:**

```plaintext
hxxps://logfriend[.]com/login
logfriend[.]com/api/extension/*
panel.logfriend[.]com
```

**Panel variant và backend node:**

```plaintext
xoday[.]sbs
139[.]28[.]38[.]129        (Kyiv, Ukraine; Ubuntu/nginx; Shodan title "Forg365")
ructus[.]site
panel.ructus[.]site
185[.]174[.]101[.]1
45[.]82[.]84[.]29          (branding kiểu Ingonito365; pivot, không trung tâm)
panel.incogxray[.]sbs
```

**IP trong luồng xác thực:**

```plaintext
67[.]190[.]46[.]128        (Comcast/Xfinity, xuất hiện trong Authentication Broker
                            với originalTransferMethod=deviceCodeFlow)
```

**Gophish delivery:**

```plaintext
go.incogxray[.]sbs
_gorilla_csrf              (cookie)
gophish                    (cookie)
```

**Device-auth landing:**

```plaintext
critical-silver-yak[.]pages[.]dev
shy-crimson-wren[.]pages[.]dev
forg_jschk
```

**AiTM / redirect:**

```plaintext
pjeqlikeln.briggselectrlc[.]co
manlivep[.]org/socket.io/
PHPSESSID
preload=1
rt=<word-number route token>
```

**Browser extension:**

```plaintext
ForgCookie
ForgCookie 1.0.21
x-ms-RefreshTokenCredential
/api/extension/login
/api/extension/accounts
/api/extension/generate-cookie
```

**Entra artifact:**

```plaintext
Forg365-*                            (tên device đã đăng ký)
originalTransferMethod=deviceCodeFlow
node-fetch                           (user agent trong Graph non-interactive)
prompt=none -> substrate.office[.]com
```

**Lưu ý:** các dịch vụ security-wrapping xuất hiện trong chuỗi URL **không phải IOC** và không nên bị coi là độc hại chỉ vì có mặt trong chuỗi redirect.

* * *

*Nguồn tham khảo:*

*   [Inside Forg365: A Telegram-Distributed Sneaky 2FA-Style PhaaS Targeting Microsoft 365](https://zerobec.com/blog/inside-forg365-telegram-distributed-sneaky2fa-style-phaas) — ZeroBEC (nguồn gốc; lưu ý đây là vendor có lợi ích thương mại)
    
*   [New Forg365 phishing platform uses AI to target Microsoft 365 accounts](https://www.bleepingcomputer.com/news/security/new-forg365-phishing-platform-uses-ai-to-target-microsoft-365-accounts/) — BleepingComputer (Bill Toulas)
    
*   [Kali365 Phishing-as-a-Service Kit Hijacks Microsoft 365 Access Tokens](https://www.ic3.gov/PSA/2026/PSA260521) — FBI IC3 PSA I-052126-PSA
    
*   [FBI warns Kali365 phishing kit is stealing Microsoft OAuth tokens at scale](https://www.theregister.com/cyber-crime/2026/05/22/fbi-warns-of-kali365-as-device-code-phishing-soars/5245024) — The Register (dẫn nghiên cứu Arctic Wolf)
    
*   [ARToken: Inside an EvilTokens affiliate panel targeting Microsoft 365](https://blog.talosintelligence.com/artoken-inside-an-eviltokens-affiliate-panel-targeting-microsoft-365/) — Cisco Talos
    
*   [Sneaky 2FA: exposing a new AiTM Phishing-as-a-Service](https://blog.sekoia.io/sneaky-2fa-exposing-a-new-aitm-phishing-as-a-service/) — Sekoia
    
*   [Analyzing the rise in device code phishing attacks in 2026](https://pushsecurity.com/blog/device-code-phishing) — Push Security
    
*   [We Need to Talk About Device Code Phishing](https://www.huntress.com/blog/tradecraft-tuesday-device-code-phishing-explained) — Huntress
    
*   [Device Code Phishing Forensics: What We Learned from BEC Investigations in the Wild](https://research.eye.security/device-code-phishing-forensics/) — Eye Security
    
*   [Device Code Phishing: OAuth Flow Abuse in Entra ID](https://etcsec.com/blog/device-code-phishing-entra-id) — EtcSec
    
*   [Protect your users from Device Code Flow abuse](https://cloudbrothers.info/en/protect-users-device-code-flow-abuse/) — Cloudbrothers
    
*   [Authentication flows as a condition in Conditional Access policy](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-authentication-flows) — Microsoft Learn
    
*   [Microsoft 365 / Entra ID Guidance](https://www.cisa.gov/resources-tools/services/m365-entra-id) — CISA