Взлом ConnectWise: приложению не нужна ваша MFA

Атакующий вошёл от имени приложения

Пользователи прошли MFA. Атакующий вошёл от имени приложения. В этом граница идентичности инцидента ConnectWise Cloud Backup: учётные данные приложения использовались для получения доступа с правами, уже предоставленными в тенантах клиентов. Контроль, проверяющий вход человека, не стоял на этом пути.

Advisory ConnectWise, проверенный 20 октября 2026 года, подтверждает несанкционированный доступ к идентичностям приложений и описывает сдерживание. Исходный механизм раскрытия учётных данных всё ещё расследуется. Эта статья — архитектурный анализ открытых источников, а не воспроизведение в действующем тенанте. Долговременный вопрос: какой доступ сохраняет интеграция, если данные её оператора оказались у атакующего? [1][2]

Согласие создаёт идентичность с постоянными полномочиями

Application permissions отличаются от delegated permissions. При client-credentials flow программа аутентифицируется от своего имени, без вошедшего пользователя. У мультитенантного приложения есть service principal в каждом тенанте, где оно используется; согласие и назначенные разрешения определяют его возможности. Сброс пароля пользователя не отзывает учётные данные приложения и не меняет эти права. [3][4]

Поэтому я начинаю проверку интеграции с набора прав, а не названия продукта. Резервное копирование и восстановление могут обоснованно требовать широкого доступа, но чтение, запись и изменение идентичностей имеют разные последствия. Зафиксируйте конкретные разрешения и роли каталога в своём тенанте. Не считайте, что все клиенты выдали одинаковые права или что слово backup ограничивает приложение чтением.

Conceptual app-only path

Vendor application credential
  -> token request for customer tenant
  -> customer service principal + granted permissions
  -> access token for a resource
  -> resource operation

No user password or MFA prompt is part of this flow.

Охватывает ли политика именно этот тип приложения?

Документация Microsoft по workload Conditional Access исключает сторонние SaaS и мультитенантные приложения из этих политик для service principal. Покупка нужной лицензии не отменяет ограничения области действия. Документация workload Continuous Access Evaluation также ограничивает поддержку однотенантными service principal, зарегистрированными в данном тенанте. Название функции не доказывает защиту конкретной идентичности. [5][6]

Практическая проверка строит соответствия: для каждой интеграции назовите контроль запроса токена, ресурс, принимающий токен, и доступные операции. Там, где политика не применяется, зафиксируйте пробел и возможные компенсирующие ограничения. MFA полезна для доступа пользователей; предположение, что она регулирует и app-only credentials, оставляет отдельную идентичность без проверки.

Отключение приложения решает только часть задачи

Прекратить выдачу новых токенов и аннулировать действующий доступ — разные операции. Microsoft документирует срок токена по умолчанию 60–90 минут, но это не универсальный обратный отсчёт для инцидента. Важны настройки токена, поведение ресурса и поддерживаемые механизмы отзыва. ConnectWise прямо указывает, что выданные токены могут работать до истечения срока или другой инвалидации. Учитывайте это в плане, не приравнивайте disable к мгновенному выходу. [1][7]

Есть и третье состояние: доступ через другую идентичность. Huntress сообщает о добавлении несанкционированных учётных данных в другие приложения затронутых тенантов. Отключение исходного приложения ConnectWise их не удаляет. Поэтому моя модель закрытия включает три строки: новая выдача остановлена, прежние токены учтены, посторонний последующий доступ устранён. Девяносто минут ожидания не доказывают третью строку. [2]

Containment question                 Evidence to request
New tokens still issued?             Application state + sign-in outcomes
Existing token still accepted?       Resource behavior + expiry/invalidation
New independent access established?  Credential, grant and role-change review

Elapsed time alone is not a closure record.

Успешный вход не доказывает каждое возможное действие

Успешный вход service principal доказывает меньше, чем чтение всех почтовых ящиков. Todyl описывает входы без тех изменений для закрепления, которые искала в проверенных тенантах. Huntress описывает действия после компрометации в других средах. Это разные наборы наблюдений, а не основание приписать худший исход всем клиентам. Права показывают возможность; данные об операциях показывают наблюдавшееся использование. [2][8]

Обратное упрощение тоже опасно. Пустой журнал входов пользователей не охватывает входы service principal, которые Microsoft регистрирует отдельно. Отсутствие записей аудита также не доказывает, что любое чтение данных обязательно попало бы в журнал. Ограничьте вывод: какая телеметрия доступна, какие идентичности и ресурсы она охватывает, какие операции действительно показывает. Неизвестность полезна, если сохраняет следующий шаг расследования. [2][9]

Проследите изменения от исходного приложения к другим идентичностям

Ищите по application ID, затем сопоставляйте входы service principal с событиями аудита в окне инцидента. Указанный ниже ID Cloud Backup — начальная точка, а не полный перечень затронутых приложений; для всего семейства используйте актуальный список вендора. Сохраните инициатора, цель, результат и correlation ID. Проверяйте действия приложения как инициатора, а не только изменения самого приложения. [1]

Сверяйте незнакомые ключи, предоставленные разрешения и назначения ролей с утверждёнными записями владельцев до признания их вредоносными. Срок действия ключа сам по себе не устанавливает дату его добавления. Запишите, что удалено, почему и какую другую идентичность оно открывало. Так получается проверяемая цепочка вместо скриншота с одним отключённым enterprise application. [1]

Initial application ID: 506e08f9-6e9a-4da4-942b-a099a03644ae
Product label: ConnectWise Cloud Backup / formerly SkyKick

Investigation record:
  tenant + application ID + local service principal ID
  event time + initiator + target + outcome + correlation ID
  credential or permission change + approved owner record
  containment action + remaining access + evidence limits

Спросите, что останется после нажатия Disable

Критерий приёмки сторонней интеграции стоит сформулировать до инцидента: если её ключ утечёт завтра, какое действие клиента остановит новый доступ, что будет с выданными токенами и как найти права или ключи, созданные в других местах? У этих ответов должны быть назначенные владельцы. Интеграция без действующего владельца сохраняет весь неотозванный доступ.

Эти же вопросы определяют полезную проверку исправлений после инцидента. Я бы проверил доказательства каждого состояния сдерживания и изменения других идентичностей, прежде чем считать исходное приложение всей проблемой. Восстановление резервного копирования и доказательство контроля над доступом к тенанту — связанные решения, которым нужны отдельные подтверждения.