Короткий ответ

Если на WS-042 / DC / host.example журналы очищены — это сам по себе инцидент, не «админ почистил диск». Снимите остатки: 1102 (Security log cleared), 104 (системный лог), кто и когда, копии на WEF/SIEM/journalctl на коллекторе, файлы .evtx в C:\Windows\System32\winevt\Logs, ротированные syslog.1. Вынесите логирование наружу (коллектор, immutable), не увеличивайте локальный лог как единственную меру. Не format C: и не vacuum journal ещё раз.

Сбор того, что живо — артефакты. Кто мог стереть — часто админ.

Симптомы и как отличить

  • Event Viewer: Security 0 событий, последний 1102.
  • SIEM: разрыв потока с хоста, потом тишина.
  • Linux: /var/log/auth.log обнулён, journalctl --list-boots короче, чем вчера.
  • Совпадает с другими IOC.
КартинаНе атакаДействие
Штатная ротация logrotateвремя в cronпроверьте .1.gz на месте
GPO «максимум 20 МБ» перетёрла суткиёмкостьвсё равно дыра IR
Админ wevtutil cl по заявкеchangeредкость, документируйте
Переустановка ОСinventoryне этот хост

Возможные причины

  1. Атакующий с правами очистки журнала (обычно админ).
  2. Скрипт «освободить диск» с wevtutil cl / journalctl --vacuum-time=1s.
  3. Маленький буфер, естественный overwrite — выглядит как «пусто по инциденту вчера», но 1102 нет.
  4. Перенаправление лога сломалось, локально кажется пустым, коллектор жив — проверьте SIEM.
  5. Руткит прячет события (редко) — расхождение SIEM vs локально наоборот.

Диагностика

1. Windows

wevtutil gli Security
wevtutil gli System
Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=1102 } -MaxEvents 10 -ErrorAction SilentlyContinue
Get-WinEvent -FilterHashtable @{ LogName='System'; Id=104 } -MaxEvents 10 -ErrorAction SilentlyContinue
Get-ChildItem C:\Windows\System32\winevt\Logs | Sort-Object LastWriteTime -Descending | Select-Object Name, Length, LastWriteTime

Копии, если файлы ещё не нулевые:

New-Item C:\IR\logs -ItemType Directory -Force
wevtutil epl System C:\IR\logs\System.evtx /ow:true
wevtutil epl Security C:\IR\logs\Security.evtx /ow:true
wevtutil epl 'Microsoft-Windows-Windows Defender/Operational' C:\IR\logs\Defender.evtx /ow:true

На коллекторе WEF/SIEM: запрос по WS-042 за неделю до дыры.

2. Linux host.example

sudo journalctl --disk-usage
sudo ls -la /var/log /var/log/journal
sudo grep -i 'vacuum\|cleared\|logrotate' /var/log/syslog /var/log/auth.log 2>/dev/null | tail
sudo last -F
# копии того, что есть
sudo tar -czf /var/ir/varlog.tgz /var/log

auditd если был: /var/log/audit/audit.log.1.

3. Кто имел право

Windows: право «Manage auditing and security log». Linux: root. Свяжите с 4672/sudo.

Решение

Сценарий A. Есть 1102 и учётка

  1. Считайте учётку скомпрометированной, пока не доказан штатный change.
  2. Соберите SIEM/WEF.
  3. Изолируйте хост, если параллельно IOC.
  4. Ротация секретов этой учётки.

Сценарий B. Перетёрлось без 1102

Увеличьте размер журнала и включите сбор наружу. Это дыра процесса, не обязательно APT, но инцидент «не видим вчера» остаётся.

wevtutil sl Security /ms:1073741824
# 1 ГБ пример; считайте диск. Не вместо WEF

Сценарий C. Коллектор тоже пуст

Атака на логирование. Ищите доступ к SIEM/WEF, backup логов. Вынесите новый коллектор, куда прод-DA не дотягивается.

Коллектор, тени тома и кто имел Manage auditing

Локальный пустой Security при живом WEF — работайте с коллектором, не объявляйте «улик нет». Наоборот: локально полно, в SIEM дыра — чините агент, это слепота вперёд. 1102 Subject ivan.petrov = privileged abuse; SYSTEM + скрипт в GPO — найдите задание. Теневые копии тома и backup *.evtx иногда переживают cl: не chkdsk ради них.

На host.example Storage=volatile в journald означает, что reboot убьёт остаток: снимите journalctl до любой перезагрузки, затем persistent. Не vacuum «освободить 200 МБ» в IR. Вынос логирования: отдельный приёмник, куда прод-DA не локальный админ. IP 10.0.10.55 как источник WinRM перед 1102 — связка с lateral, не отдельный «баг Event Log».

Размер локального журнала увеличьте как буфер, не как архив. Архив — коллектор с retention.

Как проверить, что проблема устранена

  • 1102/факт очистки в тикете с SubjectUserName.
  • Копии с коллектора сохранены отдельно.
  • Новый поток логов идёт на внешний приёмник (тест: логон, событие появилось там).
  • Локальный размер адекватен как буфер, не как архив.
  • Учётка, стеревшая лог, разобрана.

Алерт на 1102 и на дыру потока с WS-042 в SIEM должен быть до следующего инцидента, не в «бэклоге». Право cl — узкая группа, не каждый локальный админ. На host.example rsyslog/journal-remote на коллектор, куда 10.0.10.55 не пишет. Учётка ivan.petrov с Manage auditing — пересмотр групп.

Если не помогло

  • 1102 нет, лог пуст, файл 0 байт — смотрите диск, фильтр Event Log, права. Возможен crash.
  • Linux journald volatile (в RAM) — после reboot всё умерло by design; вынесите persistent + rsyslog.
  • Политика GPO снова ставит 20 МБ — чините GPO, не только хост.
  • Атакующий чистит каждые 10 минут — изоляция важнее увеличения лога.

Профилактика

  • WEF/агент на все DC, jump, серверы, критичные ПК.
  • Алерт на 1102/104 и на дыру потока SIEM.
  • Право очистки журнала только узкой группе.
  • Immutable хранение логов.
  • Запрет скриптов vacuum/cl без заявки. Копии логов храните вне хоста, который атакующий уже чистил. Алерт на 1102 не откладывайте в бэклог.

FAQ

Достаточно ли увеличить Security до 4 ГБ?

Как буфер — да. Как единственный архив — нет. Диск кончится, атакующий всё равно cl.

Можно ли восстановить evtx undelete?

Иногда из теней тома / backup. Не обещайте. Не chkdsk ради этого первым движением.

1102 от SYSTEM

Смотрите, какой процесс; GPO/mdm/скрипт. Не «значит не человек».

Ubuntu 24.04 journal в /run

Persistent: Storage=persistent в journald.conf — штатная настройка, не отключение безопасности. Сделайте после копии того, что есть.

Нужно ли объявлять breach только из‑за 1102?

1102 = сильный сигнал сокрытия. Классифицируйте как IR, даже если «данных не украли» ещё не ясно.