28.07.2026

У KDDI и пяти японских провайдеров могли похитить 14,22 млн email-адресов и паролей

Один из крупнейших телеком-операторов Японии KDDI сообщил о взломе почтовой системы, которую использовала не только сама компания, но и еще пять японских интернет-провайдеров. По предварительным данным, злоумышленники могли получить доступ к 14,22 млн записей с email-адресами и паролями абонентов. Инцидент стал крупной утечкой для японского телеком-рынка и показал, насколько опасной может быть общая инфраструктура, если ею пользуются сразу несколько операторов.

Компрометацию систем KDDI обнаружила 17 июня 2026 года. После этого компания заявила, что оперативно заблокировала доступ атакующих и начала расследование. Первичный анализ показал, что злоумышленники проникли в систему через уязвимость в неназванном стороннем программном обеспечении. Это важная деталь: атака была связана не только с внутренней защитой KDDI, но и с рисками, которые возникают из-за внешних компонентов, поставщиков и зависимостей.

Инцидент затронул не только KDDI. По данным компании, той же почтовой инфраструктурой пользовались STNet, JCOM, Chubu Telecommunications, Nifty и Biglobe. Поэтому потенциальная утечка распространяется сразу на несколько провайдеров и их абонентские базы. Для пользователей это означает, что риск мог возникнуть даже в том случае, если они напрямую не воспринимали KDDI как своего основного поставщика услуг, но их провайдер использовал общую почтовую систему.

Точное число затронутых учетных записей пока не подтверждено окончательно, потому что расследование продолжается. Предварительно речь идет о 14,22 млн записей. Они могут принадлежать действующим клиентам, бывшим абонентам и владельцам неактивных учетных записей, которыми давно не пользовались. Это особенно важно: люди часто забывают о старых почтовых аккаунтах, но если к ним привязаны другие сервисы, утечка пароля может создать новые риски.

Главная опасность такой утечки заключается в повторном использовании паролей. Если пользователь применял один и тот же пароль для почты, соцсетей, банковских сервисов, маркетплейсов, мессенджеров или рабочих систем, злоумышленники могут попробовать войти в другие аккаунты. Такой метод называется credential stuffing: украденная пара email и пароль автоматически проверяется на множестве популярных сайтов. Даже если взлом произошел у провайдера, последствия могут выйти далеко за пределы почтового ящика.

Почтовый аккаунт особенно ценен для атакующих. Через него можно восстанавливать пароли от других сервисов, получать коды подтверждения, читать переписку, искать документы, находить чеки, данные заказов, личную информацию и контакты. Если злоумышленник получает доступ к почте, он может попытаться захватить другие аккаунты человека, изменить пароли, удалить уведомления и скрыть следы. Поэтому утечка email-паролей относится к наиболее чувствительным типам компрометации.

KDDI сообщает, что часть паролей хранилась в хешированном или зашифрованном виде. Это снижает риск немедленного захвата аккаунтов, но не устраняет проблему полностью. Если пароль был надежно хеширован с современной солью и устойчивым алгоритмом, восстановить его значительно сложнее. Но если использовался слабый алгоритм, старая схема защиты или простое шифрование с доступным ключом, часть паролей может быть раскрыта.

Компания не уточнила, какими именно методами были защищены пароли и какая доля данных могла храниться в открытом виде. Для кибербезопасности это критически важный вопрос. Между надежным хешированием и слабой защитой огромная разница. Хеширование делает пароль необратимым при правильной реализации, а шифрование можно расшифровать при наличии ключа. Если же часть паролей была сохранена открытым текстом, такие учетные данные можно использовать сразу.

Даже хешированные пароли остаются целью для атак. Злоумышленники могут пытаться подбирать их офлайн с помощью словарей, утекших баз и видеокарт. Чем проще пароль, тем быстрее он может быть восстановлен. Комбинации вроде имени, даты рождения, короткого слова, номера телефона или повторяющегося шаблона раскрываются гораздо быстрее, чем длинные уникальные фразы. Поэтому после такой утечки смена пароля обязательна даже при заявлении о хешировании.

Все пострадавшие провайдеры были уведомлены об инциденте сразу после обнаружения атаки. KDDI также сообщила о случившемся японской Комиссии по защите персональных данных и Министерству внутренних дел и коммуникаций. Это показывает, что утечка рассматривается как серьезный инцидент с персональными данными, требующий участия регуляторов. Для телеком-операторов такие события особенно чувствительны, потому что они обслуживают миллионы пользователей и хранят данные, связанные с цифровой идентичностью клиентов.

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

Для телеком-компаний этот инцидент показывает опасность общей платформенной инфраструктуры. Если несколько провайдеров используют одну почтовую систему, экономия и удобство сопровождаются концентрацией риска. Успешная атака на один компонент затрагивает сразу несколько компаний и миллионы пользователей. Поэтому общие платформы должны защищаться как критически важная инфраструктура, а не как обычный вспомогательный сервис.

