Event Logging Security

The Security log is designed for use by the system. However, users can read and clear the Security log if they have been granted the SE_SECURITY_NAME privilege (the «manage auditing and security log» user right). For more information, see Privileges.

Only the Local Security Authority (Lsass.exe) has write permission for the Security log. No other account can request this privilege. To write an event to the Security log, use the AuthzReportSecurityEvent function.

Access to the Application log, the System log, and custom logs is restricted. The system grants access based on the access rights granted to the account under which the thread is running. The following table shows which types of access are required by the event logging functions.

Access right	Description
ELF_LOGFILE_CLEAR (0x0004)	Required by ClearEventLog.
ELF_LOGFILE_READ (0x0001)	Required by OpenBackupEventLog and OpenEventLog.
ELF_LOGFILE_WRITE (0x0002)	Required by RegisterEventSource.

Use the CustomSD registry value to configure the security of the Application log, the System log, and custom logs. For more information, see Eventlog Key.

WindowsВ XP/2000: The following table describes the access rights granted for each account on each log.

Log	Account	Read	Write	Clear
Application	Administrators (system)	X	X	X
Administrators (domain)	X	X	X
LocalSystem	X	X	X
Interactive user	X	X
System	Administrators (system)	X	X	X
Administrators (domain)	X	X
LocalSystem	X	X	X
Interactive user	X
Custom	Administrators (system)	X	X	X
Administrators (domain)	X	X	X
LocalSystem	X	X	X
Interactive user	X	X

To grant access to the members of the Guest account, change the following registry value:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Log\RestrictGuestAccess

Windows security log analysis

Вы здесь:
1. Главная
2. КЛИЕНТАМ
3. Статьи и материалы
4. Полезная информация из логов рабочей станции на базе ОС Windows

Полезная информация из логов рабочей станции на базе ОС Windows

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

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

Для выявления атаки на самой ранней стадии в ОС Windows есть три полезных событийных источника: журнал событий безопасности, журнал системного мониторинга и журналы Power Shell.

Журнал событий безопасности (Security Log)

Это главное место хранения системных логов безопасности. Сюда складываются события входа/выхода пользователей, доступа к объектам, изменения политик и других активностей, связанных с безопасностью. Разумеется, если настроена соответствующая политика.

Перебор пользователей и групп (события 4798 и 4799). Вредоносное ПО в самом начале атаки часто перебирает локальные учетные записи пользователей и локальные группы на рабочей станции, чтобы найти учетные данные для своих тёмных делишек. Эти события помогут обнаружить вредоносный код раньше, чем он двинется дальше и, используя собранные данные, распространится на другие системы.

Создание локальной учётной записи и изменения в локальных группах (события 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 и 5377). Атака может также начинаться, например, с добавления нового пользователя в группу локальных администраторов.

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

Попытка входа с заданной учётной записью (событие 4648). Такое бывает, когда процесс выполняется в режиме “Запуск от имени” (run as). В нормальном режиме работы систем такого не должно быть, поэтому такие события должны находиться под контролем.

Блокировка/разблокировка рабочей станции (события 4800-4803). К категории подозрительных событий можно отнести любые действия, которые происходили на заблокированной рабочей станции.

Изменения конфигурации файрволла (события 4944-4958). Очевидно, что при установке нового ПО настройки конфигурации файрволла могут меняться, что вызовет ложные срабатывания. Контролировать такие изменения в большинстве случаев нет необходимости, но знать о них точно лишним не будет.

Подключение устройств Plug’n’play (событие 6416 и только для WIndows 10). За этим важно следить, если пользователи обычно не подключают новые устройства к рабочей станции, а тут вдруг раз — и подключили.

Windows включает в себя 9 категорий аудита и 50 субкатегорий для тонкой настройки. Минимальный набор субкатегорий, который стоит включить в настройках:

• Logon;
• Logoff;
• Account Lockout;
• Other Logon/Logoff Events.

• User Account Management;
• Security Group Management.

• Audit Policy Change;
• Authentication Policy Change;
• Authorization Policy Change.

Системный монитор (Sysmon)

Sysmon — встроенная в Windows утилита, которая умеет записывать события в системный журнал. Обычно требуется его устанавливать отдельно.

Эти же события можно в принципе найти в журнале безопасности (включив нужную политику аудита), но Sysmon даёт больше подробностей. Какие события можно забирать из Sysmon?

Создание процесса (ID события 1). Системный журнал событий безопасности тоже может сказать, когда запустился какой-нибудь *.exe и даже покажет его имя и путь запуска. Но в отличие от Sysmon не сможет показать хэш приложения. Злонамеренное ПО может называться даже безобидным notepad.exe, но именно хэш выведет его на чистую воду.

