10 Event ID, которые должен отслеживать каждый сисадмин малого офиса

За пятнадцать лет в айти-аутсорсинге я разбирал десятки взломанных серверов и почти всегда находил одно и то же: в журнале событий вся история уже была записана. Просто её никто не читал. Малый офис на 15-40 рабочих мест обычно останавливается на связке антивирус плюс бэкап и живёт спокойно, пока гром не грянет. Event Viewer открывают раз в год, и то когда сервер уже лежит. Ниже — десять Event ID, которые реально стоит держать на мушке, если у вас нет штатного безопасника, а есть только вы и час-полтора в неделю.

Зачем открывать Event Viewer, если антивирус молчит

Антивирус ловит вредоносный файл. А брутфорс пароля на RDP — это не файл, это просто перебор комбинаций логин-пароль через порт 3389. Никакого сигнатурного анализа тут не сработает, потому что ничего вредоносного на диск не падает. У меня был клиент, небольшая торговая компания на 12 человек, у которой директор сам пробросил RDP наружу для удалённой работы бухгалтера. Пароль был "Company2023". Через три недели сервер шифровали ночью, а Kaspersky всё это время молчал — вирус зашёл легально, под учётной записью с подобранным паролем.

Windows пишет буквально всё: кто вошёл, кто вышел, кого создали, кого удалили, кто получил права администратора. Это бесплатная телеметрия, которая уже встроена в систему и просто ждёт, когда на неё посмотрят. Первый и самый важный ID тут — 4625, неудачная попытка входа. Одна такая запись — ничего страшного, кто-то опечатался. Три тысячи записей за ночь с разных IP — это словарная атака, и сервер уже штурмуют.

Смотрите в детали события: там есть исходный IP, имя учётки, под которой пытались зайти, и имя рабочей станции. Если в логине мелькает admin, administrator или root — забудьте про случайность, это автоматический скрипт перебора. Мой совет банален, но его никто не выполняет: RDP наружу без VPN — это дверь нараспашку, а не удобство для бухгалтера.

4624, 4634, 4740 — кто зашёл, кто вышел, кого заблокировало

Событие 4624 — это успешный вход. Но само по себе оно бесполезно, если не смотреть на поле Logon Type. Тип 2 — это вход за клавиатурой сервера, физически или через KVM. Тип 10 — RemoteInteractive, то есть классический RDP. Тип 3 — сетевой доступ, например к общей папке. Когда у меня главный бухгалтер клиники на Каширском шоссе якобы зашла на сервер 1С в три часа ночи с типом входа 10, это оказался не трудоголизм, а её пароль, слитый через фишинговое письмо неделей раньше.

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

Отдельно держите в поле зрения 4740 — блокировку учётной записи после превышения количества неудачных попыток. Если у вас в домене Group Policy настроена блокировка после 5 попыток (а она должна быть настроена, иначе зачем вообще эта статья), массовые 4740 по разным пользователям почти всегда значат одно: кто-то методично подбирает пароли ко всем учёткам подряд, а не только к одной привилегированной.

4720 и 4726 — рождение и смерть учётных записей

Событие 4720 фиксирует создание новой учётной записи пользователя. В офисе на 20-30 рабочих мест таких событий в норме бывает одно-два в месяц — приняли нового сотрудника, завели ему учётку. Если 4720 появляется в пятницу вечером или в выходной, и никто из HR вам об этом не говорил — это повод написать директору напрямую, а не ждать понедельника.

У одного клиента, юридической фирмы на Пресне, была типичная история: бухгалтера уволили, доступ в 1С отключили, а вот доменную учётку в Active Directory забыли деактивировать. Через две недели человек зашёл через VPN и скачал базу контактов — не со зла даже, просто по привычке. Событие 4725 (отключение учётки) должно идти рука об руку с приказом об увольнении день в день, а не через две недели, когда HR наконец вспомнит прислать вам письмо.

4726 — удаление учётной записи — событие редкое и почти всегда осознанное. Если оно случилось без вашего участия и без заявки в тикет-систему, проверяйте, кто вообще имеет права Domain Admin в вашей организации. Часто оказывается, что таких прав на пять человек больше, чем нужно, просто исторически так сложилось с 2019 года.

4732 и 4728 — новый администратор в сети. Это не шутка

Событие 4732 — добавление пользователя в локальную группу с повышенными правами, например в Administrators на конкретной машине. Событие 4728 — то же самое, но для доменной группы, скажем Domain Admins. Это, пожалуй, самое критичное событие из всего списка, потому что легитимных причин для него в обычный рабочий день немного, а вот сценариев атаки — масса.

Классика жанра: шифровальщик закрепляется в сети, компрометирует одну рабочую станцию через фишинг, а дальше методично повышает привилегии скомпрометированной учётки до администратора домена — именно через операции, которые логируются как 4728. Я разбирал инцидент у производственной компании в Подмосковье, где злоумышленник добавил служебную учётку 1С-сервера в группу Domain Admins в 2:47 ночи. Никто не заметил трое суток, пока не легло всё, включая Veeam с резервными копиями.

Настройте хотя бы простейшее уведомление на эти два ID через Task Scheduler — Windows умеет привязывать задачу к конкретному событию в журнале и слать письмо или запускать скрипт. Это бесплатно, встроено в систему, и настраивается за двадцать минут. Ждать, пока купите Wazuh или полноценный SIEM, не нужно — начните с этого.

