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

В ряде случаев компании «забрасывают» активы своей инфраструктуры: старые веб‑приложения, неактуальные сайты/площадки, «торчащие» наружу узлы со служебной информацией, внутренние сервисы и т. д. Векторы атак постоянно развиваются, и гораздо эффективнее готовиться к ним заранее, вовремя устраняя потенциальные точки входа. В этой статье специалисты Центра кибербезопасности F6 рассказали как проактивный подход к мониторингу и своевременное реагирование могут помочь локализовать инцидент на ранней стадии, сэкономив время и ресурсы внутренней ИБ‑команды, и избежав возможных сопутствующих издержек для всего бизнеса, а также о важности контроля и мониторинга не только внутреннего контура инфраструктуры, но и уязвимого внешнего периметра, который часто является мишенью для злоумышленников и «точкой входа» во многих атаках.

Поле зрения команды SOC

Как правило, работа типичного аналитика SOC преимущественно связана с мониторингом и реагированием в рамках внутреннего контура инфраструктуры. Мы в Центре кибербезопасности F6 считаем (и практикуем, когда это возможно) корреляцию не только внутренних алертов между собой, но и проблем, которые возникают на внешнем периметре, с внутренними алертами. Переход от реактивного мониторинга к проактивному позволяет купировать проблему до того, как ею воспользуются злоумышленники, избежать серьезных инцидентов и/или вовремя «вклиниться» в атаку, чтобы остановить ее.

Для постоянного контроля за внешней поверхностью атаки, Attack Surface Management (ASM) непрерывно осуществляет поиск цифровых объектов заказчика, которые ежедневно проходят множество проверок системой для определения их защищенности и уровня риска. Если актив подвержен риску, то в разделе «Проблемы» портала ASM F6 создается новая запись, а аналитик получает уведомление о новом алерте и приступает к его обработке. В системе присутствует восемь категорий проблем, на основе которых составляется «карта» внешней поверхности атаки:

  • Уязвимости;

  • Сетевая безопасность;

  • Утечки;

  • Вредоносные программы;

  • Упоминания в дарквебе;

  • Безопасность SSL/TLS сертификатов;

  • Почтовая безопасность;

  • DNS и домены.

Со стороны аналитика SOC MDR наибольший «интерес» представляют те категории внешних проблем инфраструктуры, воспользовавшись которыми злоумышленник может получить доступ к инфраструктуре и развить свою атаку дальше. К таким категориям относятся уязвимости, проблемы сетевой безопасности, утечки и вредоносные программы. Особое внимание стоит обратить на упоминания в дарквебе — ASM автоматически сопоставляет данные системы F6 Threat Intelligence и находит упоминания злоумышленников о каком‑либо объекте, связанным с заказчиком, в дарквебе. Чем чаще инфраструктура компании упоминается злоумышленниками, тем выше вероятность реализации атак против нее. Предоставляемые ASM данные с теневых площадок позволяют классифицировать и анализировать риски, а также предпринять рекомендуемые действия по защите от атак.

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

Изучаем инцидент

Центром кибербезопасности F6 был получен алерт в ASM о потенциальной компрометации учетной записи одного из клиентов. На основе полученных данных мы увидели, что компрометация произошла в результате работы стилера, а учетная запись была связана с несколькими ресурсами. Часть из этих ресурсов относились к «внутренним», то есть недоступным извне, с характерными поддоменами вида portal.domain.ru, sd.domain.ru, wiki.domain.ru и т. д. В утечке присутствовал также и «говорящий» vpn.domain.ru.

Рисунок 1. Алерт, свидетельствующий о возможной компрометации
Рисунок 1. Алерт, свидетельствующий о возможной компрометации
Рисунок 2. События в ASM с более подробной информацией о компрометации
Рисунок 2. События в ASM с более подробной информацией о компрометации

Собрав дополнительный контекст с помощью F6 Threat Intelligence, мы поняли, что компрометация могла произойти в результате работы META Stealer — форком известного стилера RedLine, который предназначен для кражи конфиденциальных данных с компьютера жертвы. ВПО распространяется преимущественно через фишинговые рассылки и часто используется различными кибершпионскими группами (в т.ч. APT‑группой Sticky Werewolf).

Рисунок 3. Данные с платформы F6 Threat Intelligence о вредоносном ПО, вследствие работы которого произошла компрометация данных
Рисунок 3. Данные с платформы F6 Threat Intelligence о вредоносном ПО, вследствие работы которого произошла компрометация данных

В некоторых случаях в опубликованных на теневых площадках данных может также присутствовать информация о скомпрометированном хосте, что помогает при сборе дополнительного контекста по атаке:

