Корреляция процессов и сетевых соединений в Windows

от

«Стандартные утилиты Windows выдают разрозненные данные, которые в отрыве друг от друга не дают картины угроз. Но если соединить PID из netstat с деталями процесса, вскрывается скрытая сетевая активность, которую стандартные средства мониторинга пропускают.»

Почему стандартные инструменты недостаточны

Подсистема ядра Windows, отвечающая за сеть (Network Stack), и диспетчер процессов (Process Manager) работают независимо. Команда tasklist отображает список исполняемых модулей, но не знает, к каким сокетам они привязаны. netstat, в свою очередь, показывает открытые порты и соединения, но без контекста — непонятно, какая программа их открыла. Ключом к корреляции служит идентификатор процесса (PID), который присутствует в выводах обеих команд.

Современные угрозы редко запускают собственный исполняемый файл. Чаще они внедряются в легитимные процессы, такие как svchost.exe или dllhost.exe, используя их сетевой стек. Без сопоставления PID и процесса подозрительное соединение выглядит как обычный системный «шум».

Ключевые команды для мониторинга сетевых соединений

netstat с расширенными флагами

netstat -afo
# -a: Все соединения и порты
# -f: Отображение полного доменного имени (FQDN) вместо IP
# -o: PID процесса для каждого соединения
netstat -ano
# -n: Числовой формат (быстрее, без DNS-запросов)
# -o: PID процесса

Критические ограничения netstat

  • Отсутствие пути к файлу: netstat показывает только имя процесса, а не полный путь к исполняемому файлу. Зловред может назваться svchost.exe, но запускаться из временной папки.
  • Состояния соединений: Соединения в состоянии TIME_WAIT или CLOSE_WAIT могут сохраняться в таблице после завершения сессии, создавая ложное впечатление активности.
  • Raw sockets и руткиты: Низкоуровневые вредоносные программы, работающие через raw sockets, могут обходить стандартные механизмы отслеживания соединений TCP/UDP.
  • Права доступа: Для отображения сетевой активности всех процессов, включая системные и от других пользователей, требуется запуск с правами администратора.

Для преодоления первого ограничения необходима корреляция с другими инструментами.

Идентификация процессов через PowerShell

PowerShell предоставляет более глубокий инструментарий для анализа процессов по сравнению с классической командной строкой.

Сравнение инструментов для анализа процессов

Инструмент Особенности Ценность для расследования
tasklist Базовая утилита командной строки, показывает имя, PID, использование памяти. Низкая. Не показывает путь к файлу, владельца, загруженные модули.
Get-Process (PowerShell) Возвращает объекты с десятками свойств: полный путь (Path), время запуска (StartTime), владелец (SessionId, связанный с пользователем), список модулей (Modules). Высокая. Позволяет провести детальный анализ происхождения и активности процесса.
ps (PowerShell Alias) Алиас для Get-Process. Поведение идентично. Высокая. Удобство для быстрого использования в консоли PowerShell.

Фильтрация системного шума

Большинство сетевых соединений на рабочей станции или сервере создаются системными и служебными процессами. Чтобы сфокусироваться на потенциально опасной активности, их можно отфильтровать.

# Исключаем наиболее частые системные процессы-хост-контейнеры
Get-Process | Where-Object {
  $_.ProcessName -notmatch "^svchost$|^dllhost$|^RuntimeBroker$|^SearchIndexer$"
} | Select-Object Id, ProcessName, Path, StartTime

Такой подход может сократить объём данных для первичного анализа на 60-80%.

Схема, показывающая разделение данных: слева netstat (порты, IP, состояния, PID), справа Get-Process (PID, имя, путь, время запуска). Стрелка связывает общие PID в центре.

Практический кейс: обнаружение скрытого C2-канала

Рассмотрим гипотетический, но реалистичный сценарий, где вредоносная библиотека внедрена в стандартный системный процесс.

Шаг 1: Выявление аномальных соединений

Ищем установленные соединения на стандартном HTTPS-порту, который часто используется для легитимного и вредоносного трафика.

netstat -ano | findstr ":443.*ESTABLISHED"
TCP    192.168.1.45:52874    185.143.223.18:443    ESTABLISHED     4288
TCP    192.168.1.45:52875    91.218.114.7:443      ESTABLISHED     4288

Обнаружено, что процесс с PID 4288 поддерживает два параллельных шифрованных соединения с разными внешними IP-адресами. Для клиентского приложения вроде браузера это нормально, но для многих фоновых процессов — подозрительно.

