Російські угруповання кібершпигунства, які раніше активно експлуатували критичні вразливості у поштових серверах Zimbra, переключили свою увагу на поштову інфраструктуру Microsoft. Цього разу під ударом опинився веб-інтерфейс поштових скриньок Microsoft Outlook Web Access (OWA). Спеціалісти зафіксували масштабну кампанію, спрямовану проти державних установ США та європейських країн, а також організацій у сферах телекомунікацій, фінансів, авіації та готельного бізнесу. Активна фаза цієї операції розпочалася у другій половині липня 2026 року.

Головна небезпека виявленого методу атаки полягає в тому, що зловмисники знайшли спосіб зберігати доступ до компрометованих поштових скриньок навіть після того, як адміністратори або користувачі проводять планову чи екстрену зміну паролів (credential rotation). У типовому сценарії реагування на інциденти першим кроком захисників є скидання паролів скомпрометованих облікових записів. Проте у цьому випадку такий крок виявився неефективним через специфіку реалізації сесій у Microsoft OWA.

Технічно атака базується на експлуатації архітектурних особливостей або конкретної вразливості у механізмі керування сесіями Microsoft Exchange та OWA. Коли користувач проходить автентифікацію через OWA, сервер створює унікальний ідентифікатор сесії та пов'язані з ним токени доступу (зокрема, сесійні cookie-файли). Проблема полягає в тому, що після зміни пароля активні сесії користувача у веб-інтерфейсі OWA не анулюються примусово у реальному часі. Зловмисники, які заздалегідь викрали дійсні сесійні токени або впровадили власні механізми доступу, продовжують використовувати відкриту сесію без необхідності повторного введення нових облікових даних.

Крім того, атака може задіяти механізми тривалого збереження доступу (persistence) через інтерфейси прикладного програмування, такі як Exchange Web Services (EWS) або REST API. Якщо хакери встигають налаштувати підписку на події скриньки або згенерувати довготривалі OAuth-токени до доступу до пошти (через зловживання правами додатків), зміна пароля користувача Active Directory жодним чином не впливає на ці підключення. Це дозволяє шпигунам місяцями залишатися непоміченими у мережі жертви, збираючи конфіденційне листування та внутрішні документи.

Ця кампанія демонструє еволюцію інструментарію російських APT-груп. Після того як розробники Zimbra випустили патчі для закриття дір, які хакери використовували для масового збору пошти, зловмисники швидко адаптували свої методи під значно поширенішу корпоративну платформу Microsoft Exchange. Враховуючи, що OWA часто публікується безпосередньо у глобальній мережі для зручності віддаленої роботи співробітників, ризик компрометації залишається критично високим для багатьох українських підприємств та державних органів, які досі використовують локальні (on-premises) версії поштових серверів.

Що це означає на практиці

Для захисту корпоративної поштової інфраструктури та мінімізації наслідків можливої компрометації пентест-команда рекомендує вжити таких практичних заходів:

  • Примусове відкликання активних сесій (Revoke Sessions): При підозрі на компрометацію облікового запису або під час планової зміни паролів недостатньо просто змінити пароль в Active Directory. Адміністратори Microsoft Exchange повинні примусово завершити всі активні сесії користувача. Для локальних серверів Exchange це виконується через перезапуск пулів додатків IIS (MSExchangeOWAAppPool) або за допомогою спеціальних команд PowerShell для очищення сесійних кешів. Для хмарних середовищ Microsoft 365 обов'язково використовуйте команду Revoke-MgUserSignInSession через Microsoft Graph PowerShell.
  • Перевірка та аудит OAuth-дозволів та зареєстрованих додатків: Регулярно аналізуйте список корпоративних додатків, які мають доступ до поштових скриньок через API. Особливу увагу звертайте на дозволи на кшталт Mail.Read, Mail.ReadWrite та full_access_as_app. Видаляйте будь-які невідомі або застарілі інтеграції, оскільки вони дозволяють обходити автентифікацію за паролем.
  • Впровадження суворих правил сесій у Microsoft Exchange/IIS: Налаштуйте мінімальний час життя сесій (Session Timeout) для OWA. За замовчуванням сесії можуть залишатися активними занадто довго. Обмежте час життя cookie-файлів автентифікації та налаштуйте обов'язкове використання багатофакторної автентифікації (MFA) при кожному новому підключенні або зміні контексту безпеки.
  • Аналіз логів автентифікації та доступу до OWA: Налаштуйте детальний моніторинг журналів IIS та логів автентифікації. Шукайте аномалії, такі як доступ до однієї скриньки з різних IP-адрес протягом короткого проміжку часу (impossible travel), або використання застарілих методів доступу (наприклад, базової автентифікації, якщо вона ще не вимкнена). Особливу увагу приділіть запитам до файлів owa/auth.owa та API-ендпоінтів Exchange.