# Bezpieczny Wtorek: Kali365 omija MFA przez OAuth device code

> Kali365 wykorzystuje OAuth 2.0 device code flow w Microsoft 365 - MFA nie zostaje obejście, lecz użyte do zbudowania zaufania. Pięć kroków hardeningu Entra ID…

- Source: https://snok.ai/pl/aktualnosci/blog/bezpieczny-wtorek-ze-snok-kali365-phishing-oauth-device-code/
- Author: Jacek Bugajski
- Published: 2026-05-26

---
W połowie maja 2026 roku FBI opublikowało ostrzeżenie dotyczące nowej platformy Phishing-as-a-Service o nazwie **Kali365**. Mechanizm tego ataku zasługuje na uwagę każdego administratora Microsoft 365 - również tych, którzy uznają, że uwierzytelnianie wieloskładnikowe wystarczająco zabezpiecza ich środowisko.

Najważniejsza obserwacja jest następująca: Kali365 nie obchodzi MFA. Wykorzystuje je jako element budujący zaufanie ofiary.

![Abstrakcyjna wizualizacja przechwycenia tokenu sesji w ataku phishingowym - styl SNOK Aurora](https://snok.ai/images/blog/bezpieczny-wtorek-ze-snok-kali365-phishing-oauth-device-code.webp)

## Jak działa atak

Operator Kali365 wykorzystuje legalny mechanizm Microsoft - **OAuth 2.0 device code flow**. Przepływ ten powstał z myślą o urządzeniach bez klawiatury (telewizory, drukarki, urządzenia IoT) i nie wymaga drugiego składnika uwierzytelnienia, jeśli użytkownik samodzielnie wprowadzi kod na zaufanym urządzeniu.

Typowy scenariusz wygląda następująco:

1. Operator inicjuje device code flow w środowisku ofiary.
2. Wysyła do użytkownika wiadomość udającą wewnętrzny komunikat IT - "proszę zalogować się i wpisać kod".
3. Użytkownik loguje się na własnym koncie i przepisuje kod, w dobrej wierze.
4. Atakujący otrzymuje **token sesji** ze wszystkimi uprawnieniami ofiary.
5. MFA nie zostało obejście - zostało wykorzystane jako element budujący zaufanie.

Próg wejścia dla atakującego jest niski, a skuteczność wysoka - szczególnie w organizacjach, które nie skonfigurowały odpowiednich polityk Conditional Access.

## Pięć kroków, które warto wdrożyć w najbliższych 48 godzinach

- **Conditional Access** - polityka blokująca device code flow z lokalizacji i urządzeń niezaufanych.
- **Entra ID** - włączenie sign-in risk policies oraz user risk policies (wymaga licencji Entra ID P2).
- **Defender for Cloud Apps** - aktywne monitorowanie nietypowych przepływów OAuth i alertowanie na anomalie tokenów.
- **Token lifetime policies** - skrócenie czasu życia tokenów sesji i wymuszenie częstszej reautoryzacji.
- **Komunikacja do użytkowników** - krótka instrukcja: "Microsoft nigdy nie prosi o przepisanie kodu z innej wiadomości".

## Dlaczego ten temat dziś

Znaczna część polskich organizacji korzystających z Microsoft 365 nie ma jeszcze aktywnej polityki blokującej device code flow w niezaufanych scenariuszach. Mechanizm pozostaje domyślnie włączony, a wektor ataku - dostępny.

Jako [Microsoft Solutions Partner](https://snok.ai/pl/microsoft-snok/) pomagamy klientom przeprowadzić hardening Entra ID, skonfigurować Conditional Access i wdrożyć monitoring OAuth na Defender for Cloud Apps. Jeśli chcieliby Państwo omówić konfigurację we własnej organizacji, [zapraszamy do rozmowy](https://snok.ai/pl/kontakt/).

---

*Źródło: FBI Public Service Announcement (maj 2026) dotyczący platformy Kali365 Phishing-as-a-Service.*