Шаг 2: Идентификация процесса по PID

Get-Process -Id 4288 | Select-Object Name, Id, Path, StartTime, Company

Name    Id   Path                                StartTime           Company
----    --   ----                                ---------           -------
dllhost 4288 C:WindowsSystem32dllhost.exe     07.02.2026 02:14:22 Microsoft Corporation

Критические аномалии (красные флаги)

  • Нехарактерная активность: dllhost.exe (хост для COM-объектов) крайне редко инициирует исходящие HTTPS-соединения, тем более на разные адреса.
  • Временные метки: Время запуска процесса (02:14) не совпадает со временем загрузки системы, что указывает на запуск вручную или автоматически позже.
  • Отсутствие родительского процесса: Легитимный dllhost обычно запускается по запросу от другого приложения (например, через DCOM). В данном случае родительский процесс может отсутствовать или быть неожиданным.
  • Цифровая подпись: Хотя файл подписан Microsoft, это не гарантия чистоты, так как код мог быть исполнен в контексте этого легитимного процесса после внедрения.

Шаг 3: Дополнительная верификация

# Проверка подписи файла (косвенный признак)
Get-AuthenticodeSignature -FilePath "C:WindowsSystem32dllhost.exe"

# Просмотр активных TCP-соединений процесса через PowerShell (альтернатива netstat)
Get-NetTCPConnection -State Established -OwningProcess 4288 | Select-Object RemoteAddress, RemotePort

# Анализ загруженных модулей процесса (поиск сторонних DLL)
(Get-Process -Id 4288).Modules | Where-Object {$_.ModuleName -notlike "*windows*"} | Select-Object ModuleName, FileName

Оптимизация вывода для анализа

Для решения конкретных задач мониторинга можно создавать специализированные однострочные команды.

Мониторинг открытых портов (LISTENING)

netstat -ano | findstr "LISTENING" | findstr /V "[::]"

Команда отфильтрует только IPv4-порты, ожидающие входящих подключений. Ключ /V исключает IPv6-адреса.

Поиск активности на критических портах

# Мониторинг RDP (порт 3389)
netstat -ano | findstr ":3389"

# Мониторинг возможных оболочек (порты 4444, 8080 и т.д.)
netstat -ano | findstr ":4444 :8080 :9001"

Корреляция в реальном времени

# Цикл для мониторинга новых установленных соединений с интервалом в 10 секунд
while ($true) {
    $conn = netstat -ano | findstr "ESTABLISHED"
    if ($conn) {
        $time = Get-Date -Format "HH:mm:ss"
        Write-Host "`n[$time] Новые соединения:" -ForegroundColor Yellow
        $conn
    }
    Start-Sleep -Seconds 10
}

Типичные ошибки при анализе процессов

Распространённые ошибки

  • Анализ в отрыве от контекста: Изучение списка процессов без привязки к сетевой активности или наоборот.
  • Доверие к имени: Игнорирование процесса только потому, что его имя совпадает с системным (lsass.exe, csrss.exe), без проверки пути запуска.
  • Узкий фокус: Проверка только активных (ESTABLISHED) соединений, игнорируя открытые порты (LISTENING), которые могут ждать входящей команды.
  • Отсутствие базиса для сравнения: Невозможность отличить аномалию, потому что не зафиксировано нормальное состояние системы (какие процессы и порты обычно активны).

Профессиональные практики

  • Всегда коррелировать данные: PID из netstat -ano обязан быть проверен через Get-Process -Id PID | Format-List * для получения полной информации.
  • Проверять происхождение файла: Анализировать не только цифровую подпись, но и хеш-сумму файла, а также его расположение на диске.
  • Собирать данные в три этапа: 1) Базовая линия (норма). 2) Данные во время инцидента. 3) Состояние после принятия мер. Это позволяет оценить эффективность ответа.
  • Учитывать ограничения прав: При написании скриптов для сбора данных с множества систем использовать конструкцию -ErrorAction SilentlyContinue, чтобы ошибки доступа к чужим сессиям не прерывали весь процесс сбора.

Ручная корреляция через netstat и Get-Process — фундаментальный навык. Он не только помогает в оперативном реагировании, но и формирует понимание того, как устроена сетевая активность в системе, что необходимо для настройки более сложных систем мониторинга, соответствующих требованиям регуляторов.

Загрузка…

Оставьте комментарий