Дзвінок фальшивої техпідтримки в Microsoft Teams відкрив зловмисникам не лише доступ до комп’ютера працівника, а й шлях до сертифікатів привілейованих облікових записів. У двох розслідуваннях, оприлюднених 30 жовтня, Microsoft показала, як погоджений сеанс віддаленої допомоги перетворився на атаку на корпоративні ідентичності. В одному випадку захист заблокував значну частину подальших дій, але виключений з автоматичного стримування обліковий запис залишився доступним — і його використали для викрадення файлів.
Йдеться про соціальну інженерію та небезпечні налаштування служб сертифікації Active Directory (AD CS), а не про вразливість Teams. Ключова проблема: видалення початкової точки доступу чи зміна пароля самі собою не скасовують сертифікат, який нападник уже отримав.
Дзвінок, після якого передали керування
Обидва вторгнення почалися з повідомлень і дзвінків у Teams від нібито ІТ-підтримки. Оператори переконували користувачів дозволити інтерактивний віддалений доступ, переважно через легітимний засіб Windows Quick Assist. Імена з натяком на службу підтримки та назви хмарних середовищ, схожі на назву організації, додавали зверненню правдоподібності.
Вирішальним кроком стала згода на віддалений сеанс. Отримавши керування, оператор переносив архів у «Завантаження», розпаковував його в нову теку профілю користувача й запускав свій код через переносне середовище виконання. Microsoft бачила варіанти з Python, Bun і Java. Перейменований виконуваний файл міг зберігати справжні метадані середовища, але виконувати скрипт нападника.
Тому сама наявність Java — слабкий індикатор. Значення має послідовність: неочікувана віддалена допомога, нова доступна для запису тека, запуск коду, а потім розвідка комп’ютера й домену. Схожі приманки в Teams та Quick Assist використовували для доставки Nimbus RAT, однак новий звіт Microsoft описує інші вторгнення із сертифікатами й не пов’язує їх із тією кампанією.
Як сертифікат дав привілейований доступ
AD CS видає сертифікати, за допомогою яких можуть автентифікуватися користувачі та комп’ютери. Такий сертифікат — окремий засіб підтвердження ідентичності, а не просто копія пароля. У першому випадку зловмисник знайшов шаблон із поєднанням дозволів і налаштувань, відомим як ESC1: користувач із низькими привілеями міг указати іншу ідентичність і отримати сертифікат для привілейованого облікового запису.
Перша хвиля фішингу охопила три облікові записи й призвела до компрометації одного комп’ютера. Нападник отримав сертифікати для трьох високопривілейованих записів. Механізм стримування атак Microsoft Defender обмежив охоплені ним ідентичності, розірвав сеанси та обмежив доступ. Проте один привілейований запис був виключений з автоматичного реагування.
Приблизно за 90 хвилин друга хвиля була спрямована на 16 користувачів і дала доступ до ще одного комп’ютера. Через шаблон сертифікатів зловмисник отримав засоби автентифікації для восьми додаткових привілейованих записів. За даними Microsoft, захист заблокував понад 1000 подальших спроб доступу до файлів через SMB і додаткові входи. Це кількість заблокованих спроб, а не викрадених файлів чи постраждалих організацій.
Виключення виявилося важливішим за обнадійливу кількість блокувань. Поки стримування набувало чинності, нападник виконав DCSync — отримання облікових даних каталогу з використанням прав реплікації. Виключений запис залишався придатним і для доступу до файлового сервера. Далі копія Rclone з назвою SearchApp.exe передавала файли на зовнішній SFTP-сервер. Команда використовувала 20 паралельних передач і відбирала файли віком до трьох років; загального обсягу викраденого Microsoft не називає.
Інший шлях — від імені контролера домену
У другому середовищі шлях ESC1 був недоступний. Натомість нападник застосував PetitPotam, щоб змусити контролер домену автентифікуватися на підконтрольній зловмиснику системі, а потім ретранслював NTLM-автентифікацію до вебслужби видачі сертифікатів AD CS. Цей шлях ESC8 використовує недостатній захист точки видачі від ретрансляції.
Служба сертифікації прийняла автентифікацію машинного запису контролера домену, хоча запит надійшов з іншого пристрою. Нападник запросив сертифікат від імені цього запису, а згодом отримав квиток Kerberos за допомогою сертифікатної автентифікації. Для розслідування важлива невідповідність між ідентичністю та пристроєм, який подає запит, а не саме відвідування адреси служби сертифікації.
У цьому випадку Defender сформував сповіщення, після яких організація ізолювала відповідний комп’ютер. Microsoft не спостерігала подальшого розвитку атаки після ізоляції. Це зафіксований результат, а не твердження, що саме сповіщення автоматично відкликало всі облікові дані.
Чому завершити дзвінок недостатньо
Для працівника головна межа — передача керування. Неочікуване звернення підтримки варто перевірити через усталену систему заявок або окремо отриманий контакт. Позначки «External» і «Scam suspected» на прикладі Microsoft означають зовнішнього співрозмовника та підозру на шахрайство. Вони заслуговують на увагу, проте знайоме ім’я чи відсутність попередження не підтверджують особу.
Якщо керування вже передали, повідомте про сеанс і дійте за процедурою реагування організації, зокрема щодо ізоляції пристрою. Якщо на ПК запускали файли, актуальне сканування Gridinsoft Anti-Malware допоможе перевірити Windows на шкідливі компоненти й механізми закріплення. Очищення комп’ютера — окреме завдання від перевірки виданих сертифікатів, привілейованих записів і квитків Kerberos: чистий результат сканування не відкликає ці засоби доступу.
Адміністраторам слід зіставити віддалений сеанс із запуском середовищ виконання, запитами сертифікатів і подальшими входами; перевірити дозволи шаблонів, захист від ретрансляції та виключення зі стримування. Ці два випадки показують, чому реагування має охоплювати отримані нападником повноваження, а не лише комп’ютер, на якому почалася розмова.
Джерела
- Microsoft Security Research; Sagar Patil, Jesse Birch, Tal Tzhori. Від імітації техпідтримки до зловживання AD CS: розслідування шляхів ESC1 та ESC8. Microsoft Security Blog, 30 жовтня 2026 року. Переглянуто 1 листопада 2026 року.
