Incident response на удаленке: как вызовы COVID-19 превратились в новые практики

Мы — отдел реагирования на угрозы информационной безопасности, и наша работа — помогать заказчикам расследовать компьютерные инциденты и реагировать на них. К нам за помощью обращаются самые разные компании, и уровень зрелости ИБ у них может быть абсолютно любой: от крупной инфраструктуры с собственным SOC и штатом обученных специалистов по ИБ до обычной локалки без файрвола или антивируса, где роль безопасников в свободное время исполняют сисадмины.

Once upon a time

В те далекие времена, когда COVID-19 еще не отправил всех на удаленку, процесс реагирования на инцидент у заказчика мог выглядеть так:

• Веселая толпа выезжает на совещание, а порой и в командировку
• Общается с заказчиком, качает головой и говорит «разберемся»
• Наши эксперты в компании с технарями заказчика собирают релевантную информацию об инциденте, данные со средств защиты и затронутых систем
• Изучают данные на месте или везут их в офис и разбираются там

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

Но вот начинается пандемия…

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

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

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

Дано: заказчик, удаленка, инцидент

Итак, мы столкнулись с тремя основными проблемами:

• Как поддерживать связь с заказчиком?
• Как собирать данные на стороне заказчика?
• Как передавать данные от заказчика к нам?

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

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

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

Мы сформулировали для себя минимальный набор требований к используемым инструментам. Они должны были:

• запускаться без сложного конфигурирования и длинных командных строк;
• оставлять минимальный след в операционной системе;
• работать на максимально широком спектре операционных систем.

Отмечу, что определенные наработки у нас были и до пандемии, но именно она заставила обратить на эти проблемы больше внимания и форсировать разработку.

Сбор данных точечно

Какие у нас были варианты сбора данных?

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

Если нужно собрать данные непосредственно с хостов, то есть несколько способов. Первый — классический: снять образ диска. Плюсы такого подхода: возможность получить все данные, которые были на жестком диске, в том числе удаленные или находящиеся в неразмеченных областях. Минусы: образы диска занимают много места и не содержат волатильных данных (то есть тех, которые есть в системе во время ее работы: информация о сетевых соединениях, запущенных процессах и т. п.).

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

Третий способ набрал популярность в последние годы; он называется live response. Суть такова: специальная утилита собирает с работающей системы ограниченный набор файлов, необходимый для проведения расследования, а также волатильную информацию. Плюсы такого подхода: относительно маленький объем данных и наличие информации с работающей системы (зачастую это более показательно, чем «мертвые» данные: например, можно сразу увидеть подозрительные процессы или сетевые соединения). Минусы: ограниченность собираемого набора может привести к тому, что какие-то интересные файлы собраны не будут, и их придется запрашивать дополнительно. Кроме того, полученные таким образом данные сложно будет использовать в качестве доказательной базы, если проводится расследование в рамках уголовного дела.

Мы остановились на третьем варианте. Изначально мы проанализировали доступные на рынке инструменты и поняли, что они не удовлетворяют нашим требованиям. Решили, что нужно разрабатывать свое средство.

В качестве языка программирования выбрали Go:

• он довольно прост для изучения и позволяет эффективно писать программы;
• позволяет статически компилировать все зависимости в один файл;
• позволяет компилировать программу под разные платформы и операционные системы;
• поддерживает Windows аж в версии XP (и такое на кейсах случается). 

Так возникла утилита pt-dumper. Что же она делает? В самом простом случае она запускается двойным кликом и собирает с системы информацию, которую мы считаем необходимой для расследования. Набор данных не удивит тех, кто работает в этой области: системные файлы, такие как $MFT и файлы реестра, файлы различных forensic-артефактов, системные журналы и т. д. Кроме того, мы добавили возможность сбора любых файлов по регулярным выражениям. Это полезно: в процессе расследования мы можем обнаружить, что хакер обычно хранит свои файлы в какой-то директории или использует утилиты с какими-то конкретными именами. Конечно, собирается и волатильная информация: список запущенных процессов, список сетевых соединений, содержимое кэша DNS и т. д.

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

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

Еще мы разработали версии pt-dumper для Linux и macOS. Правда, с версией для Windows их объединяет в основном название, так как по своей архитектуре эти операционные системы сильно отличаются и набор данных там совершенно другой. Впрочем, концепция осталась той же самой.

Сбор данных массово

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

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

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

