Привет, Хабр! В прошлой статье мы делали обзор на opensource NTA – Arkime, здесь мы продолжим развивать NTA для безопасника и поговорим об анализе файлов в сетевом трафике.  Текущая статья будет своего рода обзором - инструкцией по развитию системы.

“Из коробки” Arkime может в YARA, но в таком случае анализ файлов будет на мощностях нод захвата со всеми вытекающими последствиями (увеличение потока трафика потребует СУЩЕСТВЕННОГО увеличения мощности ноды). Чтобы переложить нагрузку с “больной головы” на “здоровую” мы решили прикрутить Strelka.

Strelka

Итак, что же такое Strelka? Как заявляет комьюнити - это энтерпрайз решение для статического анализа и поиска файлов по YARA правилами (и не только) в режиме реального времени. Архитектурно представляет клиент-серверное приложение (понятное дело, требует установки агентов). Агенты написаны на Go Lang, что предоставляет возможность кроссплатформенной установки. Наглядный usecase - поиск вредоносного файла, который обошел антивирусы, но при этом был обнаружен командой кибербеза. На файл написали YARA сигнатуру и запустили поиск по всем агентам в инфраструктуре. Подобный кейс рассмотрим чуть дальше в статье.

К сожалению, о Strelka мало кто знает и использует в СНГ. Разумеется, в этом нет ничего удивительного - как правило, такие функции возлагают на вышеупомянутые коммерческие решения (антивирусы, EDR и пр.), используют самописное, либо вовсе не задумываются о таких задачах.

Изначально Strelka задумывалась как решение для поиска и анализа файлов по запросу, в том числе и анализ файлов на сетевом потоке IDS/IPS сенсорах, полученных из трафика. Именно такой функционал нам и нужен в рамках развития нашего NTA – Arkime.

Из однозначно приятных дополнительных возможностей - отправка файлов в песок для  динамического анализа (из коробки реализована только интеграция с Cuckoo sandbox, но есть возможность прикрутить любой другой, если вы умеете в Python). Используя такую интеграцию можно получить песок для всех передаваемых по сети файлов.

Архитектура Strelka достаточно гибкая и позволяет развернуть как маленькую инсталяцию для тестов, так и распределенную инсталяцию для кровавого энтерпрайза (реализация любого взаимодействия серверов и агентов).

В чем профит?

Возникает вполне логичный вопрос - зачем вовсе анализировать файлы на сетевом потоке, когда есть EDR/антивирус и прочие СЗИ с аналогичным функционалом (даже если 146% покрытие инфраструктуры указанными тулами)?

Отвечу списком, который раскрою подробнее:

1. Любой вредонос может бесследно исчезнуть на эндпоинтах до его обнаружения, но не из трафика, который захвачен NTA;

2. Точное понимание откуда, куда и когда передавался файл;

3. Модифицировался ли файл при передаче от одного узла к другому;

4. Обнаружение Lateral Movement (в дальнейшем просто latmov);

5. Передача файла с машины, которая вошла в 0,00001% без покрытия СЗИ (или вовсе не доменной);

6. Автоматизация и упрощение рутинных задач Detection Engineering’а (удобно скармливать файл стрелке и большинство полезной информации удобно (почти) раскладывается в JSON’e, отправляется в песочницы и куда только захотите).

Резюмируя, все эти пункты можно свести к следующему профиту:

• Сокращение времени расследования инцидентов;

• Увеличение видимости инфраструктуры для безопасника;

• Насыщение контекста инцидентов;

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

Плюсов не мало, однако есть очень важный нюанс, в случае анализа файлов на трафике, они должны быть переданы НЕшифрованным каналом (например, если файл передавался по RDP или по кастомному шифрованному протоколу - разумеется, он не будет проанализирован). В копилку минусов можно так же отнести отсутствие в логах Strelka айпишников, откуда файл был выдернут, НО! с помощью logstash обогатить такие данные.

Предварительная настройка ноды захвата

Для того, чтобы анализировать файлы, их сначала надо откуда-то получить. В прошлой статье мы упоминали, что Arkime сам по себе не выдергивает файлы из трафика (но индексирует их имена).  Кроме самого Arkime, на ноде захвата установлена Suricata. Именно с ее помощью мы хотели получать файлы. Однако, столкнулись с тем, что Suricata не особо адекватно выдирает файлы из трафика из-за особенностей пересбора сессии. Более эффективным вариантом будет Zeek (ранее Bro) с настройки на экстракт файлов.

Для этого стоит начать с установки самого Zeek, но мы надеемся, что с эти проблем у вас не будет =). После стандартной настройки (выбор портов для прослушки и т.д.), необходимо написать скрипт на языке самого Zeek (смесь Lua). Такой скрипт есть "из коробки", но он будет собирать все файлы подряд и изначально выключен.

Сам Zeek устроен достаточно хитро и подразумевает внутри себя целую программируемую  платформу, которая может делать все что вы захотите, при наличии прямых рук. Для включения скрипта нам нужно “загрузить” его в основной скрипт запуска Zeek. В случае использования standalone инсталяции, достаточно внести директиву “@load <имя модуля>”  в файл “префикс_корня_zeek/share/zeek/site/local.zeek”.

