Доброго времени суток, codeby.
Первоисточник:
Перевод: Перевод выполнен от команды Codeby
Важной стороной эффективного поиска угроз является понимание того, что является нормальным в среде. Если специалист в процессе поиска угроз способен определить нормальное поведение в системе, то любое отклонение от нормы, скорее всего, будет связано с тем, что тот или иной субъект недавно вошел в среду. Этот субъект может быть новой установленной программой, новым пользователем или злоумышленником.
На конечных точках выполнение определенных процессов Windows хорошо документировано. Если мы можем прогнозировать нормальное поведение этих процессов при выполнении, то мы можем легко отметить выполнение похожих, но ненормальных процессов в системах. Чтобы сбить с толку специалистов по безопасности, и аналитиков, злоумышленники в настоящее время прибегают к использованию исполняемых файлов с такими же именами, что и системные процессы. Таким образом, беглый взгляд пользователя или даже специалиста может не идентифицировать вредоносный фрагмент двоичного файла в системе. Этот метод, который популярен среди APT и групп вредоносных программ, таких как APT1, Carbanak, Elise и т. д., называется ‘
В этой статье мы рассмотрим шаблоны поведения и особенности некоторых системных процессов Windows и то, как мы можем встроить эти знания в «правило» для того, чтобы затем идентифицировать любой процесс, который не соответствует правилу.
Мы будем использовать следующие компоненты для проведения поиска:
Давайте рассмотрим пример процесса smss.exe в Windows. Этот сервис относится к Менеджеру сеансов и имеет следующие характеристики:
Теперь, когда мы знаем, как выглядит подлинный процесс Windows smss.exe, мы можем использовать эту информацию для поиска любого другого процесса smss.exe во всей инфраструктуре, а именно того, который не соответствует этим характеристикам. В нашем случае мы специально ищем вредоносные процессы, которые маскируются под подлинные процессы. Обычная техника для идентификации таких двоичных файлов заключается в том, чтобы посмотреть на имя их родительского процесса и путь их выполнения. Ниже приведен список стандартных процессов Windows, а также их родительский процесс и путь выполнения. Вы можете обратиться к
Таблица 1 Процессы в Windows
Sysmon может использоваться для генерации полных журналов выполнения процесса. Ниже приведен список событий журнала, созданный с помощью Sysmon.
Таблица 2 Sysmon ID событий
Мы сосредоточимся на событии с идентификатором (ID) 1, которое генерируется при каждом создании нового процесса. Мы получим эти логи в ELK через Winlogbeats.
Logstash может использоваться для анализа и маркировки событий, которые не соответствуют шаблону правила, приведенному выше. Взяв пример SVCHOST.EXE, отметим, что его родительский процесс называется «SERVICES.EXE» и выполняется из каталога System32. Это может быть определено как «правило» в logstash, как показано ниже.
Всякий раз, когда мы сталкиваемся с процессом с именем svchost.exe, который не выполняется из каталога C:\Windows\System32\ или у которого нет родительского процесса с именем services.exe (который сам был запущен из C:\Windows\System32\ каталога), к событию добавляется тег для дальнейшего просмотра и исследования.
Примечание: В данной статье во всех случаях используется отсылка к диску «C:\» с оговоркой на то, что на большинстве компьютеров ОС Windows установлена на диске C.
Если вам неизвестен синтаксис файла конфигурации logstash, вы можете обратиться к нижеприведенным статьям:
Мы можем создать аналогичные правила и для других системных процессов. Для этого тега теперь можно создать простую визуализацию счета метрик (обнаружен подозрительный процесс). Каждый раз, когда это количество увеличивается, мы знаем, что что-то странное происходит в инфраструктуре.
Рисунок 1: Тегиs: подозрительный процесс обнаружен в Kibana
Рисунок 2: Взаимосвязь обнаружила подозрительный процесс
В последующих статьях мы с вами рассмотрим конфигурацию и настройку Sysmon и ELK для обеспечения полного цикла поиска угроз. Ну а теперь, счастливого поиска!
Первоисточник:
Ссылка скрыта от гостей
Перевод: Перевод выполнен от команды Codeby
Важной стороной эффективного поиска угроз является понимание того, что является нормальным в среде. Если специалист в процессе поиска угроз способен определить нормальное поведение в системе, то любое отклонение от нормы, скорее всего, будет связано с тем, что тот или иной субъект недавно вошел в среду. Этот субъект может быть новой установленной программой, новым пользователем или злоумышленником.
На конечных точках выполнение определенных процессов Windows хорошо документировано. Если мы можем прогнозировать нормальное поведение этих процессов при выполнении, то мы можем легко отметить выполнение похожих, но ненормальных процессов в системах. Чтобы сбить с толку специалистов по безопасности, и аналитиков, злоумышленники в настоящее время прибегают к использованию исполняемых файлов с такими же именами, что и системные процессы. Таким образом, беглый взгляд пользователя или даже специалиста может не идентифицировать вредоносный фрагмент двоичного файла в системе. Этот метод, который популярен среди APT и групп вредоносных программ, таких как APT1, Carbanak, Elise и т. д., называется ‘
Ссылка скрыта от гостей
’ (Маскировка/сокрытие имен).В этой статье мы рассмотрим шаблоны поведения и особенности некоторых системных процессов Windows и то, как мы можем встроить эти знания в «правило» для того, чтобы затем идентифицировать любой процесс, который не соответствует правилу.
Мы будем использовать следующие компоненты для проведения поиска:
- Sysmon: этот инструмент Sysinternals является отличным средством регистрации событий Windows. Он может генерировать подробные логи в системе Windows.
- Winlogbeat: это доставщик логов Windows. Это часть Эластичного стека (Elastic stack).
- ELK stack: платформа для аналитики и визуализации. Эта структура будет использоваться в качестве нашей платформы «Поиск угроз» (‘Threat Hunting’). Логи, сгенерированные в системах Windows Sysmon, будут отправлены в стек ELK с помощью winlogbeat.
Ссылка скрыта от гостей
и
Ссылка скрыта от гостей
Марка Руссиновича , который также является автором Sysmon и более широкого набора инструментов sysinternals.Давайте рассмотрим пример процесса smss.exe в Windows. Этот сервис относится к Менеджеру сеансов и имеет следующие характеристики:
- Это первый процесс пользовательского режима;
- Родительский процесс должен называться System;
- Он загружается из %systemroot%\System32\smss.exe;
- Имя пользователя должно быть следующим: NT AUTHORITY\SYSTEM;
- Он создает два сеанса: сеанс 0 - службы ОС и сеанс 1 - сеанс пользователя;
- Сеанс 1 завершится после загрузки csrss.exe и winlogon.exe. (Следовательно, у этих двух процессов не будет родительского процесса);
- Только один smss.exe с сеансом 0 должен быть запущен. (Если запущено более одного экземпляра, то это означает, что это либо фальшивка, либо несколько пользователей вошли в систему).
Теперь, когда мы знаем, как выглядит подлинный процесс Windows smss.exe, мы можем использовать эту информацию для поиска любого другого процесса smss.exe во всей инфраструктуре, а именно того, который не соответствует этим характеристикам. В нашем случае мы специально ищем вредоносные процессы, которые маскируются под подлинные процессы. Обычная техника для идентификации таких двоичных файлов заключается в том, чтобы посмотреть на имя их родительского процесса и путь их выполнения. Ниже приведен список стандартных процессов Windows, а также их родительский процесс и путь выполнения. Вы можете обратиться к
Ссылка скрыта от гостей
(
Ссылка скрыта от гостей
) для более подробной информации.# | Название процесса (Image Name) | Директория процесса (Image Directory) | Родительский процесс (Parent Image) |
1 | svchost.exe | C:\Windows\System32\ | C:\Windows\System32\services.exe |
2 | smss.exe | %Systemroot%\System32\ | System |
3 | csrss.exe | %SystemRoot%\system32\ | – |
4 | wininit.exe | %SystemRoot%\system32\ | – |
5 | services.exe | %SystemRoot%\System32\ | %SystemRoot%\System32\wininit.exe |
6 | lsass.exe | %SystemRoot%\System32\ | %SystemRoot%\System32\wininit.exe |
7 | svchost.exe | %SystemRoot%\System32\ | %SystemRoot%\System32\services.exe |
8 | lsm.exe | %SystemRoot%\System32\ | %SystemRoot%\System32\wininit.exe |
9 | winlogon.exe | %SystemRoot%\System32\ | – |
10 | explorer.exe | %SystemRoot%\ | – |
11 | taskhost.exe | %SystemRoot%\System32\ | %SystemRoot%\System32\wininit.exe |
Sysmon может использоваться для генерации полных журналов выполнения процесса. Ниже приведен список событий журнала, созданный с помощью Sysmon.
ID события (Event IDs) | Класс события (Event Class) |
1 | Process Create |
2 | Process Terminate |
6 | Drive Load |
7 | Image Load |
2 | File Creation Time Changed |
3 | Network Connection |
8 | CreateRemoteThread |
9 | RawAccessRead |
Мы сосредоточимся на событии с идентификатором (ID) 1, которое генерируется при каждом создании нового процесса. Мы получим эти логи в ELK через Winlogbeats.
Logstash может использоваться для анализа и маркировки событий, которые не соответствуют шаблону правила, приведенному выше. Взяв пример SVCHOST.EXE, отметим, что его родительский процесс называется «SERVICES.EXE» и выполняется из каталога System32. Это может быть определено как «правило» в logstash, как показано ниже.
Код:
if “svchost.exe” in [event_data][Image] and ([event_data][CurrentDirectory] !~
/(?i)C:\\Windows\\System32\\$/ or [event_data][ParentImage] !~
/(?i)C:\\Windows\\system32\\services.exe$/) {
mutate {
add_tag => [“suspicious process found”]
}
}
Всякий раз, когда мы сталкиваемся с процессом с именем svchost.exe, который не выполняется из каталога C:\Windows\System32\ или у которого нет родительского процесса с именем services.exe (который сам был запущен из C:\Windows\System32\ каталога), к событию добавляется тег для дальнейшего просмотра и исследования.
Примечание: В данной статье во всех случаях используется отсылка к диску «C:\» с оговоркой на то, что на большинстве компьютеров ОС Windows установлена на диске C.
Если вам неизвестен синтаксис файла конфигурации logstash, вы можете обратиться к нижеприведенным статьям:
Ссылка скрыта от гостей
Ссылка скрыта от гостей
Мы можем создать аналогичные правила и для других системных процессов. Для этого тега теперь можно создать простую визуализацию счета метрик (обнаружен подозрительный процесс). Каждый раз, когда это количество увеличивается, мы знаем, что что-то странное происходит в инфраструктуре.
Рисунок 1: Тегиs: подозрительный процесс обнаружен в Kibana
Рисунок 2: Взаимосвязь обнаружила подозрительный процесс
В последующих статьях мы с вами рассмотрим конфигурацию и настройку Sysmon и ELK для обеспечения полного цикла поиска угроз. Ну а теперь, счастливого поиска!
Последнее редактирование: