BIS Journal №4(59)2025

25 ноября, 2025

Сеть поражена шифровальщиком. Что делать?

Какие три ошибки часто допускают и почему не спасают обычные планы восстановления? Какие первые десять шагов предпринять? Кто может помочь? Какие элементарные меры подготовки позволят сохранить миллионы рублей и нервных клеток? Попробуем ответить.

Ошибка№1: относиться к шифрованию как к обычному ИT-инциденту. При шифровании ИT-инфраструктуры главная цель компании — как можно скорее вернуться к нормальной работе. Однако в большинстве случаев вирусы-шифровальщики являются полностью человекоуправляемыми: если компания восстановит данные из сохранившихся резервных копий, злоумышленник может снова всё удалить или зашифровать. Это не ИТ-сбой, а целенаправленное вредительское воздействие на любые элементы инфраструктуры, на сотрудников компании, причём в любое время дня и ночи и с учётом ваших ответных действий. Бессмысленно восстанавливать данные, если сперва не выдворить злоумышленника, не выявить и не пресечь все способы его доступа в вашу инфраструктуру.

Ошибка №2: считать шифровальщик проблемой только ИT-службы или отдела ИБ. Кризисная ситуация может привести к краху бизнеса и требует управления руководителем компании, а также участия всех её подразделений. Если смоделировать ситуацию реагирования на киберинцидент с самыми печальными последствиями, то станет очевидно, что потребуется слаженная работа руководства компании, ИТ, ИБ, PR, HR, юриста, ответственных за закупки и даже хозяйственного отдела.

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

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

Рекомендуем рассмотреть при реагировании на киберинцидент следующее:

1. Заблокировать доступ к ДБО в банках и проверить последние операции: стоит иметь распечатки с номерами телефонов сотрудников банка и данными для аутентификации.

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

3. Изолировать ценное: отключить от сети серверы с резервными копиями и важными данными. Выгрузить списки паролей и записи DNS-сервера на съёмный носитель и на бумагу: без адресов серверов и паролей будет сложно их исследовать или восстанавливать. Не подключать накопители с важной информацией, включая резервные копии, к потенциально скомпрометированным системам до момента устранения угрозы данным — вредоносного ПО, которое может повредить данные на резервных носителях. 

4. Рассмотреть отключение от интернета всей или части вашей сети, для чего полезно заранее настроить, но не активировать правила на межсетевых экранах или сетевом оборудовании, изучить настройки в личном кабинете интернет-провайдера.

5. Определить цели компании при реагировании на киберинцидент: действительно будем стремиться найти злоумышленника и довести дело до суда, не боясь огласки? Или наоборот, будем стараться не допустить «хайпа»? Достижение каждой цели требует своих затрат, и затраты растут, если цели друг другу противоречат.

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

7. Проинформировать надзорные органы об инциденте, рассмотреть информирование клиентов и партнёров. Инфраструктура компании может быть использована для атаки на партнёров: через учётные записи от систем, сетевой доступ посредством VPN, с помощью фишинговых писем от лица ваших работников. Целесообразно определить одно ответственное за внешние коммуникации лицо и место ведения коммуникаций — социальные сети могут быть неплохим вариантом. Хорошо, если у компании есть заранее согласованные с PR и юридической службой черновики заявлений для клиентов и СМИ на случай недоступности сервисов, утечки информации, взлома сайта и размещения на нём противоправной информации. 

8. Вести все коммуникации вне поражённой инфраструктуры, а во внутренней сети, почте и мессенджерах соблюдать «режим тишины» во избежание прочтения злоумышленниками вашей переписки, её публикации, создания помех в восстановлении. Стоит завершить все авторизованные в атакованной инфраструктуре сессии мессенджеров и использовать для связи нескомпрометированные персональные мобильные устройства. 

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

10. Провести реагирование на инцидент (DFIR, Digital Forensic and Incident Response/цифровая криминалистика и реагирование на инциденты), а при отсутствии нужных компетенций — обратиться в компании, занимающиеся реагированием на повседневной основе. Это большая работа — найти и пресечь все способы доступа злоумышленников в инфраструктуру компании, найти и отключить их вредоносные инструменты. Стоит подумать о режиме работы персонала, задействованного в ликвидации инцидента, о компенсации сверхурочной работы. Отмена отпусков, командировок, увольнений вполне оправдана в такой ситуации. 

В проведении DFIR может помочь киберкриминалистическая лаборатория. Для субъектов КИИ такая лаборатория должна обладать статусом аккредитованного центра ГосСОПКА. DFIR может проводиться с выездом в офис компании экспертов, к приезду которых необходимо приготовить пропуска и парковку, рабочие места (стол/стул/свет/электропитание/кофемашина), чат вне поражённой инфраструктуры с необходимыми участниками реагирования на инцидент, синхронный режим работы сотрудников ИТ/ИБ. Два эксперта DFIR часто организуют работу 24/7: восемь часов эксперт работает один, восемь — вдвоём с напарником, восемь на отдых. Обеспечьте аналогичный режим работы, если хотите максимума эффективности. После установочной встречи эксперты проведут анализ сети и скомпрометированных узлов, носителей информации (включая съём копий для анализа), поиск точек входа злоумышленников и всех поражённых узлов, закладок и средств удалённого доступа, подготовят отчёт для представления в правоохранительные органы.

