Windows Incident Response: системный подход. Часть 1

Недавно я писал материал о реагировании на инциденты информационной безопасности в Linux в двух частях (одна ^[1], вторая ^[2]). Я попытался написать что-то поинтереснее, чем просто набор команд, чтобы этот материал можно было использовать как методологию – раз, и основу для собственных плейбуков – два.  

Теперь применим тот же подход к Windows. В конце концов, большинство корпоративных рабочих станций работают на Windows, у всех есть виндовые домены, и машин под Windows Server тоже везде хватает. 

Материалов о Windows Incident Response немало. Но многим работам не хватает целостного представления о предмете. Они выглядят как наборы команд для терминала; если вывод есть – плохо, если нет – хорошо. Эта проблема характерна и для статей по Linux IR, но выражена там не так сильно – думаю, по причине того, что ОС Windows щедра на следы — заметно щедрее Linux. Таким образом, тема объемнее за счет большего количества источников, и нюансов в них больше – каждый из источников по-своему «говорит» и по-своему «врет», аналитик должен хорошо разбираться в этом. 

Собственно, нужна методология. Реагирование ^[3] – это не бездумный копипаст десятков команд и не поиск одного ультимативного артефакта, который ответит на все наши вопросы. Это корреляция множества следов, которые лежат в разных местах и каждый из которых отвечает лишь на часть вопросов. 

Под катом — пытаемся подходить к вопросу системно через разбор заражённого хоста аналитиком IR от первой команды до готового таймлайна и списка IOC. Если вы читаете это не из любопытства, а потому что подозреваете компрометацию прямо сейчас, а антивирус молчит, вы можете опираться на статью для ручного поиска вредоносного ПО.

Сценарий, для которого написана статья

Представим корпоративную машину под управлением Windows Server. Сервер входит в домен AD, имеет какую-то роль и находится в активной эксплуатации. В какой-то момент команда информационной безопасности получает указание проверить сервер из-за неуточнённого подозрения на компрометацию. Конкретного детекта, указывающего на вредоносный файл или механизм закрепления, нет. Известно лишь, что с сервера наблюдалась подозрительная сетевая активность. Такой сценарий намеренно оставляет минимум исходных данных. Это допущение, такое же, как и в статье про Linux IR. В реальном инциденте такие размытые начальные данные едва ли возможны — расследование обычно начинается с определённого алерта EDR, SIEM, антивируса или межсетевого экрана. Этот алерт становится первой зацепкой и влияет на порядок действий аналитика. Например, обнаружение обфусцированной команды PowerShell заставит начать с соответствующего процесса, его родителя и журналов PowerShell, а необычный объём исходящего трафика — с сетевых соединений и процессов, которым они принадлежат. Но здесь мы будем расследовать хост «по умолчанию», чтобы охватить максимально возможный объем полезных с точки зрения ^[4] анализа мест.

Безусловно, в реальном расследовании будет всегда важна роль сервера. Это может быть IIS, файловый сервер, NPS, принт-сервер и т.д. Расследование всегда будет проводиться с учетом этой роли. Для примеров в материале приведен анализ сервера с ролью RDS. Терминалки постоянно находятся в использовании большим количеством людей, являются точкой входа в инфраструктуру и местом запуска множества инструментов — из-за этого они заражаются чаще остальных. Чтобы в выводе команд ниже было на что посмотреть, на сервере заранее воспроизведён контролируемый сценарий заражения: в системе есть процессы, сетевые соединения, пользовательские следы и механизмы закрепления, которые предстоит обнаружить и связать между собой.

О чём рассказывается в материале

Нет никаких шансов описать все одной статьей, поэтому будет цикл. Он посвящён исследованию работающего Windows-хоста — Windows live response. Мы разберём:

• подготовку инструментария;

• сетевые соединения и их привязку к процессам;

• изоляцию подозрительной системы;

• фиксацию исходного состояния;

• процессы и связи между ними;

• службы и Scheduled Tasks;

• исполняемые файлы, цифровые подписи и контрольные суммы;

• механизмы автозапуска в реестре;

