Анализ файлов на сети без смс и регистрации

Привет Хабр! В прошлой статье мы делали обзор на 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% покрытие инфраструктуры указанными тулами)?

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

Любой вредонос может бесследно исчезнуть на эндпоинтах до его обнаружения, но не из трафика, который захвачен NTA;
Точное понимание откуда, куда и когда передавался файл;
Модифицировался ли файл при передаче от одного узла к другому;
Обнаружение Lateral Movement (в дальнейшем просто latmov);
Передача файла с машины, которая вошла в 0,00001% без покрытия СЗИ (или вовсе не доменной);
Автоматизация и упрощение рутинных задач Detection Engineering’а (удобно скармливать файл стрелке и большинство полезной информации удобно (почти) раскладывается в JSON’e, отправляется в песочницы и куда только захотите).

TL;DR подробнее:

Как известно, антивирусы не являются серебряной пулей от всех болезней, да и способов обхода их обнаружения известно не мало. Хороший специалист красной команды (этичный хакер) сможет легко обойти антивирус даже для избитого и отлично известного mimikatz’a. А серьезные ребята из АРТ группировок вовсе стараются не оставлять своих следов. При передаче нешифрованным каналом своего инструментария (например smb или любимым psexec’ом) и последующим его запуском с моментальным удалением, вряд ли удастся получить образец файла на целевой системе, однако он осядет на NTA и будет проанализирован strelka. Из этого можно будет написать детект и отслеживать дальнейшее перемещение файла по сети не только с помощью агентов/антивируса и пр, но и на сети. Хочу отметить, что речь идет не о первичном обнаружении, а именно о насыщении инцидента важными подробностями, о последующем респонзе и анализе, что в будущем приведет к своевременному первичному обнаружению.
Агенты на устройствах наверняка расскажут о наличии того или иного файла, максимум — подсветят происхождение файла (вспоминаем о Transfer Zone), но едва ли расскажут, откуда появился файл (если только косвенными признаками при анализе логов с хоста, что требует самого ценного ресурса — времени). В случае же анализа Strelk’ой — у вас будет неоспоримое доказательство о дате, источнике передачи точного файла (ведь Strelka считает хэши). Такой подход существенно сокращает время разбора инцидента, а как мы знаем, при активном реагировании, скорость анализа является очень критичным показателем — иногда секунды определят, появится ли новый доменный админ или нет.
Некоторые вирусы могут изменять свою структуру с течением времени или иными факторами (разумеется, для избежания обнаружения), но Strelka анализирует все возможные заголовки файлов, в том числе вычисляет imphash и пишет его в лог (imphash — это хэш подключаемых библиотек для исполняемого файла). Кроме imphash для исполняемых файлов записываются: архитектура, для который был написан бинарь, все метаданные исполняемого файла (например версия, цифровая подпись и пр.), ОС, характеристики подключаемых библиотек (их функции) и многие другие заголовки. По таким признакам возможно написать YARA правило (или правило корреляции — ведь логи Strelka отправляются в SIEM), которое будет отслеживать файл, даже если он постоянно изменяется (вы можете справедливо заметить, что в случае продвинутой малвари для избежания обнаружения могут подключаться дополнительные библиотеки для изменения imphash, однако не всегда будут использоваться дополнительные функции новых библиотек).
Вполне вероятно, что latmov может отслеживаться на логах и самой сети, однако как быть, когда злоумышленники используют легитимные для инфраструктуры инструменты (конечно же, что бы усложнить свое обнаружение защитниками)? Профилирование активности админов может не спасти — ведь с точки зрения логов и сети, активность ничем не отличается от действий администратора. Однако именно тут на помощь приходит Strelka — в случае передачи своих инструментов по сети (а как иначе?), они будут проанализированы. Согласитесь, что администраторы не используют хактулы и малварь при осуществлении ежедневных обязанностей?
Идеальных инфраструктур не существует. Наверняка даже в крупнейших банках мира найдется 1 машина, на которой нет СЗИ или вне домена, или вовсе является нелегитимно подключенным устройством в сеть (например raspberry pi, включенная в RJ-45 розетку сети ip-телефонии). В таком случае СЗИ смогут обнаружить (ЕСЛИ смогут) только факт появления вредоноса на атакуемой машине, но Strelka точно расскажет, откуда прилетел такой файл. В более зрелых, с точки зрения ИБ, инфраструктурах может быть обнаружен факт подключения в сеть неизвестного устройства, что послужит хорошим поводом для начала расследования — при таком раскладе развития событий, Strelka упростит анализ активности нелегитимного устройства.

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

