[Информационная безопасность, Системное администрирование, IT-инфраструктура, Софт] Включаем сбор событий о запуске подозрительных процессов в Windows и выявляем угрозы при помощи Quest InTrust

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
04-Авг-2020 14:35

Цитировать

Одна из часто встречающихся типов атак — порождение злонамеренного процесса в дереве под вполне себе добропорядочными процессами. Подозрение может вызвать путь к исполняемому файлу: частенько вредоносное ПО использует папки AppData или Temp, а это нехарактерно для легитимных программ. Справедливости ради, стоит сказать, что некоторые утилиты автоматического обновления исполняются в AppData, поэтому одной только проверки места запуска недостаточно для утверждения, что программа является вредоносной.
Дополнительный фактор легитимности — криптографическая подпись: многие оригинальные программы подписаны вендором. Можно использовать факт отсутствия подписи как метод выявления подозрительных элементов автозагрузки. Но опять же есть вредоносное ПО, которое использует украденный сертификат, чтобы подписать самого себя.
Ещё можно проверять значение криптографических хэшей MD5 или SHA256, которые могут соответствовать некоторым ранее обнаруженным вредоносным программам. Можно выполнять статический анализ, просматривая сигнатуры в программе (с помощью правил Yara или антивирусных продуктов). А ещё есть динамический анализ (запуск программы в какой-либо безопасной среде и отслеживание ее действия) и реверс-инжиниринг.
Признаков злонамеренного процесса может быть масса. В этой статье мы расскажем как включить аудит соответствующих событий в Windows, разберём признаки, на которые опирается встроенное правило InTrust для выявление подозрительного процесса. InTrust — это CLM-платформа для сбора, анализа и хранения неструктурированных данных, в которой есть уже сотни предустановленных реакций на различные типы атак.
При запуске программы, она загружается в память компьютера. Исполняемый файл содержит компьютерные инструкции и вспомогательные библиотеки (например, *.dll). Когда процесс уже запущен, он может создавать дополнительные потоки. Потоки позволяют процессу выполнять разные наборы инструкций одновременно. Существует много способов проникновения вредоносного кода в память и его запуска, рассмотрим некоторые из них.
Самый простой способ запустить вредоносный процесс — заставить пользователя запустить его напрямую (например, из вложения электронной почты), затем при помощи ключа RunOnce запускать его при каждом включении компьютера. Сюда же можно отнести «безфайловое» вредоносное ПО, которое хранит скрипты PowerShell в ключах реестра, которые выполняются на основе триггера. В этом случае сценарий PowerShell является вредоносным кодом.
Проблема с явным запуском вредоносного программного обеспечения заключается в том, что это известный подход, который легко обнаруживается. Некоторые вредоносные программы предпринимают более хитрые вещи, например, используют другой процесс, чтобы начать исполняться в памяти. Следовательно, процесс может создать другой процесс, запустив определенную компьютерную инструкцию и указав исполняемый файл (.exe) для запуска.
Файл можно указать, используя полный путь (например, C:\Windows\system32\cmd.exe) или неполный (например, cmd.exe). Если исходный процесс небезопасен, он позволит запускать нелегитимные программы. Атака может выглядеть так: процесс запускает cmd.exe без указания полного пути, злоумышленник помещает свой cmd.exe в такое место, чтобы процесс запустил его раньше легитимного. После запуска вредоносной программы она, в свою очередь, может запустить легитимную программу (например, C:\Windows\system32\cmd.exe), чтобы исходная программа продолжала работать должным образом.
Разновидность предыдущей атаки — DLL-инъекция в легитимный процесс. Когда процесс запускается, он находит и загружает библиотеки, которые расширяют его функциональные возможности. Используя DLL-инъекцию, злоумышленник создает вредоносную библиотеку с тем же именем и API, что и у легитимной. Программа загружает вредоносную библиотеку, а она, в свою очередь, загружает легитимную, и, по мере необходимости, для выполнения операций, вызывает её. Вредоносная библиотека начинает выполнять роль прокси для хорошей библиотеки.
Еще один способ поместить вредоносный код в память — вставить его в небезопасный процесс, который уже запущен. Процессы получают входные данные из различных источников — читают из сети или файлов. Обычно они выполняют проверку, чтобы убедиться в легитимности входных данных. Но некоторые процессы не имеют должной защиты при выполнении инструкций. При такой атаке не существует библиотеки на диске или исполняемого файла с вредоносным кодом. Всё хранится в памяти вместе с эксплуатируемым процессом.
Теперь разберемся методикой включения сбора подобных событий в Windows и с правилом в InTrust, которое реализует защиту от подобных угроз. Для начала, активируем его через консоль управления InTrust.

Правило использует возможности отслеживания процессов ОС Windows. К сожалению, включение сбора таких событий далеко не очевиден. Нужно изменить 3 разных настройки групповой политики:
Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Audit Policy > Audit process tracking

Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Detailed Tracking > Audit process creation