DFIR можно провести и онлайн, если ваш персонал умеет и может собирать журналы событий, улики и т. д. Эксперты изучат направленные вами данные и запросят недостающее. Онлайн DFIR может быть дешевле по ставкам экспертов, но без слаженной, быстрой и экспертной работы на стороне пострадавшей компании онлайн DFIR может продлиться дольше и оказаться даже дороже, чем с выездом.

 

Что можно сделать заранее? От простого к сложному

Чтобы сократить простой в работе и ущерб, стоит проработать план реагирования в случае успешной кибератаки и создать резерв оборудования для восстановления, а также финансов для оплаты непредвиденных расходов (например, для аренды IaaS для временного размещения части систем и процессов). Уделить особое внимание безопасности бэкапов: как данных, так и самого ПО, лицензионных ключей, паролей, файлов конфигураций. При резервировании использовать схему «3-2-1». Защитить саму систему резервного копирования, чтобы было чем восстановить бэкапы: сложно говорить о безопасности системы последней надежды, управляемой службой каталогов или администрируемой с компьютера, включённого в домен. Выбрать DFIR-партнёров и заключить с ними NDA и рамочный договор или приобрести подписку на услуги. Провести учения по реагированию на инцидент и измерить время восстановления. В случае подозрений на взлом — выполнять поиск признаков компрометации с участием киберкриминалистических лабораторий.

Лучше убедиться заранее, что журналы событий безопасности АС ведутся и не могут быть удалены (стоит проверить их состав, место и глубину хранения); диски серверов и ПК — в доступности (вы можете найти компьютер и диск в нём, взять его в руки, снять установленную вами защиту); артефакты (файлы, логические образы дисков и т. д.) могут быть собраны вами удалённо (проверьте сетевую доступность, наличие прав доступа и выгрузку паролей).

Полезно продумать идентификацию инцидента: лучше всего о подготовке к атаке узнать заранее с помощью Threat Intelligence. О начале атаки на периметр может проинформировать SOC или SIEM. Возможно, первые атаки на узлы выявит и остановит MDR, дав время предотвратить серьёзные последствия. В отсутствие средств раннего обнаружения и противодействия атакам обратите внимание на массовое отключение или изменение настроек СЗИ, включая антивирусные решения. Это лучше, чем не знать о злоумышленнике в сети до момента кражи им всей возможной информации, удаления резервных копий и запуска вируса-шифровальщика.

Больше информации можно найти в «Рекомендациях при инциденте ИБ: взлом ИT-инфраструктуры с шифрованием или удалением данных», составленных Константином Титковым (руководитель Центра ИБ дочерних и зависимых обществ, Газпромбанк; амбассадор Кибердома) в соавторстве с Сергеем Головановым (главный эксперт, АО «Лаборатория Касперского») и Ильёй Зуевым (вице-президент по ИБ, МТС Банк). Рекомендации разрешены к распространению по лицензии BSD (с обязательным указанием названия, версии, автора и соавторов)и регулярно дополняются с учётом опыта профессионального сообщества. Актуальная версия доступна, например, здесь.

В завершение для минимизации потерь при инциденте с шифрованием ИT-инфраструктуры и кражей данных рекомендуем владельцу / генеральному директору компании:

  1. Довести указанные выше рекомендации до ИT-и ИБ-подразделений.
  2. Проверить, что все всё могут и у всех всё есть, подготовительные шаги выполнены и никто не стесняется сказать, что что-то не умеет или не может.
  3. Оценить время простоя при киберинциденте с самыми печальными последствиями. Попросите сотрудников рассказать вам про план восстановления при недоступности всего, что было включено ночью и, следовательно, могло быть за ночь полностью уничтожено или зашифровано.
  4. При киберинциденте привлечь все ресурсы и подразделения, подрядчиков, создать оперативный штаб и возглавить работу по восстановлению.
  5. Поддерживать работников в ходе ликвидации последствий инцидента, а не наказывать.
  6. Помнить, что демотивированный сотрудник не заинтересован в реагировании на инцидент, а сотрудник, который допустил (по своей вине или нет), но исправил ситуацию, лучше и ценнее нового!
Стать автором BIS Journal

Смотрите также

Подписаться на новости BIS Journal / Медиа группы Авангард

Подписаться
Введите ваш E-mail

Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных

24.11.2025
Интернет-шатдауны и антифрод-меры подталкивают россиян к исходу в кеш
24.11.2025
Субъекты КИИ будут отвечать на запросы ФСБ в течение суток
24.11.2025
«Чёрная пятница» в новом прочтении? Маркетплейсам могут ограничить банковскую активность
24.11.2025
Действие CISA 2015 продлили, чтобы компании не боялись обмениваться данными
24.11.2025
Entrust: Генеративный ИИ и дипфейки интенсифицируют фрод
21.11.2025
Подтверждена совместимость РОСА Хром 12 с программным комплексом MFASOFT Secure Authentication Server
21.11.2025
«При внедрении важно определиться с целеполаганием»
21.11.2025
Банк России взялся за средние звенья цепи
21.11.2025
Мессенджер Max нашёл себе друга по импортозамещению
21.11.2025
В Ташкенте состоялся FINNEXT Asia 2025

Стать автором BIS Journal

Поля, обозначенные звездочкой, обязательные для заполнения!

Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных