Кто и когда заходил на компьютер по следам в журнале безопасности

Каждый вход в систему оставляет след, даже если человек об этом не подозревает. Windows ведёт подробную летопись того, кто, когда и каким способом получил доступ к машине, и хранит её в журнале безопасности. Большую часть времени эта летопись пылится невостребованной, но в нужный момент превращается в незаменимый источник правды. Уволенный сотрудник якобы не заходил после увольнения, а вход был. Пользователь клянётся, что не вводил неверный пароль, а в журнале десятки неудачных попыток. Кто-то подключился к машине ночью, когда в офисе никого не было. Все ответы лежат в этих записях, надо лишь уметь их прочитать.

Журнал безопасности отличается от прочих журналов системы своей дотошностью. Он фиксирует не только сам факт входа, но и массу подробностей: имя учётной записи, точное время, способ входа, источник подключения. По этим деталям восстанавливается картина событий с почти детективной точностью. Проблема в том, что записей много, они формализованы и закодированы числовыми идентификаторами, и без понимания этого языка журнал выглядит непролазной чащей. Стоит разобраться в ключевых кодах и приёмах фильтрации, и чаща превращается в понятную хронику.

Язык числовых кодов событий и что скрывается за главными из них

Каждый тип события в журнале безопасности помечен своим числовым идентификатором, и знание нескольких ключевых кодов открывает девяносто процентов повседневных задач. Главный из них это код успешного входа в систему. Именно он отвечает на вопрос кто и когда зашёл, и встречается в журнале чаще всего. Выбрать последние успешные входы можно через PowerShell по этому коду:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 20 | Format-Table TimeCreated, Id, Message -AutoSize

В описании такого события указаны имя и домен учётной записи, под которой выполнен вход, что сразу даёт ответ на первый вопрос любого расследования.

Рядом живёт код неудачного входа, и его ценность для безопасности трудно переоценить. Череда таких событий подряд это классический почерк подбора пароля, когда кто-то методично перебирает варианты, пытаясь угадать учётные данные. Тот же запрос с кодом неудачного входа выводит подозрительную активность:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 50 | Format-Table TimeCreated, Message -AutoSize

Один-два неудачных входа это обычная человеческая забывчивость, а вот десятки за короткий промежуток это уже тревожный сигнал, требующий внимания. Этот же код помогает разобраться в загадочных блокировках, когда учётная запись запирается из-за множества неверных попыток, источник которых поначалу неясен.

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

Тип входа как ключ к пониманию способа доступа

Внутри события входа прячется параметр исключительной важности, тип входа. Он отвечает на вопрос не кто зашёл, а как именно, и без него картина остаётся неполной. Windows различает множество способов попасть в систему, и каждому присвоен свой номер типа. Интерактивный вход означает, что человек физически сел за машину и ввёл пароль с клавиатуры на экране входа. Сетевой вход случается, когда к компьютеру обращаются по сети, открывая общую папку или печатая на сетевом принтере.

Это различие критично для верной трактовки записей. Допустим, в журнале значится вход под учётной записью сотрудника глубокой ночью. Звучит тревожно, пока не посмотришь на тип входа. Если он сетевой, то, скорее всего, это просто фоновое обращение к общей папке на машине, а вовсе не человек, ночью пробравшийся к компьютеру. А вот интерактивный вход в это время это уже совсем другой разговор, требующий объяснений. Без типа входа легко поднять ложную тревогу или, наоборот, проглядеть настоящую.

Особый случай это тип входа, возникающий при использовании кэшированных доменных учётных данных. Когда пользователь входит под доменной учёткой, а контроллер домена недоступен, система проверяет пароль по локально сохранённым данным и регистрирует вход с особым типом. Проверить, включён ли вообще аудит входов, без которого журнал будет пуст, позволяет команда:

auditpol /get /category:"Вход/выход"

А при нужде аудит и неудачных, и успешных входов включается так:

auditpol /set /subcategory:"Вход в систему" /success:enable /failure:enable