Computer Configuration > Policies > Administrative Templates > System > Audit Process Creation > Include command line in process creation events

После включения, правила InTrust позволяют обнаруживать неизвестные ранее угрозы, которые демонстрируют подозрительное поведение. Например, можно выявить описанное тут вредоносное ПО Dridex. Благодаря проекту HP Bromium, известно, как устроена такая угроза.

В цепочке своих действий Dridex использует schtasks.exe, чтобы создать запланированное задание. Использование именно этой утилиты из командной строки считается весьма подозрительным поведением, аналогично выглядит запуск svchost.exe с параметрами, которые указывают на пользовательские папки или с параметрами, похожими на команды «net view» или «whoami». Вот фрагмент соответствующего правила SIGMA:

detection:
selection1:
CommandLine: '*\svchost.exe C:\Users\\*\Desktop\\*'
selection2:
ParentImage: '*\svchost.exe*'
CommandLine:
- '*whoami.exe /all'
- '*net.exe view'
condition: 1 of them

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

Процессы, выполняющиеся из необычных мест, таких как пользовательские временные папки.
Хорошо известный системный процесс с подозрительным наследованием — некоторые угрозы могут попытаться использовать имя системных процессов, чтобы остаться незамеченными.
Подозрительные исполнения административных инструментов, таких как cmd или PsExec, когда они используют учетные данные локальной системы или подозрительное наследование.
Подозрительные операции теневого копирования — обычное поведение вирусов-вымогателей перед шифрованием системы, они убивают резервные копии:
— Через vssadmin.exe;
— Через WMI.
Регистровые дампы целых кустов реестра.
Горизонтальное перемещение вредоносного кода при удаленном запуске процесса с использованием таких команд, как at.exe.
Подозрительные локальные групповые операции и доменные операции с использованием net.exe.
Подозрительные операции брандмауэра с использованием netsh.exe.
Подозрительные манипуляции с ACL.
Использование BITS для эксфильтрации данных.
Подозрительные манипуляции с WMI.
Подозрительные скриптовые команды.
Попытки сдампить безопасные системные файлы.

Объединенное правило очень хорошо работает для обнаружения угроз, таких как RUYK, LockerGoga и других вирусов-вымогателей, вредоносных программ и наборов инструментов для киберпреступлений. Правило проверено вендором в боевых средах, чтобы минимизировать ложные срабатывания. А благодаря проекту SIGMA, большинство этих индикаторов производят минимальное количество шумовых событий.
Т.к. в InTrust это правило мониторинга, вы можете выполнить ответный сценарий в качестве реакции на угрозу. Можно использовать один из встроенных сценариев или создать свой собственный, а InTrust автоматически распространит его.

Кроме того, можно проверить всю связанную с событием телеметрию: скрипты PowerShell, выполнение процессов, манипуляции с запланированными задачами, административную активность WMI и использовать их для постмортемов при инцидентах безопасности.

В InTrust есть сотни других правил, некоторые из них:

Выявление атаки понижения версии PowerShell — когда кто-то специально использует старую версию PowerShell, т.к. в более старой версии не было возможности аудита происходящего.
Выявление входа в систему с высоким уровнем привилегий — когда учетные записи, которые являются членами определенной привилегированной группы (например, администраторы домена), случайно или из-за инцидентов безопасности интерактивно входят в систему на рабочих станциях.

InTrust позволяет использовать лучшие практики безопасности в виде предустановленных правил обнаружения и реакции. А если вы считаете, что нечто должно работать иначе — можно сделать свою копию правила и настроить как нужно. Отправить заявку на проведение пилота или получение дистрибутивов с временными лицензиями можно через форму обратной связи на нашем сайте.
Подписывайтесь на нашу страницу в Фейсбуке, публикуем там краткие заметки и интересные ссылки.
Почитайте другие наши статьи по теме информационной безопасности:
Как InTrust может помочь снизить частоту неудачных попыток авторизаций через RDP
Выявляем атаку вируса-шифровальщика, получаем доступ к контроллеру домена и пробуем противостоять этим атакам
Что полезного можно вытащить из логов рабочей станции на базе ОС Windows (популярная статья)
Отслеживание жизненного цикла пользователей без плоскогубцев и изоленты
А кто это сделал? Автоматизируем аудит информационной безопасности
Как снизить стоимость владения SIEM-системой и зачем нужен Central Log Management (CLM)
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_sistemnoe_administrirovanie (Системное администрирование), #_itinfrastruktura (IT-инфраструктура), #_soft (Софт), #_quest, #_intrust, #_gals_software, #_security, #_information_security, #_siem, #_clm, #_log_management, #_gartner, #_blog_kompanii_gals_software (
Блог компании Gals Software
), #_informatsionnaja_bezopasnost (
Информационная безопасность
), #_sistemnoe_administrirovanie (
Системное администрирование
), #_itinfrastruktura (
IT-инфраструктура
), #_soft (
Софт
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 23-Ноя 00:41
Часовой пояс: UTC + 5