Дослідники компанії ZeroBEC розкрили подробиці фішингової кампанії Operation BlueDash, у межах якої зловмисники використовують підроблені сторінки оновлення Microsoft Teams для доставки легітимних інструментів віддаленого моніторингу та керування (RMM). Жертв перенаправляють через скомпрометовану вебінфраструктуру на фальшиву сторінку Microsoft Store, де їм повідомляють про необхідність оновити Teams перед відкриттям «захищеного документа». Кампанія становить загрозу для організацій будь-якого масштабу, оскільки використовує легітимне ПЗ для отримання стійкого віддаленого доступу, що ускладнює виявлення стандартними засобами захисту.
Технічний ланцюжок атаки
За даними дослідників, підроблена сторінка Teams розміщена на домені teamvem[.]com. Під час взаємодії з нею завантажується файл supportdev.exe — завантажувач на базі Inno Setup, який запускає PowerShell у прихованому вікні. Скрипт завантажує офіційний інсталятор Level RMM і реєструє скомпрометовану кінцеву точку з використанням контрольованого зловмисниками реєстраційного ключа (LEVEL_API_KEY=GxSCHE8EZwfyYN3iPQHPai8D).
Як зазначається, той самий PowerShell-скрипт паралельно завантажує та встановлює ConnectWise ScreenConnect. Розгортання кількох RMM-інструментів на одному хості, за оцінкою ZeroBEC, спрямоване на створення резервних каналів доступу: якщо один інструмент буде виявлено й видалено, другий продовжить функціонувати.
Після встановлення RMM-агентів оператори виконують серію розвідувальних команд:
- Перевірка стану очікуваного перезавантаження системи
- Визначення статусу захисту системного тому (шифрування)
- Перелік активних профілів брандмауера
- Виявлення членів локальної групи «Адміністратори» та її назви
Дослідники зазначають, що ця послідовність нагадує «операторський чекліст»: визначити стан системи, оцінити захист шифруванням і конфігурацію брандмауера, виявити привілейованих користувачів — і лише після цього ухвалювати рішення щодо подальших дій.
Інфраструктура та мультибрендова схема
Аналіз інфраструктури зловмисників виявив домен support[.]berrydev[.]xyz, пов’язаний із доменом GitHub Pages berry4603.github[.]io і репозиторієм Bluedashltd. Цей репозиторій містить вихідний код фішингових сторінок, конфігурацію CNAME і корисне навантаження SupportDev. Згідно з історією комітів, кампанія активна щонайменше з лютого 2026 року, коли було створено репозиторій із підробленою сторінкою Microsoft Store.
Другий репозиторій (rustovni), прив’язаний до того самого облікового запису GitHub, імовірно містить приманку у вигляді запрошення на зустріч у Zoom і компоненти доставки корисного навантаження. У цьому варіанті завантажується агент Tactical RMM з офіційного GitHub-релізу, встановлюється у тимчасовий каталог Windows і реєструє хост із використанням вбудованого токена автентифікації.
Наявність варіантів із різними приманками (Teams, Zoom) і різними RMM-платформами (Level RMM, ScreenConnect, Tactical RMM) вказує на мультибрендову схему: ядро операції залишається незмінним, а змінюються лише корпоративний застосунок-приманка, хост доставки корисного навантаження та платформа віддаленого керування.
Індикатори компрометації
- Домени: teamvem[.]com, support[.]berrydev[.]xyz, berry4603.github[.]io
- Файл: supportdev.exe (завантажувач Inno Setup)
- Реєстраційний ключ: LEVEL_API_KEY=GxSCHE8EZwfyYN3iPQHPai8D
Контекст: тренд зловживання RMM-інструментами
Operation BlueDash вписується в сталу тенденцію використання легітимних інструментів віддаленого керування як бекдорів. Раніше, у травні 2026 року, ZeroBEC задокументувала аналогічну кампанію з фішинговими листами про «захищені документи», які призводили до прихованого встановлення RMM-бекдорів. Привабливість цього підходу для зловмисників очевидна: легітимне ПЗ з дійсними цифровими підписами рідко блокується антивірусами, а RMM-агенти забезпечують повноцінний віддалений доступ із можливістю передавання файлів, виконання команд і керування робочим столом.
JIVS PhishKit: паралельна загроза
Паралельно з Operation BlueDash компанія ZeroBEC описала кампанію JIVS PhishKit — скоординовану атаку зі збирання облікових даних корпоративної пошти, націлену на кількох користувачів усередині однієї організації. Особливість цього набору — універсальна фішингова сторінка, здатна імітувати вхід до Microsoft 365, Google Workspace, cPanel, Roundcube, Zimbra та інших поштових систем. Замість клону конкретного провайдера використовується узагальнена форма «Session Expired».
Фішингові повідомлення надсилалися від автентифікованого, але не пов’язаного з організацією зовнішнього відправника, із попередженням про «порушення політики» поштової скриньки та переспрямовували на PHP-сторінку на домені corychase[.]org. Набір збирає лише адресу корпоративної пошти та пароль — без перехоплення сесійних cookies, токенів OAuth, кодів MFA або даних браузерних сесій. Найраніший артефакт кампанії датований 21 серпня 2025 року.
Рекомендації щодо захисту
- Контроль RMM-інструментів: впровадьте політику дозволених застосунків (allowlisting), яка чітко визначає, які RMM-платформи допустимі в інфраструктурі. Встановлення Level RMM, Tactical RMM або ScreenConnect поза затвердженим ІТ-процесом має генерувати сповіщення високого пріоритету.
- Моніторинг PowerShell: налаштуйте логування блоків скриптів (Script Block Logging) та відстежуйте запуск PowerShell у прихованому режимі (
-WindowStyle Hidden), особливо якщо батьківським процесом є невідомий виконуваний файл. - Блокування IOC: додайте зазначені домени (teamvem[.]com, support[.]berrydev[.]xyz, berry4603.github[.]io, corychase[.]org) до чорних списків DNS і проксі-серверів.
- Поведінкове виявлення: послідовність розвідувальних команд (перевірка потреби в перезавантаженні, статус шифрування, профілі брандмауера, перелік адміністраторів), виконуваних у RMM-контексті поза затвердженим ІТ-процесом, є надійним поведінковим індикатором компрометації.
- Навчання співробітників: поінформуйте персонал, що Microsoft Teams оновлюється через вбудовані механізми й ніколи не вимагає завантаження оновлень із зовнішніх сайтів або через «Microsoft Store» за посиланням із листа.
- Захист облікових даних: у контексті JIVS PhishKit переконайтеся, що MFA увімкнена для всіх корпоративних поштових акаунтів — навіть у разі компрометації пароля це унеможливить доступ до облікового запису.
Організаціям варто насамперед провести аудит встановлених RMM-інструментів на всіх кінцевих точках, зіставивши їх зі списком затвердженого ПЗ. Будь-який неавторизований RMM-агент — потенційний індикатор компрометації, що потребує негайного розслідування з ізоляцією хоста та ротацією облікових даних привілейованих користувачів на ураженій системі.
