Представьте, что на дашбордах корпоративных систем мониторинга и защиты всё тихо: сигнатуры и фиды не замечают никаких подозрительных взаимодействий с внешними ресурсами. Антивирус тоже молчит: никаких вредоносных файлов на диске, подозрительных процессов и сетевых соединений. Но эта «тишина» обманчива. В шифрованных сессиях видны небольшие периодические обращения к внешнему хосту. Хотя популярные онлайн-сервисы проверки репутации по нему ничего подозрительного не нашли, эти периодические обращения всё же привлекли наше внимание. Мы взяли IP-адрес удаленного узла и стали детально наблюдать за его поведением. В результате расследования выяснилось, что это маяк (beacon) с техникой in-memory execution: код загружался и выполнялся исключительно в памяти, не оставляя отдельного файла на диске. Маяк был хорошо модифицирован, поэтому сигнатурные средства его не обнаружили. Связь он устанавливал с новым сервером C&C, который еще не успел попасть ни в одну репутационную базу. Обнаружили это не с помощью антивируса и не с помощью DPI, а через простой анализ сессий по периодичности, размеру и продолжительности.

Этот кейс хорошо показывает суть: угрозы в сети часто видны по поведению трафика, даже без расшифровки пакетов.

Привет, Хабр!

На связи Александр Уваров, я ведущий архитектор систем информационной безопасности в «Гарде».

Еще несколько лет назад шифрованный трафик был скорее исключением. Сейчас весь внешний трафик компании идет по зашифрованным каналам. Например, через HTTPS на уровне приложений или VPN на уровне сети. Внутри корпоративной сети, по нашим оценкам, зашифровано 70–80% трафика. Пользователям это удобно и безопасно, а для ИБ-команд это означает, что анализировать содержимое трафика напрямую уже не представляется возможным.

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

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

Хорошая новость — зашифрованный трафик оставляет след. На каждом этапе атаки в сетевом трафике появляется узнаваемый паттерн, который видно в метаданных сессий даже без расшифровки. Всё потому, что там есть незашифрованная часть: IP-адреса, порты, домены, время запросов, объем переданных данных. По этим метрикам можно строить детектирующие правила, которые покажут атаку независимо от того, какой инструмент использует злоумышленник.

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

Почему сигнатуры видят не всё?

Хочу начать с ответа на самый популярный вопрос многих заказчиков: «Зачем нужна вся эта ваша поведенческая аналитика, когда есть сигнатурный анализ?»

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

С шифрованием ситуация еще сложнее. Payload HTTPS-сессии закрыт, и строковые правила с хешами к нему вообще неприменимы. Понимая это, злоумышленники меняют User-Agent, ротируют домены через CDN, прячут C2 за легитимными сервисами или используют DGA (Domain Generation Algorithm).

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

Далее я это подробно продемонстрирую. 

Этап 1. Разведка

Перед атакой злоумышленник изучает инфраструктуру: какие хосты активны, какие сервисы открыты, какие версии ПО используются. Сканирование может варьироваться от простых пингов (ICMP-запросов) до детального анализа, который выявляет конкретное ПО и его версии. По результатам этого анализа злоумышленник подбирает инструменты для следующего этапа атаки. Это может быть быстрое автоматизированное сканирование или медленный перебор, растянутый на дни.

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

ML-прогнозирование — это когда алгоритм сам учится находить закономерности в сетевых сессиях, а затем использует их, чтобы предсказывать значения и показывать отклонения. В этом случае будет определяться всплеск относительно прогнозного значения при обращении к портам получателя, которых ранее в сессиях не было.

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

• короткая продолжительность сессии — автоматизированные запросы без длительного соединения;

• небольшой размер сессии — тестовые запросы без передачи данных;

• порт назначения;

• направление трафика «внешний → внутренний».

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

Еще один паттерн, который тоже часто вызывает ложные срабатывания при мониторинге — ICMP. NDR обязательно реагирует на ICMP-туннели, но не всегда их появление означает атаку.

У нас был такой случай: туннель строился не от зараженного компьютера к серверу хакера, а между обычным терминальным сервером и корпоративным DNS. В моменты пиковой нагрузки DNS-сервер начинал отвечать с задержкой 5–10 секунд. Клиент переставал ждать, закрывал соединение и отправлял запрос заново. Когда сервер наконец отправлял запоздалый ответ, клиент его уже не ждал, и по RFC 792 был обязан вернуть ICMP Destination Unreachable, упаковав внутрь кусок исходного пакета. Такая «матрешка» технически является туннелем, поэтому система на нее и реагировала. Аналитикам приходилось тратить время на разбор сработки, в то время как настоящая подозрительная ICMP-активность могла затеряться. Однако отключать такие алерты не стоит, лучше разобраться с причиной. Чаще всего она указывает не на атаку, а на проблемы с производительностью DNS или других сервисов, которые тоже нужно чинить.

