Сервисные аккаунты M365 снова показали неприятную магию корпоративной безопасности: можно закрыть человеческие учетные записи, включить MFA и все равно получить дыру через забытый технический логин. В Чили неизвестная группа атаковала организации через Microsoft 365 и смогла добраться до корпоративных данных не через сотрудников, а через «ничьи» аккаунты для бизнес-процессов.
По данным Dark Reading, исследователи Proofpoint рассказали об этой кампании на конференции Proofpoint Protect 2026 в Сан-Диего. Актор, которого компания отслеживает как UNK_CondorFiltration, использовал открытый инструмент TeamFiltration и базовый credential spraying. Судя по описанию атаки, никакой киношной эксплуатации нулевого дня не понадобилось: хватило старых учеток, слабой гигиены доступа и того самого «потом разберемся», которое живет в каждом втором тенанте.
Кампания началась 21 июля. Сначала атакующие проверяли сотни M365-аккаунтов, связанных с двумя крупными банками в Чили. Через неделю они переключились на тысячи аккаунтов в третьей финансовой организации той же страны. Эти попытки, по данным исследователей, не дали заметного результата. В середине августа группа вернулась с третьей волной и сфокусировалась уже на одном крупном чилийском ритейлере. Там атака сработала: были скомпрометированы семь корпоративных учетных записей.
Самая важная деталь — среди более чем 5700 проверенных аккаунтов в 28 M365-тенантах атакующие не взломали ни одной обычной учетной записи сотрудника. Успех пришел через семь функциональных и сервисных аккаунтов, которые, похоже, были забыты или плохо документированы. Такие аккаунты создают для тикетинга, согласования платежей поставщикам, интеграций, автоматизации и прочих скучных, но критичных задач. Потом проект закрывается, команда меняется, владелец уходит, а логин остается — иногда с общим паролем, иногда без MFA, иногда с правами шире, чем у живого человека.
В этом случае у скомпрометированных учеток не было активной пользовательской истории: никто не логинился в них и не выполнял действий от их имени. Именно поэтому они могли годами не попадать в поле зрения администраторов. Proofpoint считает, что у части аккаунтов могли быть дефолтные или разделяемые учетные данные. Шесть из семи таких учетных записей злоумышленники, по данным исследователей, забрали за семь минут. Для команды безопасности это звучит особенно обидно: месяцы на hardening рабочих аккаунтов — и семь минут на забытую техническую дверь.
После первичного доступа атакующие использовали функцию автоэксфильтрации TeamFiltration. Они вытягивали письма, чаты и файлы из Outlook, Teams и OneDrive. В одном из эпизодов активность пошла дальше: злоумышленники проверяли VPN компании, заходили в портал управления M365 и Azure Portal, а также просматривали файлы в SharePoint. Для бизнеса это уже не «утекла почта одного отдела», а потенциальный доступ к управленческой, финансовой и клиентской информации, плюс карта внутренних процессов.
TeamFiltration — не новый секретный имплант, а открытый набор для атак на M365, появившийся несколько лет назад. Он умеет перечислять аккаунты в тенанте, пробовать учетные данные, обходить часть блокировок за счет ротации инфраструктуры и помогать с дальнейшей выгрузкой данных. Инструмент одинаково доступен исследователям, пентестерам и людям, которые не спрашивают юридический отдел перед запуском. Поэтому история в Чили важна не экзотикой, а простотой: если сервисные аккаунты M365 не инвентаризированы, их можно найти быстрее, чем владелец бизнеса вспомнит, зачем они создавались.
Директор по исследованию угроз Proofpoint Янив Мирон указывает на типичную причину проблемы: сервисные учетные записи создают под конкретную задачу, но после исчезновения этой задачи никто не отключает доступ. Хуже, когда такие аккаунты появляются неофициально, силами отдельных команд, без нормального описания в IAM-процессах. Тогда SOC и администраторы Entra ID могут даже не знать, что именно им нужно защищать. Рекомендация приземленная: привязывать каждую облачную учетную запись к ответственному сотруднику, задавать срок жизни и регулярно искать имена, которые выбиваются из корпоративного шаблона.
Для русскоязычных IT-команд урок довольно прямой. Проверка MFA у сотрудников — это только половина работы. Нужен реестр нечеловеческих идентичностей: сервисные аккаунты, shared mailbox, интеграции, автоматические процессы, временные пользователи подрядчиков. У каждого должен быть владелец, назначение, минимальные права, срок пересмотра и понятный сценарий отключения. И да, скрипт, который проходит по пользователям M365 и показывает странные имена, давно пора считать не хаком энтузиаста, а обычной гигиеной.
Главный тренд здесь шире одной атаки в Чили: облачная безопасность все чаще ломается не там, где компании ждут сложного противника, а там, где у них нет учета. Следующий большой спор в корпоративной защите будет не о том, включили ли MFA, а о том, кто в компании вообще отвечает за учетные записи, у которых нет лица, должности и рабочего места.