• локальные и доменные учётные записи;

• Prefetch, Amcache, LNK, Jump Lists и другие Windows-артефакты;

• журналы Windows, PowerShell, Defender, RDP;

• построение таймлайна и формирование IOC;

• действия после завершения расследования.

Будет четыре части: 

• В первой обсудим методологию расследования, доверие к инструментам, фиксацию исходного состояния системы и сеть. 

• Во второй — изоляцию хоста, процессы и службы. 

• В третьей — задачи планировщика, автозапуск, пользователей и журналы событий. 

• В четвёртой — подготовку коллекции для офлайн-анализа, артефакты, восстановление хронологии атаки, IOC и действия после инцидента.

Что останется за рамками

Основной объект исследования это работающая система. Полноценный анализ образа диска и дампа оперативной памяти ^[5] требует отдельного инструментария и выполняются долго, поэтому memory forensics и глубокий offline-анализ в этот цикл не войдут.

Также за рамками останутся реверс вредоносных файлов и анализ инфраструктуры. Мы, очевидно, не можем не учитывать доменный контекст терминального сервера, но не станем превращать расследование одного хоста в полный AD Incident Response.

Наконец, приведенный порядок действий не является универсальной последовательностью для любого инцидента. Реальный алерт, наблюдаемая активность, критичность системы и риск дальнейшего распространения атаки всегда могут изменить приоритеты. Цель материала — показать базис, который поможет понимать, какие данные доступны на Windows-хосте, насколько им можно доверять и как связывать отдельные находки в цельную картину произошедшего.

Итак, что следует сделать с подозрительным Windows-сервером и как не уничтожить наиболее ценные следы своими же действиями?

Подозрительный Windows-сервер — что дальше?

Основные принципы расследования

До первой команды стоит договориться о том, как вообще работать на скомпрометированном хосте. Нарушение этих принципов уничтожает улики быстрее, чем это сделал бы атакующий.

Принцип первый: порядок важнее скорости

Данные на хосте живут разное время. Что-то исчезнет при перезагрузке, что-то — через час, что-то останется на диске месяцами. Отсюда Order of Volatility ^[6]: начинать с самого недолговечного, двигаться к более устойчивому.

Для Windows очередь выглядит примерно так:

1. Оперативная память — исчезает полностью при выключении;

2. Сетевые соединения, ARP- и DNS-кеш — живут недолго;

3. Список процессов, дескрипторы, загруженные модули — до завершения процесса;

4. Реестр, журналы событий, Prefetch, Amcache, файлы — переживают перезагрузку.

Выключение и перезагрузка «чтобы прервать атаку» будут стоить нам достаточно дорого в плане артефактов. Её следует избегать.

Первым шагом по этой логике ^[7] должен идти дамп оперативной памяти. Память содержит то, чего на диске может не быть: код, внедрённый в чужой процесс, расшифрованную полезную нагрузку, ключи, учётные данные, закрытые сетевые сессии, историю команд. Снимается он переносным инструментом — для физических машин я использую FTK Imager с внешнего носителя, для виртуальных машин можно использовать методы на уровне гипервизора наподобие описанных в этой статье ^[8]. 

Также, многие EDR способны делать дамп памяти через агента на эндпоинте. Сделанный дамп необязательно анализировать тут же, особенно если ваши ресурсы ограничены и нет возможности дать второму человеку параллельную задачу на анализ дампа через Volatility. 

Замечу, что я бы снимал дамп памяти после изоляции. При активных действиях атакующих на хосте изоляция приоритетнее.

Принцип второй: минимальный след

Любое действие на системе, очевидно, меняет её состояние. Каждый запуск процесса порождает событие 4688 в журнале Security — в том же журнале, который мы собираемся анализировать. Каждый запущенный нами исполняемый файл может попасть в Amcache и Prefetch — туда же, куда мы будем смотреть в поисках следов атакующего. PowerShell, если включено логирование блоков сценариев, пишет наши команды в журнал наравне с чужими. Запись файлов на системный диск перезаписывает свободные секторы, где могли лежать удалённые артефакты.

Поэтому надо стараться делать так:

• собранные артефакты складывать на внешний носитель или сетевой ресурс, а не на диск жертвы, 

• ничего не устанавливать — инструменты приносить с собой готовыми, в portable, 

• не перезапускать службы без нужды, 

• не останавливать подозрительные процессы до того, как они изучены, 

• фиксировать в журнале расследования каждую команду, чтобы потом отличить свой след от чужого.

Последний пункт особенно важен, забивать на него категорически нельзя. Через двое суток мы сами не вспомним, чей powershell.exe в конкретном событии 4688: наш или атакующего.

Полностью следа не избежать. В этом расследовании я, например, создал на самом сервере каталог C:IR-Collection и складывал артефакты туда, а на внешнюю машину переносил уже готовую коллекцию. Правильнее было бы писать сразу вовне. Это осознанный компромисс лабораторных условий, и в реальном инциденте на критичной системе я бы так не делал.

Принцип третий: цель IR — понять, а не вылечить

Принцип контринтуитивный, и его игнорируют чаще прочих. Реагирование на инцидент не должно представлять из себя операцию по удалению вредоносного ПО.

То есть в конечном счете вредоносные сущности, конечно, будут удалены с систем, равно как их механизмы закрепления и ошибки ^[9] в конфигурации. Но это не должно быть так: «нашел вредоносную службу – выключил, нашел файл – удалил». Это неэффективно, возвращать систему в эксплуатацию после такого подхода не стоит. Дело в том, что никогда нельзя гарантировать, что все вредоносы и механизмы закрепления были найдены и нейтрализованы. Предположим, что мы нашли ключ автозагрузки, две задачи планировщика и службу. Уверенности, что не было пятого механизма — вредоносной DLL, загружаемой штатным процессом, — у нас нет. Расследование отвечает на вопросы, без которых восстановление превращается в лотерею: когда именно началось заражение (иначе непонятно, какую копию считать чистой), каким путём код попал на сервер (иначе всё повторится через неделю), какие учётные записи и соседние системы могли быть затронуты. И даёт индикаторы: адреса, хеши, имена служб и задач, ключи реестра, характерные командные строки — материал для правил в SIEM и EDR.

Короче говоря, один правильно разобранный хост усиливает защиту всей инфраструктуры — в этом смысл работы, а не в удалённом файле.

Учтите, что если работы проводятся на проде, ваши коллеги, вполне вероятно, будут продавливать вас на сценарий «быстро почистить и вернуть всё в эксплуатацию». Это не энтерпрайзный подход. При расследовании инцидента на терминальном сервере ситуация может обостриться — его используют много сотрудников, «людям работать надо». И отсюда — здесь не одна учётная запись, а много, и пользовательские профили, сохранённые учётные данные, токены, подключённые сетевые диски. Компрометация RDS — это потенциальная компрометация всех, кто на нём работал, а откат к бэкапу означает простой для всех сразу. Давление «почистить и вернуть в работу до утра» может быть беспрецедентным, поэтому убедитесь, что ваш CISO обладает достаточным политическим весом в компании и готов отстаивать качество работы IR-команды в высоких кабинетах.

Шаг 1. Инструментарий и начало работы

Скучный, но необходимый раздел. 

Злоумышленники изменяют переменные окружения, чтобы перехватить ход выполнения. Это может привести к непреднамеренному выполнению вредоносного кода при расследовании. В то же время, нам необходимо использование командной строки и Powershell, так как они легко документируются и предоставляют точный вывод. Например, копаться в логах удобнее командлетом Get-WinEvent, а не громоздким GUI eventvwr.msc.

Как использовать необходимые инструменты? Во-первых, есть три способа перехватить исполнение команды в cmd и powershell. 

Первый – переменная PATH (T1574.007 ^[10])

PATH определяет, какой именно файл запустится, когда вы набираете имя команды без полного пути. Windows перебирает каталоги из PATH по очереди и берёт первое совпадение. Если каталог, доступный пользователю на запись, стоит в списке раньше системного, то положенный туда net.exe выполнится вместо настоящего. Действует это на обе оболочки сразу.

