Справочник системных ошибок и решений

Windows Server, Active Directory, 1С:Предприятие, СУБД, Linux, Cisco, MikroTik, Asterisk.

⚠️ Важная информация Все материалы, инструкции, команды и скрипты на сайте предоставлены исключительно в ознакомительных целях. Их применение может повлиять на работу операционной системы, программного обеспечения, баз данных, сетевого оборудования и других компонентов инфраструктуры. Перед выполнением действий создайте резервную копию и по возможности протестируйте изменения в безопасной среде. Пользователь самостоятельно оценивает риски и несет ответственность за результат. При отсутствии необходимых знаний обратитесь к квалифицированному ИТ-специалисту.

4104 Windows Server, AD и Роли

Event ID 4104: Аудит блоков сценариев PowerShell (Script Block Logging)

Обновлено: 15.08.2026 · Официальная документация ↗

Архитектура аудита PowerShell (AMSI / Script Block)

Событие 4104 логируется в специальном журнале Microsoft-Windows-PowerShell/Operational. Сообщение: «Создание блока сценария... (Scriptblock text)». Это Святой Грааль информационной безопасности. Современные хакеры и вирусы почти не используют .exe файлы. Они используют бесфайловые атаки (Fileless Malware), загружая вредоносные скрипты PowerShell прямо в оперативную память. Обычный аудит процессов (4688) покажет только запуск powershell.exe. Но событие 4104 покажет весь исходный код скрипта, который был запущен.

Деобфускация (AMSI)

Уникальная особенность 4104 (начиная с PowerShell 5.0) — интеграция с AMSI. Даже если хакер зашифровал свой скрипт в Base64 или использовал сложную обфускацию (запутывание), PowerShell ядро (Engine) обязано расшифровать его перед выполнением. Именно расшифрованный, чистый вредоносный код попадет в текст события 4104.

Пошаговое дерево решений (Настройка и Threat Hunting)

Сценарий 1: Включение аудита Script Block Logging (GPO)

По умолчанию Windows логирует в 4104 только те скрипты, которые покажутся подозрительными встроенному Defender. Нам нужно логировать 100% скриптов.

  1. Откройте gpmc.msc.
  2. Перейдите: Конфигурация компьютера -> Адм. шаблоны -> Компоненты Windows -> Windows PowerShell.
  3. Найдите политику Включить ведение журнала блоков сценариев PowerShell (Turn on PowerShell Script Block Logging).
  4. Включите политику. Дополнительно поставьте галочку Log script block invocation start/stop events.
  5. Выполните gpupdate /force на серверах.

Сценарий 2: Поиск вредоносных команд (Threat Hunting)

Вы можете проактивно искать маркеры работы Mimikatz, BloodHound или команд скачивания вирусов в сыром коде скриптов.

Скрипт поиска опасных блоков:
# Ищем вызовы Invoke-WebRequest, IEX, Net.WebClient, Mimikatz
$MalwareTerms = 'Invoke-Mimikatz|IEX|Net.WebClient|DownloadString|System.Reflection.Assembly|VirtualAlloc'
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-PowerShell/Operational'; ID=4104} | 
    Where-Object {$_.Properties[2].Value -match $MalwareTerms} | 
    Select-Object TimeCreated, 
    @{N='ScriptBlockText';E={$_.Properties[2].Value}} | Format-List

Сценарий 3: Защита от отключения (Downgrade Attacks)

Хакеры знают про 4104. Они используют атаку понижения версии (Downgrade Attack), запуская powershell.exe -version 2.0. Старый PowerShell 2.0 не умеет писать 4104 и слеп к аудиту.

Решение: Полностью удалите компонент PowerShell 2.0 из Windows Server через Server Manager (Удаление ролей и компонентов).

Типовые ошибки администраторов

  • Отказ от сбора логов Operational: Большинство администраторов настраивают SIEM на сбор только журналов System и Security. В результате они вообще не видят логи PowerShell. Обязательно добавьте канал Microsoft-Windows-PowerShell/Operational в настройки вашего WEF (Event Forwarding).
Не замечаете, как хакеры живут в вашей оперативной памяти месяцами?
Бесфайловые угрозы (Fileless Malware) обходят 95% классических антивирусов. Защита серверов требует проактивного Threat Hunting'а. Делегируйте ИБ профессионалам ITSTM: мы внедрим EDR-систему, включим Script Block Logging, настроим AppLocker (Constrained Language Mode) и заблокируем исполнение несанкционированных скриптов.
💡 Практика специалистов: При анализе инцидентов хакеры часто пытаются отключить Script Block Logging прямо на лету, выполняя команду `$ProgressPreference = 'SilentlyContinue'` или инжектируя код в память для обхода ETW-провайдера (ETW Patching). Внедрение систем Endpoint Detection and Response (EDR) на уровне ядра (Mini-filters) — единственный способ гарантировать целостность телеметрии.

Частые вопросы (FAQ)

Почему текст скрипта в логе 4104 разбит на несколько событий?

Поле журнала EVTX имеет лимит длины. Если хакер запустил гигантский скрипт (например, фреймворк Empire на 10 000 строк), PowerShell разобьет его на несколько логов 4104. Используйте поле 'MessageNumber' и 'MessageTotal' для их склейки в SIEM.

Записывает ли 4104 пароли администратора?

Да! Если вы пишете скрипт резервного копирования и вставляете туда пароль открытым текстом (Cleartext), этот пароль попадет в журнал 4104 и будет доступен любому, кто читает логи. Всегда используйте SecureString и PSCredential.

Поможет ли ExecutionPolicy Bypass скрыть логи?

Нет. Флаг -ExecutionPolicy Bypass отключает защиту запуска скриптов, но никак не влияет на систему логирования. Ядро PowerShell все равно запишет скрипт в 4104.

Чем 4104 отличается от 4103?

4104 (Script Block) логирует сам ТЕКСТ исполняемого скрипта или команды. 4103 (Module Logging) логирует этапы выполнения (пайплайны), показывая, какие переменные и значения передавались между функциями.

Генерируется ли 4104 при использовании PowerShell ISE / VS Code?

Да, любой хост, загружающий библиотеку System.Management.Automation.dll (даже кастомные приложения на C#, исполняющие PS-скрипты внутри себя), будет генерировать эти логи.

Полезные материалы
Рекомендуем