Рисунок 4. Данные о потенциально скомпрометированной операционной системе
Рисунок 4. Данные о потенциально скомпрометированной операционной системе
Рисунок 5. Данные о языковом пакете потенциально скомпрометированной операционной системы
Рисунок 5. Данные о языковом пакете потенциально скомпрометированной операционной системы

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

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

Имея на руках собранный контекст, наш MXDR и SIEM в арсенале, мы перешли в фазу активного исследования.

Собираем артефакты

Первым делом проверили, были ли какие‑либо события в MXDR, связанные с задействованным ВПО. Ретроспективный анализ событий не показал активности, связанной с эксплуатацией стилера. Мы предположили, что хост является личным устройством сотрудника, либо находится вне зоны видимости решения, например, в не защищенном сегменте сети.

Поскольку в данных об утечке фигурировал поддомен vpn.*, а также нам известна подсеть клиента, которая используется для удаленного подключения, мы изучили, была ли какая‑либо нетипичная сетевая активность с пула адресов, предназначенных для VPN, в период между датой публикации записи о компрометации и обнаружением данной записи с помощью ASM до текущего момента.

В SIEM клиента нашли следы свежего RDP подключения с хоста из VPN‑пула от данного пользователя на один из хостов домена.

Рисунок 6. События в SIEM, свидетельствующие об удаленном подключении пользователя на другое доменное устройство
Рисунок 6. События в SIEM, свидетельствующие об удаленном подключении пользователя на другое доменное устройство

Этой информации не было достаточно для установления характера и легитимности данной активности, а корпоративный хост пользователя был вне зоны покрытия EDR‑агентом MXDR. Вдобавок пользователь мог легитимно подключаться по RDP. Поэтому для уточнения характера активности мы попросили клиента установить EDR‑агент на конечный хост пользователя, который входил в корпоративную инфраструктуру.

После его установки был инициирован сбор артефактов для оперативной проверки подозрительной активности. В данном случае нас интересует «джентльменский набор» — журналы Windows, реестр и MFT‑таблица. Дополнительно EDR‑агент собирает Amcache, который тоже пригодился нам для дальнейшего исследования.

Рисунок 7. Лог из MXDR об инициализации сбора артефактов с устройства
Рисунок 7. Лог из MXDR об инициализации сбора артефактов с устройства
Рисунок 8. Собранные средствами EDR криминалистически значимые данные в интерфейсе MXDR
Рисунок 8. Собранные средствами EDR криминалистически значимые данные в интерфейсе MXDR

Анализируем артефакты

В Amcache мы обнаружили потенциальные свидетельства о проведении разведки, на что намекает существование утилит для получения информации о хосте, сети и домене (12:00 — 12:26 UTC; 15:00 — 15:26 MSK, совпадает со временем RDP‑сессии пользователя).

Рисунок 9. Данные из Amcache, свидетельствующие о наличии утилит для получения дополнительной информации об устройстве
Рисунок 9. Данные из Amcache, свидетельствующие о наличии утилит для получения дополнительной информации об устройстве

Анализ MFT‑таблицы показал следующие записи. Создание Prefetch файла curl и появление подозрительного файла в папке AppData\Local\Temp позволило предположить, что пользователь загрузил его из интернета с помощью данной утилиты командной строки в 12:26 по UTC (15:26 по MSK).

Рисунок 10. Данные файловой таблицы MFT, свидетельствующие о наличии подозрительного файла во временной директории и использовании curl
Рисунок 10. Данные файловой таблицы MFT, свидетельствующие о наличии подозрительного файла во временной директории и использовании curl

Пока шел процесс анализа триажа, решением F6 MXDR был поднят алерт на вредоносную активность на задействованном хосте. Система выявила выполнение подозрительных Powershell‑скриптов и очистку журналов Windows.

Рисунок 11. Событие в системе MXDR, свидетельствующее о потенциально вредоносной активности с устройства пользователя
Рисунок 11. Событие в системе MXDR, свидетельствующее о потенциально вредоносной активности с устройства пользователя
Рисунок 12. Расширенная информация по потенциально вредоносному событию с устройства пользователя
Рисунок 12. Расширенная информация по потенциально вредоносному событию с устройства пользователя

Пользователь в рамках новой RDP‑сессии в 16:20 запустил загруженный файл с аргументами, потенциально указывающими на создание туннеля с удалённым сервером. Позже мы обнаружили, что данный файл является популярной у злоумышленников утилитой revsocks.