Второй – AutoRun в ключе Command Processor – добавляет свой код в CMD

Значение AutoRun в разделе SoftwareMicrosoftCommand Processor задаёт команду, которая выполняется при каждом запуске ^[11] cmd.exe, до того как вы введёте что-либо своё. Ключ существует в двух ветках: HKCU (для текущего пользователя) и HKLM (для всех). В отличие от PATH, здесь ничего не подменяется — просто ваша сессия начинается с чужой команды.

Третий – профили PowerShell — добавляют свой код в PowerShell (T1546.013 ^[12])

Профиль — это скрипт, выполняющийся при каждом старте оболочки. То есть по сути это то же, что и ключ AutoRun для cmd. Только ключей для cmd два, а профилей 4, в разных каталогах. 

Ну, еще теоретически атакующие могут подменить сами cmd.exe и powershell.exe. Но это встречается редко, поскольку файлы, находящиеся в System32 папке защищены WRP ^[13]. 

Какое решение? Запускать cmd и powershell особым образом и проверять переменные окружения и профили. 

Win+R → cmd /D и далее Ctrl+Shift+Enter даст запуск командной строки с повышением прав и игнорированием ключей AutoRun. 

Команда Win+R → powershell.exe -NoProfile и Ctrl+Shift+Enter даст запуск powershell без профилей. 

Порядок работы отсюда такой: сначала командная строка с /D, из неё проверяем реестр, переменные окружения и наличие файлов профилей. Затем PowerShell с -NoProfile — для всего остального.

Ключ AutoRun в обеих ветках:

reg query "HKCUSoftwareMicrosoftCommand Processor" /v AutoRun

reg query "HKLMSoftwareMicrosoftCommand Processor" /v AutoRun

Ошибка «не удаётся найти» — правильный результат. Ключа нет, при запуске командной строки ничего постороннего не выполняется. 

Переменные окружения:

echo ComSpec=%ComSpec%

echo Path=%Path%

echo PSModulePath=%PSModulePath%

ComSpec указывает, какой интерпретатор запустится, когда командный процессор понадобится другой программе. В PATH смотрим на две вещи: нет ли посторонних каталогов и не стоит ли доступный пользователю на запись каталог раньше системных. PSModulePath — то же самое для модулей PowerShell: чужой каталог в списке означает, что при вызове командлета может подгрузиться модуль, переопределяющий его поведение ^[14].

Что реально запустится по имени powershell.exe

where powershell.exe 

Файлы профилей. Четыре профиля лежат в двух каталогах, по два в каждом, поэтому хватает двух команд с маской:

dir /a "C:WindowsSystem32WindowsPowerShellv1.0*profile.ps1" 

dir /a "%USERPROFILE%DocumentsWindowsPowerShell*profile.ps1" 

Описанные выше действия выполнялись штатными исполняемыми файлами Windows. Их использование допустимо с учетом описанных проверок, но я советую использовать собственные исполняемые файлы командной строки и Powershell.

Использование своих файлов терминала с отличающимися от системных именами избавляет от возможных проблем, связанных с техникой T1546.012 ^[15], а также повышает гигиену расследования – каждый наш запуск процесса порождает событие 4688 в журнале Security, и к концу там могут оказаться сотни наших событий с powershell.exe вперемешку с чужими. С powershell-ir.exe вопрос снимается: в журнале, в списке процессов, в Amcache и Prefetch ваша активность подписана именем. Это помогает и тому, кто будет перепроверять вашу работу.

Достаточно скопировать файлы cmd.exe и powershell.exe с идентичной машины (с такой же ОС). Их запуск также производится через Win+R → C:Kitcmd-ir.exe /D и Ctrl+Shift+Enter.

Помимо файлов командной строки и Powershell в C:Kit лежит Sysinternals Suite целиком, но реально пригодились пять утилит: PsList для дерева процессов, ListDLLs для загруженных модулей, Handle для открытых дескрипторов, Strings для извлечения строк из подозрительного бинаря и Autorunsc для сплошного обхода точек автозапуска.