Особенно важно управление сторонним программным обеспечением. Если взлом произошел через уязвимость в внешнем компоненте, компаниям нужно знать, какие продукты используются, какие версии установлены, кто отвечает за обновления, как быстро устанавливаются патчи и как проверяется эксплуатация известных CVE. Без точной инвентаризации организация может не понимать, что в ее критической системе есть уязвимый компонент, пока не произойдет инцидент.

Стороннее ПО часто становится слабым местом, потому что его воспринимают как уже готовое и надежное решение. Но любое внешнее приложение, библиотека, почтовый сервер, панель администрирования, шлюз или модуль авторизации требует регулярного обновления, мониторинга и контроля доступа. Если поставщик выпускает исправление, но оно не устанавливается вовремя, уязвимость превращается в открытую дверь для атакующих.

Для почтовой инфраструктуры особенно важна сегментация. Серверы, где хранятся учетные данные пользователей, не должны иметь лишний доступ к другим внутренним системам. Если атакующий получает доступ к почтовому компоненту, он не должен автоматически получить путь к биллингу, CRM, сетевому оборудованию, административным панелям или данным других сервисов. Чем лучше разделены зоны, тем меньше масштаб последствий.

Отдельный вопрос — хранение паролей. Современная система не должна хранить пользовательские пароли в открытом виде. Надежный вариант — адаптивное хеширование с солью и алгоритмами, рассчитанными на замедление массового подбора. Если в старой инфраструктуре остались устаревшие методы хранения, их нужно менять до инцидента, а не после утечки. При компрометации базы именно способ хранения паролей определяет, насколько быстро злоумышленники смогут их использовать.

Для пользователей KDDI, STNet, JCOM, Chubu Telecommunications, Nifty и Biglobe главный практический шаг — немедленно сменить пароль от почтового аккаунта. Новый пароль должен быть уникальным и не использоваться ни в одном другом сервисе. Если старый пароль применялся где-то еще, его нужно заменить везде. Важно не просто добавить цифру в конец старого пароля, а создать полностью новую надежную комбинацию.

Лучше использовать менеджер паролей, который генерирует длинные уникальные пароли для каждого сайта. Это снижает главный риск credential stuffing. Даже если один сервис будет взломан, злоумышленники не смогут войти с тем же паролем в другие аккаунты. Для обычного пользователя это одна из самых эффективных мер защиты после любой утечки учетных данных.

Также нужно включить двухфакторную аутентификацию там, где она доступна. Для почты это особенно важно. Даже если пароль станет известен атакующим, второй фактор может остановить вход. Лучше использовать приложение-аутентификатор или аппаратный ключ безопасности, если сервис поддерживает такие методы. SMS-коды лучше, чем отсутствие второго фактора, но они слабее из-за риска перехвата номера, SIM swap и социальной инженерии.

После смены пароля стоит проверить активные сессии почтового аккаунта. Если сервис показывает подключенные устройства, недавние входы, IP-адреса или приложения с доступом к почте, нужно удалить все неизвестные элементы. Также важно проверить правила пересылки писем. Злоумышленники часто добавляют скрытую пересылку на внешний адрес, чтобы читать новые письма даже после смены пароля. Если такое правило осталось, компрометация продолжится незаметно.

Нужно проверить и настройки восстановления аккаунта. Если атакующий успел изменить резервный email, номер телефона, контрольные вопросы или подключенные приложения, он может попытаться вернуть доступ позже. После утечки почтовых данных пользователь должен убедиться, что все способы восстановления принадлежат ему, а неизвестные адреса и номера удалены.

Особое внимание стоит уделить аккаунтам, связанным с этой почтой. Банковские сервисы, маркетплейсы, облачные хранилища, соцсети, мессенджеры, игровые аккаунты, государственные порталы и рабочие сервисы могут использовать email для восстановления доступа. Если злоумышленник получит контроль над почтой, он может начать цепочку захвата других учетных записей. Поэтому после утечки нужно проверить наиболее важные сервисы и включить в них дополнительную защиту.

Пользователям нужно ожидать роста фишинговых писем. После утечки email-адресов злоумышленники могут рассылать сообщения от имени KDDI, других провайдеров, банков, сервисов доставки или служб поддержки. В письмах могут просить «подтвердить пароль», «обновить настройки безопасности», «получить компенсацию», «проверить утечку» или «перейти на защищенный портал». Такие письма могут выглядеть убедительно, потому что мошенники знают реальный адрес и могут упоминать провайдера.

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

Если человек получил подозрительное письмо после новости об утечке, лучше не отвечать на него и не открывать вложения. Фишинг после крупных инцидентов часто использует страх и срочность. Мошенники могут писать, что аккаунт будет заблокирован через несколько часов, что пароль уже опубликован или что нужно срочно скачать «защитную программу». Любая такая срочность должна восприниматься как тревожный сигнал.

Для бывших клиентов риск тоже сохраняется. Даже если человек давно не пользуется почтовым аккаунтом провайдера, он мог применять тот же пароль в других сервисах. Старые учетные записи часто остаются забытыми, но данные из них продолжают иметь ценность. Если пользователь когда-то был клиентом одного из затронутых провайдеров, ему стоит вспомнить, где использовался этот email и пароль, и заменить повторяющиеся комбинации.

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

