Я уже не раз рассказывал о бесплатном решении Cisco Threat Response (CTR), которое позволяет существенно снизить время на расследование инцидентов, характеризующихся множеством разнотипных индикаторов компрометации — хэшей файлов, IP-адресов, имен доменов, адресов e-mail и т.п. Но прошлые заметки были посвящены либо примерам использования CTR с отдельными решениями Cisco, либо его интеграции с ГосСОПКОЙ и ФинЦЕРТом. Сегодня я хотел бы описать, как можно применить CTR для расследования отдельных хакерских кампаний, которые могут использовать множество векторов против множества различных целей внутри компании. В качестве примера возьмем уже упомянутую мной в одной из предыдущих статей кампанию DNSpionage.
В прошлый раз я показывал, как ее можно обнаружить с помощью только одного решения — системы анализа сетевых аномалий Cisco Stealthwatch Enterprise. Тогда мы фиксировали взаимодействие вредоносной клиентской части с командным сервером по протоколу DNS, который и служил индикатором в случае использования его на неразрешенных узлах внутри корпоративной сети. По сути мы искали аномалии в сетевом трафике для поиска признаков инцидента. Сейчас давайте посмотрим, как выявить кампанию DNSpionage с помощью более привычных индикаторов вредоносной активности (IOC)?
Список индикаторов мы можем посмотреть в каком-либо бюллетене Threat Intelligence. В данном случае мы воспользуемся сайтом подразделения Cisco Talos, крупнейшей в мире неправительственной группы расследования инцидентов, которая и выявила впервые кампанию DNSpionage (тут и тут).
В бюллетене мы видим список индикаторов — хэши файлов, IP и доменные адреса командных и фишинговых серверов, задействованных в атаке.
Если мы будем каждый из индикаторов «прогонять» через соответствующие средства защиты, то у нас это займет слишком много времени. Например, в Cisco AMP for Endpoints, решении класса EDR, мы вводим один или сразу несколько интересующих нас хэшей в строку поиска (справа вверху):
и получаем интересующий нас результат — найден узел, на котором замечена активность вредоносной программы, у которой искомый нами хэш.
Кстати, хочу отметить, что поиск по хэшам может быть использован не только для обнаружения вредоносной активности, но и для борьбы с утечками информации. Вспомним, что одной из технологий борьбы с утечками (наряду с контейнерами/метками и контентным анализом) является использование цифровых отпечатков, которые могут быть реализованы как раз с помощью хэшей, которые и будет контролировать AMP4E (а также иные решения Cisco, в которых может быть реализован движок AMP — Cisco Firepower, Cisco Email Security Appliance, Cisco Web Security Appliance, Cisco Umbrella и т.п.). Правда, работает такой механизм только для редко изменяемых файлов. Если вам интересно, что Cisco предлагает для борьбы с утечками, то могу порекомендовать запись и презентацию нашего свежего вебинара, который мы посвятили этой теме.
Но вернемся к нашей истории. Если попробовать отслеживать доступ к доменам командных или фишинговых серверов, то нам может помочь решение Cisco Umbrella.
Так как основной вектор заражения в большинстве инцидентов, — это электронная почта, то нам необходимо также искать интересующие нас индикаторы и в e-mail. Для этого мы в Cisco Security Management Appliance или Cisco E-mail Security Appliance указываем хэш соответствующего индикатора:
и находим 5 почтовых ящиков, в которых найдены следы искомых нами файлов.
Наконец, отследить (и заблокировать) IP-адреса, с которыми взаимодействует клиентская часть вредоносной кампании, нам помогает Cisco Firepower, межсетевой экран следующего поколения с встроенной системой предотвращения вторжения.
В данном примере, мы хоть и выявляем признаки DNSpionage, но делаем это не так быстро, как хотели. Мы переключаемся между консолями. Мы проводим множество операций copy-past и 4 разных продукта ищут 4 разных типа индикаторов компрометации, тем самым увеличивая время на проведение расследования и реагирование. Можно ли ускорить этот процесс? Безусловно. Можно воспользоваться SIEM, которая может быть интегрирована с TI-источниками, или в которую можно загрузить индикаторы компрометации из внешних TI-источников. Но это дорого, если она коммерческая, или потребует высоких компетенций, если она из разряда open source. Есть более простое и тем более бесплатное решение — Cisco Threat Response, которое ориентировано в первую очередь на решения Cisco, а также на решения других вендоров. С помощью плагина к браузеру мы «вытягиваем» все индикаторы со страницы блога Cisco Talos, описывающих кампанию DNSpionage.
Для ускорения процесса реагирования мы можем блокировать соответствующие индикаторы прямо через плагин.
Но нас интересует расследование инцидента в попытке понять, какие из наших узлов и пользователей были скомпрометированы. И желательно увидеть все на одном экране. CTR как раз и дает нам такую возможность. В левой верхней части графического интерфейса мы видим все наши индикаторы. В левой нижней — карту нашего «заражения».
Фиолетовым цветом показываются уже пострадавшие цели в нашей инфраструктуре — ПК, почтовые ящики, подсети и т.п. В правой верхней части мы видим временную шкалу, отображающую даты появлений (в том числе и первого) индикаторов в нашем сетевом окружении. Наконец, правая нижняя область позволяет нам получить подробную информацию по каждому индикатору, обогащенную и проверенную внешними источниками TI, например, VirusTotal, или средствами защиты третьих фирм.
Поняв масштабы заражения, мы можем начать соответствующим образом реагировать на выявленную угрозу, блокируя ее проявления через Cisco Umbrella, блокирующую взаимодействие с доменами командных серверов:
или через Cisco AMP for Endpoints, изолирующим работу вредоносного файла или процесса.
Сразу же из интерфейса CTR мы можем увидеть результат блокирования файла, домена или иного индикатора.
За счет интеграции CTR с Cisco E-mail Security Appliance или Cisco Firepower мы можем изолировать также зараженные почтовые ящики или скомпрометированные узлы соответственно.
А можно ли выполнить все тоже самое, но не используя интерфейс Cisco Threat Response? Иногда хочется использовать свои, более привычные инструменты для этого. Да, можно. Например, мы можем встроить функциональность CTR в любую, поддерживающую браузер, технологию (например, в собственный портал), а за счет наличия API к функциям CTR можно обращаться вообще отовсюду.
Допустим вы предпочитаете интерфейс командной строки и хотите проводить расследование и реагирование вводя все команды с клавиатуры. Это тоже легко сделать. Например, вот как работает интеграция CTR с системой командной работы Cisco Webex Teams и разработанного для нее бота AskWill на примере кампании DNSpionage. Cisco Webex Teams часто используют наши заказчики для организации взаимодействия специалистов службы ИБ. Этот пример тем более интересен, так как показывает, как можно выстроить процесс расследования и реагирования при удаленной работе, когда, единственное что объединяет специалистов SOC, — это система коммуникаций.
Например, мы хотим получить статус по домену 0ffice36o.com, который использовался командным сервером в рамках DNSpionage. Мы видим, что Cisco Umbrella возвращает нам статус «вредоносный».
А вот как будет выглядеть команда на получение информации о том, встречаются ли в нашей инфраструктуре сразу несколько индикаторов компрометации для кампании DNSpionage, выявленные подразделением Cisco Talos.
Затем мы можем заблокировать вредоносный домен через Cisco Umbrella или Cisco Stealthwatch Cloud. В последнем случае система анализа аномалий будет блокировать взаимодействие с командным сервером для используемых нами облачных инфраструктур Amazon AWS, MS Azure и т.п.
Наконец, если мы по ошибке заблокировали какой-то индикатор или со временем стало известно, что он перестал представлять угрозу, мы можем удалить его из черного списка защитных решений.
Вот так работает бесплатное решение Cisco Threat Response, основная задача которого, — снизить время на расследование и реагирование инцидентов. И как рассказывают наши заказчики, CTR позволяет им существенно сократить его. У 60% пользователей сокращение составляет 50%; еще у 23% — не менее 25%. Неплохо для бесплатного решения, да?!
В прошлый раз я показывал, как ее можно обнаружить с помощью только одного решения — системы анализа сетевых аномалий Cisco Stealthwatch Enterprise. Тогда мы фиксировали взаимодействие вредоносной клиентской части с командным сервером по протоколу DNS, который и служил индикатором в случае использования его на неразрешенных узлах внутри корпоративной сети. По сути мы искали аномалии в сетевом трафике для поиска признаков инцидента. Сейчас давайте посмотрим, как выявить кампанию DNSpionage с помощью более привычных индикаторов вредоносной активности (IOC)?
Список индикаторов мы можем посмотреть в каком-либо бюллетене Threat Intelligence. В данном случае мы воспользуемся сайтом подразделения Cisco Talos, крупнейшей в мире неправительственной группы расследования инцидентов, которая и выявила впервые кампанию DNSpionage (тут и тут).
В бюллетене мы видим список индикаторов — хэши файлов, IP и доменные адреса командных и фишинговых серверов, задействованных в атаке.
Если мы будем каждый из индикаторов «прогонять» через соответствующие средства защиты, то у нас это займет слишком много времени. Например, в Cisco AMP for Endpoints, решении класса EDR, мы вводим один или сразу несколько интересующих нас хэшей в строку поиска (справа вверху):
и получаем интересующий нас результат — найден узел, на котором замечена активность вредоносной программы, у которой искомый нами хэш.
Кстати, хочу отметить, что поиск по хэшам может быть использован не только для обнаружения вредоносной активности, но и для борьбы с утечками информации. Вспомним, что одной из технологий борьбы с утечками (наряду с контейнерами/метками и контентным анализом) является использование цифровых отпечатков, которые могут быть реализованы как раз с помощью хэшей, которые и будет контролировать AMP4E (а также иные решения Cisco, в которых может быть реализован движок AMP — Cisco Firepower, Cisco Email Security Appliance, Cisco Web Security Appliance, Cisco Umbrella и т.п.). Правда, работает такой механизм только для редко изменяемых файлов. Если вам интересно, что Cisco предлагает для борьбы с утечками, то могу порекомендовать запись и презентацию нашего свежего вебинара, который мы посвятили этой теме.
Но вернемся к нашей истории. Если попробовать отслеживать доступ к доменам командных или фишинговых серверов, то нам может помочь решение Cisco Umbrella.
Так как основной вектор заражения в большинстве инцидентов, — это электронная почта, то нам необходимо также искать интересующие нас индикаторы и в e-mail. Для этого мы в Cisco Security Management Appliance или Cisco E-mail Security Appliance указываем хэш соответствующего индикатора:
и находим 5 почтовых ящиков, в которых найдены следы искомых нами файлов.
Наконец, отследить (и заблокировать) IP-адреса, с которыми взаимодействует клиентская часть вредоносной кампании, нам помогает Cisco Firepower, межсетевой экран следующего поколения с встроенной системой предотвращения вторжения.
В данном примере, мы хоть и выявляем признаки DNSpionage, но делаем это не так быстро, как хотели. Мы переключаемся между консолями. Мы проводим множество операций copy-past и 4 разных продукта ищут 4 разных типа индикаторов компрометации, тем самым увеличивая время на проведение расследования и реагирование. Можно ли ускорить этот процесс? Безусловно. Можно воспользоваться SIEM, которая может быть интегрирована с TI-источниками, или в которую можно загрузить индикаторы компрометации из внешних TI-источников. Но это дорого, если она коммерческая, или потребует высоких компетенций, если она из разряда open source. Есть более простое и тем более бесплатное решение — Cisco Threat Response, которое ориентировано в первую очередь на решения Cisco, а также на решения других вендоров. С помощью плагина к браузеру мы «вытягиваем» все индикаторы со страницы блога Cisco Talos, описывающих кампанию DNSpionage.
Для ускорения процесса реагирования мы можем блокировать соответствующие индикаторы прямо через плагин.
Но нас интересует расследование инцидента в попытке понять, какие из наших узлов и пользователей были скомпрометированы. И желательно увидеть все на одном экране. CTR как раз и дает нам такую возможность. В левой верхней части графического интерфейса мы видим все наши индикаторы. В левой нижней — карту нашего «заражения».
Фиолетовым цветом показываются уже пострадавшие цели в нашей инфраструктуре — ПК, почтовые ящики, подсети и т.п. В правой верхней части мы видим временную шкалу, отображающую даты появлений (в том числе и первого) индикаторов в нашем сетевом окружении. Наконец, правая нижняя область позволяет нам получить подробную информацию по каждому индикатору, обогащенную и проверенную внешними источниками TI, например, VirusTotal, или средствами защиты третьих фирм.
Поняв масштабы заражения, мы можем начать соответствующим образом реагировать на выявленную угрозу, блокируя ее проявления через Cisco Umbrella, блокирующую взаимодействие с доменами командных серверов:
или через Cisco AMP for Endpoints, изолирующим работу вредоносного файла или процесса.
Сразу же из интерфейса CTR мы можем увидеть результат блокирования файла, домена или иного индикатора.
За счет интеграции CTR с Cisco E-mail Security Appliance или Cisco Firepower мы можем изолировать также зараженные почтовые ящики или скомпрометированные узлы соответственно.
А можно ли выполнить все тоже самое, но не используя интерфейс Cisco Threat Response? Иногда хочется использовать свои, более привычные инструменты для этого. Да, можно. Например, мы можем встроить функциональность CTR в любую, поддерживающую браузер, технологию (например, в собственный портал), а за счет наличия API к функциям CTR можно обращаться вообще отовсюду.
Допустим вы предпочитаете интерфейс командной строки и хотите проводить расследование и реагирование вводя все команды с клавиатуры. Это тоже легко сделать. Например, вот как работает интеграция CTR с системой командной работы Cisco Webex Teams и разработанного для нее бота AskWill на примере кампании DNSpionage. Cisco Webex Teams часто используют наши заказчики для организации взаимодействия специалистов службы ИБ. Этот пример тем более интересен, так как показывает, как можно выстроить процесс расследования и реагирования при удаленной работе, когда, единственное что объединяет специалистов SOC, — это система коммуникаций.
Например, мы хотим получить статус по домену 0ffice36o.com, который использовался командным сервером в рамках DNSpionage. Мы видим, что Cisco Umbrella возвращает нам статус «вредоносный».
А вот как будет выглядеть команда на получение информации о том, встречаются ли в нашей инфраструктуре сразу несколько индикаторов компрометации для кампании DNSpionage, выявленные подразделением Cisco Talos.
Затем мы можем заблокировать вредоносный домен через Cisco Umbrella или Cisco Stealthwatch Cloud. В последнем случае система анализа аномалий будет блокировать взаимодействие с командным сервером для используемых нами облачных инфраструктур Amazon AWS, MS Azure и т.п.
Наконец, если мы по ошибке заблокировали какой-то индикатор или со временем стало известно, что он перестал представлять угрозу, мы можем удалить его из черного списка защитных решений.
Вот так работает бесплатное решение Cisco Threat Response, основная задача которого, — снизить время на расследование и реагирование инцидентов. И как рассказывают наши заказчики, CTR позволяет им существенно сократить его. У 60% пользователей сокращение составляет 50%; еще у 23% — не менее 25%. Неплохо для бесплатного решения, да?!
Дополнительная информация:
- Интеграция Cisco Threat Response и Cisco Stealthwatch Enterprise
- Взаимодействие решений Cisco в ГосСОПКОЙ и ФинЦЕРТом
- Почему Cisco не покупает Splunk или рассказ о том, как работает платформа Cisco для threat hunting
- Threat Hunting с помощью нового решения Cisco Visibility
- Кейсы для применения средств анализа сетевых аномалий: обнаружение кампании DNSpionage