Это все, что минимально необходимо на исследуемой машине. Некоторые данные, типа истории браузеров, невозможно исследовать этими средствами. Поэтому в инструментарий должен входить второй пакет инструментов, размещаемый на машине аналитики, куда будут доставляться файлы для исследования. Проводить извлечение информации из файлов наподобие Amcache на зараженной машине – увеличивать шум.

На зараженную машину приносим:

На машине аналитика:

Ограничения

Проверка профилей, реестра, PATH, использование своих exe не обеспечивает абсолютной защиты. К моменту, когда мы видим рабочий стол и нажимаем Win+R, на хосте уже отработали Userinit, Shell, ключи Run нашего профиля, содержимое папки «Автозагрузка» и всё, что подписано на вход в систему. И, конечно, принесенные экзешники продолжают опираться на системные DLL. Защиты от Kernel-level compromise тоже нет.

Это риск, который мы принимаем. Полностью доверенное окружение может обеспечить только загрузка с внешнего носителя, это намного дольше и уже не live-response.

И кстати. Нам нужны права админа, но использовать для расследования учетную запись ДОМЕННОГО админа — плохая идея. При его логоне на зараженный хост мы рискуем отдать атакующему админские креды . Даже если процесс lsass защищен с помощью Credential Guard или LSA Protection — лучше не рисковать. Чтобы не превращать инцидент из локального в доменный, пользуйтесь учетной записью локального (не AD) администратора. После расследования не забудьте сменить ее пароль.

Шаг 2. Фиксация состояния

Не забудьте изменять значение адресов, пользователей, имен файлов и т.д. в командах на свои, если требуется.

Инструментарий проверен, оболочка запущена. Первое, что делается дальше, — включается запись сессии. Всё, что происходило до этого момента, в командной строке уже зафиксировано визуально на скриншотах, но дальше объём вывода будет такой, что полагаться на память или скриншоты нельзя.

$CaseRoot = 'C:IR-Collection'

Start-Transcript -Path "$CaseRoot1-live-response-transcript.txt"

Start-Transcript пишет в файл каждую введённую команду и каждый её вывод, с отметками времени начала и конца сессии. Это windows-аналог script из Linux-цикла. Вообще, конечно, фиксировать результаты своей работы можно по-разному. Был случай, когда мы с коллегами сидели в ВКС, я шарил экран, а другой парень записывал все это. Но это, конечно, неудобно для дальнейшего разбора.

Зачем это нужно, становится ясно через сутки работы. Мы не вспомним, что показывал netstat до того, как соединение закрылось, и в каком порядке проверяли ключи реестра. А если дело дойдёт до служебного расследования, потребуется доказать, что именно мы делали на системе и чего не делали.

Практическое замечание по расположению. Транскрипт должен писаться на внешний носитель — на исследуемом хосте вы создаёте лишние файлы и перезаписываете свободное место. В нашем расследовании коллекция складывалась в C:IR-Collection прямо на сервере, а выгружалась целиком уже в конце. Для лаборатории это допустимо, для реальной системы — компромисс, которого лучше избежать.

Время: первое, что фиксируется

Get-Date

[DateTime]::UtcNow

Get-TimeZone | Select-Object Id, BaseUtcOffset

Зафиксировать UTC и смещение важно. Источники данных в Windows отдают время по-разному: журналы событий в оснастке показывают локальное, а UserAssist в реестре хранят UTC. UTC удобнее для корреляции с другими системами, локальное время — для разговора с пользователями и владельцами сервиса.

Что за машина перед нами

Get-CimInstance Win32_OperatingSystem |
    Select-Object Caption, Version, BuildNumber, LastBootUpTime

Кто на машине прямо сейчас

quser

LastBootUpTime важнее, чем кажется. Система загружена 24 августа в 15:34, то есть работает около девяти часов. Если LastBootUpTime позже времени компрометации — существенная часть информации потеряна.

Читаем вывод quser. admin014 на console — это мы, аналитик. Знак > в начале строки помечает текущий сеанс.

