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

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

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

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

Этот процесс был представлен в «Руководстве по работе с инцидентами компьютерной безопасности» (Computer Security Incident Handling Guide[9]9
  https://www.altx-soft.ru/upload/iblock/124/NIST%20800–61%20Руководство%20по%20обработке%20инцидентов%20ИБ. pdf


[Закрыть]) Полом Цихонски, Томом Милларом, Тимом Грансом и Карен Скарфоне. До сих пор многие группы реагирования на инциденты по всему миру постоянно используют его в своей практике. Я не собираюсь пересказывать здесь эту статью – я поделюсь своим мнением и опытом, чтобы вы могли лучше понять ее, когда будете читать или перечитывать.

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

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

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

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

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

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

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

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

Некоторые компании не задумываются о безопасности даже после успешной атаки с использованием программ-вымогателей. Яркий пример – австралийская транспортно-логистическая компания 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 могут сэкономить вам много времени, но, если они недоступны, вам придется использовать различные инструменты цифровой криминалистики, как коммерческие, так и находящиеся в открытом доступе. Такие инструменты повышают скорость обработки, но, к сожалению, они не могут ускорить анализ – ведь анализ атак с использованием программ-вымогателей, как и сами эти атаки, всегда выполняется человеком. Еще один важный момент – необходим доступ к хорошим источникам информации о киберугрозах: он ускорит анализ и поможет лучше понять, что именно вы ищете. Наконец, требуется обучение. Его можно проводить в разных формах: под руководством инструктора, по заранее записанному видео, с помощью вебинаров – полезно даже просто почитать хороший отчет или книгу об угрозах (например, эту книгу).

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

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

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

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

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

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

