- Злоумышленник получил несанкционированный доступ к Центральному реестру физических лиц Дании (CPR) через стороннюю компанию.
- Взлом произошел из-за элементарного пароля «123456», установленного минимум на трех корпоративных аккаунтах, включая учетную запись администратора.
- Инцидент затронул личные данные 8,8 миллиона ныне живущих и умерших граждан, а саму брешь выявили лишь благодаря финансовому счету за аномальный трафик.
Один из самых вопиющих инцидентов в сфере информационной безопасности за последнее время развернулся в Дании. Государственный Центральный реестр физических лиц (CPR), содержащий конфиденциальные сведения практически обо всем населении королевства, подвергся масштабной компрометации. Причиной утечки колоссального массива записей стало пренебрежение базовой цифровой гигиеной со стороны частного подрядчика.
Анатомия взлома: 14 миллионов запросов за 10 дней
Лицо, заявившее об ответственности за кибератаку, сообщило журналистам датского издания Politiken, что проникновение в систему не потребовало сложных эксплойтов или специализированного оборудования. Доступ был получен через учетные записи датской компании Pays ApS, базирующейся на острове Фюн. Организация имела легитимный доступ к реестру CPR для ведения коммерческой деятельности, включая верификацию клиентов.
Как выяснилось, сразу три корпоративных профиля компании — среди которых числился и аккаунт системного администратора — были защищены примитивной комбинацией «123456». Полномочия позволили злоумышленнику беспрепятственно выгружать информацию государственного масштаба.
| Параметр инцидента | Показатели и детали |
|---|---|
| Затронутые записи | 8,8 млн человек (из ~11 млн в реестре CPR) |
| Тип скомпрометированных данных | Имена, адреса, идентификационные номера (CPR) |
| Период активности атаки | С 10 по 20 сентября |
| Число автоматических поисковых запросов | 14 млн обращений к базе |
| Дата обнаружения аномалии | 2 октября (спустя 12 дней после окончания выгрузки) |
| Официальное раскрытие инцидента | 5 октября |
Как обнаружили вторжение
По информации датской телерадиокомпании TV 2, злоумышленник непрерывно парсил государственную базу данных с 10 по 20 сентября, сгенерировав 14 миллионов автоматизированных поисковых запросов. Ни автоматические системы защиты реестра, ни служба безопасности подрядчика вовремя не среагировали на аномальный поток трафика.
Проникновение вскрылось лишь 2 октября благодаря бдительности сотрудника Министерства высшего образования и науки. Специалист обратил внимание на входящий счет за обслуживание инфраструктуры, где фигурировала беспрецедентно высокая плата из-за резкого всплеска запросов со стороны Pays ApS. 4 октября власти уведомили датское управление по защите данных (Datatilsynet), а 5 октября факт взлома признали публично.
Реакция сторон и последствия
Управляющий директор Pays ApS Софи Лаурсен подтвердила факт компрометации инфраструктуры компании, после чего официальный сайт сервиса был переведен в офлайн. При этом правительственные чиновники и сама компания воздерживаются от подробных публичных комментариев относительно столь грубых нарушений парольной политики.
Сам хакер утверждает, что не собирается продавать или публиковать полученные сведения в открытом доступе. Однако утечка имен, адресов и персональных идентификаторов 8,8 млн граждан (включая умерших людей и эмигрантов) ставит под угрозу конфиденциальность огромной части населения Дании.
Инцидент наглядно демонстрирует, что надежность централизованных баз данных определяется самым слабым звеном в цепочке интеграций. Предоставление внешним подрядчикам доступа к критическим реестрам без обязательной двухфакторной аутентификации (2FA) и жесткого контроля сложности паролей создает колоссальные риски, нивелируя любые инвестиции в безопасность ядра системы.
Классика жанра, сами наступали на эти грабли, пока не закрутили гайки. Теперь у нас в контуре ни один сервис не взлетит без жесткой парольной политики и обязательного 2FA через аппаратные ключи. Совет коллегам: настройте банальный rate limiting на API и алерты в Grafana по скачкам трафика, чтобы не ждать потом круглый счет от облачного провайдера.
Подобные инциденты наглядно вскрывают системную проблему управления рисками цепочки поставок (Third-Party Risk). Отсутствие обязательной мультифакторной аутентификации для привилегированных учетных записей и базового rate limiting на шлюзах API госресурса — критический провал архитектуры ИБ. Рынок неизбежно придет к ужесточению регуляторного комплаенса по директиве NIS2.