Сетевые подключения (ID события 3). Очевидно, что сетевых подключений много, и за всеми не уследить. Но важно учитывать, что Sysmon в отличие от того же Security Log умеет привязать сетевое подключение к полям ProcessID и ProcessGUID, показывает порт и IP-адреса источника и приёмника.

Изменения в системном реестре (ID события 12-14). Самый простой способ добавить себя в автозапуск — прописаться в реестре. Security Log это умеет, но Sysmon показывает, кто внёс изменения, когда, откуда, process ID и предыдущее значение ключа.

Создание файла (ID события 11). Sysmon, в отличие от Security Log, покажет не только расположение файла, но и его имя. Понятно, что за всем не уследишь, но можно же проводить аудит определённых директорий.

А теперь то, чего в политиках Security Log нет, но есть в Sysmon:

Изменение времени создания файла (ID события 2). Некоторое вредоносное ПО может подменять дату создания файла для его скрытия из отчётов с недавно созданными файлами.

Загрузка драйверов и динамических библиотек (ID событий 6-7). Отслеживание загрузки в память DLL и драйверов устройств, проверка цифровой подписи и её валидности.

Создание потока в выполняющемся процессе (ID события 8). Один из видов атаки, за которым тоже нужно следить.

События RawAccessRead (ID события 9). Операции чтения с диска при помощи “\\.\”. В абсолютном большинстве случаев такая активность должна считаться ненормальной.

Создание именованного файлового потока (ID события 15). Событие регистрируется, когда создается именованный файловый поток, который генерирует события с хэшем содержимого файла.

Создание named pipe и подключения (ID события 17-18). Отслеживание вредоносного кода, который коммуницирует с другими компонентами через named pipe.

Активность по WMI (ID события 19). Регистрация событий, которые генерируются при обращении к системе по протоколу WMI.

Для защиты самого Sysmon нужно отслеживать события с ID 4 (остановка и запуск Sysmon) и ID 16 (изменение конфигурации Sysmon).

Журналы Power Shell

Power Shell — мощный инструмент управления Windows-инфраструктурой, поэтому велики шансы, что атакующий выберет именно его. Для получения данных о событиях Power Shell можно использовать два источника: Windows PowerShell log и Microsoft-WindowsPowerShell / Operational log.

Windows PowerShell log

Загружен поставщик данных (ID события 600). Поставщики PowerShell — это программы, которые служат источником данных для PowerShell для просмотра и управления ими. Например, встроенными поставщиками могут быть переменные среды Windows или системный реестр. За появлением новых поставщиков нужно следить, чтобы вовремя выявить злонамеренную активность. Например, если видите, что среди поставщиков появился WSMan, значит был начат удаленный сеанс PowerShell.

Microsoft-WindowsPowerShell / Operational log (или MicrosoftWindows-PowerShellCore / Operational в PowerShell 6)

Журналирование модулей (ID события 4103). В событиях хранится информация о каждой выполненной команде и параметрах, с которыми она вызывалась.

Журналирование блокировки скриптов (ID события 4104). Журналирование блокировки скриптов показывает каждый выполненный блок кода PowerShell. Даже если злоумышленник попытается скрыть команду, этот тип события покажет фактически выполненную команду PowerShell. Ещё в этом типе события могут фиксироваться некоторые выполняемые низкоуровневые вызовы API, эти события обычно записывается как Verbose, но если подозрительная команда или сценарий используются в блоке кода, он будет зарегистрирован как c критичностью Warning.

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

Расскажите в комментариях, какие собираете логи для аудита информационной безопасности и какие инструменты для этого используете. Одно из наших направлений — решения для аудита событий информационной безопасности. Для решения задачи сбора и анализа логов можем предложить присмотреться к Quest InTrust, который умеет сжимать хранящиеся данные с коэффициентом 20:1, а один его установленный экземпляр способен обрабатывать до 60000 событий в секунду из 10000 источников.

Прочее Как правильно анализировать cbs.log и результаты проверки sfc /scannow

Кирилл

Начну с небольшого определения:
Что такое cbs.log?

Файл-лог журнала обслуживания windows, который содержит подробные сведения об ошибках автономного обслуживания, подробные сведения об ошибках интерактивного обслуживания, а так же как вспомогательный элемент для dism.exe

Не вдаваясь в тонкости осмысливания написанного ( определение взято отсюда ) сообщу следующее:

Многим из нас знакома программа sfc.exe, с помощь которой можно проверить состояние целостности защищенных системных файлов.
(Обсуждение в этой теме: Обзор утилиты sfc.exe )
Результат ее работы будет отражен как раз так же в этом логе.
Но, для большинства пользователей, анализ результата проверки остается трудновыполнимой задачей.

Хорошо, если система рапортует о том, что защита ресурсов wiindows не обнаружила поврежденных файлов или что все поврежденные файлы восстановлены.
А что делать, если мы видим что то вроде такого сообщения?

Программа защиты ресурсов Windows обнаружила поврежденные файлы, но не может восстановить некоторые из них

Один из шагов к решению проблемы — это произвести анализ лога, который создается при сканировании. Лог-файл находится по пути %windir%\logs\cbs\cbs.log и открыть его можно любым текстовым редактором, включая стандартный notepad.
Неподготовленный пользователь, открыв и посмотрев лог, скорее всего испытает острое желание закрыть файл и больше не открывать. Поэтому, для комфорта восприятия, пользователи придумали приводить лог в более читабельный вид, распарсив его и отфильтровав «лишние» записи оставить только те, что нужны.
Сделать это можно разными методами, кстати — в сети распространен метод с парсингом файла cbs.log введя в командной строке простую команду:

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

Как быть?
Для более комфортного первоначального анализа мы с коллегами создали такой скрипт:
Проверка целостности системных файлов утилитой sfc

Запустив скрипт вы сможете произвести проверку целостности системных файлов, произвести очистку и восстановление хранилища данных windows, в котором хранятся резервные копии защищенных системных файлов windows.
Из этих копий и производится восстановление поврежденных файлов.
Скрипт выводит аналогичный, но чуть более информативный лог + копирует в каталог запуска скрипта сам файл cbs.log.
А так же очищает старые записи, что немного экономит место на диске и спасает от зависаний компьютера ( при определенных условиях) при попытке открыть cbs.log. Да и читать будет удобнее и меньше.
Это связано с тем, что порой размер файла cbs.log может раздуваться и я видел монстров по 40 с лишним мегабайт. в общем, скрипт его «облегчает» до оптимального объема.
Идем дальше.
Пробуем читать cbs.log.

Что нужно знать?

При обнаружении поврежденных защищенных системных файлов SR пытается их восстановить из хранилища данных.
Само хранилище данных находится по адресу:

И, если по каким то причинам не удалось получить доступ к файлам или в хранилище они тоже оказались повреждены — в таком случае периодически мы можем наблюдать сообщение о невозможности восстановления файлов.
К которому бонусом может присоединиться какая нибудь трабла в работе системы.
=========================================================

Напомню, что лог cbs.log находится по такому пути:

Вернемся, непосредственно, к файлу cbs.log. Вы его уже открыли в текстовом редакторе?
Открывайте.
Лично мне более удобным для работы с файлами такого типа является редактор notepad++
Так как редакторов много и каждый волен выбирать тот, что ему по душе — то далее я буду описывать свои действия в редакторе в контексте интерфейса notepad++ , а вы (если пользуетесь другим) , можете ориентироваться по аналогии в своем.

Думаю вы уже до этого находили информацию о том, что нужные нам действия помечаются тегом [SR] в каждой строке — именно по этому признаку и принято парсить cbs.log. А если вы не знали — значит узнали теперь)
Теперь у нас с вами два варианта: либо переходить сразу к проблемным файлам через поиск (это если у вас уже есть отфильтрованый одним из упомянутых методов лог) либо вывести все строки с тегом [SR].
Я лично всегда так делаю — легче потом будет навигация.
В notepad++ есть возможность вывести в дополнительной области все найденные по маске ( тегу [SR] ) строки.

Делается это просто: открываем поиск (кнопка в виде бинокля), вводим в строку поиска [SR], далее нажимаем кнопку «Найти все в текущем документе» и получаем в нижней области программы все строки найденные по нужному фильтру, а в вверхней области основной текст файла cbs.log, как видно на скриншоте:

Это позволит вам видеть проблемные места (нижняя область) и одновременно смотреть сопутсвующую информацию по ним в основном логе (верхняя область).
Ну как, все получилось?

Далее в нижней области, где отфильтрованы строки с тегом [SR] пропускаем все что выглядит примерно так:

Сделать это легко — достаточно воспользоваться скроллом, потянув за него указателем мышки.
Почему пропустить? Файлы системой защиты проверяются блоками по 100 файлов и это на сейчас служебная информация, не несущая для нас полезной нагрузки.

