Для кого это: для всех, кто отвечает за безопасность компании или собственного сайта. Это не разбор отдельного инцидента, а закономерность, которая проявляется при сопоставлении того, что японские организации раскрыли в августе 2026 года. Все факты взяты из этих раскрытий и из публикаций в СМИ; выводов о причинах нет.
Классификация по пути проникновения
На основе того, что опубликовала каждая организация; цифры и причины приведены только в том виде, в каком были раскрыты.
| Раскрыто | Организация | Откуда начиналось | Класс |
|---|---|---|---|
| 3 авг. | Kodansha | Корпоративный почтовый ящик — украдены контакты, а некоторым из них была отправлена почта от имени этого сотрудника | Учётные данные |
| 4 и 7 авг. | Innovation Co. | Учётные данные GitHub — компания раскрыла два сбоя: токены, жёстко заданные в конфигурации, и персональные данные, хранившиеся в репозиториях | Учётные данные |
| 13 авг. | Charm | Несанкционированный доступ к интернет-магазину (–230 000 записей, включая хэши паролей) | Прямой |
| 14 авг. | Nichirei | Программа-вымогатель (сбой системы 13 июля; данные сотрудников возможно раскрыты) | Прямой |
| 17 и 19 авг. | Sakura Internet | Среда управления провайдера, затем система управления договорами (в охвате до 1 360 563 учётных записей участников) | Учётные данные / провайдер |
| 20 авг. | Expo 2025 Association | Microsoft 365 субподрядчика, начиная с фишингового письма, полученного 13 мая | Учётные данные / поставщик |
| 20 авг. | VOISING | BI-инструмент (до ~170 000 человек) | Учётные данные / SaaS |
| Авг. | JST (по сообщениям) | Доступ к почтовому ящику (~16 000 сообщений) | Учётные данные |
| 12 авг. | OCS, ANA Group (по сообщениям) | Уязвимость в приложении | Прямой |
Как читать эти цифры
Приведённые цифры — на момент публикации, и большинство расследований продолжаются. В частности, 1 360 563 у Sakura Internet — это число записей участников, которые потенциально попадают в охват, а не подтверждённая утечка; компания заявляет, что вывод данных не подтверждён. Не считать окончательными цифры, по которым ещё идёт расследование, — базовый навык при чтении подобных публикаций.
Почему защиты собственных систем недостаточно
Начало: легитимная учётная запись вне вашего контроля
M365 поставщика / BI-инструмент / почтовый ящик / токен GitHub / консоль провайдера
Злоумышленник совершает обычные действия
входит обычным образом с украденными учётными данными и читает данные так же, как обычный пользователь
Ваш сервер (не затронут)
обновления, WAF и CSP на этот путь не распространяются
Эксплуатация уязвимости означает, что кто-то проник через ошибку, поэтому её устранение останавливает атаку. Украденные учётные данные означают, что кто-то вошёл штатно, поэтому исправлять здесь нечего. Защищать нужно сами учётные данные: кто ими владеет, где они хранятся и как долго остаются действительными.
Что здесь не работает
- Установка обновлений — не имеет отношения к атаке, которая ничего не эксплуатирует
- WAF / IPS — легитимный вход не выглядит аномальным
- «Мы слишком малы, чтобы нас атаковать» — целью был поставщик или провайдер, а вы пострадали как его клиент
- Смена модели хостинга — VPS не останавливает кражу учётных данных
Что работает
- Многофакторная аутентификация, особенно для почты, хостинга кода и административного доступа к SaaS
- Короткоживущие учётные данные с узкой областью действия — отзывайте долгоживущие токены
- Инвентаризация поставщиков и SaaS, которые могут обращаться к вашим данным
- Никаких секретов, жёстко заданных в конфигурации; никаких персональных данных в репозиториях
- Планирование исходя из того, что данные могли быть прочитаны — уменьшайте объём того, что можно украсть
Что делать
Составьте список внешних сервисов и субподрядчиков, от которых вы зависите
Хостинг, SaaS, BI-инструменты, почтовая платформа, хостинг кода — и субподрядчики. Без такого списка вы не сможете даже ответить на вопрос «попадаем ли мы в охват?», когда появляется новость. Как его составить: чек-лист инвентаризации активов.
Прежде всего включите многофакторную аутентификацию для почты и хостинга кода
Несколько отправных точек, перечисленных выше, были связаны с почтовыми ящиками и учётными данными хостинга кода. Это учётные записи, с помощью которых можно перевыпустить всё остальное, поэтому они стоят выше прочих. → выбор многофакторной аутентификации
Проведите инвентаризацию долгоживущих учётных данных и сократите их срок жизни и область действия
Секреты в конфигурационных файлах, токены доступа без срока действия, ключи, действующие во всех репозиториях. Исходите из возможности кражи и делайте так, чтобы то, что получит злоумышленник, было небольшим и краткосрочным. → чем опасны .env и ключи API / предотвращение утечки секретов при коммите
Заранее определите, что произойдёт, если ваш провайдер будет взломан
Когда придёт уведомление о компрометации вашего провайдера, что именно вы потеряете? Ответ на этот вопрос заранее определяет, что вы будете делать в тот день. → что делать, если взломан ваш веб-хостинг
Исходите из того, что за этим последует оппортунистический фишинг
За крупными инцидентами всегда следуют письма, выдающие себя за них. В одном из августовских случаев было раскрыто, что письма от имени сотрудника отправлялись украденным контактам. Не переходите по ссылкам из письма «уведомление об инциденте»; откройте официальный сайт самостоятельно. → что такое фишинг
Взгляд этого сайта: это не история о крупных компаниях
В таблице перечислены крупные организации, но места, где всё начиналось, не связаны с размером: почтовый ящик, административные права в SaaS, учётные данные, оставленные в репозитории. То же самое относится к одиночному разработчику, и, пожалуй, даже хуже, потому что небольшая структура сильнее зависит от внешних сервисов, а одна учётная запись, как правило, открывает доступ к большему. Наша позиция последовательна: прямо сейчас не выдавать учётные данные шире, чем нужно, и не оставлять действующими те, что не используются — это даёт больше, чем попытки сделать системы невзламываемыми. Установку обновлений продолжайте как базовую меру, а внимание переносите на учётные данные.
Источники
Факты взяты из раскрытий каждой организации и из публикаций в СМИ. Никаких выводов о причинах или ответственности сверх опубликованного.
- Sakura Internet — первое сообщение (17 авг.) / второе сообщение (19 авг., обновлено 26 авг.) / FAQ
- Expo 2025 Association — сообщение о несанкционированном доступе у субподрядчика (20 авг.)
- Kodansha — уведомление об утечке персональных данных (3 авг.)
- Charm — уведомление о несанкционированном доступе (13 авг.)
- Innovation Co. — итоговый отчёт по инциденту с GitHub (7 авг.)
- Публикация о Nichirei — @IT (15 авг.)
- Публикация о VOISING — ITmedia NEWS (21 авг.)
Читайте далее
- Недавние случаи, начавшиеся с учётной записи или входа поставщика: Navigate360 P3 (платформа для советов Crime Stoppers) / ASOS (Великобритания, данные клиентов)
- Случай на сайте вакансий, когда облачный ключ подрядчика был использован злоумышленниками: MyBRANDS
- Все инциденты 2026 года (Япония и мир): список утечек и кибератак и то, чем отличается путь проникновения
- Сравнение крупных случаев 2026 года: что общего у KDDI, Aflac, Цифрового агентства и Sakura Internet
- Когда VPN становится путём проникновения: VPN-устройства — основной путь проникновения программ-вымогателей: защита удалённого доступа после взлома Цифрового агентства
- Подготовка: чек-лист инвентаризации активов / выбор многофакторной аутентификации
- Когда взломан провайдер: что делать, если взломан ваш веб-хостинг
- Когда украдены облачные учётные данные для разработки: несанкционированный доступ к Nikkei (около 1,83 млн записей)
- Когда получены облачные учётные данные для эксплуатации: несанкционированный доступ к облачным сервисам Digital Arts
- Кража учётных данных: когда одна установка npm крадёт ваши учётные данные / чем опасны .env и ключи API
- Проектирование: ошибки в дизайне сброса пароля — когда собственный процесс сброса сервиса выдаёт учётные данные злоумышленнику
- Случай: программа-вымогатель KADOKAWA (2024) — учётные данные, украденные фишингом, как точка входа