С точки зрения загрузчика - пути к модулями начинаются из папки share и share/policy, и идеологически - каждый модуль находится в своей папке. Дефолтный крипт выгрузки всех файлов является частью стандартного модуля FileAnalysis,  и находится по пути “frameworks/files/extract-all-files”. Как уже было сказано выше, скрипт будет выдирать все подряд, чего мы хотим избежать. Для этого мы своровали вдохновились более точечной вариацией от Security Onion Solutions, где предварительно создан словарь с mime типами файлов и их расширениями. Так как данный скрипт генерируется при установке самого SOS, мы переопределим свои типы и используем их.

Для того чтобы скрипт стал “модулем”, который мы будем использовать, переместим его в папку (для сохранения истоков - share/policy/securityonion/file-extract/) и создадим файл “__load__.zeek” (по аналогии __init__.py в Python модулях), в которой добавим директиву  “@load ./extract”. Соответственно, сам скрипт будет называть extract.zeek и в него мы добавим следующее: 

redef FileExtract::prefix = "<путь к папке с вырезанными файлами>";

# Set a limit to the file size

redef FileExtract::default_limit = 9000000; # максимальный размер файл для вырезки

# These are the mimetypes we want to rip off the networks

export {

    global _mime_whitelist: table[string] of string = {

   [“application/x-dosexec”] = “exe”,

  # Здесь можно описывать другие типы

} &default = “”;

# Start grabbing the file from the network if it matches the mimetype

event file_sniff(f: fa_file, meta: fa_metadata) &priority=10 {

    local ext = "";

    if( meta?$mime_type ) {

    if ( meta$mime_type !in _mime_whitelist ) {

          return;

    }

    ext = _mime_whitelist[meta$mime_type];

    local fname = fmt("%s-%s.%s", f$source, f$id, ext);

    Files::add_analyzer(f, Files::ANALYZER_EXTRACT, [$extract_filename=fname]);

        }

}

# Wait for file_state_remove before you do anything. This is when it is actually done.

event file_state_remove(f: fa_file)

        {

        if ( !f$info?$extracted || FileExtract::prefix == "" ) {

                return;

        }

        # Check if any of the following conditions exist:

        # - missing MD5

        # - total_bytes exists (some protocols aren't populating this field) but is 0

        # - missing bytes

        # - timed out

        if ( !f$info?$md5 || (f?$total_bytes && f$total_bytes == 0) || f$missing_bytes > 0 || f$info$timedout) {

          # Delete the file if it didn't pass our requirements check.

          local nuke = fmt("rm %s/%s", FileExtract::prefix, f$info$extracted);

          when [nuke] ( local nukeit = Exec::run([$cmd=nuke]) )

                    {

                    }

                    return;

        }

        local orig = f$info$extracted;

        local split_orig = split_string(f$info$extracted, /\./);

        local extension = split_orig[|split_orig|-1];

        local dest = fmt("%scomplete/%s-%s-%s.%s", FileExtract::prefix, f$source, f$id, f$info$md5, extension);

        # Copy it to the $prefix/complete folder then delete it. I got some weird results with moving when it came to watchdog in python.

        local cmd = fmt("cp %s/%s %s && rm %s/%s", FileExtract::prefix, orig, dest, FileExtract::prefix, orig);

      when [cmd] ( local result = Exec::run([$cmd=cmd]) )

                {

                }

      f$info$extracted = dest;

        }

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

Перейдем к деплою и настройке Strelka.

Деплоймент Strelka

В рамках этой статьи мы выбрали самый простой варинат деплоя - инсталяция всех компонентов в одном экземпляре с помощью docker compose (1 сервер - 1 агент). В большой инсталяции количество сервисов увеличивается по необходимости, а для роутинга и балансировки gRPC запросов используется Envoy. Проще говоря - больше нагрузка, больше сервисов.

Разберем, что в космической собаке зарыто:

• Strelka-frontend принимает входящие запросы от клиентов по gRPC.

• Strelka-backend  обрабатывает входящие файлы.

• Strelka-manager  смотрит в Redis.

• Coordinator – Redis сервер, координирующий задачи на анализ и данные между frontend и backend.

• Gatekeeper – Redis сервер, реализующий временный кэш из событий.

• Mmrpc - опциональный сервис на базе проекта MaliciousMacroBot, и включающий сканер ScanMmbot

Перейдем к самой установке (далее мы просто копируем из официального гита Strelka):

1. Копируем репозиторий и заходим в него
   git clone https://github.com/target/strelka.git && \

   cd strelka

2. Удаляем тестовый файл с yara правилами и качаем правила из Yara-Rules. Стоит отметить, что в Yara-Rules идет в комплекте файл index.yar, который включает в себя все остальные. Его же мы инклюдим в файл configs/python/backend/yara/rules.yara. Вы можете использовать другие правила или использовать свои собственные

   rm configs/python/backend/yara/rules.yara && \

   git clone https://github.com/Yara-Rules/rules.git configs/python/backend/yara/rules/ && \

   echo 'include "./rules/index.yar"' > configs/python/backend/yara/rules.yara

3. Билдим образа докера и поднимаем их, а также собираем один из клиентов - strelka-oneshot.

   docker-compose -f build/docker-compose.yaml build && \

   docker-compose -f build/docker-compose.yaml up -d && \

   go build github.com/target/strelka/src/go/cmd/strelka-oneshot

4. Берем любой пример вредоносного ПО (в примере от самой Strelka решили выбрать Emotet, находящийся в запароленном архиве) и скармливаем его нашей собаке:

./strelka-oneshot -f samples/Win32.Emotet.zip -l - | jq

Вывод будет представлять собой 2 JSON документа, которые с помощью jq будут адекватно отображены. Так как мы скармливаем архив, Strelka автоматом обрабатывает и вложенные файлы.

Как же именно strelka понимает, что за файл перед ней? С помощью пачки yara правил из файлика taste.yara, а с помощью файла конфигурации backend.yaml, будут выбраны сканеры, которые и проанализируют файлы. Все файлы конфигурации всех сервисов нашей собаки лежат в папке configs/<язык сервиса(go или python)>, как и примеры конфигураций для клиентов.

Интеграция Zeek <> Strelka

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

go build github.com/target/strelka/src/go/cmd/strelka-filestream

Обработанные файлы он будет перекладывать в другую папку, чтобы необработанные и обработанные не пересекались:

conn:
  server: '<адрес frontend>:57314'

  cert: 'ssl при наличии'

  timeout:

    dial: 5s

    file: 1m

throughput:

  concurrency: 8

  chunk: 32768

  delay: 0s

files:

  patterns:

    - '<папка с файлами от Zeek>/*'

  processed: '<любая директория, где будут храниться обработанные файлы>'

  delete: false ## Удалить ли файлы, после их отпраки на анализ

  gatekeeper: true

response:

  report: 5s

delta: 5s

staging: '/path/to/your/staging/directory/'  ## Директория, в которую файлы перемещаются ПЕРЕД отправкой

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

Также напишем простенький systemd юнит для “правильного” (по мнению бОльшего представительства линуксойдов) запуска strelka-filestream:

[Unit] 

Description=Strelka Filestream Binary 

After=network.target

[Service] Type=simple 

Restart=always 

RestartSec=5 

ExecStart=/usr/bin/strelka-filestream-linux -c /etc/strelka/filestream.yaml

[Install] 

WantedBy=multi-user.target

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

Настройка доставки логов для анализа 

Самое НЕинтересное - доставка логов в ELK, именно на этом этапе мы потратили больше всего времени. Схема JSON документов по результатам анализа файлов нам показалась невероятно монструозной, поэтому выделили самое интересное и основное ниже (документация на схему JSON отсутствует на момент выхода статьи):

{   “file”: …   “scan”: {

           “<название сканера или краткое определение>”: { <пачка объектов (с вложенными объектами), с информации от сканера> } 

     }}

И выглядит все оно конечно просто и понятно, но как только вы сами закинете тестовый Emotet на анализ, вы увидите “немного” больше, чем показывают в примере. Тут по плану должен был быть пример лога, но в нем более 9к строк, поэтому прикладываем только отрывок под скрытый текст.

Самое страшное здесь - секции с импортируемыми функциями из PE заголовков, полная meta информация по yara правилам и массив из информации об энтропии каждой секции исполняемого файла (не пугайтесь, если вы ничего не поняли - мы тоже ничего не поняли).

Нам очень хотелось слать всю информацию о сработках yara правил в Elasticsearch и в дальнейшем использовать в визуализациях, или даже написать правила в Elastic Security.

Но к нашему сожалению - meta данные по yara правилам - массив из несвязанных объектов, поэтому пришлось воспользоваться Vector и написать парсер на VRL, так как писать все это на Painless Script - полное безумие (попробуйте сами).

Анализ

Результатом обработки файлов является лог-файл на ноде захвата и для его последующего анализа требуется его куда-то забирать и визуализировать. Для этого мы решили использовать filebeat + ELK stack (теоретически, можно складывать в ELK Arkime, к которому прикручена Kibana/opensearch, но мы складываем в отдельную инсталяцию). Пример лога в ELK для тестового EICAR файла (мы используем yara правила от Elastic - можно глянуть тут): 

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

Пару скринов ниже покажут пример анализа internal monologue:

Однако Strelka вытаскивает еще полезную информацию:

• Тип файла (из заголовка)

• URL’ы в файлах

• Импортируемые функции из библиотек 

Послесловие

Strelka не единственная в своем роде - коллеги по цеху из Канады разрабатывают AssemblyLine - концептуально похожий проект со Strelka.

Авторы текста:
Тыщенко Иван, tg:@nerebros

Дьячков Иван, tg: @Roosevelt_Rus