Пароль Password1, оставленный на тестовой учётной записи с 2012 года, стал одной из точек входа при атаке шифровальщика на валлийскую организацию Data Cymru. Злоумышленники получили данные 3300 человек, преимущественно детей, а британский регулятор отдельно указал на слабые пароли, неотключённые аккаунты и одинаковые пароли локальных администраторов. Для российских IT-команд это очередное неприятное напоминание: старый тестовый доступ часто опаснее экзотической уязвимости.
Инцидент произошёл 1 ноября 2024 года, сообщает The Register. Британское Управление комиссара по информации (ICO) вынесло официальные предупреждения Data Cymru и её поставщику инфраструктуры Ogi Networks Limited (ONL), не назначив штрафов. Data Cymru помогает государственным структурам Уэльса работать с данными, а ONL обеспечивала для неё серверную и сетевую инфраструктуру, лицензии и поддержку.
По версии ICO, атакующий воспользовался учётной записью Test2, проник во внутреннюю сеть и зашифровал 182,7 ГБ данных на файловом сервере и внутреннем сервере баз данных. До запуска шифровальщика он успел выгрузить 42 ГБ с основного контроллера домена, файлового сервера и SQL-сервера. Объём сам по себе не выглядит рекордным на фоне крупных вымогательских кампаний, но содержание данных делает эпизод куда серьёзнее: речь идёт о персональной информации тысяч людей.
Аккаунт Test2 ONL создала 13 января 2012 года во время первоначального проекта для Data Cymru. Вероятно, его использовали, чтобы проверить доступ пользователей перед миграцией реальных учётных записей. Пароль для него выбрали без фантазии — Password1. ICO приводит оценку менеджера паролей Bitwarden: такой пароль относится к категории «очень слабых» и подбирается менее чем за секунду. Тестирование завершилось, проект продолжал жить, а временный аккаунт пережил более 12 лет эксплуатации.
Один вход — несколько серверов
Проблема не ограничилась Test2. Локальные административные учётные записи на трёх затронутых системах использовали один и тот же пароль. После компрометации одной машины атакующий мог собрать хеши локальных аккаунтов и применять их для аутентификации на других узлах сети. Это классический сценарий бокового перемещения: первоначальный доступ может быть примитивным, но единые секреты превращают его в пропуск ко всей инфраструктуре.
ONL признала, что после первоначального развёртывания не проводила проверки локальных администраторских аккаунтов. Они оставались активными независимо от того, нужны ли были кому-либо, и сохраняли исходные пароли, заданные в январе 2012 года. ICO также установило, что у поставщика не было процедуры аудита пользовательских учётных записей в Active Directory Data Cymru. Иными словами, организация не просто не заметила конкретный Test2: у неё отсутствовал регулярный механизм, который вообще должен был находить подобные цифровые артефакты.
Регулятор квалифицировал действия ONL как нарушение статьи 32 британского GDPR: компания не обеспечила технические и организационные меры, соразмерные риску, и не оценивала их регулярно. Data Cymru получила отдельное предупреждение за собственные недостатки защиты. Важная деталь для компаний с аутсорсинговой инфраструктурой: ICO не позволило свести ответственность к подрядчику. ONL создала тестовую учётную запись, но Data Cymru сохраняла контроль над сетью и могла поручить создание либо удаление аккаунтов.
Руководитель расследований ICO Дэвид Дудсон сформулировал вывод без дипломатии: Password1 — это фактически открытая дверь для злоумышленников. По его словам, ответственность лежала на обеих организациях, поскольку ни одна не настроила ясный и работающий процесс регулярного поиска и удаления устаревших аккаунтов. Регулятор не обнаружил здесь редкой цепочки неизвестных уязвимостей: причиной стал набор базовых ошибок, которые десятилетиями считаются недопустимыми.
Что из этого следует IT-командам
История полезна именно своей банальностью. Тестовые учётные записи редко попадают в квартальные отчёты и почти никогда не выглядят срочной задачей. Они создаются для миграции, пилота, интеграции или разового доступа подрядчика, а потом исчезают из памяти команды. За годы меняются администраторы, подрядчики и доменные политики, но забытый аккаунт остаётся — часто с широкими правами и паролем, который когда-то казался временным.
Минимальная защита здесь не требует дорогой платформы: нужен инвентарь учётных записей, владелец для каждой из них, срок действия для временных доступов и регулярная сверка неактивных объектов в Active Directory. Отдельно стоит проверять локальные администраторские учётные записи: одинаковый пароль на серверах убивает сегментацию быстрее, чем её успевают описать в политике ИБ. Уникальные пароли, управляемые решениями для локальных администраторов, многофакторная аутентификация там, где она применима, и журналирование аномальных входов снижают шанс превратить единичную компрометацию в захват сети.
Техническая часть важна, но не заменяет распределения ответственности. В договорах с провайдерами стоит явно фиксировать, кто создаёт, утверждает, пересматривает и отключает доступы; формулировка «инфраструктуру обслуживает подрядчик» не отвечает ни на один из этих вопросов. Слабые пароли и забытые аккаунты обычно появляются на стыке зон ответственности, где каждая сторона уверена, что ревизию делает другая.
Случай Data Cymru показывает, что следующая крупная точка входа может не быть нулевым днём и не появиться в ленте CVE. Ею способен оказаться старый тестовый пользователь, о назначении которого никто уже не помнит. Поэтому самый практичный вопрос для руководителя разработки, инфраструктуры или ИБ звучит не «есть ли у нас Password1», а «можем ли мы за день доказать, кому и зачем нужен каждый активный аккаунт в нашей сети».