По умолчанию Windows кэширует последние использованные доменные учётные записи, чтобы человек мог войти даже без связи с контроллером. Видя в журнале этот тип, администратор понимает, что вход прошёл по кэшу, а не через живую проверку на контроллере, и это объясняет, почему то же событие могло не отразиться на сервере.

Графический просмотр журнала и базовая фильтрация

Точка входа для работы с журналом это графическая оснастка просмотра событий. Она открывается короткой командой, вызывающей знакомое многим окно с деревом журналов:

eventvwr.msc

В этом окне журнал безопасности лежит в разделе журналов Windows, и при первом открытии он встречает неподготовленного человека сплошным потоком записей, в котором немудрено утонуть. Спасение здесь это фильтрация. Оснастка позволяет отобрать только события с нужным идентификатором, и, указав код успешного входа, администратор разом отсекает весь посторонний шум, оставляя лишь интересующие его записи о входах в систему.

Фильтр по одному коду это лишь начало. Внутри отобранных событий ищут по имени конкретной учётной записи, чтобы проследить активность одного человека, или сужают выборку по типу входа, чтобы отделить живые входы от сетевых обращений. Графическая оснастка хороша наглядностью и годится для разбора единичного случая на одной машине, когда нужно своими глазами пройтись по событиям и вчитаться в подробности каждого. Но при работе с потоком данных или несколькими машинами на смену графике приходит командная строка.

Командные инструменты для выборки и автоматизации

Когда нужно вытащить из журнала конкретный срез данных или обработать события скриптом, на сцену выходит PowerShell с его мощным механизмом запросов к журналам. Команда получения событий умеет фильтровать записи по журналу, идентификатору и времени прямо при выборке, что несравнимо быстрее ручного перебора. Поиск всех неудачных входов за последние сутки выглядит компактно:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddDays(-1)}

Здесь в фигурных скобках задаётся набор условий: журнал безопасности, код неудачного входа и начало периода в виде вчерашней даты. Команда вернёт ровно те события, что попадают под все условия, и сделает это за мгновение даже на большом журнале. Возвращённые события приходят как объекты, которые легко дальше фильтровать, считать и выгружать в отчёт, что превращает разовый поиск в основу для регулярного автоматического мониторинга.

Вторая рабочая лошадка это утилита wevtutil, заточенная под управление журналами из командной строки. Она умеет не только читать события, но и показывать настройки самих журналов, что бывает нужно при отладке аудита. Запрос свойств журнала безопасности выполняется лаконично:

wevtutil gl Security

Эта команда покажет параметры журнала: его размер, политику перезаписи старых событий, права доступа. Понимание этих настроек важно, потому что от размера журнала и политики перезаписи зависит, как глубоко в прошлое простирается доступная история. Маленький журнал с агрессивной перезаписью хранит лишь свежие события, и при расследовании давнего инцидента нужных записей в нём может уже не оказаться, о чём стоит позаботиться заранее, увеличив объём журнала на важных машинах.

Практические расследования, ради которых всё затевается

Соберём приёмы воедино через типичные задачи. Разбор блокировки учётной записи это, пожалуй, самый частый повод заглянуть в журнал. Учётка пользователя раз за разом запирается, человек нервничает, работа стоит. Фильтр по коду неудачного входа быстро показывает источник лишних попыток, и нередко выясняется, что виноват старый сохранённый пароль на какой-то машине или забытая сессия на телефоне, методично долбящая в систему неверными данными. Найдя источник, проблему устраняют в корне, а не борются с симптомом, сбрасывая блокировку по десять раз на дню.

Другая задача это проверка факта доступа в конкретное время. Когда нужно подтвердить или опровергнуть, заходил ли определённый человек на машину в определённый момент, журнал даёт точный ответ. Фильтр по коду успешного входа и имени учётной записи показывает все входы этого пользователя, а тип входа уточняет, был ли это живой человек за клавиатурой или фоновое сетевое обращение. Такая выборка не раз ставила точку в спорах, где одна сторона уверяла, что доступа не было, а беспристрастный журнал свидетельствовал об обратном.