Для компаний, чьи сотрудники могли использовать почтовые адреса этих провайдеров для рабочих задач, стоит провести отдельную проверку. Если личный email был привязан к корпоративным сервисам, облакам, GitHub, VPN или внутренним инструментам, утечка может создать риск для бизнеса. Корпоративные системы не должны зависеть от личных почтовых ящиков сотрудников, особенно для восстановления паролей и административного доступа.

Организациям полезно проверить журналы входов на предмет credential stuffing. После крупных утечек злоумышленники могут массово пробовать пары email и пароль в разных сервисах. Признаками являются многочисленные неудачные входы, попытки с разных IP-адресов, входы в старые аккаунты, активность из необычных стран и попытки обойти MFA. Такие события лучше выявлять автоматически, потому что вручную их легко пропустить.

Для провайдеров важен и вопрос уведомления пользователей. Сообщение должно быть понятным, конкретным и практичным: какие данные могли утечь, какие провайдеры затронуты, что пользователю нужно сделать, как проверить подлинность уведомления и куда обращаться за помощью. Если формулировки слишком размытые, люди недооценивают риск или, наоборот, попадают на фишинговые сайты, пытаясь самостоятельно искать подробности.

После таких утечек провайдерам стоит принудительно сбросить пароли для затронутых аккаунтов или хотя бы для тех, где пароли могли храниться слабее. Это неудобно, но снижает риск массового захвата учетных записей. Если пользователь сам не сменит пароль, украденные данные могут оставаться рабочими. Чем чувствительнее почтовая система, тем важнее активные меры, а не только рекомендация «поменяйте пароль».

Также важно внедрять обнаружение аномального входа. Если в аккаунт входят из нового региона, с неизвестного устройства, после долгого периода неактивности или сразу после утечки, сервис должен требовать дополнительную проверку. Такая защита помогает даже в ситуации, когда пароль уже известен атакующему. Контекст входа становится дополнительным слоем безопасности.

Для операторов связи и интернет-провайдеров инцидент KDDI должен стать поводом пересмотреть хранение учетных данных, мониторинг почтовой инфраструктуры, контроль поставщиков, сегментацию, аудит доступа и планы реагирования на утечки. Почтовый сервис может выглядеть как обычная дополнительная услуга, но для пользователей он часто является центром цифровой жизни. Утечка почтового пароля создает намного больше последствий, чем компрометация отдельного форума или развлекательного сайта.

Отдельно нужно оценить данные бывших и неактивных клиентов. Если аккаунт давно не используется, провайдер должен понимать, зачем он хранится, какие данные в нем остаются и можно ли его отключить или перевести в безопасный архив. Хранение миллионов старых учетных записей увеличивает масштаб утечки. Принцип минимизации данных актуален не только для банков и соцсетей, но и для телеком-операторов.

Для регуляторов такой случай тоже важен. Когда одна инфраструктура обслуживает несколько провайдеров, инцидент у одного оператора становится межорганизационной проблемой. Нужно понимать, кто отвечает за защиту, кто уведомляет пользователей, как распределяется ответственность, какие стандарты хранения паролей применяются и как быстро партнеры получают информацию о риске. Без четких правил пользователи могут долго не понимать, затронуты они или нет.

В кибербезопасности этот инцидент хорошо показывает, почему парольная модель сама по себе слабая. Пользователи повторно используют пароли, сервисы по-разному их защищают, а утечки одной базы запускают атаки на множество других платформ. Поэтому будущее защиты учетных записей связано с уникальными паролями, MFA, passkeys, аппаратными ключами, аномальным анализом входов и отказом от устаревших способов хранения паролей.

Passkeys могут снизить риск таких утечек, потому что вместо общего секрета, который хранится и вводится пользователем, используется криптографическая пара ключей. Даже если база сервиса скомпрометирована, атакующий не получает пароль, который можно попробовать на других сайтах. Но переход на такие механизмы требует времени, поддержки со стороны сервисов и привычки пользователей. Пока пароли остаются массовым способом входа, утечки будут продолжать иметь тяжелые последствия.

Главный вывод состоит в том, что KDDI сообщила о взломе почтовой системы, которую использовали также STNet, JCOM, Chubu Telecommunications, Nifty и Biglobe. Атака была обнаружена 17 июня 2026 года, а проникновение, по данным расследования, произошло через уязвимость в неназванном стороннем программном обеспечении. Потенциально злоумышленники могли похитить 14,22 млн записей с email-адресами и паролями действующих, бывших и неактивных пользователей. Часть паролей была хеширована или зашифрована, но KDDI не раскрыла методы защиты и не уточнила, какая доля могла храниться открытым текстом. Пользователям затронутых провайдеров нужно немедленно сменить почтовые пароли, заменить такие же пароли в других сервисах, включить двухфакторную аутентификацию, проверить активные сессии, правила пересылки, способы восстановления аккаунта и быть готовыми к фишингу от имени провайдеров.

Добавить комментарий