Рисунок 13. Событие свидетельствующее об успешном удаленном подключении к устройству пользователя
Рисунок 13. Событие свидетельствующее об успешном удаленном подключении к устройству пользователя
Рисунок 14. Событие, свидетельствующее об использовании revsocks
Рисунок 14. Событие, свидетельствующее об использовании revsocks

Далее из папки С:\Users\Public был запущен скрипт ad.ps1, который представляет собой инструмент для разведки в домене Active Directory — AdRecon (https://github.com/sense‑of‑security/ADRecon) для сбора подробной информации об устройстве домена, пользователях и политиках.

Рисунок 15. Событие, свидетельствующее об использовании ADRecon
Рисунок 15. Событие, свидетельствующее об использовании ADRecon

После завершения его работы пользователь попытался очистить логи Powershell с помощью встроенного инструмента wevtutil.

Рисунок 16. Событие очистки журнала Windows Powershell
Рисунок 16. Событие очистки журнала Windows Powershell

Кроме того, модуль NTA обнаружил сетевую активность Go‑бэкдора.

Рисунок 17. Сетевые коммуникации, обнаруженные модулем MXDR NTA, свидетельствующие об активности Go-бэкдора
Рисунок 17. Сетевые коммуникации, обнаруженные модулем MXDR NTA, свидетельствующие об активности Go-бэкдора

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

Для локализации инцидента аналитики ЦК направили команду на изоляцию хоста и рекомендовали заказчику оперативно заблокировать задействованную учетную запись.

Рисунок 18. Лог из системы MXDR о сетевой изоляции устройства пользователя
Рисунок 18. Лог из системы MXDR о сетевой изоляции устройства пользователя

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

Рисунок 19. Запись из журнала событий Windows, свидетельствующая об исполнении вредоносного ПО
Рисунок 19. Запись из журнала событий Windows, свидетельствующая об исполнении вредоносного ПО

В рамках анализа инцидента данный экземпляр вредоносного ПО был загружен в модуль MXDR MDP, где был атрибутирован к семейству META Stealer.

Рисунок 20. Вердикт модуля MXDR MDP по вредоносному файлу с устройства пользователя
Рисунок 20. Вердикт модуля MXDR MDP по вредоносному файлу с устройства пользователя

Чтобы исключить закрепление злоумышленника в сети клиент инвентаризировал внутренние активы и установил EDR‑агенты на непокрытые хосты.

Что имеем в итоге?

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

Подключившись по RDP к одному из конечных хостов с полученными данными, злоумышленник провел скрытную первичную разведку посредством выполнения команд в терминале и загрузил инструмент туннелирования для использования в дальнейшем. Вернувшись на хост позднее, злоумышленник провел разведку с использованием ADRecon, закрепился с создания туннеля и попытался очистить логи Powershell, чтобы скрытно продвинуться по сети. Однако, действия аналитиков и инструменты F6 MXDR и F6 ASM позволили быстро локализовать инцидент и выявить точку входа, что не позволило злоумышленнику развить атаку и добраться до чувствительных данных.

Конечно, не всегда все бывает так «радужно» и скомпрометированные данные могут уйти в продажу или публичный доступ, а ими могут воспользоваться злоумышленники (как те, кто получил их в ходе, например, фишинговой атаки, так и другие группы, которым может понадобиться получить доступ к конкретной организации) для дальнейшего развития атаки (все зависит от атакующей группы, ее целей, потенциальной выгоды и т. д.). Обнаружить подобную активность и следы компрометации на ранней стадии позволяет выстроенный процесс проактивного поиска угроз на хостах, используя данные киберразведки (Threat Hunting). Кроме того, аналитики SOC должны обнаружить точку входа, написать детектирующие правила и обновить процесс самого хантинга с учетом новых полученных «знаний».

Справка

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

F6 Attack Surface Management (ASM) — это комплексное SaaS‑решение, предназначенное для оценки поверхности атаки компании и связанных с ней активов. Система позволяет выявить уязвимые активы с высоким уровнем риска, давно забытые теневые ИТ (Shadow IT), выделить слабые места организации и устранить брешь до совершения атаки. Понимание того, что именно необходимо защищать, и какие элементы уязвимы, — первый шаг на пути к построению последовательной и эффективной стратегии защиты.

F6 Managed XDR — модульное решение с управлением из единого окна, которое защищает почту, корпоративные устройства, анализирует трафик и файлы. Противостоит программам‑шифровальщикам, троянам, шпионам, бэкдорам, вредоносным скриптам и скрытым каналам передачи данных внутри и за пределами защищенного периметра — угрозам, которые могут вывести бизнес из строя. Можно выбрать любую комбинацию модулей, возможно развертывание локально (on‑prem) или в облаке (cloud).

Комментарии (0)