Другой пример – межсетевой экран (брандмауэр). Брандмауэры и правда не останавливают драконов[10]10
  Отсылка к книге и сайту Кэри Паркера «Брандмауэры не останавливают драконов» (Firewalls Don't Stop Dragons). – Прим. науч. ред.


[Закрыть], но все же они могут быть очень полезны для реагирования на инциденты – конечно, если у вас сохранились журналы за нужный период.

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

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

Еще один важный аспект, связанный с инфраструктурой, – технические средства обеспечения безопасности. Я уже упоминал XDR. Вы можете спросить – почему именно XDR, ведь на рынке много разных решений? Дело в том, что XDR можно использовать для мониторинга, поиска угроз, сбора криминалистических данных и, что еще более важно, для блокировки вредоносных файлов и изоляции скомпрометированных хостов. Конечно, средства Security Information and Event Management (SIEM) тоже могут обеспечивать мониторинг, оповещение и поиск угроз, но они не могут блокировать вредоносные файлы и изолировать хосты, а это играет решающую роль, когда речь идет об атаках с использованием программ-вымогателей. Зато SIEM могут очень долго хранить журналы, поэтому, если вы имеете дело с долгосрочным инцидентом, правильная настройка SIEM может сыграть решающую роль.

Конечно, речь идет не только о XDR: это просто самый современный и эффективный инструмент предотвращения инцидентов и реагирования на них. Чем больше у вас инструментов, тем проще справляться с инцидентами.

Теперь рассмотрим этапы обнаружения и анализа угроз.

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

Это два наиболее важных этапа процесса реагирования на инциденты. Почему? Если обнаружение и анализ не увенчались успехом, то, скорее всего, ваша инфраструктура или инфраструктура вашего клиента будут зашифрованы той или иной программой-вымогателем.

Возможны два сценария:

● все уже зашифровано – то есть произошла атака, которую нужно реконструировать;

● в сети появился предвестник программы-вымогателя, который нужно как можно скорее локализовать и устранить.

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

Рис. 3.1. Портал программы-вымогателя BlackMatter

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

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

Какую-то информацию вы можете получить из различных общедоступных источников, мы подробно поговорим об этом в главе 6 «Сбор данных о киберугрозах, связанных с программами-вымогателями».

Также может быть весьма полезно иметь доступ к коммерческим платформам анализа киберугроз.

Рис. 3.2. Профиль BlackMatter на платформе Group-IB Threat Intelligence

Почему это удобно? Такие платформы содержат много информации о программах-вымогателях на всех уровнях – стратегическом, оперативном и тактическом. Там вы найдете информацию о TTP программ-вымогателей, включая используемые ими инструменты, уязвимости и т. д. Кроме того, вы увидите множество различных индикаторов компрометации, таких как хеши, имена файлов и IP-адреса. Наконец, обычно там есть информация о целевых странах и отраслях. Мы обсудим эту тему более подробно в главе 4 «Киберразведка и программы-вымогатели».

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

Давайте рассмотрим один из примеров, которые мы уже обсуждали в предыдущих главах, – программу-вымогатель Ryuk.

Если атака произошла и файлы уже зашифрованы, нужно найти источник развертывания программы-вымогателя и используемый метод. Ryuk зачастую развертывается с контроллера домена. Допустим, вам посчастливилось найти, с какого именно, но есть проблема: из-за недостатка записей в журнале вы не видите источник подключения к этому серверу.

Тогда вы анализируете имеющиеся у вас сведения о киберугрозах и обнаруживаете, что связанные с Ryuk преступники обычно используют такие инструменты, как Cobalt Strike, AdFind и Bloodhound, и получают первоначальный доступ к сетям с помощью целевых фишинговых электронных писем, доставляя Trickbot или BazarLoader.

Теперь вы знаете, что искать, – у операторов программ-вымогателей чрезвычайно популярны различные фреймворки постэксплуатации, такие как Cobalt Strike, а они, к счастью, оставляют множество следов, которые можно найти в процессе реагирования на инциденты. Больше об источниках криминалистических артефактов вы узнаете из главы 7 «Цифровые криминалистические артефакты и их основные источники».

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

Рассмотрим ситуацию, когда атака еще не произошла – программа-вымогатель пока не развернута, но замечены некоторые предвестники взлома. Какими они бывают?

Мы уже знаем, что для получения первоначального доступа к сети злоумышленники обычно используют Trickbot или BazarLoader. Это значит, что мы должны реагировать на любые события, связанные с подобными угрозами, например на предупреждения от антивирусного программного обеспечения. Антивирусы могут быть полезны, даже если атака уже состоялась, поскольку злоумышленники используют различные инструменты и некоторые из них не могут остаться незамеченными. Поэтому подобные предупреждения могут подсказывать, где побывали злоумышленники во время постэксплуатации.

Кроме того, очень важно изолировать рабочую станцию (если это осуществимо и не повлияет на бизнес-процессы) и проверить, нет ли других необнаруженных артефактов. Если вы успешно обнаружили и удалили штамм BazarLoader, в памяти вполне мог остаться Cobalt Strike Beacon, а субъекты угрозы уже могли переместиться дальше по сети.

То же самое можно сказать и об уликах, указывающих на разведку сети или Active Directory. Если вы обнаружите такую активность, как, например, использование AdFind, очень важно понять, легитимна ли она, и отреагировать.

Это, конечно, не весь список примеров – мы обсудим их более подробно в главе 5 «Тактики, техники и процедуры групп, занимающихся распространением программ-вымогателей».

А теперь давайте перейдем к сдерживанию, устранению и восстановлению.

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

Как только вы разберетесь, с какой атакой имеете дело, пора применить меры сдерживания.

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

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

Многие операторы программ-вымогателей используют легальные приложения для удаленного доступа, например следующие:

● TeamViewer

● AnyDesk

● SupRemo

● Remote Utilities

● Atera RMM

● Splashtop

● ScreenConnect

Это значит, что, как только вы обнаружили инцидент, такое программное обеспечение лучше заблокировать.

Как вы уже знаете, большинство злоумышленников занимаются кражей данных. Поэтому, если вы увидели следы деятельности предвестников программ-вымогателей и подозреваете, что злоумышленники все еще находятся в сети, лучше заблокировать доступ к популярным облачным файлообменникам, таким как MEGA, DropMeFiles, MediaFire и пр.

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

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

Если вы изолировали злоумышленников от взломанной сети и следов последующей вредоносной активности не появляется, можно приступить к удалению вредоносных программ и инструментов, используемых злоумышленниками.

С удалением скриптов и сервисов, не требующих установки, все понятно.

Инструменты удаленного доступа, такие как TeamViewer, имеют удобные деинсталляторы, поэтому удалить их со скомпрометированных хостов будет несложно.

С вредоносными программами несколько сложнее. Например, они могут быть бесфайловыми, то есть находиться только в памяти, не оставляя экземпляра на диске. Если вредоносное ПО закрепилось в скомпрометированной системе, что происходит довольно часто, то оно остается в памяти и после перезагрузки.

Назовем некоторые широко распространенные механизмы закрепления, используемые вредоносными ПО, которые используются в атаках с использованием программ-вымогателей.

● Ключи запуска реестра или папки автозагрузки.

● Службы Windows.

● Запланированные задания.

Можно обойтись без удаления механизма устойчивости, если вы уже удалили вредоносное ПО, но иногда это может привести к ложному обнаружению угрозы. Однажды мой клиент обнаружил вредоносную службу, связанную с Cobalt Strike, – моя команда моментально отреагировала, но вскоре выяснилось, что это всего лишь пережиток прошлой атаки, с которой команда клиента боролась несколько лет назад.

Итак, вы заблокировали командные серверы, изменили пароли для взломанных учетных записей, удалили вредоносное ПО и инструменты злоумышленников. Достаточно ли этого? Готовы ли вы снова запустить эту рабочую станцию или сервер? Если вы на сто процентов уверены, что все чисто, – почему бы и нет? Если нет – возможно, лучше заново развернуть систему из образа.

Возможна и другая ситуация – сеть уже зашифрована. Обычно в этом случае остается два варианта: вести переговоры с кибершантажистами и платить выкуп или восстанавливать инфраструктуру с нуля.

В первом случае дешифраторы, предоставляемые злоумышленниками, могут создать дополнительные проблемы. Вот еще один пример: операторы программы-вымогателя ProLock активно действовали с апреля по июнь 2020 г., и некоторые жертвы согласились заплатить выкуп и получили дешифратор. Но возникла проблема – дешифратор не работал должным образом, некоторые файлы размером более 64 Мбайт повреждались в процессе расшифровки. Как только это стало известно, репутация злоумышленников пошатнулась, и очень скоро ProLock исчез.

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

Поэтому после успешной атаки – и особенно если организация решила заплатить – крайне важно улучшить состояние безопасности, чтобы вооружиться против будущих кибератак. Этому посвящен последний этап – действия после инцидента.

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

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

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

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

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

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

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

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

Это не весь список действий после инцидента, а лишь несколько примеров, чтобы помочь вам понять, что обычно делается на этом этапе.

Надеюсь, теперь вы лучше понимаете, как в целом выглядит типичный процесс реагирования на инциденты. Дополнительные сведения можно найти в «Руководстве по работе с инцидентами компьютерной безопасности», подготовленном NIST.

Выводы

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

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