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

Существуют различные методы развертывания программ-вымогателей, включая изменение групповых политик, использование PsExec или даже ручное копирование и запуск — на усмотрение киберпреступников.

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

$recycle.bin

config.msi

$windows.~bt

$windows.~ws

windows

appdata

application data

boot

google

mozilla

program files

program files (x86)

programdata

system volume information

tor browser

windows.old

intel

msocache

perflogs

x64dbg

public

all users

default

Интересно, что в списке есть папка tor browser. Дело в том, что у Darkside был портал для жертв в даркнете, доступ к которому возможен только через браузер Tor.

После развертывания программы-вымогателя злоумышленники готовы обсудить с жертвой сумму выкупа. Иногда требуют выкуп отдельно за дешифровку и отдельно — за удаление украденных данных.

Иногда атака на этом не заканчивается. Например, известно, что злоумышленники, связанные с группой REvil, проводят DDoS-атаки против жертв, которые отказываются платить.

Выводы

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

В следующей главе мы рассмотрим процесс реагирования на инциденты и шесть этапов реагирования на современные атаки с использованием программ-вымогателей.

Глава 3

Процесс реагирования на инциденты

Вы уже имеете неплохое представление о современных атаках с использованием программ-вымогателей, а значит, пора разобраться в процессе реагирования на инциденты. Анализ процессов может показаться немного скучным, но разбираться в них очень важно — это поможет вам более оперативно реагировать на инциденты.

Мы не будем останавливаться на вещах, о которых вы уже знаете. Вместо этого мы рассмотрим классический процесс реагирования на инциденты, разработанный Национальным институтом стандартов и технологий США (National Institute of Standards and Technology, NIST), в контексте атак с использованием программ-вымогателей — естественно, с использованием реальных примеров и опыта.

Этот процесс был представлен в «Руководстве по работе с инцидентами компьютерной безопасности» (Computer Security Incident Handling Guide9) Полом Цихонски, Томом Милларом, Тимом Грансом и Карен Скарфоне. До сих пор многие группы реагирования на инциденты по всему миру постоянно используют его в своей практике. Я не собираюсь пересказывать здесь эту статью — я поделюсь своим мнением и опытом, чтобы вы могли лучше понять ее, когда будете читать или перечитывать.

В этой главе мы рассмотрим все этапы процесса реагирования на инциденты и затронем следующие темы:

Подготовка к инцидентам.

Обнаружение и анализ угроз.

Сдерживание, устранение и восстановление.

Действия после инцидента.

Подготовка к инцидентам

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

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

Некоторые компании не задумываются о безопасности даже после успешной атаки с использованием программ-вымогателей. Яркий пример — австралийская транспортно-логистическая компания Toll Group. В феврале 2020 г. эта компания подверглась атаке со стороны операторов программы-вымогателя Netwalker. В мае Toll Group вернулась к нормальной работе, и ее тут же успешно атаковала другая группа — на этот раз связанная с программой-вымогателем Nefilim.

Как видите, мир программ-вымогателей очень агрессивен, поэтому подготовка команды и ИТ-инфраструктуры к угрозам крайне важна.

Команда

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

Кроме того, организация может воспользоваться услугами одной из сторонних команд управления защитой бизнеса (Managed Detection and Response, MDR), которые выполняют мониторинг и реагирование.

Конечно, если это необходимо, группу реагирования на инциденты можно создать внутри компании как часть службы безопасности или внутреннего операционного центра безопасности (Security Operations Center, SOC).

Прежде всего такая команда должна иметь возможность реагировать на инциденты. Вот что это значит:

Способность собирать данные. В ходе реагирования на инциденты очень важно иметь возможность собирать необходимые данные — от единичного артефакта запущенного процесса до полного журнала событий или файлов реестра. Вот почему мы всегда используем собственное расширенное решение для обнаружения и реагирования (Extended Detection and Response, XDR), Group-IB MXDR — и это лишь один пример из множества решений, представленных на рынке. Важно, чтобы выбранное решение позволяло следить за всей инфраструктурой, собирать данные с любого хоста и при необходимости выполнять проактивный поиск угроз. Правда, некоторые из этих задач можно решить развертыванием различных скриптов, но такой подход может быть менее эффективным и значительно увеличить время реагирования на инцидент.

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

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