Шифровальщики. Как реагировать на атаки с использованием программ-вымогателей

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

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

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

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

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

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

Теперь давайте ознакомимся со спецификой подготовки инфраструктуры.

Инфраструктура

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

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

Как это работает на практике? Допустим, вы обнаружили следы запуска Cobalt Strike Beacon на хосте с помощью команды jump psexec_psh — такое случается сплошь и рядом, и чаще всего при этом записывается событие создания новой службы с идентификатором 7045 в системном журнале. В первую очередь нас обычно интересует источник запуска — и найти его не очень сложно, например, по входу в систему, то есть событию с ID 4624 в журнале безопасности. Сложности начинаются, когда вы обнаруживаете, что служба была создана две недели назад, а в вашем журнале безопасности есть записи только за последние три дня.

Другой пример — межсетевой экран (брандмауэр). Брандмауэры и правда не останавливают драконов10, но все же они могут быть очень полезны для реагирования на инциденты — конечно, если у вас сохранились журналы за нужный период.

В моей практике был случай, когда мы определили все хосты, использовавшиеся для первоначального доступа, за один час. Чтобы получить первоначальный доступ, злоумышленники использовали целевые фишинговые электронные письма с вредоносными вложениями, но на этот раз они атаковали не один хост, а четыре. Нам удалось быстро найти один из них, поскольку он использовался для развертывания программы-вымогателя, — мы обнаружили, что хост был скомпрометирован четыре месяца назад. Наш клиент хорошо вел журналы, поэтому мы смогли заглянуть на четыре месяца назад и по коммуникациям с сервером управления и контроля идентифицировать еще три хоста. Если бы не журналы, поиск мог бы занять гораздо больше времени, а злоумышленники успели бы изменить тактики, техники и процедуры (tactics, techniques, and procedures, ТТРs) и внедрить новые бэкдоры.