Для массового сканирования инфраструктуры мы создали утилиту pt-scanner. Она состоит из двух компонентов — сервера и клиента. Сервер запускается на специально выделенной машине в инфраструктуре заказчика и ждет информацию от клиентов. Клиенты запускаются на сканируемых машинах и собирают необходимую хостовую информацию, затем отправляют ее на сервер. Для взаимодействия необходимо обеспечить связность между клиентами и сервером по 80-му порту. В остальном и клиент, и сервер запускаются так же просто, как и pt-dumper, — даблкликом и без параметров. При этом вопрос распространения клиентской части заказчик решает самостоятельно и использует те средства удаленного запуска, которые ему удобны. Если заказчик не знает, как это сделать, мы можем предложить ему проверенные варианты (PsExec, доменные политики, SCCM, KSC и т. д.).

Набор собираемых данных в целом похож на тот, который собирается с помощью pt-dumper, но не включает в себя тяжеловесные данные. При этом в клиенте есть функциональность проверки процессов и файлов по хешам, путям и с помощью YARA-правил.

Сервер просто получает данные от клиентов и складывает их в архивы. Фактически никакого другого взаимодействия между клиентом и сервером не происходит. Эта схема эффективно и надежно работает в том случае, когда все задачи по запуску сканирования выполняет сам заказчик. Но когда в инфраструктуре работаем мы, функциональность иногда оказывается недостаточной. Еще до пандемии COVID-19 мы начали разработку интерактивного аналога pt-scanner и назвали его pt-responder.

В клиентскую часть добавили возможность закрепления на сканируемых системах (на случай перезагрузок), а в сервер встроили веб-интерфейс для управления работой агентов. Но самые большие изменения произошли в логике работы агента: теперь сырые данные обрабатывались прямо на хосте и отправлялись на сервер в формате JSON. Для этого мы написали парсеры для практически всех интересующих нас forensic-артефактов, а также сборщики различных волатильных данных. А чтобы можно было использовать pt-responder как pt-scanner, то есть для неинтерактивного сбора информации, мы реализовали механизм пресетов.

Впрочем, практика показала, что pt-scanner мы все равно используем гораздо чаще, чем pt-responder. Но наработки pt-responder не пропали даром: разработанные парсеры мы внедрили как в pt-scanner, так и в pt-dumper. За счет этого удалось ускорить процесс анализа: часть данных в собранном архиве теперь приходит уже в разобранном виде, и можно не тратить время на запуск утилит для парсинга артефактов.

Передача данных

Итак, заказчик собрал данные, теперь ему нужно как-то передать их нам на анализ.

До эпидемии COVID-19 можно было съездить к заказчику и забрать все на жестком диске. Недостатки очевидны: надо тратить время на дорогу и копирование данных. В реалиях локдаунов такой метод вообще малоприменим и остается на крайний случай.

Еще можно копировать данные непосредственно по VPN/RDP, если заказчик предоставляет такую возможность. Часто такие каналы не отличаются стабильностью и скоростью работы, поэтому передавать большие объемы данных проблематично.

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

Поэтому мы решили изобрести свой велосипед и назвали его pt-cloud. На самом деле, это не облачное решение, как можно было бы решить по названию. Заказчику мы отдаем клиентскую часть приложения, она содержит всего две кнопки: «Выбрать файл» и «Отправить файл». Ошибиться невозможно.

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

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

Новые практики

Теперь процесс реагирования стал выглядеть так.

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

Почему же «костыли», призванные минимизировать боль от ограничений, которые наложила пандемия COVID-19, стали неотъемлемой частью наших практик?

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

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

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

Плюсы для заказчиков:

• Не нужно пускать посторонних людей в свою инфраструктуру. Можем проиллюстрировать градус недоверия на собственном примере. Positive Technologies является известным вендором в области ИБ, то есть заказчики вроде бы должны доверять нам, но тем не менее мы регулярно обнаруживаем, что они загружают наши утилиты на VirusTotal.
• Возможность быстро получить значимые результаты. Если заказчик готов быстро собирать и передавать данные, то мы так же быстро можем их анализировать и давать результат. Это означает, что в течение пары часов после передачи наших утилит заказчик уже может получать от нас информацию, как именно развивается инцидент, каким мог быть исходный вектор, а также различные индикаторы компрометации, которые можно загрузить в средства защиты информации для улучшения видимости и локализации инцидента.