Сокращение времени расследования инцидентов;
Увеличение видимости инфраструктуры для безопасника;
Насыщение контекста инцидентов;
Дополнительные возможности детекта вредоносной активности в сети.

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

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

!!!Дисклеймер!!!

Мы не претендуем (хотя стремимся к ней) на идеальную конфигурацию Suricata, Zeek, Strelka и тд, а так же на полноту покрытия всех потребностей безопасника. Мы точно знаем, что у нас есть недостатки в конфигах, но мы только начали свой путь и, со временем, мы станем лучше, в том числе, благодаря вашим советам и рекомендациям. “Совет начинающим: начните” (с) Великие цитаты Великих людей =)

Для того, чтобы анализировать файлы, их сначала надо откуда-то получить. В прошлой статье мы упоминали, что 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, где файл будет удален, если во время сбора не были выполнены некоторые требования.

Путь курильщика:

Настройка suricata.yaml:

Чтобы научить сурка сохранять файлы, необходимо добавить следующие строки (из документации самого сурка 1 и 2) в suricata.yaml (оформить код-блоком) :

- eve-log:

enabled: yes

filetype: regular

filename: eve.json

…

types:

…

- files:

force-magic: yes

…

- file-store:

version: 2

enabled: yes

dir: /ваша/директория/

stream-depth: 0

…

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

Все эти директории — первые 2 символа в sha-256 хэше, того файла, который был сохранен. (например, если SHA-256 хэш файла начинается с ”00”, то он будет сохранен в директории 00)
Готово, теперь файлы будут выдергиваться в эту директорию.

Перейдем к деплою и настройке 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):

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