Этап 2. Первичное проникновение 

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

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

Характерные метрики для детекта перебора паролей:

• протокол SSH или порт 22;

• небольшой объем сессии — неудачная авторизация имеет характерный размер;

• короткая продолжительность сессии (менее 5 минут);

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

Конкретные пороги можно калибровать под инфраструктуру вручную или же использовать ML-прогнозирование. Модель сама будет выявлять все всплески трафика по протоколам FTP, RDP, HTTP/S, SMTP, LDAP, брутфорс которых выглядит похоже.

SSH здесь наиболее типичный случай и был показан мной просто как пример:

Этап 3. Закрепление и развитие 

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

Почему биконинг сложно детектировать?

Детектировать биконинг непросто по двум причинам. Во-первых, атакующие специально усложняют задачу: современные фреймворки добавляют случайное отклонение интервалов (jitter), чтобы трафик выглядел менее регулярно. Во-вторых, похожее поведение есть и у вполне легитимных систем. Не секрет, что в любой инфраструктуре есть периодические взаимодействия по HTTP, DNS, DoH. Если при этом C2 использует DGA-домен, репутационные базы не помогут, так как домен свежий, о нем еще никто не знает. 

В одном из пилотов заказчик был уверен, что у него в трафике всё чисто. У компании были антивирусы последних версий, и мониторинг вроде был настроен. Биконинг обнаружили только через анализ сессий: с одной машины периодически уходили небольшие HTTPS-запросы к адресу, которого не было ни в одном репутационном списке. Командный центр был свежий, о нем никто еще не знал, зато паттерн соединений был характерным:

Как NDR вычисляет маяки, даже когда payload зашифрован?

Поведенческий анализ сессий работает в паре с ML-моделью энтропии. NDR накапливает статистику по периодичности соединений, длительности сессий, объемам данных, направлению, TLS-профилю и доменам, выявляя параметры, характерные для известных инструментов эксплуатации вроде Cobalt Strike или Brute Ratel. 

Модель фиксирует пару «источник → назначение» и смотрит на трафик в нескольких временных окнах сразу, поэтому NDR может обнаружить биконинг, несмотря на все попытки злоумышленников скрыть эту активность. 

Итак, еще раз обобщу признаки, по которым можно определить биконинг:

• направление «внутренний → внешний»;

• протоколы SSL/HTTPS или порт 443;

• короткая продолжительность сессии (например, меньше 10 минут);

• небольшой характерный размер сессии;

• регулярные запросы с одного хоста к одному адресу с характерным интервалом.

Справедливости ради, чтобы определить, связана ли наблюдаемая активность с действиями злоумышленника или это обычная работа легитимной системы с идентичным поведением, одного лишь поведенческого анализа недостаточно. Здесь нужны точные исключения: конкретный сервис, направление, владелец системы. При этом NDR не заменяет endpoint-расследование — он дает список машин, с которых стоит начать анализ. А дальше все равно требуется проверка подозрительных хостов endpoint-средствами: журналы процессов, автозапуск, сетевые соединения, история PowerShell, scheduled tasks, браузерные расширения и прокси-логи.

Этап 4. Достижение цели 

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

Основные метрики для детектирования эксфильтрации будут следующие:

1. Направление трафика «внутренний → внешний».

2. Протоколы Dropbox, Google Drive и аналогичные или атрибут http_host для менее известных хранилищ.

3. Порог по суммарному объему трафика.

Далее хочется поговорить подробнее про ситуацию, когда злоумышленник использует те же внешние сервисы, что и сотрудники компании (Dropbox, Google Drive, OneDrive). Трафик к подобным ресурсам выглядит легитимным, и атакующий просто добавляется к этому потоку и растворяется в нем. Обнаружить такую вредоносную активность можно двумя способами. 

Во-первых, по объему передаваемой информации. Например, если в течение 15 минут от одного источника (IP-адреса отправителя) будут зафиксированы сетевые транзакции к внешним ресурсам суммарным размером сессий более 100 МБ, то это может считаться аномальным всплеском:

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

От сигнатур к поведенческому анализу 

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

Сигнатурный анализ смотрит на содержимое пакетов, которое за TLS не видно.

Поведенческий анализ смотрит не на то, что передается, а на то, как ведут себя соединения: периодичность, объем, направление, TLS-профиль, поведение хоста. Правда, поведенческий анализ сам по себе тоже может давать ложные срабатывания, особенно когда атака намеренно мимикрирует под легитимную активность. Для таких случаев в NDR есть кластеризация. Хосты со схожим сетевым поведением автоматически группируются, и если устройство начинает вести себя нетипично для своего кластера, система фиксирует аномалию. Это особенно важно для обнаружения горизонтального перемещения.

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