a.sokolova, сеанс номер 3, статус «Диск» — то есть Disconnected, отключён. Вход выполнен в 00:11, простой 2 минуты. Пользователь подключался по RDP полчаса назад, отключился, не завершив сеанс.

Отключённый сеанс — не то же самое, что завершённый. Он продолжает существовать вместе со всеми запущенными в нём процессами. Пользователь ушёл, а его программы работают. Для RDS это штатное поведение ^[16] и одновременно удобство для атакующего: вредонос, запущенный в пользовательском сеансе, продолжает работать после того, как пользователь закрыл окно RDP-клиента.

Роль сервера

Get-WindowsFeature | Where-Object Installed
Установленные роли говорят, чего ожидать от системы, что считать нормальным и куда смотреть в первую очередь. У нас RDS, что ожидаемо, но также и RSAT-AD-Tools — на сервере доступны средства работы с Active Directory, то есть с этого хоста можно обращаться к домену. Для оценки последствий компрометации это существенно.

Поскольку есть роль Storage-Services, проверяем, какие сетевые шары здесь есть.

Get-SmbShare

Если есть шары непонятного происхождения, можно также дополнительно использовать:

Get-SmbSession показывает клиентов, подключённых к шарам RDS;

Get-SmbOpenFile показывает удалённо открытые через SMB файлы.

Установленные обновления

Get-HotFix

Для дальнейшей оценки патч-менеджмента.

Конфигурация аудита

auditpol /get /category:*

Надо проверить до того, как начнется работа с журналами. Настройки аудита определяют, что вообще попадает в журналы. К примеру, если аудит создания процессов выключен, событий 4688 не будет.

Шаг 3. Сеть

Сеть идёт первой в анализе по двум причинам. Во-первых, по order of volatility активные соединения — самые недолговечные данные после памяти. Во-вторых, исходное подозрение сформулировано именно как «странная сетевая активность», и логично начать с проверки этой гипотезы.

Чтобы увидеть сетевые соединения, зараженный хост НЕ должен быть изолирован. То есть аналитик должен пойти на определенный риск, не применив немедленно меры сдерживания ради снятия данных сетевого состояния. Потому что после сетевой изоляции в команде netstat вывод будет малополезен. Насколько это допустимо — вопрос хороший. Лично я бы в реальных условиях применял бы изоляцию немедленно, не тратя времени на изучение соединений непосредственно в netstat на хосте. Намного надежнее провести изоляцию сразу, а пакеты от зараженного хоста посмотреть на маршрутизаторе или фаерволле.

Тем не менее, на лабораторном стенде изоляция была проведена после снятия сетевых соединений – и это неудачная тактика.

Список активных сетевых соединений

netstat -ano

Флаг -a (All) — отображает все подключения и прослушиваемые порты (как TCP, так и UDP), -n (Numeric) — выводит адреса и номера портов в числовом формате, -o (Owning process) — добавляет колонку с PID.

Узнать процесс с подозрительными соединениями по PID

Get-Process -Id 8724

Браузер, запущен из сеанса a.sokolova (3). На С2 не похоже, скорее легитимный шум, идем дальше.

Полный срез соединений в файл

