Взлом реестра Дании дал злоумышленнику доступ к данным 8,8 млн человек — предположительно через учётную запись подрядчика, защищённую паролем «123456». Для любой компании, подключающей поставщиков к критичным системам, это неприятное напоминание: сильная защита центральной базы мало помогает, если в неё можно войти через плохо настроенный внешний аккаунт.
Как сообщает vc.ru, атакующий получил доступ к датскому государственному реестру CPR через учётную запись ИТ-компании Pays ApS. Компания легально использовала систему для проверки информации о корпоративных клиентах, однако доступ подрядчика стал точкой входа в государственную инфраструктуру.
По данным датских властей, несанкционированный доступ обнаружили 2 октября 2026 года. Сам инцидент, по имеющейся информации, начался ещё в первых числах сентября — почти за месяц до обнаружения. Это важная деталь: даже если злоумышленник не распространял выгрузку, длительное присутствие в системе оставляет достаточно времени, чтобы собрать значительный массив записей и проверить, какие ещё действия доступны из скомпрометированной учётной записи.
В CPR хранятся сведения примерно о 11 млн человек. В эту цифру входят не только нынешние жители страны, но и умершие либо уехавшие из Дании. Атакующий утверждает, что получил данные 8,8 млн записей, включая имена, адреса и персональные номера CPR. Такие номера используются в датской административной системе как идентификаторы граждан и резидентов, поэтому утечка сочетания имени, адреса и номера повышает риск мошеннических обращений, социальной инженерии и попыток пройти проверки личности в зависимых сервисах.
Ответственность за атаку взял на себя человек, который сообщил газете Politiken, что вошёл в аккаунт Pays ApS с паролем «123456». По его словам, такой же пароль применялся ещё в двух учётных записях компании. Независимое техническое подтверждение этой версии в приведённых данных не раскрывается, но власти сам факт компрометации реестра подтвердили. Злоумышленник также заявил, что не намерен продавать или публиковать полученные сведения. Для пострадавших это не гарантия безопасности: после получения данных контролировать копии, логи и возможную передачу информации уже невозможно.
Проблема не в одном плохом пароле
История выглядит почти карикатурно, но сводить её к привычной шутке про «123456» было бы слишком удобно. Государственный реестр не обязательно должен быть напрямую уязвим, чтобы пострадать: достаточно выдать партнёру широкие права, не потребовать многофакторную аутентификацию, не ограничить доступ по сети и не заметить аномальную активность. В результате защита всей цепочки оказывается равна защите наименее дисциплинированного участника.
Для команд разработки и ИБ здесь нет экзотического урока. Учётные записи подрядчиков и интеграций должны жить отдельно от пользовательских, получать минимально необходимые права и иметь ограниченный срок действия. Парольная политика без технического принуждения тоже не работает: запрет популярных комбинаций, менеджер паролей, MFA и контроль повторного использования паролей нужны не в регламенте, а в механизмах входа. Если сотрудник или внешний поставщик может выбрать «123456», система фактически заранее согласилась принять этот риск.
Отдельный вопрос — мониторинг. Разрыв почти в месяц между предполагаемым началом доступа и обнаружением означает, что одних журналов событий недостаточно. Для систем с персональными данными критичны оповещения о массовом поиске и выгрузке записей, необычных временных окнах работы, запросах из новых сетей и изменениях поведения учётной записи. Полезны и регулярные проверки того, кому вообще нужен доступ: интеграции часто получают права на старте проекта, а затем остаются в системе дольше самого контракта.
Взлом реестра Дании также показывает, почему оценка поставщика не должна заканчиваться подписанием договора. Бизнесу стоит проверять не только наличие формального сертификата или политики безопасности, но и практические вещи: обязательна ли MFA, кто администрирует аккаунты, как отзывается доступ, есть ли аудит привилегий и как быстро партнёр сообщает об инцидентах. Для государственных платформ, где на кону данные миллионов людей, такие требования становятся частью архитектуры, а не приложением к закупочной документации.
Самый неудобный вывод из этой истории прост: масштаб критической системы не защищает её от базовых ошибок. Чем больше организаций подключено к реестру и чем больше у них прав, тем внимательнее придётся управлять каждым внешним входом. Вопрос после этого инцидента не только в том, были ли скопированы данные, но и в том, сколько других интеграций в похожих системах до сих пор считают пароль достаточным средством защиты.