[Перевод] Иголка в стоге сена: ищем следы работы C2-фреймворка Sliver
Привет, Хабр, на связи лаборатория кибербезопасности компании AP Security! Не так давно на нашем канале вышла статья по использованию фреймворка постэксплуатации Sliver C2 от Bishop Fox.
Сегодня мы представляем вам исследование компании Immersive Labs по детектированию и анализу нагрузок и туннелей взаимодействия Sliver.
Этот С2 всё сильнее набирает популярность, а значит специалисты по реагированию на инциденты должны быть всегда готовы столкнуться лицом к лицу с новыми техниками и инструментами. Приятного прочтения!
Sliver C2 представляет собой кроссплатформенный расширяемый фреймворк постэксплуатации, созданный командой Bishop Fox. Он написан преимущественно на языке Go, что делает его быстрым, переносимым и легко настраиваемым. Такая универсальность делает инструмент популярным в Red Team проектах.
Фреймворк Sliver C2 обладает возможностями, рассчитанными как на начинающих, так и на опытных пользователей. Одной из его особенностей является возможность генерировать динамические пэйлоады под разные ОС.
Что касается коммуникаций, то Sliver поддерживает широкий спектр протоколов, включая HTTP, HTTPS, DNS, TCP и WireGuard. Это обеспечивает гибкость и скрытность, а также возможность маскировки канала C2 под легитимный сетевой трафик.
Более подробно об использовании Sliver можно прочитать в нашей статье Sliver C2: Подробный туториал.
Одним словом, Sliver C2 в последнее время серьезно набирает популярность. Ниже приведена диаграмма использования различных фреймворков постэксплуатации в последние месяцы.
Threat hunting
Из-за роста популярности данного фреймворка, хакеры и пентестеры всё чаще используют его при проведении атак на инфраструктуру. Именно поэтому специалистам по реагированию на инциденты, участникам Blue Team и инженерам SOC важно знать методы обнаружения Sliver по различным артефактам в файловой системе, оперативной памяти и сетевом трафике.
В данном отчете подробно описываются технические методы обнаружения, которые можно использовать для выявления использования Sliver.
Целевая инфраструктура
Для захвата трафика и сбора артефактов, а в дальнейшем анализа маячков фреймворка был создан небольшой тестовый полигон, предназначенный для тестирования средств обнаружения и сбора логов. При этом наша микроинфраструтура должна была включать возможности EDR.
Endpoint Detection and Response (EDR) — продвинутая система безопасности, представляющая собой интегрированное решение для обеспечения безопасности конечных точек от потенциальных угроз. Технология сочетает в себе непрерывный мониторинг и сбор данных о хостах в режиме реального времени и решает проблему постоянного мониторинга и реагирования на сложные угрозы.
Полигон состоял из следующих основных элементов:
Хост-машина, которую мы контролировали для установки имплантата
Регистрация событий
Sysmon
Splunk
Ведение сетевого журнала
EDR
Velociraptor
Сброс/восстановление
Инфраструктура злоумышленника
После развертывания целевой инфраструктуры пора заняться развертыванием C2 сервера Sliver. В данном случае все было просто: всего лишь одна VPS на «белом» IP-адресе, что позволило легко открыть необходимые порты TCP, HTTP/S и DNS для диапазона.
Можно было бы развернуть C2 во внутренней сети, однако в этом случае у него был бы внутренний IP-адрес. Поэтому для большей реалистичности использовался отдельный сервер для инфраструктуры злоумышленника.
DNS
Для DNS была выбрана конфигурация Cloudflare, которая позволила установить DNS записи, необходимые для HTTP/S C2, и создать запись nameserver для C2 без необходимости использования нескольких доменов.
В данной конфигурации используются настройки по умолчанию, приведенные в wiki BishopFix по установке и настройке DNS.
Сервер Sliver C2
В данном исследовании не рассматривалась возможность использования фреймворка Sliver, поэтому было решено сделать подключение к серверу напрямую, а не использовать многопользовательский режим, который позволяет нескольким операторам управлять C2. Более традиционное развертывание выглядит следующим образом.
В конфигурации вместо удаленных операторов был использован прямой консольный доступ к серверу C2.
Установка
Так как Sliver написан на GoLang, его установка предельно проста. Достаточно скачать необходимый исполняемый файл, дать ему права на выполнение и запустить.
Запустив сервер Sliver C2, были также запущены локальные listeners для HTTP и DNS.
Настройка
Теперь, когда listeners запущены, необходимо создать маячки для отправки на хосты, чтобы инициировать первоначальную компрометацию.
Доставка
В данном исследовании нас не интересуют продвинутые механизмы доставки. Поэтому для передачи полезной нагрузки клиенту использовалась простая команда python3 -m http.server на хосте Sliver и команду PowerShell iwr на целевом хосте.
Анализ
Итак, инфраструктура развернута, все средства настроены, нагрузка доставлена. Пришло время приступить к анализу. Маячки могут быть обфусцированы и модифицированы с помощью различных техник — их слишком много, чтобы описывать их в исследовании. В данном отчете представлены некоторые базовые методы обнаружения бинарных файлов, но основное внимание уделяется обнаружению имплантата в памяти или по протоколам C2.
Нагрузка
Пэйлоад был сгенерирован в виде скомпилированного двоичного файла на языке Go. Это делает его легко портируемым под разные ОС и архитектуры. Однако, из-за статической линковки средний размер файла составляет 16 Мб, а это далеко не маленькая цифра для полезной нагрузки C2. Для решения этой проблемы Sliver поддерживает использование других фреймворков и инструментов, таких как Metasploit, для создания более компактных совместимых нагрузок.
Обнаружение в памяти облегчается, поскольку весь двоичный файл Go должен быть распакован в память независимо от упаковки двоичного файла или поэтапной доставки.
Yara Rules для обнаружения исполняемого файла
Простое правило Yara использовалось для обнаружения немодифицированного импланта Sliver, созданного для Windows, Linux или MacOS.
Yara Rules для обнаружения нагрузки в памяти
Это правило предназначено для обнаружения Sliver, работающего в памяти; приведенное выше Yara правило не подходит для обнаружения в оперативной памяти, поскольку использует некоторые фиксированные смещения для уменьшения количества ложных срабатываний при сканировании файлов.
Command & Control
Sliver имеет четыре основных протокола взаимодействия:
DNS
При обмене данными через DNS маячок Sliver кодирует свои сообщения в запросы и ответы поддоменов. Практически, этот принцип ничем не отличается от стандартных методов DNS туннелирования.
Однако, Sliver отличается от большинства C2 тем, как упаковываются и кодируются данные, что позволяет передать гораздо больший объем данных в одном запросе.
Структура
Так как DNS не ориентирован на создание соединения, Sliver необходим способ отслеживания последовательности данных в закодированных пакетах. Для этого он использует protobuff.
Protocol Buffers (Protobuf) — это формат сериализации данных, разработанный компанией Google. Он эффективно и компактно хранит структурированные данные в двоичной форме, что позволяет быстрее передавать их по сети. Protobuf поддерживает широкий спектр выбранных языков программирования и является платформонезависимым, что означает, что программы, написанные с его использованием, могут быть легко перенесены на другие платформы.
Кодирование
После того как сообщение упаковано в protobuf, его необходимо закодировать в строку поддомена. По умолчанию используется кодировка Base58 с возможностью перехода на Base32.
Для дополнительной маскировки Sliver также использует слегка измененные алфавиты для кодировки Base32 и Base58.
Обнаружение
Поскольку зашифрованная нагрузка ограничена 254 символами на поддомен, а количество символов в одном запросе ограничено, сервера C2 и маячки, использующие DNS, генерируют значительный трафик, сильно превышающий объем трафика других протоколов. Это может позволить легко обнаружить такой канал, если в инфраструктуре регистрируется DNS-трафик.
Ниже приведены примеры обнаружения DNS туннеля с помощью Kibana. Здесь показан счетчик событий после отправки 3–4 команд с С2 за 5 минут.
Kibana — программная панель визуализации данных, использующая Elastic. Kibana используется для мониторинга и анализа ИТ-инфраструктуры в составе Elastic Stack, в который помимо нее входят Elasticsearch и Logstash.
HTTP (S)
Протокол взаимодействия идентичен для HTTP и HTTPS. Единственным отличием является использование шифрования, что требуется перехват TLS или ведение сетевого журнала на хосте с помощью Zeek или PacketBeat.
Важно отметить, что настройка параметров протокола HTTP в Sliver является весьма гибкой, и приведенная в исследовании информация относится к настройкам по умолчанию.
Структура
Sliver использует расширения файлов для определения типа запроса
.woff — Используется для стейджеров
.html — Обмен ключами
.js — Сообщения длинного опроса
.php — Сессионные сообщения
.png — Сообщения о закрытии сессии
Для каждого запроса создается случайный путь, который игнорируется и не имеет отношения ни к сообщению, ни к запросу. Однако существует фиксированное количество путей и имен файлов по умолчанию, что позволяет создавать некоторые типовые правила обнаружения.
Стоит еще раз отметить, что все эти параметры могут быть дополнительно сконфигурированы оператором C2.
Кодирование
Сообщения кодируются следующими методами:
Кодер выбирается случайным образом при каждой отправке нового сообщения. Используемый кодер кодируется как значение nonce и добавляется в качестве параметра запроса к каждому HTTP-запросу. Например, по следующему URL-адресу можно легко определить, какой кодер используется, с помощью небольшого количества кода на языке Python.
На выходе получим encoder_id, равный 13. По таблице определяем, что использовался base64 с «кастомным» алфавитом.
Ниже приведены измененные алфавиты для кодировок Base32, 58, 64
Кодировка английскими словами
В качестве механизма кодирования в данном методе используются списки английских слов. Сами же слова при этом «захардкожены» в нагрузке, всего их 1420.
Сами по себе слова не важны, для кодирования и декодирования используется позиция в списке или сумма символов в слове. Пример декодера, написанного на языке Python, приведен ниже.
Обнаружение
Если маячок настроен на использование HTTP или у вас есть возможность TLS-перехвата на прокси-сервере или пограничном маршрутизаторе, то эти для обнаружения туннеля Sliver можно использовать следующие правила для Snort.
Если собрать сетевые журналы с узлов инфраструктуры с помощью анализатора вроде Zeek или Packet Beat, то в журналах событий можно обнаружить те же закономерности.
Шифрование
Процесс шифрования канала достаточно неплохо описан в официальной документации на GitHub. Здесь мы не будем рассматривать все детали, а лишь скажем, что каждое сообщение шифруется индивидуально с использованием сеансового ключа, генерируемого нагрузкой при каждом отдельном запуске.
Сеансовые ключи
Сеансовый ключ в защищенном виде передается на C2 сервер Sliver. Однако если вы сможете извлечь ключ из памяти процесса Sliver, то сможете расшифровать любой перехваченный сетевой трафик, как и в случае с любым другим фреймворком постэксплуатации.
Чтобы найти ключ шифрования в памяти, необходимо в первую очередь выяснить, как он выглядит и существует ли он где-то в структуре данных, которую можно разобрать. Самый простой способ сделать это — узнать ключ и затем искать его в памяти.
Этого оказалось достаточно просто добиться. Поскольку Sliver имеет открытый исходный код, мы взяли копию исходного кода и модифицировали его так, чтобы он выдавал сеансовые ключи в открытом виде.
После внесения изменений в код мы смогли скомпилировать новую версию C2 сервера и запустить ее на нашей инфраструктуре злоумышленника.
После этого, когда маячок подключался обратно, мы получали сеансовый ключ в открытом виде.
Память процесса
Далее необходимо было определить процесс под которым запущен маячок. Это довольно просто сделать, Velociraptor и ранее созданное Yara-правило.
Запускаем сканирование и через некоторое время получаем дамп вредоносного процесса.
В качестве альтернативы, если вы знаете имя или PID процесса, можно воспользоваться стандартной утилитой procdump из пакета Sysinternals.
После получения дампа памяти процесса, попробуем найти в нем ключ шифрования.
Извлечение ключей
Используя ключи, полученные на C2 сервере Sliver после подключения маячка, был просканирован дамп процесса с целью найти их.
Хорошая новость заключается в том, что ключ всегда можно найти в памяти активного процесса. Плохая же заключается в том, что он не находится в фиксированном месте, а значит будет затруднительно прочитать это значение.
Запуск одного и того же процесса позволил выявить закономерность.
Весь процесс поиска закономерности состоял из следующих этапов:
Остановить запущенный процесс
Запустить процесс
Послать с сервера несколько команд на маячок
Подождать 1–2 минуты
Получить дамп процесса
Найти ключ, который отображается для каждой сессии
Перейти к 1-му шагу
Таким образом был найден паттерн
**00 00 [32 bytes key] ?? ?? ?? 00 C0 00 00**
Сканирование памяти по этому шаблону давало несколько тысяч результатов — 17 206 совпадений шаблонов для данного каждого захвата памяти. Однако быстрая проверка показала, что ключ находится в этом наборе совпадений.
В идеале нужно было уменьшить это число. Если бы количество результатов было достаточно мало, можно было бы перебрать ключ, получив зашифрованную нагрузку. Как же уменьшить количество результатов?
Сам сеансовый ключ получается из хэша SHA256 случайных байтов. Было выдвинуто предположение, что в любом сеансовом ключе не будет серии из трех последовательных байтов 0×00, и смогли сократить этот список всего до 38 возможных ключей.
Не исключено, что сеансовый ключ может содержать последовательность из нескольких нулевых байтов, но вероятность этого крайне мала. Чтобы доказать это, был написан небольшой скрипт, который генерировал 10 млн. случайных значений SHA256 и затем проверял их на наличие возможных цепочек нулевых байтов.
Как видно из 30 миллионов сгенерированных значений SHA256, вероятность появления трех или четырех последовательных нулевых байтов составляет 0,0004%.
Расшифровка трафика
Если бы возможно было перехватить трафик с помощью сниффера, перехвата журналов DNS или даже извлечения фрагментов из памяти процессов, то информации для расшифровки было бы достаточно.
Все инструменты и скрипты, используемые для разбора PCAP-файлов и расшифровки трафика, были опубликованы в репозитории Immersive Labs.
DNS туннели
Журналы DNS, пожалуй, проще всего собирать либо из файлов PCAP, либо из журналов событий и SIEM.
Используя скрипт sliver_pcap_parser.py из репозитория GitHub, было указано доменное имя, и скрипт извлек все возможные закодированные значения, готовые для следующего шага — расшифровки.
HTTP туннели
Этот же скрипт может анализировать HTTP-запросы и ответы на предмет возможной закодированной нагрузки. Полезная нагрузка HTTP записывается в JSON-файл, содержащий все необходимые поля для обработки сценарием расшифровки.
Память процесса
В зависимости от времени, прошедшего с момента наблюдения до получения дампа памяти, в нем могут быть обнаружены части сессии. В репозитории GitHub можно найти Python-скрипт sliver_memdump_parser.py для сканирования дампа процесса на наличие таких фрагментов.
Декодирование и расшифровка
Получив дамп процесса и закодированные части сессии, извлеченные из подходящего источника, была произведена попытка декодировать и расшифровать данные сессии.
Сначала скрипт сканировал дамп памяти процесса на наличие всех возможных ключей сессии, затем проверял каждый ключ, используя предоставленную нагрузку, пока не добивался успешного декодирования.
Данные сообщения представлены в виде структуры protobuf.
Заключение
В последнее время специалисты по реагированию на инциденты всё чаще встречаются с Sliver C2. Методы разбора атак с использованием Sliver во многом схожи с анализом инцидентов, в которых в качестве фреймворка постэксплуатации применялся не менее известный коммерческий Cobalt Strike, однако везде есть свои особенности.
Также стоит упомянуть, что для анализа Cobalt давно существуют целые микролаборатории и наборы скриптов, заточенные именно под него, в то время как под Sliver только начинают появляться инструменты, что существенно усложняет анализ.
