Выкуп в $22 млн не помог Change Healthcare вернуть данные после атаки ALPHV/BlackCat, а совокупные расходы на восстановление оценивались в $1,6 млрд. Ransomware-группы всё чаще сначала лишают жертву возможности восстановиться, и защита резервных копий превращается из рутинной задачи администраторов в вопрос выживания бизнеса. Для российских IT-команд это означает простую проверку: сможет ли один скомпрометированный аккаунт удалить и продакшен, и все точки восстановления.
Как сообщает BleepingComputer, атакующие целенаправленно ищут серверы бэкапов, архивы и площадки аварийного восстановления. Их цель не в том, чтобы просто зашифровать данные: без доступной резервной копии у компании остаётся меньше аргументов не платить. Материал подготовлен при поддержке Kaseya, однако описанные приёмы хорошо известны по расследованиям крупных инцидентов и рекомендациям американских ведомств по кибербезопасности.
Сценарий с Change Healthcare стал показательной историей. В феврале 2024 года ALPHV/BlackCat проникла в инфраструктуру через портал удалённого доступа без многофакторной аутентификации. Восстановление оказалось затруднено: резервная инфраструктура не была достаточно изолирована и устойчиво подготовлена к быстрому возврату сервисов. Компания UnitedHealth заплатила выкуп, но это не обеспечило возврат данных. Главный урок здесь неприятен: наличие бэкапа на схеме архитектуры ещё не означает наличие работающего плана восстановления.
Две копии не помогут, если у них один ключ
Атаки на NEW Cooperative и Crystal Valley в 2021 году показали более прямой способ убрать путь к восстановлению. Группа BlackMatter, по данным совместного предупреждения CISA, ФБР и АНБ, использовала скомпрометированные административные учётные записи, находила подключённые хранилища и устройства резервного копирования, а затем очищала или переформатировала их. После этого шифровались остальные системы. Бэкапы находились в той же сети, что и рабочая инфраструктура, поэтому для злоумышленников были не запасным парашютом, а ещё одним сетевым ресурсом.
В августе 2026 года CISA и ФБР описали похожую тактику у Gunra. В одном подтверждённом случае группировка удалила резервные и архивные данные и в основном дата-центре организации, и на площадке disaster recovery. Причина особенно важна для компаний с несколькими площадками: обе среды были доступны по одним похищенным учётным данным. Географическое разнесение не создаёт независимости, когда доступ к двум контурам держится на одном наборе привилегий.
Отсюда меняется сама логика аудита. Вопрос «сколько у нас копий и где они лежат» недостаточен. Нужны ответы на более приземлённые вопросы: какие сети соединяют продакшен и хранилище, кто может менять политику хранения, какие сервисные аккаунты имеют доступ, попадают ли их логи в SIEM и можно ли с одной консоли удалить все recovery points. Если ответ на последний вопрос положительный, защита резервных копий построена вокруг доверия к одному рубежу — а ransomware как раз рассчитывает этот рубеж пройти.
Базовой мерой становится неизменяемое хранение: копия, которую нельзя изменить или удалить до окончания заданного срока, включая действия администратора. Объектные хранилища уже поддерживают механизмы object lock, но сама функция не исправит слабую архитектуру. Нужны отдельные сетевые сегменты, раздельные роли и учётные записи для бэкап-среды, MFA для её администрирования и минимум постоянных привилегий. Важно заранее продумать и «break glass»-доступ: аварийный аккаунт не должен одновременно оказаться удобной дверью для атакующего.
Бэкап без тестового восстановления — лишь надежда
Отдельная проблема — отношение к программному обеспечению резервного копирования как к бытовой технике: поставили, настроили, больше не трогаем. В материале упоминается атака Akira на авиакомпанию, где злоумышленники воспользовались уязвимостью с патчем, доступным больше года. Серверы бэкапов часто получают обновления позже критичных бизнес-систем, журналирование на них слабее, а реакции SOC медленнее. Это делает их особенно удобной тихой целью: атакующий может неделями готовить удаление копий, пока команда мониторит в основном продакшен.
Практический минимум для IT-директора и руководителя безопасности выглядит скучно, но работает: включить платформу резервного копирования в общий patch management, ограничить админские права по ролям, включить многофакторную аутентификацию, контролировать изменения политик хранения и регулярно проводить полноценные тесты восстановления. Проверять надо не только успешное завершение job в панели, но и время подъёма конкретных систем, доступность ключей, целостность данных и последовательность действий во время имитации атаки. Резервная копия, которую не удалось восстановить под нагрузкой, — не страховка, а отложенная авария.
Проблема упирается не только в технологии. В исследовании Kaseya, на которое ссылается материал, почти 77% опрошенных IT-организаций считают, что их инвестиции в кибербезопасность не успевают за угрозами; среди MSP о недостаточных вложениях клиентов говорят 65%. Поэтому защита резервных копий должна попадать в бюджет и список проверяемых бизнес-рисков наравне с защитой рабочих станций и внешнего периметра. При следующем ransomware-инциденте решающим окажется не число копий в отчёте, а то, сможет ли злоумышленник добраться до них раньше команды восстановления. Подробнее об исходном материале и упомянутом исследовании — .