А ваши СОКи готовы к жаждущим рыданий неПетям?

Активное действие требует активного противодействия

Последние два месяца окропили страницы истории событиями, заставившими поверить в существование информационной безопасности самых консервативных скептиков и даже людей, не связанных с ИБ и ИТ вообще (картинок с блокскрином в самых неожиданных местах полно в Сети).
На просторах Всемирной Паутины в великом избытке можно найти всевозможные технические детали этих атак, поэтому в этом посте мы поговорим о более "бумажных" аспектах ИБ, а именно требованиях к операционной безопасности, выставляемых практикой мониторинга и контроля подобных атак.

На слайде 4 я рассказывал о Контексте угрозы, о современных ТТР, с которыми приходится считаться, а далее, начиная со слайда 11, приводил примеры инцидентов, с использованием этих ТТР и рассказывал, как это обнаруживать. Возможно тогда, все эти "новомодные" подходы типа Threat hunting, обнаружение по ТТР и усиление классического SOC, казались какими-то теоритезированными и далекими, но безжалостная практика показала, что современность требует именно этого.

Рассмотрим поверхностно применяемые техники и как они могут быть обнаружены.

WannaCry (12.05.2017)
Распространение - эксплоит EthernalBlue. Патч был выпущен заблаговременно (14.03.2017), спустя месяц (14.04.2017) - слив, который сразу же был проанализирован, и все нормальные IPS/IDS его детектили уже, самое позднее, на следующий день.
Нагрузка детектировалась нормальными антивирусами эвристикой (по поведению), а затем и сигнатурой на тушки.
"Классических" подходов к ИБ - вполне достаточно:

• патчи ставить, можно даже с опозданием на месяц,
• сигнатуры антивируса, IPS/IDS - обновлять,
• сеть сегментировать (так как после сканирования своей подсети, сканировались случайные адреса),
• в антивирусе включить поведенческий детект.

В целом, если перечисленные контроли работают, никакой мониторинг/SOC и не нужен.
Однако успешность атаки показала, что даже эти, назовем их статические (типа, сделал и забыл, никакой адаптации не нужно) меры, далеко не всегда выполняются.
Положительный эффект - то, что MS17-010, наконец-то, только истинные обломовцы не поставили.

Очевидно, что статических мер - недостаточно (про это были первые два абзаца воды) и вот практика это показала...

exPetr (27.06.2017)
Распространительный функционал обогащен дополнительными возможностями:

• эксплоит EternalRomance (направлен на XP/2003, тоже патчится MS17-010);
• увод аккаунтов (функционал схожий с Mimikatz);
• далее с этими аккаунтами - wmic и psexec по сети;
• выбор жертвы:
• просмотр своих интерфейсов --> сканирование их сетей по 139 и 445 --> доступным - эксплоит/соединение;
• аналог netstat - с кем соединения established --> эксплоит/соединение;
• перечень хостов из arp-кеша --> эксплоит/соединение;
• перечисление компов в домене --> эксплоит/соединение;
• если адрес хоста - динамический --> эксплоит/соединение DHCP-сервера --> получение всех клиентов DHCP-севера --> эксплоит/соединение клиентов DHCP-сервера.

Вынесем за скобки другие фичи, типа удаления логов (~антифоренсика) и т.п., разберемся хотя бы с выписанным.

Выделенные красным - как раз те техники, что требуют дополнительных мер операционной безопасности - мониторинга и даже несколько более глубокого, так как:

1. дамп паролей из памяти по поведению надежно продетектить сложно, так как, в целом, инжект в память lsass может быть вызван и легальной работой какой-нибудь загадочной аутентификации или системы безопасности, поэтому, как правило, антивирус детектит конкретный инструмент (Mimikatz, WCE, pwdump и пр.), а не ТТР;
2. горизонтальные перемещения - выполняются с использованием легальных и даже штатных инструментов, использование которых не представляет собой ничего вредоносного, более того, зачастую используются администраторами (в нормальных инфраструктурах, конечно, не используют psexec (поэтому красным он не выделен), поскольку есть более "интерпрайзные" решения и, исходя из принципа минимума функционала, следует ими и ограничиться, однако, использование WMI (wmic) - достаточно распространенная практика);
3. тупое шумное сканирование (любая NIDS вполне эффективно обнаруживает сканирования и портсвипы) обогащено функционалом выявления хостов с которыми непосредственно сейчас или в недалеком прошлом уже было сетевое взаимодействие и поэтому вредоносное подключение к ним не будет радикально выделяться при анализе межхостовых взаимодействий;
4. сканирований за рамки своего VLAN-а уже нет, поэтому пролет "подозрительного" трафика через маршрутизатор (потенциально - межсетевой экран) отсутствует.

1 - обнаруживатется по инжектам в lsass - при наличии достаточной репутационной базы (и коммуникации с админами), аналитик без особого труда из множества инжектов найдет те, которые следует поисследовать, и среди них будет угроза, за которой охотились.

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

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

Нормальные Охотники на угрозы анализируют сетевые соединения. Если у вас DHCP-сервер - маршрутизатор (или, во всяком случае, не windows), то обращение к нему по 445 будет выглядеть более чем странно и внимательный аналитик непременно решит докопаться что за процесс генерит столь странные обращения.

Не надо быть сильно смекалистым, чтобы из написанного выше не сделать выводы, почему SOC-а в его классическом текущем понимании мало. И, все-таки, кратко остановлюсь на этом:

• нужны низкоуровневые события с эндпоинта - запуски процессов, их сетевые соединения, загрузки библиотек, инжекты в код других процессов и т.п.;
• в дополнение к эндпоинту, нужны данные, как минимум, с сетевого периметра, крайне полезен результат анализа внутреннего трафика;
• нужны механизмы контроля использования легитимных и штатных инструментов ОС с возможностью быстрого понимания что "нормально", а что - "подозрительно";
• нужны хорошие справочники TI, как позволяющие автоматически маркировать объекты в логах с последующим использованием в корреляционной логике, так и служащие справочником для аналитика, выполняющего расследование подмеченной подозрительной активности;
• ну и, конечно, инфраструктура быстрого (~ автоматического) проведения форенсики - песочницы, опять же обвешенной всевозможным TI, позволяющим что-то автоматически протеггировать и немного сократить задачу аналитика по поиску следов атаки или подозрительной активности.

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