Наконец, регулярный мониторинг входов это уже не разовое расследование, а постоянная практика безопасности. Настроив автоматический сбор и анализ событий входа через скрипты, администратор замечает аномалии раньше, чем они перерастут в инцидент. Всплеск неудачных попыток среди ночи, вход под учёткой из необычного источника, активность давно неиспользуемой записи это всё ранние сигналы, которые журнал подаёт исправно, надо лишь наладить их прослушивание. Превращение журнала из пассивного архива в активный инструмент наблюдения и отличает зрелую организацию безопасности от той, что разбирается с проблемами лишь по факту.

Когда события не пишутся и как включить нужный аудит

Бывает неприятный сюрприз: администратор лезет в журнал за событиями входа, а их там нет или почти нет. Причина обычно в том, что соответствующий аудит просто не включён, и система не фиксирует то, что её не просили фиксировать. Запись событий безопасности управляется политикой аудита, и без её настройки журнал останется пустым именно в той части, которая интересует больше всего. Поэтому прежде чем расследовать по журналу, стоит убедиться, что нужный аудит вообще ведётся.

Тонкость в том, что аудит делится на категории, и для истории входов нужны именно категории, отвечающие за вход в систему и за вход учётных записей. Это две разные вещи: одна фиксирует входы на самой машине, другая проверку учётных данных, которая на контроллере домена выглядит иначе, чем на рядовой станции. Отсюда растёт частое недоумение, когда событие неудачного входа есть на клиентском компьютере, но отсутствует на контроллере, или наоборот. Разные роли машин пишут разные события, и понимание этого избавляет от бесплодных поисков записи там, где её в принципе быть не должно.

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

Выгрузка событий в файл для разбора и хранения

Отдельная полезная практика это выгрузка нужных событий в отдельный файл, чтобы разбирать их не торопясь или сохранить как доказательство. Журнал на работающей машине постоянно пополняется и перезаписывается, поэтому важные для расследования события разумно вытащить и отложить, пока они не затёрлись. Экспортировать весь журнал безопасности в файл целиком умеет команда:

wevtutil epl Security C:\Audit\security-backup.evtx

А выгрузить только отобранные события входа в текстовый отчёт помогает PowerShell:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624,4625} | Export-Csv C:\Audit\logons.csv -NoTypeInformation -Encoding UTF8

Так летучий журнал превращается в постоянный документ, который не пропадёт при следующей перезаписи.

Такая выгрузка ценна не только для хранения, но и для переноса. Когда событие случилось на одной машине, а разбираться с ним удобнее на своём рабочем месте, проще выгрузить нужный срез в файл и забрать с собой, чем сидеть за чужим компьютером. Файл с событиями открывается в той же оснастке просмотра на любой машине, и вся подробность записей сохраняется. Это превращает разбор инцидента в спокойную кабинетную работу вместо беготни по чужим столам.

Для серьёзных расследований и долгого хранения событий в крупных организациях идут дальше и настраивают централизованный сбор журналов со множества машин в единое хранилище. Тогда история входов со всего парка стекается в одно место, где её удобно анализировать целиком, искать связи между событиями на разных компьютерах и хранить столько, сколько требуют правила. Но даже без такой тяжёлой инфраструктуры простая привычка вовремя выгружать важные события в файл многократно выручает там, где журнал иначе успел бы перезаписать ценные следы.

Журнал безопасности хранит правду о том, что происходило с компьютером, в мельчайших подробностях, и эта правда доступна любому, кто выучил его язык. Несколько ключевых кодов событий, понимание типов входа и пара приёмов фильтрации превращают пугающий поток записей в ясную хронику. И тогда вопросы, которые казались неразрешимыми, кто заходил, когда, откуда и каким способом, получают точные ответы, подкреплённые беспристрастными отметками системы, которая всё это время молча вела свою летопись.