ви в клірнеті. перелічені тут адреси відкриваються лише всередині мережі tor - завантажте tor-браузер тут »
AlphaBay.Market
UK
остання перевірка: 12 хв тому відстежується onion: 260
головна / новини / Безпека
28 жовтня 2026 Безпека 1 хв читання

Фішинг з кодом пристрою: підтвердження входу, якого ви не починали

У лютому 2025 року Microsoft Threat Intelligence Center задокументував активну кампанію актора, якого відстежує як Storm-2372: вона викрадала сесії входу в організацій Європи, Північної Америки, Африки та Близького Сходу. Показова в цій техніці — фішингу з кодом пристрою — те, чого вона уникає: тут немає підробної сторінки входу, яку можна розпізнати, немає пароля, який можна вкрасти, і немає шкідливого коду, який можна виявити. Жертва взагалі нічого таємного не вводить. Код, наданий зловмисником, вводиться на справжній сторінці входу Microsoft, жертва підтверджує запит на власному пристрої — і зловмисник іде з робочою сесією.

Легітимна функція, вивернута навиворіт

Device code flow — це справжня функція OAuth 2.0, а не підробка. Вона існує для пристроїв без повноцінної клавіатури чи браузера: принтери, телевізори, екрани переговорних, приставки. Пристрій показує короткий код, користувач відкриває портал входу на телефоні чи ноутбуці, вводить код, авторизується й підтверджує. Пристрій отримує свої токени. Storm-2372 розвернув цю послідовність. За даними Microsoft, із серпня 2024 року група вела кампанію так: відкривала чати в Microsoft Teams від імені керівників чи чиновників, а потім під приводом обміну документами переводила розмову в Signal або WhatsApp. Запрошення на зустрічі, розіслані поштою, несли ту саму наживку, замасковану під звичайний трафік Teams. Матеріал BleepingComputer про цю саму кампанію описував жертв, яких просили «аутентифікувати» пристрій, щоб отримати важливий документ: ті переходили за посиланням на справжню сторінку входу Microsoft, вводили надісланий код і підтверджували вхід — разом зі звичайним кроком багатофакторної автентифікації. Серед задокументованих Microsoft цілей — державні органи, ІТ-провайдери, оборонний сектор, телеком, охорона здоров'я, вища освіта та енергетичні компанії.

Чому це повністю обходить MFA

Усе вирішує порядок дій. Зловмисник спершу сам ініціює легітимний запит коду пристрою і лише потім підключає жертву. Коли жертва вводить код і підтверджує, усі перевірки на сторінці проходять чесно: сторінка справжня, код дійсний, а людина за нею справді завершує вхід, включно з належною багатофакторною автентифікацією. Токени, які видає Microsoft, включно з довговічними refresh-токенами, дістаються тому, хто розпочав запит, — тобто зловмисникові. З погляду каталогу користувач просто успішно увійшов у систему. Поштовим фільтрам і веб-проксі нема чого позначати, бо вся задіяна інфраструктура цілком легітимна. У звіті Microsoft описано, що відбувалося далі в скомпрометованих тенантах: зловмисники шукали поштовими скриньками запитами Graph API за словами на кшталт credentials, passwords і admin, викачували листування та використовували довірені внутрішні облікові записи для фішингу колег — одне підтвердження могло каскадом пройтися організацією. В оновленні, опублікованому за день після першої публікації, Microsoft також задокументувала перехід до запитів через клієнт Microsoft Authentication Broker: це дозволяло реєструвати контрольовані зловмисником пристрої та запитувати primary refresh tokens. Proofpoint, яка спостерігала за технікою під час її поширення фішинговими наборами 2026 року, відзначила подальше вдосконалення: коди генеруються на запит у момент, коли жертва клікає посилання, що обходить п'ятнадцятихвилинний строк дії заздалегідь створеного коду.
Звична порада — уважно роздивитися сторінку входу, перш ніж щось вводити, — тут не працює. Як зазначає Proofpoint в аналізі пізніших кампаній, перевірка URL безсила, бо портал справді належить Microsoft; зловживається підтвердження жертви, а не адресний рядок.

Червоні прапорці, які варто знати

Ознаки стабільні від кампанії до кампанії, і жодна не потребує технічних знань, щоб їх помітити.
  • вхід, якого ви не починали: код пристрою існує лише тому, що його хтось запросив
  • поспіх і тиск — «діяти, доки код не сплив» або «до початку зустрічі»
  • лист, чат чи повідомлення з проханням підтвердити щось кодом, про який ви ніколи не просили
  • контакт, що перескакує між платформами: чат у Teams переїжджає в Signal або WhatsApp
  • документ чи запрошення на зустріч, що «розблоковуються» лише після введення коду
Microsoft також зазначає, що сучасні інтерфейси входу Azure перед завершенням device code flow просять підтвердити, до якої саме програми ви входите. Прочитати цей екран підтвердження, а не клікнути на автоматі — часто саме тут ілюзія ламається: програма на тій стороні — не ваша.

Що насправді це обмежує

Для адміністраторів найсильніший контроль — вузький: дозволяти device code flow лише там, де є реальна операційна потреба. В Microsoft Entra ID це політика умовного доступу з умовою Authentication Flows, що блокує автентифікацію кодом пристрою; Proofpoint рекомендує спершу вмикати її в режимі report-only, щоб виміряти вплив до примусового застосування, а там, де потік не можна вимкнути повністю, — білий список схвалених користувачів, платформ або іменованих локацій. Настанова CISA щодо багатофакторної автентифікації наполегливо закликає до фішингостійких методів на кшталт ключів FIDO і passkey, які прив'язують облікові дані до входу, що фактично відбувається, а не до чогось, що віддалений зловмисник може погасити. Настанова британського NCSC щодо фішингу формулює ширшу думку: багаторівневі технічні заходи, культура повідомлень без пошуку винних і перевірка незвичних запитів другим каналом дають більше, ніж саме лише навчання пильності. Той, хто вже ввів код і підтвердив запит, має вважати обліковий запис скомпрометованим і діяти на рівні сесії, а не пароля: коли адміністратор відкликає сесії запису, викрадені refresh-токени втрачають чинність — саме цей крок відновлення документує Microsoft. Після цього варто перевірити правила поштової скриньки, надані згоди та вихідну пошту: токени могли вже бути використані для фішингу колег. Ця схема з тієї ж родини, що й шахрайство з фальшивими агентами підтримки, про яке ми писали раніше: зловмисник не перемагає технологію — він на мить позичає авторитет самого користувача. Вхід, якого ніхто не просив вас починати, — саме його варто відхилити.

більше нотаток

усі новини ›

MFA fatigue та push bombing: коли запит на підтвердження стає атакою

Діючий пароль дозволяє заспамити телефон запитами на підтвердження, доки хтось не натисне «схвалити». Як працює MFA fatigue, що показали інциденти Uber і Cisco та чому number matching і апаратні ключі змінюють результат.

Перехоплення сесії: чому викрадений cookie цінніший за пароль

AiTM-фреймворки для фішингу та логи інфостилерів дедалі частіше торгують автентифікованими сесіями, а не паролями: викрадений session cookie вже за муром MFA. Розгляд того, як працює перехоплення сесії та які захисти справді тримають удар.