Мы рассматриваем реальный публичный инцидент не как перепечатку новости, а через вопрос «как защититься от этого?». Это разбор, основанный на публичных материалах (официальном отчете экспертной комиссии и публикациях в прессе). Источники приведены в конце. Мы не включаем инструкции по атаке и персональные данные. Названия поставщиков и подрядчиков не важны, поэтому мы описываем их по роли, а не называем по имени.
- Объект атаки
- Больница Tsurugi Handa (префектура Токусима). Больничные системы, включая EMR
- Обнаружение
- Рано утром 31 октября 2021 года (записки с требованием выкупа напечатаны на принтерах; EMR и системы выставления счетов не работали)
- Точка входа (по отчету)
- VPN-устройство, доступное из интернета, не обновлено против CVE-2018-13379, а утекшие учетные данные не были отозваны
- Почему атака распространилась и восстановление не удалось (по отчету)
- Короткие пароли, отсутствие блокировки учетной записи, права администратора у пользователей → легкое боковое перемещение. Основная система и резервная копия в одной сети, обе зашифрованы. Убеждение, что «закрытая сеть безопасна»
- Последствия
- EMR не работала, оказание помощи серьезно нарушено; записи около 85 000 пациентов стали недоступны. Обычная работа возобновилась примерно через два месяца
- Основные меры
- Отслеживание известных CVE на устройствах, доступных из интернета, и быстрое обновление / отзыв утекших и повторно используемых учетных данных, многофакторная аутентификация, минимальные привилегии, блокировка учетной записи / 3-2-1 и офлайн-копии с защитой от изменения / сегментация / медицинский BCP
Что произошло (простыми словами)
Программа-вымогатель шифрует системы, чтобы сделать их непригодными, и требует оплату за их восстановление. Путь проникновения здесь не был сложной уязвимостью нулевого дня. На VPN-устройстве, которое больница открыла в интернет, была уязвимость, публичная с 2019 года (CVE-2018-13379), и ее так и не закрыли. Хуже того, эта уязвимость ранее позволила утечь учетным данным, а устройство больницы попало в список утекших. Публичная уязвимость, долго остававшаяся незакрытой, плюс утекшие учетные данные, которые не были отозваны, облегчили атакующему проникновение.
Оказавшись внутри, атака распространилась, и в отчете объясняется почему: короткие пароли, отсутствие блокировки входа и права администратора у пользователей. Как только был скомпрометирован один компьютер, атака могла распространиться по всей больнице с административными правами. Самое тяжелое: основная система и ее резервная копия находились в одной сети, и обе были зашифрованы. Резервная копия, которая должна была существовать, была зашифрована вместе с рабочей системой и не могла использоваться для восстановления. EMR оставалась недоступной, а обычная работа возобновилась только примерно через два месяца.
«Наличие резервной копии» и «возможность восстановиться» — не одно и то же
Сам факт существования резервной копии не гарантирует восстановления. Если она находится в той же сети и с теми же привилегиями, что и рабочая система, программа-вымогатель шифрует рабочую систему и копию вместе (именно так больница Handa потеряла обе). Работает резервная копия, которая изолирована от рабочей системы, хранится офлайн или вне площадки, имеет версии, желательно защищена от изменения, и восстановление из которой вы действительно отрабатывали. Практическое правило: 3-2-1 плюс офлайн-копия.
Каждый этап атаки и как его остановить
Это тоже цепочка, в которой на каждом этапе есть точка остановки. Читайте ее не как шаги атаки, а как места, где можно было бы ее прервать.
① VPN, доступный из интернета, не обновлен против CVE-2018-13379 + утекшие учетные данные → вход
Уязвимость 2019 года оставалась открытой, а утекшие учетные данные не были отозваны.
⊘ Стоп: отслеживать CVE на устройствах, доступных из интернета; быстро обновлять; отзывать утекшие учетные данные; MFA
② Короткие пароли, нет блокировки, права администратора у пользователей → распространение по больнице
С одного скомпрометированного компьютера права администратора позволили широко распространиться по больнице.
⊘ Стоп: надежная аутентификация; блокировка учетной записи; минимальные привилегии; сегментация; мониторинг входов
③ Основная система и резервная копия в одной сети → обе зашифрованы
Резервная копия не была изолирована от рабочей системы, поэтому тоже была зашифрована.
⊘ Стоп: офлайн- и внешние копии с версиями и защитой от изменения (3-2-1)
④ EMR долго не работает → серьезное нарушение оказания помощи
Восстановление заняло около двух месяцев и серьезно затронуло региональное медицинское обслуживание.
⊘ Стоп: отработанное восстановление; медицинский BCP (бумажный резерв); быстрое реагирование на инцидент и раскрытие информации
Хронология по публикациям
31 октября 2021
Рано утром на принтерах напечатались записки с требованием выкупа; EMR и системы выставления счетов перестали работать. В тот же день состоялась пресс-конференция.ноябрь 2021
Оказание помощи продолжалось на бумаге. Начались расследование и работы по восстановлению; сообщалось, что восстановление данных возможно.декабрь 2021
Подтверждено восстановление данных EMR; работы по восстановлению велись поэтапно.4 января 2022
Системы вернули в работу, и обычная работа возобновилась примерно через два месяца после заражения.июнь 2022
Экспертная комиссия опубликовала отчет о расследовании, в котором указаны путь проникновения (незакрытая уязвимость VPN), устройство резервного копирования и убеждение, что «закрытая сеть безопасна».
Первопричина: не только точка входа, но и отсутствие базовых мер
Считать, что «VPN больницы подвергся атаке», и на этом остановиться, значит упустить главное. Использовалась известная, публичная уязвимость, а не новая и сложная атака. Проникновение, распространение и неудачное восстановление были связаны с пренебрежением базовыми мерами: обновлениями, учетными данными и изоляцией резервных копий. В отчете жестко критикуется продажа и эксплуатация крайне уязвимой системы без регулярных обновлений (поставщика мы не называем). Но важен и долгосрочный вывод: даже если вы передаете эксплуатацию на аутсорсинг, риск остается за вами.
Слабости, выявленные в отчете (на тот момент)
- VPN, доступный из интернета, не обновлен против CVE-2018-13379
- Учетные данные устройства утекли и не были отозваны
- Короткие пароли, нет блокировки, права администратора у пользователей
- Основная система и резервная копия в одной сети, обе зашифрованы
- Убеждение, что «закрытая сеть безопасна»; недостаточные ИТ-ресурсы
Защищенная конфигурация (профилактика)
- Отслеживать CVE на устройствах, доступных из интернета, и быстро обновлять; MFA
- Отзывать утекшие и повторно используемые учетные данные; минимальные привилегии; блокировка учетной записи
- Резервные копии изолированы от рабочей системы: офлайн или вне площадки, с версиями и защитой от изменения
- Сегментировать сеть по важности (сегментировать даже закрытую сеть)
- Отработанное восстановление и медицинский BCP (бумажный резерв)
Даже если работы переданы на аутсорсинг, риск остается у вашей организации
Даже если поставщик создает и обслуживает ваши системы, именно ваша организация несет простой, нарушение оказания помощи и отвечает за это. Поэтому не перекладывайте все на поставщика: проверьте, в договоре и на практике, «кто, когда и как устанавливает обновления для CVE на устройствах, доступных из интернета», «изолирована ли резервная копия от рабочей системы» и «когда мы в последний раз отрабатывали восстановление». (Связанные материалы: инцидент в больнице Осаки, где точкой входа стал VPN для обслуживания подрядчика, и инцидент с Capcom, где точкой входа стало старое VPN-устройство.)
Как не допустить повтора в вашей среде
Это применимо далеко за пределами больниц, ко всем организациям с устройствами, доступными из интернета, и резервными копиями. По порядку приоритета:
Отслеживайте известные CVE на устройствах, доступных из интернета, и быстро устанавливайте обновления
Отслеживайте известные уязвимости (CVE) в доступном из интернета оборудовании: VPN, межсетевых экранах. Применяйте исправления сразу после публикации. Выстройте регулярный процесс устранения CVE, чтобы ситуация «известная публичная CVE осталась незакрытой» исключалась на уровне процессов.
Отзывайте утекшие и повторно используемые учетные данные; переходите к минимальным привилегиям
Отзывайте утекшие учетные данные, прекратите их повторное использование и применяйте MFA там, где это возможно. Добавьте блокировку учетной записи и мониторинг входов, а права администратора не выдавайте без необходимости (минимальные привилегии).
Изолируйте резервные копии от рабочей системы и храните их офлайн (3-2-1)
Размещайте резервные копии в отдельной сети с отдельными привилегиями, храните их офлайн или вне площадки, с версиями и защитой от изменения, и регулярно отрабатывайте восстановление из них. Это главная защита от ситуации «резервная копия зашифрована вместе с рабочей системой».
Сегментируйте сеть и разработайте медицинский BCP
Сегментируйте сеть по важности (базовый уровень безопасности организации) и подготовьте BCP (процедуры работы на бумаге), чтобы продолжать оказывать помощь пациентам, если ключевые системы долго недоступны. Больнице Handa засчитали быстрое задействование BCP и открытое раскрытие информации; именно подготовка сделала возможным быстрое реагирование.
Где это пересекается с принципами дизайна этого сайта
Главный вывод в том, что ущерб определили пренебрежение базовыми мерами, а не сложная атака: устанавливать обновления для известных CVE, правильно управлять учетными данными и изолировать резервные копии. Ничего из этого не ново и не сложно. Это противоположность принципам самого этого сайта: быстро устранять известные уязвимости, не использовать учетные данные повторно и поддерживать восстанавливаемую конфигурацию. В частности, «у нас есть резервная копия, но она лежит там же, где и рабочая система» несет ту же опасность, что и один API-ключ, открывающий все наборы данных. Обновляйте устройства, доступные из интернета, строго управляйте учетными данными, изолируйте резервные копии и отрабатывайте восстановление. Эти защиты может внедрить любая организация, независимо от размера и сферы.
Источники (публичные материалы)
Факты здесь основаны на публичной информации, указанной ниже. Мы не включаем инструкции по атаке, персональные данные и названия поставщиков или подрядчиков, а только выводы для защиты.
- Больница Tsurugi Handa — «Отчет экспертной комиссии по расследованию инцидента заражения компьютерным вирусом» (опубликован в 2022 году) — handa-hospital.jp
- Публикации и анализ (проникновение через незакрытую уязвимость VPN CVE-2018-13379, резервная копия в той же сети, убеждение «закрытая сеть безопасна» и восстановление, 2021–2022) — на основе официального отчета комиссии
Читайте далее
- Больницы в 2026 году: нарушение оказания помощи из-за кибератак (США, Бельгия, Япония) и процедуры работы в условиях простоя
- Когда точка входа — VPN: VPN-устройства — самый частый путь проникновения; защита удаленного доступа после взлома Цифрового агентства
- Глоссарий: что такое программа-вымогатель (как она работает и как не платить) / что такое CVE (управление известными уязвимостями)
- Практика: основы резервного копирования (правило 3-2-1) / руководство по устранению CVE / базовый уровень безопасности организации
- Случаи: программа-вымогатель в больнице Осаки (2022) (VPN подрядчика и медицинский BCP) / программа-вымогатель в Capcom (2020) (точкой входа стало старое VPN-устройство) / программа-вымогатель в KADOKAWA (2024) (слабая сегментация позволила распространиться по всей компании)