Фішинг кодом пристрою перетворюється з нішевого прийому на повторювану схему викрадення ідентичності. Proofpoint повідомляє, що нові інструменти device-code phishing з’являються щотижня, а кампанії використовують URL, PDF-вкладення та QR-коди, щоб привести жертву на сторінку з коротким кодом підтвердження. Далі користувача спрямовують на справжній потік microsoft.com/devicelogin, де введення коду, наданого атакувальником, може дати доступ без викрадення самого пароля [1].
Ключова зміна тут психологічна. Класичний фішинг просить жертву ввести пароль на підробленій сторінці. Device code phishing може виглядати безпечніше, бо фінальний вхід відбувається на легітимному домені Microsoft. Саме це і є пасткою: користувач не просто “входить, щоб відкрити документ”, а фактично авторизує сесію атакувальника. Proofpoint спостерігала кілька майже однакових варіантів таких сторінок за короткий період у квітні 2026 року, зокрема активність, пов’язану з PhaaS-наборами EvilTokens, Tycoon, ODx і Kali365 [1].
Для менеджерів паролів діє окрема приманка: перевірте фішингові листи LastPass і Bitwarden з lookalike compliance-доменами та фальшивим DocuSign-завантаженням.
Чим це відрізняється від фішингу пароля
Для звичайних користувачів Microsoft 365 тривожний сигнал — це не лише дивна сторінка для введення пароля. Підозрілим має бути будь-яке повідомлення, яке просить скопіювати код з email, PDF, QR-сторінки, “захищеного документа”, HR-повідомлення, судового порталу або сторінки підписання та вставити його на Microsoft device login. Якщо користувач сам не починав вхід з телевізора, пристрою переговорної кімнати, CLI-утиліти або іншого пристрою без браузера, такий кодовий потік варто вважати небезпечним.
Для адміністраторів це проблема токенів і сесій, а не лише паролів. Документація Microsoft Entra прямо описує device code flow як високоризиковий і дозволяє керувати ним через політики Conditional Access для authentication flows [2]. Практична послідовність реагування: перевірити журнали входу на device-code flow, знайти незнайомі застосунки або локації, відкликати refresh tokens для постраждалих користувачів, змінювати пароль уже після відкликання токенів і розглянути блокування device code flow всюди, де він не потрібен реальному бізнес-пристрою.
Саме тому сучасні Microsoft-теми у фішингу зближуються. AiTM-набори, фальшиві Teams-звернення до help desk і тепер device-code кампанії намагаються обійти просту перевірку пароля та перейти до контролю сесії. Для користувача дія виглядає легітимною, але доступ отримує атакувальник.
Пов’язаний контекст: Operation Ramz показує, що за фальшивими сторінками входу часто стоїть окрема інфраструктура, а не лише одна видима форма.
Пов’язаний контекст: Microsoft пізніше описала Storm-2949 і зловживання Self-Service Password Reset, ще один приклад атаки через довірені identity flows.
Джерела
- Proofpoint Threat Research: “Device Code Phishing is an Evolution in Identity Takeover”, 13 травня 2026 року. Звіт
- Microsoft Learn: Authentication flows as a condition in Conditional Access policy. Інструкція
Схожий ризик: у новій схемі Nimbus RAT через Teams vishing і Quick Assist зловмисники також використовують довіру до Microsoft-сервісів, але замість коду пристрою ведуть користувача до віддаленого доступу.
Для Microsoft 365 також варто перевірити Ghost-Sender у Exchange Online, бо підроблений внутрішній лист може виглядати переконливо навіть без крадіжки токена.
Для геймерських акаунтів схожий ризик виникає у фейкових перевірках FACEIT, які крадуть Steam-логіни та Steam Guard коди; там варто перевірити реальний адресний рядок, активні сесії та pending trades.
Є і суміжний сценарій без device code: зловмисники телефонують користувачу і ведуть його через фальшиву реєстрацію passkey. Якщо вас просили додати новий метод входу в Microsoft 365, перегляньте ознаки фальшивого налаштування passkey.