Как только находим нечто отличающееся — стоп.
Например:
2017-10-29 21:28:40, Info CSI 000001e1 [SR] Cannot repair member file [l:24<12>]»gpscript.exe» of Microsoft-Windows-GroupPolicy-Script, Version = 6.1.7601.23452, pA = PROCESSOR_ARCHITECTURE_INTEL (0), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = , Type neutral, TypeName neutral, PublicKey neutral in the store, hash mismatch

Все, сейчас мы нашли то, что надо.
Если вбить в переводчик то, что написано раздельным текстом, то можно вполне понять что не так.
На примере данной строки давайте и разберемся.

Пусть перевод несколько забавный, но суть мы уловили — не удалось восстановить файл gpscript.exe, в хранилище компонентов он так же считается поврежденным, так как хэш сумма файла не совпадает с эталоном.
Что дальше?
Дальше можно либо приступить к восстановлению хранилища компонентов, либо смотреть какой файл нужен, где он должен лежать и как его восстановить, если нет возможности автоматически восстановить хранилище компонентов.
Начнем с второго варианта — получаем информацию о файле. Находим упомянутую строку в основном логе:

Тут мы отчетливо видим, что файл в хранилище должен быть по адресу:
Hashes for file member \SystemRoot\WinSxS\x86_microsoft-windows-grouppolicy-script_31bf3856ad364e35_6.1.7601.23452_none_677acd98e72e71cc\gpscript.exe
Версия его: Version = 6.1.7601.23452 и на него ссылается компонент патча KB3159398.
Открываем упомянутый патч на сайте Microsoft:
Download Обновление для системы безопасности Windows 7 (KB3159398) from Official Microsoft Download Center
Находим там ссылку «Связанные ресурсы», переходим.
https://support.microsoft.com/ru-ru. -the-security-update-for-group-policy-june-14
Открываем сведения о файлах и находим тот, что нам нужен:

Все, значит это то, что нам нужно.
Просто переустанавливаем это обновление и нужные файлы перезаписываются. А значит — все станет ОК.

Это был пример на живом логе реальной системы.

Почему необходимо найти именно такой же файл и такой же версии?
Потому что когда данный файл внедрялся в систему, то создается ряд условий, на основании которых система защиты будет считать «правильным» только такой файл, который будет соответствовать этим самым условиям.
Другими словами, если какое то из обновлений системы, к примеру, обновляло версию файла и эталоны, то файл из ранее сделанной резервной копии, но другой версии будет считаться неактуальным.
Именно поэтому часто встречающуюся рекомендацию:
Вставьте диск (флэшку) с дистрибутивом вашей версии операционной системы и введите sfc / scannow .
Можно смело пропускать мимо ушей, глаз или как там еще информация дошла до вас.

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

Конечно, если вы были настолько благоразумны, что после очередного обновления сделали резервный диск восстановления — то тут, конечно, все в порядке и файлы подойдут.

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

Отсюда можно сделать вывод, что при первоначальной проверке заморачиваться на счет наличия дистрибутива не стоит.
Исключение Windows XP — там система потребует наличия папки I386, которая имеется как раз на дистрибутиве (если у вас нет где то отдельно).
В нашем скрипте проверка ее наличия осуществляется автоматически и пользователю не придется выполнять танцы с бубном для того, что бы указать системе где она, если не удастся обнаружить.
Достаточно смонтировать образ диска и все.

Как еще можно восстановить поврежденные файлы?

Можно попытаться выполнить автоматическое восстановление хранилища компонентов через пункт «Расширенная проверка и восстановление файлов» скрипта, или запустив командную строкуот имени Администратора и ввести команду:
(Для Windows 8 — 10)
dism /Online /cleanup-image /restorehealth

Для Windows 7 команда будет выглядеть немного иначе, а так же потребуется наличие установленного Download Обновление для Windows 7 (KB2966583) from Official Microsoft Download Center

DISM /Online /Cleanup-Image /ScanHealth

В обоих случаях интернет должен быть подключен.
После того, как хранилище компонентов будет восстановлено, попробуйте снова выполнить проверку sfc /scannow
Как правило этой операции бывает достаточно.

Если вам понадобилось восстановление файлов хранилища данных вручную — то вам понадобится стать владельцем объекта и получить права на изменение.

Итак, теперь общее понимание у нас имеется, далее просто будем собирать типовые примеры записей лога cbs.log и методы исправления проблем.

Для того, что бы облегчить себе задачу и сэкономить время+силы, я использую для первоначального анализа файл sfcdoc.log, создаваемый скриптом.
Можно использовать и sfcdetalis.txt — но он менее информативен.

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