Прежде всего, я хотел бы поблагодарить CERT США за публикацию новейшего отчета об угрозах деятельности Dragonfly под названием TA17–293A.
Я считаю, что даже информация, которая в некоторых аспектах является неточной или сомнительной, требует обратной связи, создаваемой сильным и взаимосвязанным сообществом. Поэтому я решительно поддерживаю обмен информацией об угрозах и подчеркиваю эту позицию, извлекая, уточняя и получая новые подписи из опубликованных отчетов всех сторон в нашем сообществе.
Последний отчет американского CERT содержал много информации об злоумышленнике по имени Dragonfly, который я соотносил в своей электронной таблице «Группы и операции APT» в Google Docs с «Energetic Bear» и «Crouching Yeti».
Может ли кто-нибудь из Crowdstrike или Kaspersky проверить правильность сопоставления? Кажется, в одной строчке слишком много «медведей».
Этот отчет содержал правила TTP, IOC и YARA для упомянутых вредоносных программ и образцов средств взлома.
Первое, что я делаю, это проверяю предоставленные хэши с помощью моего скрипта «Munin», который дает мне лучший обзор образцов, предоставляя мне информацию об используемых именах файлов, дате первой отправки, антивирусном покрытии и некоторых тегах, таких как «Подписано» »(Подписанный исполняемый файл),« Аннулирован »(отозванный сертификат) или« Безвредный »(каталог программного обеспечения Microsoft).
Результаты выборочной онлайн-проверки: https://docs.google.com/spreadsheets/d/1DLsQrADjmmHxhHJo5DPhCn0aDEP5wkbS5iYEzAyk6BU/edit?usp=sharing
Пока скрипт работал в фоновом режиме, я уже заметил, что злоумышленник использовал переименованную версию «PsExec» как «ps.exe», а US CERT включил хеши известного и довольно популярного инструмента в список IOC. US CERT правильно перечисляет их как «безвредные» и добавляет комментарий, объясняющий интеграцию.
Они заявляют: «Согласно анализу DHS, кибер-злоумышленники могут размещать ps.exe в скомпрометированных системах. Следует обратить внимание на копии Psexec.exe, которые были переименованы и появляются в необычных местах ».
В этом нет никаких проблем, пока аналитик читает и предварительно проверяет IOC перед их вводом в производство. К сожалению, такие IOC часто попадают в большой обмен информацией об угрозах и в конечном итоге оказываются в решении для мониторинга безопасности / SIEM / EDR, вызывая многочисленные ложные срабатывания.
Две перечисленные версии PsExec могут быть индикатором компрометации, если организация запрещает использование PsExec или может быть уверена, что перечисленные версии не используются системными администраторами (обе маловероятны).
Если у вас есть подходящее решение для мониторинга безопасности, вы можете проверить запуск процесса с помощью следующей командной строки:
ps.exe -accepteula
Простого выполнения «ps.exe» будет недостаточно в большинстве корпоративных сред, поскольку существует множество инструментов, в том числе «ps.exe» в Cygwin, которые носят это имя. Но не существует инструмента SysInternals с параметром «-accepteula» с именем «ps.exe».
Я быстро написал правило сигмы, чтобы описать этот метод обнаружения.
Но продолжим. Особенно меня беспокоили включенные правила YARA. После беглого обзора я заметил, что мне нужно распутать сложные условия, чтобы раскрыть первоначальные намерения автора. Кроме того, у меня не было образцов, для которых были созданы эти правила. Поэтому я не мог просто отбросить строки или условия, потому что не мог проверить, соответствует ли измененное правило исходному набору образцов.
Разрывы строк помогли мне лучше понять условия. Я заметил, что, например, строка $ s25 была включена в условие, которое гласит:
StringA AND StringB OR StringC
Из-за того, что «И» связывает более жестко, чем «ИЛИ», одна только эта строка всегда будет запускать это правило. Простое «/icon.png» в любом файле вызывает срабатывание этого правила.
Я догадался, что автор намеревался объединить строку $ s25 со строкой $ s0, которая представляет собой «файл: //». Я все еще не был уверен, что это не сработает на сотнях образцов.
Я переименовал правила $ s14 в $ s21 и использовал $ x * для любого типа строки, которая достаточно конкретна, чтобы служить в качестве единственного индикатора, и упростил условие для этих строк до «1 из ($ x *)».
Я переименовал строку $ s0 в $ n1 и объединил ее со строками с именем $ ax *, которые выглядели достаточно конкретными, чтобы служить второй частью этого условия. Я пытался использовать строки $ au * в сочетании с $ n1, но они оказались слишком слабыми. Если бы у меня были исходные образцы, я бы проанализировал образец, содержащий «file: //» и «icon.png», и проверил бы его на предмет других пригодных для использования значений.
Мое решение подвержено ложноотрицательным результатам, но я полностью осознаю этот риск, и у меня нет другого выбора, кроме как принять его.
Другие строки в этом списке выглядели настолько специфичными, что я уменьшил сложность их сопоставления, включив их в список строк $ x *. Остальные попали в список с идентификатором $ s *. Две из этих строк необходимы для срабатывания правила.
Второе правило, которое я изменил, было четвертым правилом в наборе.
Правило не ошибочное, но оно содержит очень короткую строку:
a(“
Поскольку мы используем YARA в наших сканерах, которые проходят через всю файловую систему, сканируя каждый файл на диске, высокая производительность имеет решающее значение. YARA использует «Aho Corasick» для сопоставления строк и поэтому работает очень быстро, но невыгодные правила могут существенно повлиять на производительность.
YARA включает функцию, которая предупреждает о струнах, которые отрицательно влияют на производительность. Эта трехсимвольная строка не вызвала предупреждающего сообщения, но я почти уверен, что атом такой длины отрицательно сказывается на производительности. Давным-давно я написал содержание под названием «Рекомендации по эффективности YARA», которое, по сути, представляет собой просто сборник отзывов Виктора и Уэсли по вопросам, которые я им задавал. Я добавлю этот Суть в Приложение к этому посту.
Поскольку условие объединяет четыре строки $ decode * достаточной сложности, я просто попытался оставить очень короткую строку.
Последним шагом было небольшое улучшение правил, включая условие заголовка ZIP в позиции 0.
strings:
$zip_magic = { 50 4b 03 04 }
condition:
$zip_magic at 0
Поскольку все элементы в «строках» применяются при сопоставлении строк, YARA сначала найдет все строки в файле, которые соответствуют, а затем проверит их расположение, если расположение определено в условии. Мы можем улучшить правило, удалив магию ZIP из строк и включив проверку в позицию 0 в условии.
uint32(0) == 0x04034b50
Или используйте uint32be () для чтения значений с прямым порядком байтов со смещения 0.
uint32be(0) == 0x504b0304
Есть функция под названием «Оценка короткого замыкания». Попытайтесь написать условия, при которых элементы, которые с наибольшей вероятностью будут ложными, будут размещены первыми. Состояние оценивается слева направо. Чем раньше он будет идентифицирован как «не срабатывающий», тем лучше.
См. «Рекомендации по производительности YARA» для получения более подробной информации по этому вопросу.
Ссылки
Рекомендации по производительности YARA