cd strelka
Удаляем тестовый файл с 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
Билдим образа докера и поднимаем их, а также собираем один из клиентов — 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
Берем любой пример вредоносного ПО (в примере от самой 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»: {
«address_of_entry_point»: 1075979,
«base_of_code»: 4096,
«base_of_data»: 1671168,
«checksum»: 8268887,
«compile_time»: «2023-01-20T18:07:04»,
«debug»: {
«age»: 1,
«guid»: «2d00683a-1f90-0e48-8dc7b915b650eec3»,
«pdb»: «D:\a\1\s\exe\Win32\Public_Release\Sysmon.pdb»,
«type»: «rsds»
},
«dll_characteristics»: [
«DYNAMIC_BASE»,
«NX_COMPAT»,
«TERMINAL_SERVER_AWARE»
],
«elapsed»: 1.431875,
«file_alignment»: 512,
«file_info»: {
«company_name»: «Sysinternals — www.sysinternals.com«,
«file_description»: «System activity monitor»,
«file_version»: «14.14»,
«fixed»: {
«operating_systems»: [
«WINDOWS32»
],
«type»: {
«primary»: «UNKNOWN»
}
},
«internal_name»: «System Monitor»,
«legal_copyright»: «By Mark Russinovich and Thomas Garnier\nCopyright (C) 2014-2023 Microsoft Corporation\nUsing libxml2. libxml2 is Copyright (C) 1998-2012 Daniel Veillard. All Rights Reserved.»,
«product_name»: «Sysinternals Sysmon»,
«product_version»: «14.14»,
«var»: {
«character_set»: «Unicode»,
«language»: «U.S. English»
}
},
«flags»: [
«no_certs_found»
],
«header»: {
«machine»: {
«id»: 332,
«type»: «I386»
},
«magic»: {
«dos»: «DOS»,
«image»: «32_BIT»
},
«subsystem»: «WINDOWS_CUI»
},
«image_base»: 4194304,
«image_characteristics»: [
«EXECUTABLE_IMAGE»,
«32BIT_MACHINE»
],
«image_version»: 0,
«imphash»: «22c706ca771a1849826506040b11d50f»,
«linker_version»: 14.34,
«major_image_version»: 0,
«major_linker_version»: 14,
«major_operating_system_version»: 6,
«major_subsystem_version»: 6,
«minor_image_version»: 0,
«minor_linker_version»: 34,
«minor_operating_system_version»: 0,
«minor_subsystem_version»: 0,
«operating_system_version»: 6,
«resources»: [
{
«id»: 1001,
«language»: {
«primary»: «ENGLISH»,
«sub»: «ENGLISH_US»
},
«md5»: «3e725ceddba1b9460f6304986e6248da»,
«sha1»: «8710b02483beac27184dd236209f7d1df864ffe6»,
«sha256»: «d92b848707513894733fe2da0faf7ba7dcfbbb98380d06e07c87521e7fab6bf0»
},
{
«id»: 1002,
«language»: {
«primary»: «ENGLISH»,
«sub»: «ENGLISH_US»
},
«md5»: «01124a558ec6d65f6471456da07ab4ea»,
«sha1»: «743e1c0d0495d334c77132640352208f806aeb54»,
«sha256»: «9681d860e84375b95b3d59006dae41b007bca3824bfe10e0c313b72f68ac178a»
},
{
«id»: 1,
«language»: {
«primary»: «ENGLISH»,
«sub»: «ENGLISH_US»
},
«md5»: «12a95179b2738a3f37060eacad6bd6a3»,
«sha1»: «1197df76d0a31be7a369b13499f1e73c6b6791d0»,
«sha256»: «3d63feefaf94dc719aa83afc9b25dc8ca317a686cdb617e39f4c1548b060a8ed»
},
{
«language»: {
«primary»: «ENGLISH»,
«sub»: «ENGLISH_US»
},
«md5»: «932524ab57ae83176d5596fff967aa52»,
«name»: «SYSMONSCHEMA»,
«sha1»: «691dd0236bc963b1b7528accdba56fee26fce10d»,
«sha256»: «0387426eeb7ea7705c7524e2d6425a7c6fda9923c25650309ae3a6440a0e9971»
},
{
«id»: 1,
«language»: {
«primary»: «ENGLISH»,
«sub»: «ENGLISH_US»
},
«md5»: «bfc1566bfd06c8135ab5c3a2e321ebe7»,
«sha1»: «66bd09bd18c6953d6fcea960431dfb6ddd7f9416»,
«sha256»: «db58c2c74246fa1e1c6c504373332303a511be9072ee5b31796c2a837a922f17»,
«type»: «MESSAGETABLE»
},
{
«id»: 1,
«language»: {
«primary»: «ENGLISH»,
«sub»: «ENGLISH_US»
},
«md5»: «d901d37a441a56585e2878f8f31fd958»,
«sha1»: «0c60e3a7cc4a9c5726767611fd774c5826690438»,
«sha256»: «695d4d08304fd3377908fb02cb58063052223e391b9ed70da067a9bb3725c53e»,
«type»: «VERSION»
},
{
«language»: {
«primary»: «ENGLISH»,
«sub»: «ENGLISH_US»
},
«md5»: «97563aa40292469b3e117adfc66dfcbe»,
«name»: «SYSMONMAN»,
«sha1»: «8c4b4d8d95edc34e21b1723f3badcfaf51ea6dd5»,
«sha256»: «71318e89313c58d15da819be6f89fdc975228cbf82626bfa2c78aa2f28d04ad8»,
«type»: «HTML»
},
{
«id»: 1,
«language»: {
«primary»: «ENGLISH»,
«sub»: «ENGLISH_US»
},
«md5»: «d41d8cd98f00b204e9800998ecf8427e»,
«sha1»: «da39a3ee5e6b4b0d3255bfef95601890afd80709»,
«sha256»: «e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855»,
«type»: «MANIFEST»
}
],
«rich»: {
«clear_data»: {
«data»: «RGFuUwAAAAAAAAAAAAAAAEt4AwETAAAAS3gFAcUAAABPfP0ABAAAAE98BQFWAAAAT3wEARMAAABPfAMBGQAAAEt4BAEZAAAAuHUDAQEAAAC7dQQBCgAAAEt4AQEjAAAAAAABAFIBAADBfAkBPQAAAMF8/wABAAAAAACXAAIAAADBfAIBAQAAAA==»,
«md5»: «fa160a389ccba4f1f5e7ea61c15d319a»
},
«info»: [
{
«count»: 19,
«toolid»: 259,
«version»: 30795
},
{
«count»: 197,
«toolid»: 261,
«version»: 30795
},
{
«count»: 4,
«toolid»: 253,
«version»: 31823
},
{
«count»: 86,
«toolid»: 261,
«version»: 31823
},
{
«count»: 19,
«toolid»: 260,
«version»: 31823
},
{
«count»: 25,
«toolid»: 259,
«version»: 31823
},
{
«count»: 25,
«toolid»: 260,
«version»: 30795
},
{
«count»: 1,
«toolid»: 259,
«version»: 30136
},
{
«count»: 10,
«toolid»: 260,
«version»: 30139
},
{
«count»: 35,
«toolid»: 257,
«version»: 30795
},
{
«count»: 338,
«toolid»: 1,
«version»: 0
},
{
«count»: 61,
«toolid»: 265,
«version»: 31937
},
{
«count»: 1,
«toolid»: 255,
«version»: 31937
},
{
«count»: 2,
«toolid»: 151,
«version»: 0
},
{
«count»: 1,
«toolid»: 258,
«version»: 31937
}
],
«key»: «6220d5e7»,
«raw_data»: {
«data»: «JkG7tGIg1ediINXnYiDV5ylY1uZxINXnKVjQ5qcg1ectXCjnZiDV5y1c0OY0INXnLVzR5nEg1ectXNbmeyDV5ylY0eZ7INXn2lXW5mMg1efZVdHmaCDV5ylY1OZBINXnYiDU5zAh1eejXNzmXyDV56NcKudjINXnYiBC52Ag1eejXNfmYyDV5w==»,
«md5»: «99df8167e636a4e5d03f3a305f56b445»
}
},
«section_alignment»: 4096,
«sections»: [
{
«address»: {
«physical»: 1666038,
«virtual»: 4096
},
«characteristics»: [
«CNT_CODE»,
«MEM_EXECUTE»,
«MEM_READ»
],
«entropy»: 6.636632502553922,
«md5»: «55eac3bed86e853dd7b97ecae392a49c»,
«name»: «.text»,
«sha1»: «d86802270020bf19260c1a0f4c4e46551a9f01d6»,
«sha256»: «7b80a0764abba960a81e444dcc6f5cb3ec8c38c0c4aeb89e518ef40ee0d129d1»,
«size»: 1666048
},
{
«address»: {
«physical»: 786576,
«virtual»: 1671168
},
«characteristics»: [
«CNT_INITIALIZED_DATA»,
«MEM_READ»
],
«entropy»: 4.3805809880051365,
«md5»: «ba57f1bdd64e68192ac99511c004430d»,
«name»: «.rdata»,
«sha1»: «ae67fd775a29fe2e812c04d7fae00fed6cd3f10f»,
«sha256»: «95d49c9c84ddb5bd3fb746000e2be173d51af0a4971d0d2f82a728d769a74778»,
«size»: 786944
},
{
«address»: {
«physical»: 29224,
«virtual»: 2461696
},
«characteristics»: [
«CNT_INITIALIZED_DATA»,
«MEM_READ»,
«MEM_WRITE»
],
«entropy»: 4.474025218651877,
«md5»: «31a647892600452887f8681d5007a2e4»,
«name»: «.data»,
«sha1»: «7b84cf7ccb58aca03a780b60ee731ef458f311d7»,
«sha256»: «6331c1d1e5d08db286a879035ffa9f08f999bf87358938ef184ccaf25fe0b626»,
«size»: 14848
},
{
«address»: {
«physical»: 5686360,
«virtual»: 2494464
},
«characteristics»: [
«CNT_INITIALIZED_DATA»,
«MEM_READ»
],
«entropy»: 1.699918955277781,
«md5»: «bf1b231fd7cebcaf9ce86b18fdcba822»,
«name»: «.rsrc»,
«sha1»: «1e941fdd57610dd433314447b1076f84bad98594»,
«sha256»: «fe21359b2a4ce3fde264344efee4f475b752d192ea1039aad72edf19e764f073»,
«size»: 5686784
},
{
«address»: {
«physical»: 60920,
«virtual»: 8183808
},
«characteristics»: [
«CNT_INITIALIZED_DATA»,
«MEM_DISCARDABLE»,
«MEM_READ»
],
«entropy»: 0,
«md5»: «d41d8cd98f00b204e9800998ecf8427e»,
«name»: «.reloc»,
«sha1»: «da39a3ee5e6b4b0d3255bfef95601890afd80709»,
«sha256»: «e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855»,
«size»: 60928
}
],
«size_of_code»: 1666048,
«size_of_headers»: 1024,
«size_of_heap_commit»: 4096,
«size_of_heap_reserve»: 1048576,
«size_of_image»: 8245248,
«size_of_initialized_data»: 6564352,
«size_of_stack_commit»: 4096,
«size_of_stack_reserve»: 1048576,
«size_of_uninitialized_data»: 0,
«subsystem_version»: 6,
«summary»: {
«resource_md5»: [
«01124a558ec6d65f6471456da07ab4ea»,
«97563aa40292469b3e117adfc66dfcbe»,
«12a95179b2738a3f37060eacad6bd6a3»,
«3e725ceddba1b9460f6304986e6248da»,
«d41d8cd98f00b204e9800998ecf8427e»,
«932524ab57ae83176d5596fff967aa52»,
«d901d37a441a56585e2878f8f31fd958»,
«bfc1566bfd06c8135ab5c3a2e321ebe7»
],
«resource_sha1»: [
«1197df76d0a31be7a369b13499f1e73c6b6791d0»,
«0c60e3a7cc4a9c5726767611fd774c5826690438»,
«691dd0236bc963b1b7528accdba56fee26fce10d»,
«8c4b4d8d95edc34e21b1723f3badcfaf51ea6dd5»,
«743e1c0d0495d334c77132640352208f806aeb54»,
«66bd09bd18c6953d6fcea960431dfb6ddd7f9416»,
«da39a3ee5e6b4b0d3255bfef95601890afd80709»,
«8710b02483beac27184dd236209f7d1df864ffe6»
],
«resource_sha256»: [
«71318e89313c58d15da819be6f89fdc975228cbf82626bfa2c78aa2f28d04ad8»,
«d92b848707513894733fe2da0faf7ba7dcfbbb98380d06e07c87521e7fab6bf0»,
«e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855»,
«3d63feefaf94dc719aa83afc9b25dc8ca317a686cdb617e39f4c1548b060a8ed»,
«db58c2c74246fa1e1c6c504373332303a511be9072ee5b31796c2a837a922f17»,
«0387426eeb7ea7705c7524e2d6425a7c6fda9923c25650309ae3a6440a0e9971»,
«695d4d08304fd3377908fb02cb58063052223e391b9ed70da067a9bb3725c53e»,
«9681d860e84375b95b3d59006dae41b007bca3824bfe10e0c313b72f68ac178a»
],
«section_md5»: [
«55eac3bed86e853dd7b97ecae392a49c»,
«d41d8cd98f00b204e9800998ecf8427e»,
«31a647892600452887f8681d5007a2e4»,
«bf1b231fd7cebcaf9ce86b18fdcba822»,
«ba57f1bdd64e68192ac99511c004430d»
],
«section_sha1»: [
«d86802270020bf19260c1a0f4c4e46551a9f01d6»,
«da39a3ee5e6b4b0d3255bfef95601890afd80709»,
«1e941fdd57610dd433314447b1076f84bad98594»,
«ae67fd775a29fe2e812c04d7fae00fed6cd3f10f»,
«7b84cf7ccb58aca03a780b60ee731ef458f311d7»
],
«section_sha256»: [
«6331c1d1e5d08db286a879035ffa9f08f999bf87358938ef184ccaf25fe0b626»,
«e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855»,
«fe21359b2a4ce3fde264344efee4f475b752d192ea1039aad72edf19e764f073»,
«95d49c9c84ddb5bd3fb746000e2be173d51af0a4971d0d2f82a728d769a74778»,
«7b80a0764abba960a81e444dcc6f5cb3ec8c38c0c4aeb89e518ef40ee0d129d1»
]
}

Самое страшное здесь — секции с импортируемыми функциями из 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’ы в файлах
Импортируемые функции из библиотек

Inserting image... — Пример дашбордика в ELK с полезной информацией

Послесловие

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

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

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

ссылка на оригинал статьи https://habr.com/ru/articles/723748/