Атакувальник отримав пароль працівника ReliaQuest і підтвердження MFA, але перевірка довіри до пристрою зупинила доступ до застосунків компанії. В описі від 23 серпня ReliaQuest повідомляє, що під час атаки попереднього дня стороння особа ненадовго побачила одну панель облікового запису. За висновками компанії, доступу до клієнтських даних, інших облікових записів і закріплення не було.
Де спроба спрацювала, а де зупинилася
Той, хто телефонував, називався конкретним працівником безпеки й спрямовував людей на підроблену сторінку SSO. ReliaQuest повідомляє про завершення сесій, скасування чинності пароля та скидання факторів автентифікації. Це висновки компанії; успішний вхід не слід переказувати як підтверджену атаку програми-вимагача.
Важлива різниця — між підтвердженням особи та дозволом цій особі відкрити застосунок із певного пристрою. Підтвердження MFA може завершити перший крок, тоді як інший контроль відхилить другий. Після заблокованої спроби все одно лишаються розкритий пароль і небажана сесія, які потребують розслідування.
Якщо «служба безпеки» просить увійти
Завершіть неочікуваний дзвінок і зверніться до підтримки через уже відомий довідник або канал. Самостійно відкрийте звичайну закладку SSO. Посилання від співрозмовника, наданий ним номер або нова пошукова реклама не підходять для незалежного підтвердження.
Поясніть, чого вимагали: входу, підтвердження push-запиту, додавання телефона чи передачі коду відновлення. Справжнє ім’я колеги й знання роботодавця можуть зробити дзвінок переконливим, але не доводять особу співрозмовника. Для корисного повідомлення про інцидент не потрібно продовжувати розмову.
Повідомте останню виконану дію
| Що сталося | Наступний крок |
|---|---|
| Лише вислухали прохання | Запишіть час, показаний номер і названу особу. Повідомте підтримку через відомий канал. |
| Відкрили сторінку | Збережіть адресу без повторного відвідування. Укажіть, чи вводили дані, завантажували файл або дозволяли віддалений доступ. |
| Ввели пароль | Негайно повідомте про розкриття облікових даних. Відновлюйте доступ через справжній сервіс із довіреного пристрою. |
| Підтвердили MFA або додали фактор | Передайте ІТ точний час і вид дії. Потрібна перевірка сесій та змін способів автентифікації. |
Не чекайте підозрілого платежу чи повідомлення про витік. Запис «ввів пароль о 14:10 і підтвердив push о 14:11» корисніший за «можливо, натиснув фішинг». Додайте часовий пояс, якщо команда працює в різних регіонах.
Що має перевірити команда реагування
Перевірте події постачальника ідентифікації навколо цього часу: входи, відхилені спроби доступу до застосунків, нові способи автентифікації та зміни сесій. Встановіть, який ресурс справді відкрили, якщо це взагалі сталося. У записі інциденту відокремлюйте відмову в доступі від успішного читання даних.
Узгодьте зміну пароля з відкликанням сесій і перевіркою факторів. Самої зміни пароля недостатньо, щоб вважати всі попередні сесії чи додані атакувальником способи входу зниклими. Конкретні засоби залежать від постачальника ідентифікації та політики керування; використовуйте підтримувану процедуру реагування.
Окремо зафіксуйте запуск файлу чи сеанс віддаленої підтримки. Це змінює обсяг перевірки: можливий уже доступ до пристрою. Сам дзвінок або введення пароля не встановлюють наявність шкідливого ПЗ на комп’ютері.
Звичайний шлях входу має значення
Підроблена сторінка може з’явитися не лише з листа. Випадок DNS-підміни в готельному Wi-Fi з фішингом Microsoft 365 показує інший шлях до несподіваного входу. Знайомий дизайн — лише оформлення; перевіряйте сервіс і саме прохання незалежно.
Джерело
- ReliaQuest Threat Research. Спроба соціальної інженерії проти ReliaQuest: результати перевірки. 23 серпня 2026 року.