1102 и 4719 — когда подчищают следы

Событие 1102 значит, что кто-то очистил журнал безопасности целиком. Легитимных причин для этого практически не бывает — разве что вы сами это сделали ради экономии места на диске, что тоже, честно говоря, плохая практика. Во всех остальных случаях 1102 — это финальный аккорд атаки: злоумышленник уже сделал что хотел и теперь заметает следы, чтобы вы не разобрались, как он зашёл и что унёс.

Парадокс в том, что само событие 1102 удалить нельзя — оно как раз и фиксирует факт очистки, окно события "Log was cleared" остаётся в журнале даже после того, как всё остальное стёрто. Так что если вы открываете Event Viewer и видите пустой журнал безопасности с одной-единственной свежей записью 1102 — это не баг, это красный флаг размером с Красную площадь.

4719 — изменение политики аудита. Кто-то отключил логирование определённых типов событий, чтобы дальнейшие шаги не попадали в журнал вообще. Это происходит перед атакой, а не после — злоумышленник сначала отключает слежку за собой, а потом уже действует. Если вы не трогали настройки аудита через gpedit или Group Policy Management, а 4719 в логах есть — разбирайтесь немедленно, не откладывая на after lunch.

Event ID 41 и другие про сбои, а не про атаки

Не все важные события — про хакеров. Event ID 41 в системном журнале (Kernel-Power) означает, что компьютер перезагрузился без штатного завершения работы — попросту говоря, вырубился и не сказал никому почему. Один раз в год — совпадение, скачок напряжения. Три раза в неделю на сервере с базой 1С — это уже диагноз, и диагноз этот обычно называется "сдох блок питания" или "села батарея на ИБП".

У меня был случай в небольшой стоматологической клинике: сервер с 1С падал по Event ID 41 примерно раз в десять дней, всегда в разное время, без всякой закономерности. Три недели гадали на удалённом мониторинге, пока не съездили на месте и не обнаружили, что резервный ИБП APC отработал свой ресурс ещё в 2022 году и просто перестал держать нагрузку при малейшей просадке в сети. Заменили батарейный блок за 4 200 рублей — и Event ID 41 исчез навсегда.

Рядом с ним стоит смотреть 6008 — событие о неожиданном выключении, которое система фиксирует уже при следующей загрузке, и 7031 или 7034 — аварийное завершение критичной службы. Если это служба SQL Server или служба агента 1С, три таких события за неделю значат, что база данных скоро будет повреждена, и лучше сделать внеплановый Veeam-бэкап прямо сейчас, а не после того как всё уже не открывается.

Как реально организовать мониторинг без бюджета на SIEM

Полноценные SIEM-системы стоят от нескольких сотен тысяч рублей в год лицензий плюс зарплата аналитика, который будет в них сидеть. Для конторы на 20-40 рабочих мест это просто нерентабельно, и я не буду вам врать, что это необходимо. Начните с малого: PowerShell-команда Get-WinEvent с фильтром по нужным ID, запущенная по расписанию через Task Scheduler раз в час, с выгрузкой результата на почту или в Telegram-бот — это можно собрать за один вечер, и это уже закроет девяносто процентов рисков малого офиса.

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

Главное — определитесь с приоритетом. 1102 и 4728 должны прилетать вам мгновенно, хоть ночью, хоть в отпуске. 4625 и Event ID 41 достаточно проверять раз в день утренней сводкой. А вот 4624 по обычным пользователям в рабочее время можно вообще не мониторить в реальном времени — там сигнал теряется в шуме. Мониторинг логов — это не про "смотреть всё", это про "смотреть то, что реально важно", а остальное пусть копится в архиве на случай расследования.

Частые вопросы

Нужен ли малому офису платный SIEM для мониторинга событий?
Нет, не для старта. Для конторы на 15-50 рабочих мест хватает связки Task Scheduler плюс PowerShell-скрипт с оповещением на почту или в Telegram — это закрывает базовые сценарии брутфорса и эскалации привилегий бесплатно. К платным решениям вроде Wazuh или коммерческим SIEM имеет смысл переходить, когда серверов становится больше пяти-семи и вручную уже не уследить.

Как часто нужно вручную заглядывать в Event Viewer, если нет автоматических оповещений?
Минимум раз в неделю, а после инцидента у клиента или при внешнем RDP-доступе — раз в день. Проверяйте журнал безопасности на предмет всплесков 4625 и любые единичные события 1102, 4719, 4728 — их не должно быть вообще без вашего ведома.

Что делать, если в журнале обнаружился Event ID 1102, который я точно не запускал?
Немедленно менять пароли всех административных учёток и отключать удалённый доступ до выяснения обстоятельств. Дальше поднимать резервные копии Veeam за последнюю неделю и проверять целостность базы 1С и файловых шар — 1102 почти всегда означает, что атака уже случилась, а не только начинается.

Реально ли настроить такой мониторинг самому, если я не безопасник, а единственный айтишник в компании?
Вполне. Базовый скрипт на Get-WinEvent с фильтром по десятку ID из этой статьи и отправкой письма через Task Scheduler собирается за вечер даже без глубоких знаний PowerShell — примеров в интернете достаточно. Это не требует сертификатов CISSP, требует только желания один раз потратить пару часов вместо того чтобы потом тратить неделю на разбор взлома.