Get-NetTCPConnection -ErrorAction SilentlyContinue |

    Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort,

        State, OwningProcess,

        @{N='ProcessName';E={

            (Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName

        }} |

    Sort-Object State, RemoteAddress |

    Export-Csv "$CaseRoottcp-connections.csv" -NoTypeInformation -Encoding UTF8

Эта команда, фактически, более продвинутый netstat (но без UDP), записывающий вывод в файл.

На лабораторном стенде повторяем ^[17] netstat еще десять раз. Никакого подозрительного вывода. Почему?

netstat — это снимок состояния на момент запуска команды. Он показывает соединения, существующие в данную миллисекунду. Если есть устойчивый канал – он его покажет. Но если соединения короткие и/или редкие — имеем все шансы не увидеть вредоносный коннект. Однако, отсутствие соединения в netstat не опровергает наличие C2-канала.

На хосте может быть еще один источник информации ^[18] о сети – журнал брандмауэра.

Get-NetFirewallProfile |
    Select-Object Name, Enabled, LogAllowed, LogBlocked, LogFileName, LogMaxSizeKilobytes |
    Format-Table -AutoSize

Да, что-то есть. LogAllowed = True означает, что логируются пропущенные пакеты тоже. Копируем файл в коллекцию:

$FirewallLog = "$env:SystemRootSystem32LogFilesFirewallpfirewall.log"
Get-Item $FirewallLog | Select-Object FullName, Length, CreationTime, LastWriteTime
Copy-Item $FirewallLog "$CaseRoot4-pfirewall.log"
Get-FileHash "$CaseRootpfirewall.log" -Algorithm SHA256 | Format-List

Хэш файла запишется в транскрипт, в случае чего это можно будет поднять.

Смотрим в лог, видим два обращения к адресу на порт 8080 с интервалом в минуту

Минутный интервал означает автоматику, а не человека. В реальной жизни адрес 95% был бы белым, и, возможно, для определения его вредоносности вам потребуется пробить его через Virustotal. Кроме того, замечу, что логи брандмауэра показали лучший результат, чем netstat, а значит, логирование на периметровом межсетевом экране было бы столь же полезным.

В общем — лучше проводить сетевую изоляцию зараженного хоста сразу, не тратя времени на сбор netstat. Как выясняется, это не очень уж надежно.

Обратите внимание ^[19] на состав полей журнала — он объявлен в заголовке файла. Там нет ни PID, ни имени процесса. Последнее поле path — это направление (SEND или RECEIVE), а не путь к файлу.

Это я к тому, что, хоть подозрительное сетевое соединение и установлено, мы пока не можем сказать, кто инициатор. Если нет Sysmon (Event ID 3) или Event ID 5156 (Security Log, WFP), то источник будем искать через анализ процессов.

ARP и DNS-кэш

Get-NetNeighbor -IPAddress 192.168.100.11 -ErrorAction SilentlyContinue |
    Select-Object InterfaceAlias, IPAddress, LinkLayerAddress, State

Get-DnsClientCache | Where-Object {
    $_.Data -eq '192.168.100.11' }

Первая команда в PowerShell заменяет классическую утилиту arp -a и выводит состояние ARP-таблицы и ищет в нем адрес, найденный на предыдущем шаге. Она показывает соответствие между IP-адресами и физическими MAC-адресами устройств. Важно понимать, что она эффективна только при поиске адреса, находящегося в широковещательном домене исследуемого хоста. Если C2 находится в интернете (как обычно и бывает), то смотреть ARP-кэш необязательно.

Вторая команда, напротив, будет полезна и при С2 в интернете. Get-DnsClientCache выводит содержимое локального кэша DNS-клиента. Когда вредоносное ПО пытается связаться со своим C2-сервером в интернете по доменному имени, операционная система сначала разрешает это имя в IP-адрес и сохраняет результат в кэш. Пока у записи не истек TTL, здесь можно будет увидеть домен и использовать это в дальнейшем расследовании.

Если команда Get-DnsClientCache не возвращает полезных данных, это может означать как истечение TTL, так и то, что обращение идет напрямую по IP, без использования ресолва.

Завершить снятие состояния сети можно командой ipconfig /all. Незнакомый виртуальный VPN-адаптер может быть ^[20] способом связи с C2.

И проверка системного прокси:

netsh winhttp show proxy

Заключение первой части

Итак, мы рассмотрели принципы расследования, инструменты, фиксацию состояния хоста и как снимать данные сетки.

На лабораторном RDS зафиксировано состояние хоста, в сети найдено подозрительное обращение на 192.168.100.11:8080 — правда, пока есть только записи в логе брандмауэра, процесс-инициатор неизвестен. Процесс с кучей исходящих подключений (PID 8724) при проверке оказался браузером. То есть зацепка есть, а вот кто именно за ней стоит — ещё нет. Дальше — изоляция хоста и разбор процессов и служб, где эта связь (возможно) обретёт имя.

---

НЛО прилетело и оставило здесь промокод для читателей нашего блога:
-15% на заказ нового VDS ^[21] — HABRFIRSTVDS.