Уровень сложностиСредний
Время на прочтение5 мин
Количество просмотров22K
Журналирование событий информационной безопасности является важным элементом системы защиты информации. Нам необходимо знать какое событие когда произошло, когда какой пользователь пытался зайти в систему, с какого узла, удачно или нет, и так далее. Конечно, некоторые события ИБ сохраняются в журналах ОС при использовании настроек по умолчанию, например, не/удачные входы в систему, изменения прав доступа и т. д. Однако, настроек по умолчанию и локального хранения логов недостаточно для эффективного мониторинга и реагирования на события ИБ.
В этой статье мы посмотрим, как можно организовать эффективный аудит узлов под управлением ОС Windows, а в следующей статье настроим централизованный сбор событий с нескольких узлов и попробуем с помощью Powershell автоматизировать обработку собранных событий.
Зачем нужно централизованное хранение
Локальное хранение журналов событий имеет целый ряд недостатков, не позволяющих использовать этот механизм для мониторинга событий ИБ. С точки зрения безопасности локальные журналы хранят все события только на данной машине. Пока злоумышленник пытается получить доступ и поднять привилегии на данной машине, некоторые события обличающие его действия, возможно будут сохраняться в логах, но как только он получит необходимые права, он сможет почистить журнал событий, затем заполнить его фиктивными логами, в результате чего мы не увидим событий, связанных с компрометацией узла.
Да, при очистке лога будет создано событие ‘1102 Журнал аудита был очищен’, но от этого события тоже можно избавиться, просто заполнив лог большим количеством фиктивных событий.
Так как, обычно EventLog пишется по принципу циклической записи, более старые события удаляются, и их заменяют более новые.
Ну а создать поддельные события можно с помощью того же PowerShell, используя командлет Write-EventLog.
Таким образом, локальное хранение событий это не самый лучший вариант работы с логами с точки зрения безопасности. Ну а кроме того, нам не слишком удобно анализировать журналы событий, если они хранятся только локально. Тогда необходимо подключаться к журналам событий каждой локальной машины и работать с ними локально.
Гораздо удобнее пересылать логи на отдельный сервер, где их можно централизованно хранить и анализировать. В таком случае, в процессе выполнения атаки мы можем получать события от атакуемого узла, которые точно не будут потеряны. Кроме того, даже если злоумышленник сможет очистить лог на локальной машине, на удаленном сервере все события сохраняться. Ну и если события от нескольких узлов сохраняются централизованно на одном сервере, то с ними гораздо удобнее работать, что тоже не маловажно при анализе логов.
Эффективный аудит
Мы разобрались с необходимостью централизованного мониторинга событий. Однако, еще необходимо разобраться с тем, какие именно события должны присутствовать в наших логах. С одной стороны в логах должны присутствовать важные события с точки зрения ИБ, а с другой, в нем не должно быть слишком много неинтересных событий, например постоянных обращений к каким-либо файлам или сообщений о запуске каких-либо процессов, не представляющих никакого интереса для ИБ. Таким образом, чтоб нам не потонуть в большом объеме ненужных событий и не потерять что-то действительно важное, нам необходимо грамотно настроить политики аудита.
Для настройки откроем Политики аудита (Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Локальные политики / Политика аудита (Computer Configuration / Windows Settings / Security Settings / Local Policies / Audit Policy).
Также нам потребуются расширенные политики аудита, которые можно открыть здесь: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Конфигурация расширенной политики аудита (Computer Configuration / Windows Settings / Security Settings / Advanced Audit Policy Configuration).
Отличием политики расширенного аудита является наличие подкатегорий и теперь мы можем управлять аудитом на уровне не только категорий, но и подкатегорий. Если сравнить Политики аудита и Расширенные политики аудита, то можно заметить, что разделы в обычных политиках в свою очередь разделены на подразделы в расширенных политиках, что позволяет нам настраивать более подробные категории аудита. Так, для группы Вход учётной записи (Account Logon) мы можем настроить четыре проверки -Аудит проверки учётных данных, Аудит службы проверки подлинности Kerberos, Аудит операций с билетами службы Kerberos, Аудит других событий входа учётных записей.
Для каждого типа аудита мы можем настроить аудит событий успеха или отказа. С событиями успеха нужно быть аккуратными. Так, для того же аудита входов в систему мы рискуем получить большое количество событий успешного входа, которые по факту не будут представлять никакой ценности. Также, не стоит включать в аудите доступа к объектам, аудит событий «платформы фильтрации Windows», потому что он генерирует крайне большое количество событий (всё сетевое взаимодействие хоста). В результате мы снова рискуем получить большое количество ненужных событий. В результате срабатывания настроек политик аудита, в журнале создаются события, каждое из которых имеет собственный код.
Для эффективного аудита нам необходим сбор следующих типов событий: 4624 (Успешный вход в систему), 4647 (Выход из системы), 4625 (Неудачный вход в систему), 4778/4779 (Соединение/разъединение по RDP), 4800/4801 (Блокировка/Разблокировка рабочей станции) и некоторые другие.
При анализе событий нам важно понимать, как именно был осуществлен вход в систему или с каким кодом мы получили событие о неудачном входе в систему.
Посмотрим типы входа в систему:
2 – интерактивный
3 – сетевой (через сетевой диск)
4 – запуск по расписанию
5 – запуск сервиса
7 – разблокировка экрана
8 – сетевой (Basic Authentication в IIS)
10 – подключение по RDP
11 – вход по закешированным учетным данным
В приведенном ниже скриншоте у нас представлен вход в систему при запуске сервиса
И посмотрим, как мы можем узнать причину неудачного входа в систему
0xC0000064 — такого пользователя не существует
0xC000006A — неверный пароль
0xC0000234 — пользователь заблокирован
0xC0000072 — пользователь отключен
0xC000006F — пользователь попытался войти в систему вне установленных для него ограничений по дням недели или времени суток
0xC0000070 — ограничение рабочей станции или нарушение изолированной политики аутентификации (найдите идентификатор события 4820 на контроллере домена)
0xC0000193 — срок действия учетной записи истек
0xC0000071 — истек пароль
0xC0000133 — часы между DC и другим компьютером слишком сильно рассинхронизированы
0xC0000224 — пользователю необходимо сменить пароль при следующем входе в систему
0xc000015b Пользователю не был предоставлен запрошенный тип входа в систему (он же право входа в систему) на этом компьютере
Таким образом, по значениям данных кодов в соответствующих событиях мы можем понять, что стало причиной неудачного входа в систему или каким образом пользователь или сервис осуществили вход.
На картинке ниже представлен неудачный интерактивный вход в систему, причиной которого стало указание неверного пароля.
В следующей статье мы посмотрим, как средствами PowerShell можно извлекать различные значения из событий и делать обработку логов более “человеко-удобной.
Заключение
В этой статье мы рассмотрели виды аудита в современных версиях ОС Windows, поговорили о том, какие именно события должны собираться в системе и что означают некоторые поля в этих событиях. В следующей статье мы настроим централизованный сбор событий с нескольких источников и попробуем с помощью PowerShell настроить автоматический анализ собираемых событий.
Напоследок приглашаю вас на бесплатный вебинар, где мы узнаем, зачем нужны бэкапы и как их организовать путем сервисов в Windows.
Как настроить политики аудита Windows таким образом, чтобы охват мониторинга SOC был полноценным? Рассмотрим оптимальный список политик, а также выделим самое необходимое, отсеяв лишнее.
- Введение
- Знакомство с расширенным аудитом Windows
- Настройка политик аудита
- Усиление цифровой обороны
- Выводы
Введение
Все мы любим заворожённо читать про очередное расследование инцидента, где шаг за шагом распутывается клубок: как проник злоумышленник, какие инструменты он использовал и когда, что за процессы создавались на скомпрометированном хосте, что происходило в сети и, конечно же, кто виноват и что делать.
На практике ответы на эти вопросы находятся не всегда. Зачастую при расследовании специалисты отделов ИБ сталкиваются с тем, что аудит не настроен, логи перезаписались, отсутствует единая система хранения и анализа журналов, «перезалит» заражённый хост (популярное решение всех проблем).
Ниже мы разберём один из самых важных этапов, который нужен для того, чтобы расследование не завершилось ещё в самом начале: сбор и хранение журналов аудита. Будут рассмотрены возможности расширенного аудита ОС Windows и его настройка.
Знакомство с расширенным аудитом Windows
Речь пойдёт о настройках для систем Microsoft Windows Vista / Server 2008 и выше. Начиная с указанных операционных систем компания Microsoft сделала шаг вперёд в понимании аудита и управления им. Так появился расширенный аудит. Теперь администраторы и специалисты по информационной безопасности могут управлять аудитом на уровне не только категорий, но и подкатегорий.
Давайте подробнее остановимся на них. Откроем оснастку локальной групповой политики, используя команду «gpedit.msc» (или через «secpol.msc»). Для групповых политик всё будет аналогично, только все действия будут выполняться через «gpmc.msc».
Полный путь к настройкам аудита выглядит следующим образом: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Локальные политики / Политика аудита (Computer Configuration / Windows Settings / Security Settings / Local Policies / Audit Policy).
Рисунок 1. Политика аудита
Расширенный аудит, в свою очередь, находится здесь: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Конфигурация расширенной политики аудита (Computer Configuration / Windows Settings / Security Settings / Advanced Audit Policy Configuration).
Рисунок 2. Конфигурация расширенной политики аудита
Ниже на рисунке видно, как они коррелируют между собой.
Рисунок 3. Корреляция аудита и расширенного аудита
В общей сложности нам доступны 10 политик и 60 подкатегорий.
Таблица 1. Категории и подкатегории аудита
| Категория (Category) | Подкатегория (Subcategory) | |
| Вход учётной записи (Account Logon) | Аудит проверки учётных данных (Audit Credential Validation) | |
| Аудит службы проверки подлинности Kerberos (Audit Kerberos Authentication Service) | ||
| Аудит операций с билетами службы Kerberos (Audit Kerberos Service Ticket Operations) | ||
| Аудит других событий входа учётных записей (Audit Other Account Logon Events) | ||
| Управление учётными записями (Account Management) | Аудит управления группами приложений (Audit Application Group Management) | |
| Аудит управления учётными записями компьютеров (Audit Computer Account Management) | ||
| Аудит управления группами распространения (Audit Distribution Group Management) | ||
| Аудит других событий управления учётными записями (Audit Other Account Management Events) | ||
| Аудит управления группами безопасности (Audit Security Group Management) | ||
| Аудит управления учётными записями пользователей (Audit User Account Management) | ||
| Подробное отслеживание (Detailed Tracking) | Аудит активности DPAPI (Audit DPAPI Activity) | |
| PNP-действие аудита (Audit PNP Activity) | ||
| Аудит создания процессов (Audit Process Creation) | ||
| Аудит завершения процессов (Audit Process Termination) | ||
| Аудит событий RPC (Audit RPC Events) | ||
| Проверка изменений прав маркера (Audit Token Right Adjusted) [Windows 10 / Server 2016 и выше] | ||
| Доступ к службе каталогов DS (DS Access) | Аудит подробной репликации службы каталогов (Audit Detailed Directory Service Replication) | |
| Аудит доступа к службе каталогов (Audit Directory Service Access) | ||
| Аудит изменения службы каталогов (Audit Directory Services Changes) | ||
| Аудит репликации службы каталогов (Audit Directory Service Replication) | ||
| Вход / выход (Logon / Logoff) | Аудит блокировки учётных записей (Audit Account Lockout) | |
| Аудит заявок пользователей или устройств на доступ (Audit User / Device Claims) | ||
| Аудит расширенного режима IPsec (Audit IPsec Extended Mode) | ||
| Аудит основного режима IPsec (Audit IPsec Main Mode) | ||
| Аудит быстрого режима IPsec (Audit IPsec Quick Mode) | ||
| Аудит выхода из системы (Audit Logoff) | ||
| Аудит входа в систему (Audit Logon) | ||
| Аудит сервера политики сети (Audit Network Policy Server) | ||
| Аудит других событий входа и выхода (Audit Other Logon / Logoff Events) | ||
| Аудит специального входа (Audit Special Logon) | ||
| Доступ к объектам (Object Access) | Аудит событий, создаваемых приложениями (Audit Application Generated) | |
| Аудит служб сертификации (Audit Certification Services) | ||
| Аудит сведений об общем файловом ресурсе (Audit Detailed File Share) | ||
| Аудит общего файлового ресурса (Audit File Share) | ||
| Аудит файловой системы (Audit File System) | ||
| Аудит подключения платформы фильтрации (Audit Filtering Platform Connection) | ||
| Аудит отбрасывания пакетов платформой фильтрации (Audit Filtering Platform Packet Drop) | ||
| Аудит работы с дескрипторами (Audit Handle Manipulation) | ||
| Аудит объектов ядра (Audit Kernel Object) | ||
| Аудит других событий доступа к объектам (Audit Other Object Access Events) | ||
| Аудит реестра (Audit Registry) | ||
| Аудит съёмного носителя (Audit Removable Storage) | ||
| Аудит диспетчера учётных записей безопасности (Audit SAM) | ||
| Аудит сверки с централизованной политикой доступа (Audit Central Access Policy Staging) | ||
| Изменение политики (Policy Change) | Аудит изменения политики аудита (Audit Policy Change) | |
| Аудит изменения политики проверки подлинности (Audit Authentication Policy Change) | ||
| Аудит изменения политики авторизации (Audit Authorization Policy Change) | ||
| Аудит изменения политики платформы фильтрации (Audit Filtering Platform Policy Change) | ||
| Аудит изменения политики на уровне правил MPSSVC (Audit MPSSVC Rule-Level Policy Change) | ||
| Аудит других событий изменения политики (Audit Other Policy Change Events) | ||
| Использование привилегий (Privilege Use) | Аудит использования привилегий, не затрагивающих конфиденциальные данные (Audit Non Sensitive Privilege Use) | |
| Аудит других событий использования привилегий (Audit Other Privilege Use Events) | ||
| Аудит использования привилегий, затрагивающих конфиденциальные данные (Audit Sensitive Privilege Use) | ||
| Система (System) | Аудит драйвера IPsec (Audit IPsec Driver) | |
| Аудит других системных событий (Audit Other System Events) | ||
| Аудит изменения состояния безопасности (Audit Security State Change) | ||
| Аудит расширения системы безопасности (Audit Security System Extension) | ||
| Аудит целостности системы (Audit System Integrity) | ||
| Аудит доступа к глобальным объектам (Global Object Access Auditing) | Файловая система (File system) | |
| Реестр (Registry) |
Теперь вместо включения аудита «Доступ к объектам» мы можем очень тонко настроить его по подкатегориям. Например, мы не будем включать аудит событий «платформы фильтрации Windows», потому что он генерирует крайне большое количество событий (всё сетевое взаимодействие хоста), которые к тому же лучше отслеживать на специализированном оборудовании, таком как межсетевые экраны, маршрутизаторы, прокси- и DNS-серверы.
Включим аудит файловой системы, реестра, съёмного носителя и других событий доступа к объектам, а всё остальное оставим в выключенном состоянии (параметр «Не настроено»).
Рисунок 4. Пример настройки аудита доступа к объектам через подкатегории
События аудита могут иметь значение «Успех и отказ», изображённое на рис. 4, или поддерживать только одно из двух состояний. Например, аудит создания процессов (Event ID 4688: A new process has been created) может быть только «успешным» (рис. 5).
Рисунок 5. Аудит создания процессов регистрирует успешные события
Если вы не знаете, нужна ли вам та или иная политика аудита, то ознакомиться с их описанием тоже очень легко. Оно есть на вкладке «Пояснение» соответствующей политики.
Рисунок 6. Вкладка с описанием политики
Для некоторых политик аудита дополнительно нужно настраивать системные списки управления доступом (SACL). Это в первую очередь касается файлового аудита и аудита реестра (альтернатива — использовать весьма специфичную политику «Аудит доступа к глобальным объектам»).
Например, чтобы отслеживать изменения в файле «hosts», откроем его свойства и перейдём в настройки аудита: «Безопасность» -> «Дополнительно» -> «Аудит». Добавим субъект аудита: выбираем группу «Все». Тип аудита — «Успех». Ставим галочки напротив записи данных, удаления, смены разрешений и смены владельца.
Рисунок 7. Настройка SACL
Если в вашей компании уже существуют различные групповые политики с настройками аудита, но вы хотите начать использовать расширенный аудит и подкатегории, то для этого случая Microsoft учла и ввела новую политику, которая называется «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии)» (Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings). По умолчанию она включена. Проверить состояние политики можно здесь: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Локальные политики / Параметры безопасности (Computer Configuration / Windows Settings / Security Settings / Local Policies / Security Options).
Рисунок 8. Принудительное переопределение параметров политики аудита
Дополнительно вы можете управлять политиками аудита через инструмент командной строки «auditpol.exe».
Рисунок 9. Использование инструмента auditpol
Настройка политик аудита
Очень часто можно услышать совет: «давайте включим все политики». Это, конечно, — «путь джедая», но, как показывает практика, не все джедаи добрались до финала.
Для большинства сценариев мониторинга нет острой необходимости включать всё. Это излишне. Включая все политики, вы можете получить гигантский поток событий, в котором очень легко «утонуть». В большой инфраструктуре с несколькими тысячами Windows-хостов поток событий может исчисляться десятками тысяч EPS (событий в секунду). Это порождает другую, не менее сложную задачу: как этим управлять, где это хранить, как обрабатывать.
Предлагаем рассмотреть оптимальный список политик, который может вам понадобиться. Также стоит обратить внимание на то, что фактически настроек две (и, соответственно, существуют две различные GPO). Первая — исключительно для контроллеров домена, так как часть событий (например, ID 4768: A Kerberos authentication ticket (TGT) was requested) фиксируется исключительно на них. Вторая — для рядовых серверов и АРМ пользователей.
Таблица 2. Рекомендуемые настройки аудита Windows
| Категория | Подкатегория | Включить | Хост (DC, сервер, АРМ) | Категория (успех / отказ) |
| Account Logon | Audit Credential Validation | + | DC, сервер, АРМ | Успех и отказ |
| Audit Kerberos Authentication Service | + | DC | Успех и отказ | |
| Audit Kerberos Service Ticket Operations | + | DC | Успех и отказ | |
| Audit Other Account Logon Events | — | |||
| Account Management | Audit Application Group Management | + | DC | Успех и отказ |
| Audit Computer Account Management | + | DC | Успех | |
| Audit Distribution Group Management | + | DC | Успех | |
| Audit Other Account Management Events | + | DC, сервер, АРМ | Успех | |
| Audit Security Group Management | + | DC, сервер, АРМ | Успех | |
| Audit User Account Management | + | DC, сервер, АРМ | Успех и отказ | |
| Detailed Tracking | Audit DPAPI Activity | + | DC, сервер, АРМ | Успех и отказ |
| Audit PNP Activity | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Process Creation | + | DC, сервер, АРМ | Успех | |
| Audit Process Termination | — | |||
| Audit RPC Events | — | |||
| Audit Token Right Adjusted | — | |||
| DS Access | Audit Detailed Directory Service Replication | + | DC | Успех и отказ |
| Audit Directory Service Access | + | DC | Успех и отказ | |
| Audit Directory Services Changes | + | DC | Успех и отказ | |
| Audit Directory Service Replication | + | DC | Успех и отказ | |
| Logon/Logoff | Audit Account Lockout | + | DC, сервер, АРМ | Отказ |
| Audit User / Device Claims | — | |||
| Audit IPsec Extended Mode | — | |||
| Audit IPsec Main Mode | — | |||
| Audit IPsec Quick Mode | — | |||
| Audit Logoff | + | DC, сервер, АРМ | Успех | |
| Audit Logon | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Network Policy Server | — | |||
| Audit Other Logon / Logoff Events | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Special Logon | + | DC, сервер, АРМ | Успех | |
| Object Access | Audit Application Generated | — | ||
| Audit Certification Services | — | |||
| Audit Detailed File Share | — | |||
| Audit File Share | — | |||
| Audit File System | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Filtering Platform Connection | — | |||
| Audit Filtering Platform Packet Drop | — | |||
| Audit Handle Manipulation | — | |||
| Audit Kernel Object | — | |||
| Audit Other Object Access Events | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Registry | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Removable Storage | + | DC, сервер, АРМ | Успех и отказ | |
| Audit SAM | — | |||
| Audit Central Access Policy Staging | — | |||
| Policy Change | Audit Policy Change | + | DC, сервер, АРМ | Успех |
| Audit Authentication Policy Change | + | DC, сервер, АРМ | Успех | |
| Audit Authorization Policy Change | + | DC, сервер, АРМ | Успех | |
| Audit Filtering Platform Policy Change | — | |||
| Audit MPSSVC Rule-Level Policy Change | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Other Policy Change Events | — | |||
| Privilege Use | Audit Non Sensitive Privilege Use | + | DC, сервер, АРМ | Успех и отказ |
| Audit Other Privilege Use Events | — | |||
| Audit Sensitive Privilege Use | + | DC, сервер, АРМ | Успех и отказ | |
| System | Audit IPsec Driver | — | ||
| Audit Other System Events | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Security State Change | + | DC, сервер, АРМ | Успех | |
| Audit Security System Extension | + | DC, сервер, АРМ | Успех | |
| Audit System Integrity | — | |||
| Global Object Access Auditing | File system | — | ||
| Registry | — |
После включения описанных политик у вас будут все необходимые события для мониторинга и расследования инцидентов.
Усиление цифровой обороны
Для максимальной отдачи необходимо выполнить ещё одну настройку — включить логирование «командной строки процесса». Тогда на рабочих станциях и серверах, к которым применяется этот параметр политики, сведения из командной строки будут заноситься в журнал событий «Безопасность» (Security) с ID 4688.
Рисунок 10. Журналирование командной строки процесса
Требования к версии ОС: не ниже Windows Server 2012 R2, Windows 8.1. Данная функциональность также доступна и на ОС Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012 после установки обновления KB 3004375.
Путь к политике: Конфигурация компьютера / Административные шаблоны / Система / Аудит создания процессов (Computer Configuration / Administrative Templates / System / Audit Process Creation). Имя: «Включать командную строку в события создания процессов» (Include command line in process creation events).
Рисунок 11. Путь к аудиту создания процессов
Включаем политику, выставив соответствующее значение, и нажимаем «Применить» (Apply).
Рисунок 12. Настройка «Включать командную строку в события создания процессов»
После включения этой политики в журнале событий «Безопасность» (Security) в событиях с кодом 4688 появится дополнительное значение «Командная строка процесса» (Process Command Line), где будет отображаться тело исполняемой команды.
В примере ниже демонстрируется, как это поможет заглянуть чуть глубже. На первый взгляд в событии происходит запуск легитимного процесса «opera_autoupdate.exe», но вот строка «Process Command Line» больше похожа на запуск утилиты «mimikatz». Без активированной политики «Включать командную строку в события создания процессов» мы этого не зафиксируем.
Рисунок 13. Детектирование mimikatz
Укрепим нашу оборону и полным журналированием работы самого мощного инструмента ОС Windows — PowerShell. Для этого необходима версия PowerShell 5.0 или выше.
PowerShell 5.0 / 5.1 предустановлен в Windows 10, Windows Server 2016 и Windows Server 2019. Для остальных операционных систем необходимо обновить модуль Windows Management Framework.
Список поддерживаемых ОС:
- Windows Server 2012 R2
- Windows Server 2012
- Windows Server 2008 R2 SP1
- Windows 8.1
- Windows 8
- Windows 7 SP1
Скачайте с сайта Microsoft соответствующую версию, выполните установку и перезагрузку хоста. Также обязательным требованием является наличие Microsoft .NET Framework 4.5 или выше.
Включим регистрацию блоков сценариев PowerShell через соответствующую политику. Она находится по следующему пути: Административные шаблоны / Компоненты Windows / Windows PowerShell (Administrative Templates / Windows Components / Windows PowerShell). Имя: «Включить регистрацию блоков сценариев PowerShell» (Turn on PowerShell Script Block Logging)
Рисунок 14. Путь к аудиту Windows PowerShell
Включаем политику и нажимаем «Применить» (Apply). При этом устанавливать галочку напротив поля «Регистрация начала или остановки вызова блоков сценариев» (Log script block invocation start / stop events) не нужно. Данная функция увеличивает количество регистрируемых событий, которые не несут полезной информации.
Рисунок 15. Включить регистрацию блоков сценариев PowerShell
После включения этой политики PowerShell будет регистрировать в журнале событий трассировки Microsoft-Windows-PowerShell/Operational с кодом события 4104 все блоки сценариев, в том числе — путь, тело скрипта и все используемые командлеты.
Рисунок 16. Пример регистрируемого события 4104
Хорошей практикой является увеличение размера самих журналов, даже если вы используете SIEM или сервер сборщика событий (Windows Event Collector). Например, журнал «Безопасность» (Security) по умолчанию имеет размер 20 МБ. При настроенном аудите на типичном АРМ этого объёма хватит на журналирование нескольких дней, на сервере — нескольких часов, а на контроллере домена 20 МБ не хватит ни на что.
Рекомендуем для всех основных журналов следующие объёмы:
- журнал «Установка» (Setup) — не менее 10 МБ,
- журнал «Система» (System) — не менее 50 МБ,
- журнал «Приложение» (Application) — не менее 50 МБ,
- журнал «Безопасность» (Security) — не менее 200 МБ (для контроллера домена — не менее 500 МБ).
При этом оставляем функцию перезаписи старых событий (по умолчанию она активирована).
Рисунок 17. Настройка хранения журналов аудита
Выводы
Настройка необходимых для мониторинга политик аудита, локальное долговременное хранение журналов, протоколирование запуска процессов и команд PowerShell позволит не упустить важные события безопасности и тщательно расследовать инциденты. Это — один из ключевых этапов в построении процессов непрерывного мониторинга, снижения рисков ИБ и повышения уровня защищённости.
В дальнейшем важно будет обеспечить централизованный сбор и хранение журналов в SIEM-системе, настройку корреляционных правил, киберразведку (Threat Intelligence), проведение активных испытаний безопасности в формате Red / Blue Team.
Если вы видите это сообщение, значит, произошла проблема с загрузкой файлов в стилей (CSS) нашего сайта. Попробуйте сбросить кэш браузера (Ctrl+F5).
Если это не поможет, а вы находитесь в регионе, где возможны ограничения интернет-трафика с российских серверов — воспользуйтесь VPN.
|
Что означают показанные входы? При этом компьютер притормаживает последнее время. Вирусов не находит ни Касперский ни доктор Веб. 
бонус за лучший ответ (выдан): 10 кредитов Система оповещение корпорации Майрософт предусматривает ряд опций по самоинформированию, с согласия пользователя.
Конфигурация компьютера\Конфигурация Windows\Параметры безопасности\Локальные политики\Политика аудита.
Произведя это действие Вы решите проблему с *тормозами* при текстовом формировании отчёта и его рассылке. автор вопроса выбрал этот ответ лучшим Jakar 10 лет назад Аудит успеха — это количество успешных и зарегистрированных входов в систему. В данном случае со стороны Майкрософт. Есть противоположные действия, «аудит отказов», при которых Вашей операционной системой, её безопасностью или антивирусными программами будет отказано в доступе Майкрософту к Вашему компьютеру. Для этого нужно поставить определённые галочки, запретить автоматические обновления и автоматическую отсылку отчётов. Знаете ответ? |
To help troubleshoot problems, the Event Viewer, native to the Windows operating system, shows event logs of system and application messages which include errors, warnings, and information about certain events that can be analyzed by the administrator to take the necessary actions. In this post, we discuss the Audit Success or Audit Failure in Event Viewer.
In Event Viewer, Audit Success is an event that records an audited security access attempt that is successful, whereas Audit Failure is an event that records an audited security access attempt that fails. We will discuss this topic under the following subheadings:
- Audit Policies
- Enable Audit Policies
- Use Event Viewer to find the source of failed or successful attempts
- Alternatives to using Event Viewer
Let’s see these in detail.
Audit Policies
An audit policy defines the types of events that are recorded in the Security logs and these policies generate events, which can either be Success events or Failure events. All audit policies will generate Success events; however, only a few of them will generate Failure events. Two types of audit policies can be configured viz:
- Basic Audit Policy has 9 audit policy categories and 50 audit policy subcategories that can be enabled or disabled per requirement. Below is a list of the 9 audit policy categories.
- Audit account logon events
- Audit logon events
- Audit account management
- Audit directory service access
- Audit object access
- Audit policy change
- Audit privilege use
- Audit process tracking
- Audit system events. This policy setting determines whether to audit when a user restarts or shuts down the computer or when an event occurs that affects either the system’s security or the security log. For more information and the related logon events, refer to the Microsoft documentation at learn.microsoft.com/basic-audit-system-events.
- Advanced Audit Policy which has 53 categories, ergo recommended as you can be able to define a more granular audit policy and log only the events that are relevant which is particularly helpful if generating a large number of logs.
Audit failures are typically generated when a logon request fails, although they can also be generated by changes to accounts, objects, policies, privileges, and other system events. The two most common events are;
- Event ID 4771: Kerberos pre-authentication failed. This event is only generated on domain controllers and is not generated if the Do not require Kerberos preauthentication option is set for the account. For more information about this Event and how to resolve this problem, refer to the Microsoft documentation.
- Event ID 4625: An account failed to log on. This event is generated when an account logon attempt failed, assuming the user was already locked out. For more information about this Event and how to resolve this problem, refer to the Microsoft documentation.
Read: How to check the Shutdown and Startup Log in Windows
Enable Audit Policies
You can enable audit policies on the client or server machines via Local Group Policy Editor or Group Policy Management Console or Local Security Policy Editor. On a Windows server, on your domain, either create a new group policy object or you can edit an existing GPO.
On a client or server machine, in the Group Policy Editor, navigate to the path below:
Computer Configuration > Windows Settings > Security Settings > Local Policies > Audit Policy
On a client or server machine, in Local Security Policy, navigate to the path below:
Security Settings > Local Policies > Audit Policy
- In Audit policies, on the right pane double-click the policy you want to edit its properties.
- In the properties panel, you can enable the policy for Success or Failure per your requirement.
Read: How to reset all Local Group Policy settings to default in Windows
Use Event Viewer to find the source of failed or successful attempts
Administrators and regular users can open the Event Viewer on a local or remote machine, with the appropriate permission. The Event Viewer will now record an event every time there is a failed or successful event whether on a client machine or in the domain on a server machine. The Event ID that is triggered when a failed or successful event is registered differs (see the Audit Policies section above). You can navigate to Event Viewer > Windows Logs > Security. The pane in the center lists all the events that have been set up for auditing. You will have to go through events registered to look for failed or successful attempts. Once you find them, you can right-click on the event and select Event Properties for more details.
Read: Use Event Viewer to check unauthorized use of Windows computer
Alternatives to using Event Viewer
As an alternative to using Event Viewer, there are several third-party Event Log Manager software that can be used to aggregate and correlate event data from a wide range of sources, including cloud-based services. A SIEM solution is the better option if there’s a need to collect and analyze data from firewalls, Intrusion Prevention Systems (IPS), devices, applications, switches, routers, servers, etcetera.
I hope you find this post informative enough!
Now read: How to enable or disable Protected Event Logging in Windows
Why is it important to audit both successful and failed access attempts?
It is vital to audit logon events whether successful or failed to detect intrusion attempts because user logon auditing is the only way to detect all unauthorized attempts to log in to a domain. Logoff events are not tracked on domain controllers. It is also equally important to audit failed attempts to access files as an audit entry is generated each time any user unsuccessfully attempts to access a file system object that has a matching SACL. These events are essential for tracking activity for file objects that are sensitive or valuable and require extra monitoring.
Read: Harden Windows Login Password Policy & Account Lockout Policy
How do I enable audit failure logs in Active Directory?
To enable audit failure logs in Active Directory, simply right-click the Active Directory object you want to audit, and then select Properties. Select the Security tab, and then select Advanced. Select the Auditing tab, and then select Add. To view audit logs in Active Directory, click Start > System security > Administrative tools > Event viewer. In Active Directory, auditing is the process of collecting and analyzing AD objects and Group Policy data to proactively improve security, promptly detect and respond to threats, and keep IT operations running smoothly.
Read: Event ID 1101, Audit events have been dropped by the transport. 0.
Это небольшая статья призвана показать пользователям способ, которым он узнает, кто пытался войти в систему без его ведома. Если компьютер находится в офисе и к нему имеют доступ не один человек, тогда способ может пригодиться. Советую ознакомиться со статьей – кто пытался войти через вашу учетную запись. Там говориться об учетной записи Microsoft, в которую могут войти любые злоумышленники.
Один из способов имеет название «Аудит входа в систему». Опция показываем время захода и его тип. Давайте уже разбираться.
Как использовать «Аудит входа в систему»
Данная функция доступна только в PRO версии Windows, где есть функция локальных групповых политик, в домашней или корпоративной её нет. Но в ниже есть другие варианты для вашей версии. Итак, откройте окно «Выполнить» и впишем команду:
Так мы запустим утилиту групповых политик. С левой стороны окошка открываем вкладки «Конфигурация компьютера», далее «Конфигурация Windows», «Параметры безопасности», «Локальные политики» и «Политика аудита». Нажмите на этот раздел, чтобы правее от окна появились нужные опции.
Теперь выбираем пункт «Аудит событий входа в систему» (Нажимаем на него правой кнопкой мышки дважды). Появится окно свойств, где выделяем галкой пункт «Успех». Таким образом, появится возможность отслеживать все входы в Windows. Отметив галкой «Отказ», будут отслеживаться неудачные входы в Windows.
Смотрим, кто пытался войти в систему
Активировав функцию, можно заново войти в систему. Давайте проверим, кто же входил в неё. Для этого дела нам понадобиться утилита «Просмотр событий». В поиске введите эти два слова.
В утилите перейдите в раздел «Журналы Windows» и подраздел «Безопасность». Справа находим ключевое событие «Аудит успеха», также смотрите по номеру события, он должен быть «4624».
Откройте событие, чтобы узнать его свойства. Там вы найдете время входа, имя пользователя и другие сведения.
В окне просмотра событий можно применить фильтр, чтобы было легче ориентироваться среди большого количества задач. Фильтровать можно по ключевым фразам, кодам, или категориям.
В Windows 10 с помощью реестра
Если у вас не профессиональная редакция Windows, то воспользуемся реактором реестра. Снова откроем окошко «Выполнить» при помощи комбинации «Win+R» и запишем команду:
Открывшееся окно реестра слева имеет кучу разделов, с вложенными подразделами. Вам нужно дойти до самого последнего:
Выбрав последний раздел, в правой части окошка создаем параметр DWORD 32 бит. Дадим ему название DisplayLastLogonInfo. Нажимаем по нему два раза и ставим в качестве значения единицу.
Закрываем окна и перезагружаем ПК. После загрузки системы на экране появится окно с успешным входом. Там будет время, имя пользователя и дата.
Надеюсь этот небольшой материал поможет вам узнать, кто входил в систему при вашем отсутствии.
Источник
Аудит системных событий Audit system events
Область применения Applies to
Определяет, следует ли выполнять аудит, когда пользователь перезапускается или завершает работу компьютера, или когда возникает событие, которое влияет на безопасность системы или журнал безопасности. Determines whether to audit when a user restarts or shuts down the computer or when an event occurs that affects either the system security or the security log.
Если вы определяете этот параметр политики, вы можете указать, следует ли проводить аудит успехов, аудит отказов или вообще не проводить аудит для типа события. If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Аудит успехов приводит к созданию записи аудита при успешном попытке входа. Success audits generate an audit entry when a logon attempt succeeds. Аудит отказов приводит к созданию записи аудита при неудачной попытке входа. Failure audits generate an audit entry when a logon attempt fails.
Чтобы отключить аудит, в диалоговом окне свойства для этого параметра политики установите флажок определить следующие параметры политики и снимите флажки успех и отказ . To set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.
По умолчанию Default:
- Успех на контроллерах домена. Success on domain controllers.
- Без аудита на рядовых серверах. No auditing on member servers.
Настройка этого параметра аудита Configure this audit setting
Вы можете настроить этот параметр безопасности, открыв соответствующую политику в разделе Computer Конфигуратионвиндовс Сеттингссекурити Сеттингслокал ПолиЦиесаудит. You can configure this security setting by opening the appropriate policy under Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesAudit Policy.
Источник
Аудит специального входа Audit Special Logon
Область применения Applies to
- Windows 10; Windows 10
- WindowsServer2016 Windows Server 2016
Аудит специальных входов определяет, будет ли операционная система создавать события аудита для специальных входных или входных условий. Audit Special Logon determines whether the operating system generates audit events under special sign on (or log on) circumstances.
Эта подкатегория позволяет проводить аудит событий, возникающих при специальных возможностях входа, таких как указанные ниже. This subcategory allows you to audit events generated by special logons such as the following:
Использование специального входного имени, которое является входом с правами администратора и может использоваться для повышения уровня процесса до более высокого. The use of a special logon, which is a logon that has administrator-equivalent privileges and can be used to elevate a process to a higher level.
Вход участником специальной группы. A logon by a member of a Special Group. Специальные группы позволяют вести аудит событий, возникающих при входе в сеть членов определенной группы. Special Groups enable you to audit events generated when a member of a certain group has logged on to your network. Вы можете настроить список идентификаторов безопасности групп (SID) в реестре. You can configure a list of group security identifiers (SIDs) in the registry. Если какой-либо из этих SID добавляется к маркеру во время входа в систему, а Подкатегория включена, событие заносится в журнал. If any of those SIDs are added to a token during logon and the subcategory is enabled, an event is logged.
Громкость события: Event volume:
Низкий на клиентском компьютере. Low on a client computer.
Средняя на контроллерах домена или серверах сети. Medium on a domain controllers or network servers.
| Тип компьютера Computer Type | Общее успешное General Success | Общий сбой General Failure | Более надежный успех Stronger Success | Надежная ошибка Stronger Failure | Комментарии Comments |
|---|---|---|---|---|---|
| Контроллер домена Domain Controller | Да Yes | Нет No | Да Yes | Нет No | Эта подкатегория очень важна из-за событий, связанных с особыми группами , при использовании этой функции необходимо включить эту подкатегорию для аудита успехов. This subcategory is very important because of Special Groups related events, you must enable this subcategory for Success audit if you use this feature. В то же время эта подкатегория позволяет отслеживать сеансы входа в учетную запись, которым были назначены конфиденциальные полномочия. At the same time this subcategory allows you to track account logon sessions to which sensitive privileges were assigned. Эта подкатегория не имеет событий сбоя, поэтому не существует рекомендации по включению аудита отказов для этой подкатегории. This subcategory doesn’t have Failure events, so there is no recommendation to enable Failure auditing for this subcategory. |
| Рядовой сервер Member Server | Да Yes | Нет No | Да Yes | Нет No | Эта подкатегория очень важна из-за событий, связанных с особыми группами , при использовании этой функции необходимо включить эту подкатегорию для аудита успехов. This subcategory is very important because of Special Groups related events, you must enable this subcategory for Success audit if you use this feature. В то же время эта подкатегория позволяет отслеживать сеансы входа в учетную запись, которым были назначены конфиденциальные полномочия. At the same time this subcategory allows you to track account logon sessions to which sensitive privileges were assigned. Эта подкатегория не имеет событий сбоя, поэтому не существует рекомендации по включению аудита отказов для этой подкатегории. This subcategory doesn’t have Failure events, so there is no recommendation to enable Failure auditing for this subcategory. |
| Компьютере Workstation | Да Yes | Нет No | Да Yes | Нет No | Эта подкатегория очень важна из-за событий, связанных с особыми группами , при использовании этой функции необходимо включить эту подкатегорию для аудита успехов. This subcategory is very important because of Special Groups related events, you must enable this subcategory for Success audit if you use this feature. В то же время эта подкатегория позволяет отслеживать сеансы входа в учетную запись, которым были назначены конфиденциальные полномочия. At the same time this subcategory allows you to track account logon sessions to which sensitive privileges were assigned. Эта подкатегория не имеет событий сбоя, поэтому не существует рекомендации по включению аудита отказов для этой подкатегории. This subcategory doesn’t have Failure events, so there is no recommendation to enable Failure auditing for this subcategory. |
Список событий: Events List:
4964(ов): новому входу были назначены специальные группы. 4964(S): Special groups have been assigned to a new logon.
4672(ы): специальные права, назначенные новому входу. 4672(S): Special privileges assigned to new logon.
Источник
Содержание
- Проблемы в системе журналирования событий безопасности ОС Windows
- Проблема № 1. Неудачная система управления параметрами аудита
- Описание проблемы
- Объяснение
- В чем суть проблемы?
- Проблема № 2. Неудачная реализация журналирования операций удаления файлов, каталогов и ключей реестра
- Описание проблемы
- Особенности удаления файлов в Windows 10 и Server 2019
- В чем суть проблемы?
- Проблема № 3 (критическая). Неудачная реализация журналирования операции переименования файлов, каталогов и ключей реестра
- Описание проблемы
- В чем суть проблемы?
- Проблема № 4 (критическая). Невозможно отследить создание каталога и ключа реестра
- Описание проблемы
- В чем суть проблемы?
- Проблема № 5 (критическая). Сбойные параметры аудита в русских версиях Windows
- Описание проблемы
- Симптомы
- Причины
- Рекомендации по решению проблемы
- В чем суть проблемы?
- Проблема № 6 (критическая). Будь проклят «Новый текстовый документ.txt. а также Новый точечный рисунок.bmp»
- Описание проблемы
- В чем суть проблемы?
- Заключение
- Кто пытался войти в систему Windows
- Как использовать «Аудит входа в систему»
- Смотрим, кто пытался войти в систему
- В Windows 10 с помощью реестра
- Управление журналом аудита и безопасности
- Справочники
- Возможные значения
- Рекомендации
- Location
- Значения по умолчанию
- Управление политикой
- Групповая политика
- Вопросы безопасности
- Уязвимость
- Противодействие
- Возможное влияние
- Аудит выхода из системы
Проблемы в системе журналирования событий безопасности ОС Windows
В операционных системах семейства Windows реализована довольно неплохая система журналирования событий безопасности. О ней в различных публикациях и обзорах написано много чего хорошего, но эта статья будет про другое. Здесь мы поговорим о проблемах и недоработках в этой системе. Некоторые из рассматриваемых проблем будут некритичными, лишь осложняющими процедуры анализа событий, другие же будут представлять весьма серьезные угрозы безопасности.
Выявленные проблемы проверялись на Windows 7 Максимальная (русская версия), Windows 7 Professional (английская версия), Windows 10 Pro (русская версия), Windows Server 2019 Datacenter (русская версия). Все операционные системы были полностью обновлены.
Проблема № 1. Неудачная система управления параметрами аудита
Наличие проблемы подтверждено на Windows 7/10/Server 2019.
Описание проблемы
Объяснение
Чтобы разобраться в причине подобного поведения, надо залезть «под капот» операционной системы. Начнем с того, что разберемся с базовыми и расширенными политиками аудита.
До Windows Vista были только одни политики аудита, которые сейчас принято называть базовыми. Проблема была в том, что гранулярность управления аудитом в то время была очень низкой. Так, если требовалось отследить доступ к файлам, то включали категорию базовой политики «Аудит доступа к объектам». В результате чего помимо файловых операций в журнал безопасности сыпалась еще куча других «шумовых» событий. Это сильно усложняло обработку журналов и нервировало пользователей.
Microsoft услышала эту «боль» и решила помочь. Проблема в том, что Windows строится по концепции обратной совместимости, и внесение изменений в действующий механизм управления аудитом эту совместимость бы убило. Поэтому вендор пошел другим путем. Он создал новый инструмент и назвал его расширенными политиками аудита.
Суть инструмента заключается в том, что из категорий базовых политик аудита сделали категории расширенных политик, а те, в свою очередь, разделили на подкатегории, которые можно отдельно включать и отключать. Теперь при необходимости отслеживания доступа к файлам в расширенных политиках аудита необходимо активировать только подкатегорию «Файловая система», входящую в категорию «Доступ к объектам». При этом «шумовые» события, связанные с доступом к реестру или фильтрацией сетевого трафика, в журнал безопасности попадать не будут.
Гигантскую путаницу во всю эту схему вносит то, что наименования категорий базовых политик аудита и расширенных не совпадают, и по началу может показаться, что это абсолютно разные вещи, однако это не так.
Приведем таблицу соответствия наименования базовых и расширенных категорий управления аудитом
| Наименование базовых политик аудита | Наименование расширенной политики аудита |
| Аудит доступа к службе каталогов | Доступ к службе каталогов (DS) |
| Аудит доступа к объектам | Доступ к объектам |
| Аудит использования привилегий | Использование прав |
| Аудит входа в систему | Вход/выход |
| Аудит событий входа в систему | Вход учетной записи |
| Аудит изменения политики | Изменение политики |
| Аудит системных событий | Система |
| Аудит управления учетными записями | Управление учетными записями |
| Аудит отслеживания процессов | Подробное отслеживание |
Важно понимать, что и базовые и расширенные категории по сути управляют одним и тем же. Включение категории базовой политики аудита приводит к включению соответствующей ей категории расширенной политики аудита и, как следствие, всех ее подкатегорий. Во избежание непредсказуемых последствий Microsoft не рекомендует одновременное использование базовых и расширенных политик аудита.
Теперь настало время разобраться с тем, где хранятся настройки аудита. Для начала введем ряд понятий:
| Наименование средства | Отображаемые политики аудита | Сохраняемые политики аудита |
| «Базовые политики аудита» оснастки «Локальные политики безопасности» | Эффективные политики аудита | Эффективные политики аудита, сохраненные политики аудита |
| «Расширенные политики аудита» оснастки «Локальные политики безопасности» | Файл %SystemRoot%System32GroupPolicyMachineMicrosoftWindows NTAuditaudit.csv | |
| Утилита auditpol | Сохраненные параметры аудита | Эффективные параметры аудита, сохраненные параметры аудита |
Поясним таблицу на примерах.
Отдельного комментария требует порядок отображения параметров аудита в «Базовых политиках аудита» оснастки «Локальные политики безопасности». Категория базовой политики аудита отображается как установленная, если установлены все подкатегории соответствующей ей расширенной политики аудита. Если хотя бы одна из них не установлена, то политика будет отображаться как не установленная.
Администратор с помощью команды auditpol /set /category:* установил все подкатегории аудита в режим «Аудит успехов». При этом если зайти в «Базовые политики аудита» оснастки «Локальные политики безопасности», то напротив каждой категории будет установлено «Аудит успеха».
В «Базовых политиках аудита» оснастки «Локальные политики безопасности» эти сведения об аудите не отображаются, так как во всех категориях не определена одна или более подкатегорий. В «Расширенных политиках аудита» оснастки «Локальные политики безопасности» эти сведения не отображаются, так как оснастка работает только c параметрами аудита, хранящимися в файле %SystemRoot%System32GroupPolicyMachineMicrosoftWindows NTAuditaudit.csv.
В чем суть проблемы?
По началу может показаться, что все это и не проблема вовсе, но это не так. То, что все инструменты показывают параметры аудита по разному, создает возможность к злонамеренному манипулированию политиками и, как следствие, результатами аудита.
Рассмотрим вероятный сценарий
Пусть в корпоративной сети работает технологическая рабочая станция на базе Windows 7.
Машина не включена в домен и выполняет функции робота, ежедневно отправляющего отчетность в контролирующие органы. Злоумышленники тем или иным образом получили на ней удаленный доступ с правами администратора. При этом основная цель злоумышлеников — шпионаж, а задача — оставаться в системе незамеченными. Злоумышленники решили скрытно, чтоб в журнале безопасности не было событий с кодом 4719 «Аудит изменения политики», отключить аудит доступа к файлам, но при этом чтобы все инструменты администрирования говорили, что аудит включен. Для достижения поставленной задачи они выполнили следующие действия:
Проблема № 2. Неудачная реализация журналирования операций удаления файлов, каталогов и ключей реестра
Наличие проблемы подтверждено на Windows 7/10/Server 2019.
Описание проблемы
На одну операцию удаления файла, каталога или ключа реестра операционная система генерирует последовательность событий с кодами 4663 и 4660. Проблема в том, что из всего потока событий данную парочку не так уж просто связать друг с другом. Для того чтобы это сделать, анализируемые события должны обладать следующими параметрами:
Событие 1. Код 4663 «Выполнена попытка получения доступа к объекту». Параметры события:
«ObjectType» = File.
«ObjectName» = имя удаляемого файла или каталога.
«HandleId» = дескриптор удаляемого файла.
«AcessMask» = 0x10000 (Данный код соответствует операции DELETE. С расшифровкой всех кодов операций можно ознакомиться на сайте Microsoft).
Событие 2. Код 4660 «Объект удален».
Параметры события:
«HandleId» = «HandleId события 1»
«SystemEventRecordID» = «SystemEventRecordID из события 1» + 1.
С удалением ключа (key) реестра всё то же самое, только в первом событии с кодом 4663 параметр «ObjectType» = Key.
Отметим, что удаление значений (values) в реестре описывается другим событием (код 4657) и подобных проблем не вызывает.
Особенности удаления файлов в Windows 10 и Server 2019
В Windows 10 / Server 2019 процедура удаления файла описывается двумя способами.
В чем суть проблемы?
Проблема заключается в том, что узнать кто удалил файл или каталог, становится нетривиальной задачей. Вместо банального поиска соответствующего события по журналу безопасности необходимо анализировать последовательности событий, что вручную делать довольно трудоемко. На хабре даже по этому поводу была статья: «Аудит удаления и доступа к файлам и запись событий в лог-файл средствами Powershell».
Проблема № 3 (критическая). Неудачная реализация журналирования операции переименования файлов, каталогов и ключей реестра
Наличие проблемы подтверждено на Windows 7/10/Server 2019.
Описание проблемы
Эта проблема состоит из двух подпроблем:
В чем суть проблемы?
Помимо затруднения поиска операций переименования файлов подобная особенность журналирования не позволяет отследить полный жизненный цикл объектов файловой системы или ключей реестра. В результате чего на активно используемом файловом сервере становится крайне затруднительно определить историю файла, который многократно переименовывался.
Проблема № 4 (критическая). Невозможно отследить создание каталога и ключа реестра
Наличие проблемы подтверждено на Windows 7/10/Server 2019.
Описание проблемы
Windows не позволяет отследить создание каталога файловой системы и ключа реестра. Это заключается в том, что операционная система не генерирует событие, в котором содержалось бы имя создаваемого каталога или ключа реестра, и параметры которого указывали бы на то, что это именно операция создания.
В чем суть проблемы?
Эта проблема существенно затрудняет проведение расследований инцидентов информационной безопасности. Нет никаких разумных объяснений тому, что в журналах не фиксируется данная информация.
Проблема № 5 (критическая). Сбойные параметры аудита в русских версиях Windows
Наличие проблемы подтверждено на русских редакциях Windows 7/10/Server 2019.
Описание проблемы
В русских версиях Windows есть ошибка, приводящая систему управления аудитом безопасности в нерабочее состояние.
Симптомы
Причины
Проблема возникает, если администратор активировал хотя бы одну из «сбойных» подкатегорий расширенных политик аудита. К подобным сбойным категориям, в частности, относятся:
Рекомендации по решению проблемы
Если проблема еще не произошла, то не активируйте указанные «сбойные» подкатегории. Если события этих подкатегорий очень нужны, то пользуйтесь утилитой auditpol для их активации или же управляйте аудитом с помощью базовых политик.
Если проблема произошла, то необходимо:
В чем суть проблемы?
Наличие данной проблемы уменьшает количество событий безопасности, которые можно контролировать штатным образом через расширенные политики аудита, а также создает угрозы отключения, блокирования и дестабилизации управления системой аудита в корпоративной сети.
Проблема № 6 (критическая). Будь проклят «Новый текстовый документ.txt. а также Новый точечный рисунок.bmp»
Наличие проблемы подтверждено на Windows 7. Проблема отсутствует в Windows 10/Server 2019.
Описание проблемы
Это очень странная проблема, которая была обнаружена чисто случайно. Суть проблемы в том, что в операционной системе есть лазейка, позволяющая обойти аудит создания файлов.
Из командной строки выполним команду: echo > «c:testНовый текстовый документ.txt»
Наблюдаем:
По факту создания файла в журнале безопасности появилось событие с кодом 4663, содержащее в поле «ObjectName» имя создаваемого файла, в поле «AccessMask» значение 0x2 («Запись данных или добавление файла»).
Для выполнения следующих экспериментов очистим папку и журнал событий.
В журнале событий данное действие никак не отразилось. Также никаких записей не будет, если с помощью того же контекстного меню создать «Точечный рисунок».
Как и в случае с созданием файла через командную строку в журнале появилось событие с кодом 4663 и соответствующим наполнением.
В чем суть проблемы?
Конечно создание текстовых документов или картинок особого вреда не представляет. Однако, если «Проводник» умеет обходить журналирование файловых операций, то это смогут сделать и вредоносы.
Данная проблема является, пожалуй, наиболее значимой из всех рассмотренных, поскольку серьезно подрывает доверие к результатам работы аудита файловых операций.
Заключение
Приведенный перечень проблем не исчерпывающий. В процессе работы удалось споткнуться о еще довольно большое количество различных мелких недоработок, к которым можно отнести использование локализованных констант в качестве значений параметров ряда событий, что заставляет писать свои анализирующие скрипты под каждую локализацию операционной системы, нелогичное разделение кодов событий на близкие по смыслу операции, например, удаление ключа реестра — это последовательность событий 4663 и 4660, а удаление значения в реестре — 4657, ну и еще по мелочи…
Справедливости ради отметим, что несмотря на все недостатки система журналирования событий безопасности в Windows имеет большое количество положительных моментов. Исправление указанных здесь критических проблем может вернуть системе корону лучшего решения по журналированию событий безопасности из коробки.
MAKE WINDOWS SECURITY EVENT LOGGING GREAT AGAIN!
Источник
Кто пытался войти в систему Windows
Это небольшая статья призвана показать пользователям способ, которым он узнает, кто пытался войти в систему без его ведома. Если компьютер находится в офисе и к нему имеют доступ не один человек, тогда способ может пригодиться. Советую ознакомиться со статьей – кто пытался войти через вашу учетную запись. Там говориться об учетной записи Microsoft, в которую могут войти любые злоумышленники.
Один из способов имеет название «Аудит входа в систему». Опция показываем время захода и его тип. Давайте уже разбираться.
Как использовать «Аудит входа в систему»
Данная функция доступна только в PRO версии Windows, где есть функция локальных групповых политик, в домашней или корпоративной её нет. Но в ниже есть другие варианты для вашей версии. Итак, откройте окно «Выполнить» и впишем команду:
Так мы запустим утилиту групповых политик. С левой стороны окошка открываем вкладки «Конфигурация компьютера», далее «Конфигурация Windows», «Параметры безопасности», «Локальные политики» и «Политика аудита». Нажмите на этот раздел, чтобы правее от окна появились нужные опции.
Теперь выбираем пункт «Аудит событий входа в систему» (Нажимаем на него правой кнопкой мышки дважды). Появится окно свойств, где выделяем галкой пункт «Успех». Таким образом, появится возможность отслеживать все входы в Windows. Отметив галкой «Отказ», будут отслеживаться неудачные входы в Windows.
Смотрим, кто пытался войти в систему
Активировав функцию, можно заново войти в систему. Давайте проверим, кто же входил в неё. Для этого дела нам понадобиться утилита «Просмотр событий». В поиске введите эти два слова.
В утилите перейдите в раздел «Журналы Windows» и подраздел «Безопасность». Справа находим ключевое событие «Аудит успеха», также смотрите по номеру события, он должен быть «4624».
Откройте событие, чтобы узнать его свойства. Там вы найдете время входа, имя пользователя и другие сведения.
В окне просмотра событий можно применить фильтр, чтобы было легче ориентироваться среди большого количества задач. Фильтровать можно по ключевым фразам, кодам, или категориям.
В Windows 10 с помощью реестра
Если у вас не профессиональная редакция Windows, то воспользуемся реактором реестра. Снова откроем окошко «Выполнить» при помощи комбинации «Win+R» и запишем команду:
Открывшееся окно реестра слева имеет кучу разделов, с вложенными подразделами. Вам нужно дойти до самого последнего:
Выбрав последний раздел, в правой части окошка создаем параметр DWORD 32 бит. Дадим ему название DisplayLastLogonInfo. Нажимаем по нему два раза и ставим в качестве значения единицу.
Закрываем окна и перезагружаем ПК. После загрузки системы на экране появится окно с успешным входом. Там будет время, имя пользователя и дата.
Надеюсь этот небольшой материал поможет вам узнать, кто входил в систему при вашем отсутствии.
Источник
Управление журналом аудита и безопасности
Область применения
Описывает лучшие практики, расположение, значения, управление политикой и соображения безопасности для параметра Политики безопасности управления аудитом и безопасностью журналов безопасности.
Справочники
Этот параметр политики определяет, какие пользователи могут указывать параметры аудита доступа к объекту для отдельных ресурсов, таких как файлы, объекты Active Directory и ключи реестра. Эти объекты указывают свои списки управления доступом к системе (SACL). Пользователь, которому назначено это право пользователя, также может просматривать и очищать журнал безопасности в viewer событий. Дополнительные сведения о политике аудита доступа к объекту см. в этой информации.
Возможные значения
Рекомендации
Location
Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesUser Rights Assignment
Значения по умолчанию
По умолчанию этот параметр — администраторы на контроллерах домена и на автономных серверах.
В следующей таблице перечислены фактические и эффективные значения политики по умолчанию для последних поддерживаемых версий Windows. Значения по умолчанию также можно найти на странице свойств политики.
| Тип сервера или объект групповой политики | Значение по умолчанию |
|---|---|
| Default Domain Policy | Не определено |
| Политика контроллера домена по умолчанию | Администраторы |
| Параметры по умолчанию для автономного сервера | Администраторы |
| Действующие параметры по умолчанию для контроллера домена | Администраторы |
| Действующие параметры по умолчанию для рядового сервера | Администраторы |
| Действующие параметры по умолчанию для клиентского компьютера | Администраторы |
Управление политикой
В этом разделе описаны компоненты, средства и рекомендации, которые помогут в управлении этой политикой.
Для активации этого параметра политики не требуется перезагрузка компьютера.
Изменения прав пользователя вступают в силу при его следующем входе в учетную запись.
Аудит доступа к объекту не выполняется, если вы не включаете их с помощью редактора локальной групповой политики, консоли управления групповой политикой (GPMC) или средства командной строки Auditpol.
Дополнительные сведения о политике аудита доступа к объекту см. в этой информации.
Групповая политика
Параметры применяются в следующем порядке с помощью объекта групповой политики (GPO), который перезаписывал параметры на локальном компьютере при следующем обновлении групповой политики:
Когда локальный параметр серый, он указывает, что GPO в настоящее время контролирует этот параметр.
Вопросы безопасности
В этом разделе описывается, каким образом злоумышленник может использовать компонент или его конфигурацию, как реализовать меры противодействия, а также рассматриваются возможные отрицательные последствия их реализации.
Уязвимость
Любой пользователь с правом управления аудитом и журналом безопасности может очистить журнал Безопасности, чтобы удалить важные доказательства несанкционированной деятельности.
Противодействие
Убедитесь, что только группа локальных администраторов имеет право пользователя на управление аудитом и журналом безопасности.
Возможное влияние
Ограничение права пользователя журнала аудита и безопасности на локализованную группу администраторов — это конфигурация по умолчанию.
Предупреждение: Если этим пользователям назначены группы, не соответствующие локальной группе администраторов, удаление этого права пользователя может вызвать проблемы с производительностью в других приложениях. Прежде чем удалить это право из группы, изучите, зависят ли приложения от этого права.
Источник
Аудит выхода из системы
Журнал аудита определяет, генерирует ли операционная система события аудита при прекращении сеансов логотипа.
Эти события происходят на компьютере, к нему был доступ. Для интерактивного логотипа эти события создаются на компьютере, на который был внесен вход.
В этой подкатегории нет события сбоя, так как неудаваемые журналы (например, при резком закрытии системы) не создают записи аудита.
События Logon имеют важное значение для понимания активности пользователей и обнаружения потенциальных атак. События logoff не являются на 100 процентов надежными. Например, компьютер можно отключить без надлежащего входа и отключения; В этом случае событие входа не создается.
Объем событий: High.
Эта подкатегория позволяет проверять события, созданные при закрытии сеанса логотипа. Эти события происходят на компьютере, к нему был доступ. Для интерактивного входа событие аудита безопасности создается на компьютере, на который вошел учетная запись пользователя.
| Тип компьютера | Общий успех | Общий сбой | Более сильный успех | Более сильный сбой | Комментарии |
|---|---|---|---|---|---|
| Контроллер домена | Нет | Нет | Да | Нет | Эта подкатегория обычно создает огромное количество»4634(S): учетная запись была отключена». события, которые, как правило, имеют мало релевантности для безопасности. Важнее проверять события Logon с помощью подкатегории Audit Logon, а не событий Logoff. Включите аудит успешности, если вы хотите отслеживать, например, как долго сеанс был активен (в связи с событиями Audit Logon) и когда пользователь входил в систему. В этой подкатегории нет событий сбоя, поэтому нет рекомендации включить аудит отказа для этой подкатегории. |
| Сервер участника | Нет | Нет | Да | Нет | Эта подкатегория обычно создает огромное количество»4634(S): учетная запись была отключена». события, которые, как правило, имеют мало релевантности для безопасности. Важнее проверять события Logon с помощью подкатегории Audit Logon, а не событий Logoff. Включите аудит успешности, если вы хотите отслеживать, например, как долго сеанс был активен (в связи с событиями Audit Logon) и когда пользователь входил в систему. В этой подкатегории нет событий сбоя, поэтому нет рекомендации включить аудит отказа для этой подкатегории. |
| Workstation | Нет | Нет | Да | Нет | Эта подкатегория обычно создает огромное количество»4634(S): учетная запись была отключена». события, которые, как правило, имеют мало релевантности для безопасности. Важнее проверять события Logon с помощью подкатегории Audit Logon, а не событий Logoff. Включите аудит успешности, если вы хотите отслеживать, например, как долго сеанс был активен (в связи с событиями Audit Logon) и когда пользователь входил в систему. В этой подкатегории нет событий сбоя, поэтому нет рекомендации включить аудит отказа для этой подкатегории. |
Список событий:
4634(S): учетная запись была отключена.
4647(S). Инициированный пользователем журнал.
Источник
Уважаемые друзья, в предыдущих публикациях мы говорили об основах информационной безопасности, законодательстве по защите персональных данных и критической информационной инфраструктуры, безопасности в кредитно-финансовой сфере, а также провели анализ основных стандартов по управлению рисками информационной безопасности и обсудили системы класса IRP, предназначенные для автоматизации реагирования на инциденты ИБ. Как мы знаем, при обработке инцидентов детальный анализ событий безопасности с устройств является одним из ключевых этапов. В данной публикации мы рассмотрим настройку подсистемы аудита ОС Windows, принципы анализа и централизованного сбора журналов аудита с Windows-устройств и их пересылку в SIEM-систему IBM QRadar, а также покажем, как можно с помощью штатных средств Windows и утилиты Sysmon настроить простейшую систему реагирования на инциденты ИБ. Вперед!
Для решения задачи обработки инцидентов ИБ логично рассуждать, что чем больше данных (логов, событий безопасности) мы собираем, храним и анализируем, тем проще нам будет в дальнейшем не только оперативно среагировать на инцидент, но и расследовать обстоятельства произошедших атак для поиска причин их возникновения. При этом большое количество данных для обработки имеет и очевидный минус: нас может просто «засыпать» сообщениями, алертами, уведомлениями, поэтому необходимо выбрать самые значимые с точки зрения ИБ события и настроить соответствующие политики аудита. Microsoft предлагает использовать бесплатный набор утилит и рекомендаций (Baselines) в своем наборе Microsoft Security Compliance Toolkit, в котором в том числе приведены и рекомендуемые настройки аудита для контроллеров домена, рядовых серверов и рабочих станций. Кроме рекомендаций вендора можно обратиться еще к документам CIS Microsoft Windows Server Benchmark и CIS Microsoft Windows Desktop Benchmark, в которых, в числе прочего, указаны рекомендуемые экспертами политики аудита для, соответственно, серверных и десктопных версий ОС Windows. Однако зачастую выполнение абсолютно всех рекомендаций неэффективно именно по причине потенциального появления большого количества «шумящих», малозначительных с точки зрения ИБ событий, поэтому в настоящей статье мы сначала приведем список наиболее полезных и эффективных (с нашей точки зрения) политик аудита безопасности и соответствующих типов событий безопасности ОС Windows.
Напомню, что в ОС Microsoft Windows, начиная с Microsoft Windows Server 2008 и Vista, используется достаточно продвинутая система аудита, настраиваемая при помощи конфигурирования расширенных политик аудита (Advanced Audit Policy Configuration). Не стоит забывать о том, что как только на устройствах будут включены политики расширенного аудита, по умолчанию старые «классические» политики аудита перестанут быть эффективными, хотя данное поведение может быть переопределено в групповой политике «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии))» (Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings).
Политики аудита Windows
Пройдем последовательно по настройкам, эффективным для решения задач аудита ИБ и выработки целостной политики аудита безопасности.
|
Категория аудита |
Подкатегория аудита |
События аудита |
EventID |
Комментарии |
|
Вход учетной записи |
Аудит проверки учетных данных |
Успех, Отказ |
4776 |
Целесообразно контролировать на домен-контроллерах при использовании NTLM-аутентификации. |
|
Аудит службы проверки подлинности Kerberos |
Успех, Отказ |
4771 |
Неуспешная аутентификация учетной записи на контроллере домена с использованием Kerberos-аутентификации. |
|
|
4768 |
Запрос билета Kerberos, при этом следует анализировать коды ответа сервера. |
|||
|
Примечание: Данный тип аудита следует включать на контроллерах домена, при этом для детального изучения попыток подключения и получения IP-адреса подключающегося устройства на контроллере домена следует выполнить команду nltest /dbflag:2080ffff и проводить аудит текстового лог-файла %windir%debugnetlogon.log |
||||
|
Управление учетными записями |
Аудит управления учетными записями компьютеров |
Успех |
4741 |
Заведение устройства в домен Active Directory; может использоваться злоумышленниками, поскольку любой пользователь домена по умолчанию может завести в домен 10 устройств, на которых может быть установлено неконтролируемое компанией ПО, в том числе вредоносное. |
|
Аудит управления группами безопасности |
Успех, Отказ |
4728 |
Добавление члена глобальной группы. |
|
|
4732 |
Добавление члена локальной группы. |
|||
|
4756 |
Добавление члена универсальной группы. |
|||
|
Аудит управления учетными записями пользователей |
Успех, Отказ |
4720 |
Создание учетной записи. |
|
|
4725 |
Отключение учетной записи. |
|||
|
4740 |
Блокировка учетной записи. |
|||
|
4723 |
Смена пароля. |
|||
|
4724 |
Сброс пароля. |
|||
|
Подробное отслеживание |
Аудит создания процессов |
Успех |
4688 |
При создании процесса. |
|
4689 |
При завершении процесса. |
|||
|
Примечание: Чтобы для командного интерпретатора велась запись введенных команд, следует включить политику «Конфигурация компьютера — Конфигурация Windows — Административные шаблоны — Система — Аудит создания процессов -> Включать командную строку в события создания процессов». Примечание: Чтобы велась запись выполняемых PowerShell-команд и загруженных PowerShell-модулей, следует включить в каталоге «Конфигурация компьютера — Конфигурация Windows — Административные шаблоны — Компоненты Windows — Windows PowerShell» политики «Включить ведение журнала модулей» (в настройках политики указать все модули символом «*») и «Включить регистрацию блоков сценариев PowerShell» (в настройках политики отметить check-box «Регистрация начала или остановки вызова блоков сценариев»). Работа PowerShell-скриптов регистрируется с EventID=4104,4105,4106 в журнале Microsoft-Windows-PowerShell/Operational, а загрузка PowerShell-модулей регистрируется с EventID=800 в журнале Windows PowerShell. |
||||
|
Вход/выход |
Аудит выхода из системы |
Успех |
4634 |
Для неинтерактивных сессий. |
|
4647 |
Для интерактивных сессий и RDP-подключений. |
|||
|
Примечание: При этом следует обращать внимание на код Logon Type, который показывает тип подключения (интерактивное, сетевое, с закэшированными учетными данными, с предоставлением учетных данных в открытом виде и т.д.). |
||||
|
Аудит входа в систему |
Успех, Отказ |
4624 |
При успешной попытке аутентификации, создается на локальном ПК и на домен-контроллере при использовании NTLM и Kerberos-аутентификации. |
|
|
4625 |
При неуспешной попытке аутентификации, создается на локальном ПК и на домен-контроллере при использовании NTLM аутентификации; при Kerberos-аутентификации на контроллере домена создается EventID=4771. |
|||
|
4648 |
При попытке входа с явным указанием учетных данных, например, при выполнении команды runas, а также при работе «хакерской» утилиты Mimikatz. |
|||
|
Примечание: При этом следует обращать внимание на код входа (Logon Type), который показывает тип подключения (интерактивное, сетевое, с закэшированными учетными данными, с предоставлением учетных данных в открытом виде и т.д.). Целесообразно также обращать внимание на код ошибки (Status/SubStatus), который также сохраняется в событии аудита и характеризует причину неуспешного входа — несуществующее имя учетной записи, недействительный пароль, попытка входа с заблокированной учетной записью и т.д. |
||||
|
Аудит других событий входа и выхода |
Успех, Отказ |
4778 |
RDP-подключение было установлено. |
|
|
4779 |
RDP-подключение было разорвано. |
|||
|
Аудит специального входа |
Успех |
4672 |
При входе с административными полномочиями. |
|
|
Доступ к объектам |
Аудит сведений об общем файловом ресурсе |
Успех, Отказ |
5145 |
При доступе к системных сетевым ресурсам, таким как \C$ . Данное событие будет создаваться при работе ransomware, нацеленного на горизонтальное перемещение по сети. |
|
Аудит других событий доступа к объектам |
Успех, Отказ |
4698 |
При создании задания в «Планировщике задач», что часто используется злоумышленниками как метод закрепления и скрытия активности в атакованной системе. |
|
|
Изменение политики |
Аудит изменения политики аудита |
Успех |
4719 |
Изменение политики аудита. |
|
4906 |
Изменение настройки CrashOnAuditFail. |
|||
|
Примечание: Изменить реакцию ОС на невозможность вести журнал аудита безопасности (настройка CrashOnAuditFail) можно в каталоге «Конфигурация компьютера — Конфигурация Windows — Параметры безопасности — Локальные политики — Параметры безопасности» в политике «Аудит: немедленное отключение системы, если невозможно внести в журнал записи об аудите безопасности». |
||||
|
Система |
Аудит расширения системы безопасности |
Успех |
4610 4614 4622 |
При появлении в системе новых пакетов аутентификации, что не должно происходить несанкционированно. |
|
4697 |
При создании нового сервиса, что часто используется злоумышленниками как метод закрепления и скрытия активности в атакованной системе. |
Кроме описанных выше настроек, имеет смысл также контролировать появление в журнале безопасности события с EventID=1102, которое формируется сразу после очистки журнала безопасности, что может говорить о вредоносной активности. Более того, разумно будет включить в каталоге «Конфигурация компьютера — Конфигурация Windows — Параметры безопасности — Локальные политики — Параметры безопасности» политику «Сетевая безопасность: ограничения NTLM: исходящий трафик NTLM к удаленным серверам» в значение «Аудит всего». После этого EventID=8001 в журнале Microsoft-Windows-NTLM/Operational будет содержать информацию об автоматической аутентификации на веб-ресурсах с учетной записью пользователя. Следующим шагом станет allow list с перечнем веб-ресурсов, которые легитимно могут запрашивать учетные записи, а указанную политику можно будет перевести в режим блокировки. Это не позволит вредоносным ресурсам получать NTLM-хэши пользователей, которые кликнули на ссылку из фишингового письма.
Обратим внимание и на то, что подсистема журналирования Windows весьма гибка и позволяет настроить аудит произвольных папок и веток реестра — следует лишь выбрать критичные для ИТ-инфраструктуры объекты аудита и включить данные опции.
Настройка Windows Event Forwarding, интеграция с IBM QRadar
Настроив необходимые параметры аудита, перейдем к решению вопроса автоматизации сбора журналов аудита и их централизованного хранения и анализа. Штатный механизм Windows Event Forwarding, который работает из коробки с Microsoft Windows Server 2008 / Vista и старше, позволяет осуществлять централизованный сбор журналов аудита на устройстве-коллекторе (не ниже Windows Server 2008 и Vista, но все же рекомендуется использовать выделенный Windows Server 2012R2 и старше) с устройств-источников с применением функционала WinRM (Windows Remote Management, использует протокол WS-Management) и использованием т.н. «подписок» на определенные события (набор XPath-выражений, о которых мы поговорим далее, для выбора интересующих журналов и событий на источнике). События с удаленных устройств могут быть как запрошены коллектором (режим Pull/Collector initiated), так и отправлены самим источником (режим Push/Source computer initiated). Мы рекомендуем использовать последний режим, поскольку в режиме Push служба WinRM слушает входящие соединения только на коллекторе, а на клиентах-источниках WinRM не находится в режиме прослушивания и лишь периодически обращается к коллектору за инструкциями, что уменьшает поверхность потенциальной атаки на конечные устройства. По умолчанию для шифрования трафика от источников к коллектору, принадлежащих одному Windows-домену, используется Керберос-шифрование SOAP-данных, передаваемых через WinRM (режим HTTP-Kerberos-session-encrypted), при этом HTTP-заголовки и соответствующие метаданные передаются в открытом виде. Другой опцией является использование HTTPS с установкой SSL-сертификатов на приемнике и источнике, при этом они могут не принадлежать одному домену. При дальнейшем изложении будем считать, что мы работаем в одном домене и используем настройку по умолчанию.
Рассмотрев концепцию пересылки логов с Windows-устройств, перейдем непосредственно к настройке нашей связки: источник событий -> сервер-коллектор -> утилита IBM WinCollect -> SIEM-система IBM QRadar.
Для включения сервиса сбора логов следует выполнить нижеописанные шаги:
1. На сервере-коллекторе выполнить команду winrm qc, ответить согласием на оба последующих вопроса (включение службы WinRM и прослушивание порта TCP:5985 для входящих соединений от источников). Следует учесть, что выполнение команды winrm qc одновременно включает Windows Remote Shell (WinRS) и разрешает принимать входящие соединения для удаленного управления через функционал WinRS. Отключить WinRS можно либо через политику «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Удаленная оболочка Windows / Разрешить доступ к удаленной оболочке -> Запретить» (Computer Configuration / Administrative Templates / Windows Components / Windows Remote Shell / Allow Remote Shell Access -> Disabled), либо командой winrm set winrm/config/winrs @{AllowRemoteShellAccess=»false»}
2. На сервере-коллекторе выполнить команду wecutil qc, согласиться на включение службы «Сборщик событий Windows» (Windows Event Collector). При этом в Windows Firewall создается разрешающее правило для входящих соединений на коллектор по TCP:5985.
3. На источниках событий следует включить службу WinRM: установить «Тип запуска» в значение «Автостарт» и запустить «Службу удаленного управления Windows» (Windows Remote Management (WS-Management)).
4. Проверить состояние службы WinRM на сервере-колекторе можно командой winrm enumerate winrm/config/listener, в результате выполнения которой отобразятся настройки порта и список локальных IP-адресов, на которых прослушиваются соединения по TCP:5985. Команда winrm get winrm/config покажет подробные настройки службы WinRM. Переконфигурировать настройки можно либо непосредственно через утилиту winrm, либо через групповые политики по пути «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Удаленное управление Windows» (Computer Configuration / Administrative Templates / Windows Components / Windows Remote Management).
5. На источниках событий требуется предоставить доступ к журналам аудита службе WinRM путем включения встроенной учетной записи NT AUTHORITYNETWORK SERVICE (SID S-1-5-20) в локальную группу BUILTINEvent Log Readers («Читатели журнала событий»). После этого необходимо перезапустить «Службу удаленного управления Windows» (WinRM) и службу «Журнал событий Windows» (EventLog).
6. Затем следует создать и применить конфигурацию групповой политики для источников, в которой будет указана конфигурация и адрес сервера-коллектора. Требуется включить политику «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Пересылка событий / Настроить адрес сервера…» (Computer Configuration / Administrative Templates / Windows Components / Event Forwarding / Configure the server address…) и указать адрес сервера-коллектора в следующем формате:
Server=http://servername.domain.local:5985/wsman/SubscriptionManager/WEC,Refresh=60
где 60 – частота обращения (в секундах) клиентов к серверу за новыми инструкциями по пересылке журналов. После применения данной настройки на устройствах-источниках следует сделать перезапуск службы WinRM.
7. Далее создаем и применяем конфигурацию подписки на сервере-коллекторе: открываем оснастку управления журналами аудита (eventvwr.msc) и находим внизу раздел «Подписки» (Subscriptions). Нажимаем правой кнопкой мыши и выбираем «Создать подписку», задаем имя подписки. Далее выбираем опцию «Инициировано исходным компьютером» (Source Computer Initiated, это означает предпочтительный режим Push). Нажимаем на кнопку «Выбрать группы компьютеров» (Select Computer Groups), выбираем из Active Directory те устройства или их группы, которые должны будут присылать логи на коллектор. Далее, нажимаем «Выбрать события» (Select Events) и вводим XPath-запрос (пример для сбора журналов Security):
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*</Select>
</Query>
</QueryList>
8. В итоге, клиенты должны иметь активные сетевые соединения по TCP:5985 с сервером-коллектором. На сервере-коллекторе в eventvwr.msc в свойствах «Подписки» можно будет увидеть список клиентов-источников, а пересланные события будут находиться в разделе «Журналы Windows – Перенаправленные события» (Windows Logs – Forwarded Events) на сервере-коллекторе.
9. Далее решаем задачу пересылки собранных на сервере-коллекторе логов с источников в SIEM систему IBM QRadar. Для этого нам потребуется установить на сервере-коллекторе утилиту IBM WinCollect.
Рекомендуем использовать управляемый (Managed) режим работы WinCollect для упрощения его администрирования. Для того, чтобы отправляемые через WinCollect агрегированные события корректно обрабатывались в IBM QRadar, нам следует воспользоваться рекомендациями IBM и на сервере-коллекторе с установленной утилитой WinCollect перевести формат пересылаемых событий в RenderedText, а также сменить их локаль на EN-US командой wecutil ss SubscriptionName /cf:RenderedText /l:en-US (где SubscriptionName — имя подписки, заданное в п.7 выше). Кроме того, необходимо обеспечить сетевую доступность между сервером-коллектором с установленным WinCollect и нодами IBM QRadar по TCP:8413 и TCP/UDP:514.
10. После установки утилиты WinCollect на сервер-коллектор, в самой SIEM-системе IBM QRadar нужно будет добавить этот сервер в список источников (тип источника Microsoft Security Event Log, в поле Target Destination в выпадающем списке лучше выбрать вариант с TCP-syslog-подключением, отметить check-box Forwarded Events).
После применения указанных настроек новые события и устройства-источники, пересылающие Windows-логи на сервер-коллектор, появятся в консоли IBM QRadar автоматически. В итоге, после внедрения SIEM-системы данные в ней и регистрацию событий информационной безопасности можно будет легко обогатить журналами аудита Windows, собранными описанным способом с различных устройств в инфраструктуре компании.
Утилита Sysmon
Кроме задействования штатного функционала подсистемы журналирования, можно воспользоваться и официальной бесплатной утилитой Sysmon из пакета Microsoft Windows Sysinternals, которая существенно расширяет и дополняет возможности мониторинга ОС. Данная утилита дает возможность проводить аудит создания файлов, ключей реестра, процессов и потоков, а также осуществлять мониторинг загрузки драйверов и библиотек, сетевых подключений, WMI-событий и именованных каналов. Из особо полезных функций отметим возможность утилиты показывать родительский процесс и командную строку процесса, отображать значение хэш-сумм при событиях создания процесса и загрузки драйверов и библиотек с указанием наличия и действительности цифровой подписи. Несложным путем можно автоматизировать сравнение полученных хэш-сумм с индикаторами компрометации (IoCs, Indicator of Compromise) из данных фидов CyberThreat Intelligence, а также использовать приложение QVTI для IBM QRadar, с помощью которого хэши запускаемых файлов автоматически проверяются через сервис VirusTotal. Еще одной приятной опцией является возможность создания XML-конфигураций, в которых можно предельно четко указать объекты контроля и настройки работы Sysmon. Одними из наиболее продвинутых и детальных вариантов XML-конфигураций, с нашей точки зрения, являются конфиги https://github.com/ion-storm/sysmon-config и https://github.com/SwiftOnSecurity/sysmon-config .
Установка Sysmon предельно проста и также может быть легко автоматизирована:
1. Дистрибутив скачивается с https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon
Все исполняемые файлы подписаны.
2. Создается или скачивается по приведенным выше ссылкам xml-файл с конфигурацией Sysmon.
3. Установка sysmon для x64 производится командой:
C:foldersysmon64.exe -accepteula -i C:foldersysmonconfig-export.xml , где sysmonconfig-export.xml – файл конфигурации, sysmon64.exe – файл-установщик.
Поддерживается запуск установки из сетевой папки.
4. После установки создается журнал Microsoft-Windows-Sysmon/Operational , размер которого мы сразу рекомендуем увеличить как минимум до 100 Мб.
Перезапуск устройства не требуется, Sysmon работает в виде сервиса, его исполняемый файл находится в C:Windowssysmon64.exe . По нашим подсчетам, footprint на конечной системе даже при использовании максимально детального конфига Sysmon не превышает 5-10% ЦПУ и около 100 Мб ОЗУ.
XPath-запросы
Наконец, выполнив необходимые настройки файлов журналов Windows, перейдем непосредственно к поиску интересующей информации. Заметим, что в случае включения всех рекомендованных политик аудита ИБ сами журналы событий становятся достаточно объемными, поэтому поиск по их содержимому может быть медленным (этих недостатков лишены специализированные решения, предназначенные в том числе для быстрого поиска информации — Log Management и SIEM-системы). Отметим также, что по умолчанию не все журналы Windows отображаются к графической оснастке (eventvwr.msc), поэтому в данной оснастке следует перейти в меню «Вид» и отметить check-box «Отобразить аналитический и отладочный журналы».
Итак, поиск по журналам аудита будем осуществлять с помощью встроенного редактора запросов XPath (XPath queries). Открыв интересующий нас журнал, например, журнал безопасности Windows (вкладка «Журналы Windows» -> «Безопасность» / Security), нажатием правой кнопки мыши на имени журнала выберем пункт «Фильтр текущего журнала». Нам откроется графический редактор поисковых запросов, при этом для наиболее продуктивной работы следует открыть вторую вкладку открывшегося окна с названием XML, отметив внизу check-box «Изменить запрос вручную». Нам будет предложено изменить XML-текст (по сути, XPath запрос) в соответствии с нашими критериями поиска.
Результат запроса будет также представляться в различных формах, но для лучшего понимания и получения детального контента в конкретном событии рекомендуем переключиться на вкладку «Подробности», а там выбрать radio-button «Режим XML», в котором в формате «ключ-значение» будут представлены данные события безопасности.
Приведем несколько полезных XPath запросов с комментариями.
1. Поиск по имени учетной записи в журнале Security — возьмем для примера имя Username:
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[EventData[Data[@Name='TargetUserName']='Username']]
</Select>
</Query>
</QueryList>2. Поиск по значению конкретного свойства события в журнале Sysmon — возьмем для примера поиск событий, в которых фигурировал целевой порт 443:
<QueryList>
<Query Id="0" Path="Microsoft-Windows-Sysmon/Operational">
<Select Path="Microsoft-Windows-Sysmon/Operational">*[EventData[Data[@Name='DestinationPort'] = '443']]</Select>
</Query>
</QueryList>3. Произведем поиск сразу по двум условиям — возьмем для примера событие входа с EventID=4624 и имя пользователя Username:
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">
*[System[(EventID=4624)]]
and
*[EventData[Data[@Name='TargetUserName']='Username']]
</Select>
</Query>
</QueryList>4. Поиск по трем условиям — дополнительно укажем Logon Type = 2, что соответствует интерактивному входу в ОС:
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">
*[System[(EventID=4624)]]
and
*[EventData[Data[@Name='TargetUserName']='Username']]
and
*[EventData[Data[@Name='LogonType']='2']]
</Select>
</Query>
</QueryList>5. Рассмотрим функционал исключения из выборки данных по определенным критериям — это осуществляется указанием оператора Suppress с условиями исключения. В данном примере мы исключим из результатов поиска по фактам успешного входа (EventID=4624) все события, которые имеют отношения к системным учетным записям (SID S-1-5-18/19/20) с нерелевантным для нас типам входа (Logon Type = 4/5), а также применим функционал задания условий поиска с логическим оператором «ИЛИ», указав не интересующие нас имя процесса входа (Advapi) и методы аутентификации (Negotiate и NTLM):
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[System[(EventID=4624)]]</Select>
<Suppress Path="Security">*[EventData[(Data[@Name='TargetUserSid'] and (Data='S-1-5-18' or Data='S-1-5-19' or Data='S-1-5-20') and Data[@Name='LogonType'] and (Data='4' or Data='5'))]]
or
*[EventData[(Data[@Name='LogonProcessName'] and (Data='Advapi') and Data[@Name='AuthenticationPackageName'] and (Data='Negotiate' or Data='NTLM'))]]
</Suppress>
</Query>
</QueryList>IRP-система штатными средствами Windows
Как мы увидели, встроенный функционал подсистемы журналирования Windows позволяет весьма гибко осуществлять поиск по зафиксированным событиям аудита ИБ, комбинируя различные условия поиска. Однако, у Windows есть еще одна интересная «фишка», которая позволяет использовать сформированные описанным выше образом правила поиска событий — мы говорим про создание задач с определенным триггером в «Планировщике заданий» Windows, что также является штатным функционалом ОС.
Как мы знаем, задачи в ОС Windows могут выполнять совершенно разные функции, от запуска диагностических и системных утилит до обновления компонент прикладного ПО. В задаче можно не только указать исполняемый файл, который будет запущен при наступлении определенных условий и триггеров, но и задать пользовательский PowerShell/VBS/Batch-скрипт, который также будет передан на обработку. В контексте применения подсистемы журналирования интерес для нас представляет функционал гибкой настройки триггеров выполнения задач. Открыв «Планировщик заданий» (taskschd.msc), мы можем создать новую задачу, в свойствах которой на вкладке «Триггеры» мы увидим возможность создать свой триггер. При нажатии на кнопку «Создать» откроется новое окно, в котором в drop-down списке следует выбрать вариант «При событии», а в открывшейся форме отображения установить radio-button «Настраиваемое». После этих действий появится кнопка «Создать фильтр события», нажав на которую, мы увидим знакомое меню фильтрации событий, на вкладке XML в котором мы сможем задать произвольное поисковое условие в синтаксисе XPath-запроса.
Например, если мы хотим выполнять некоторую команду или скрипт при каждом интерактивном входе в систему пользователя Username, мы можем задать в качестве триггера задачи следующее поисковое выражение, уже знакомое нам по примеру выше:
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">
*[System[(EventID=4624)]]
and
*[EventData[Data[@Name='TargetUserName']='Username']]
and
*[EventData[Data[@Name='LogonType']='2']]
</Select>
</Query>
</QueryList>Другой пример: оповещение администратора при подозрительном обращении к системному процессу lsass.exe, который хранит в своей памяти NTLM-хэши и Керберос-билеты пользователей Windows, что может говорить об использовании утилиты Mimikatz или аналогичных ей:
<QueryList>
<Query Id="0" Path="Microsoft-Windows-Sysmon/Operational">
<Select Path="Microsoft-Windows-Sysmon/Operational">
*[System[(EventID=10)]]
and
*[EventData[Data[@Name='TargetImage']='C:WindowsSystem32lsass.exe']]
and
*[EventData[(Data[@Name='GrantedAccess'] and (Data='0x1010' or Data='0x1038'))]]
</Select>
</Query>
</QueryList>Таким образом, при условии работоспособности системы журналирования событий Windows можно не только детально и глубоко анализировать все произошедшее на устройстве, но и выполнять произвольные действия при появлении в журнале ОС событий, отвечающих условиям XPath-запроса, что позволяет выстроить целостную систему аудита ИБ и мониторинга событий безопасности штатными средствами ОС. Кроме того, объединив рекомендованные политики аудита информационной безопасности, утилиту Sysmon с детально проработанными конфигами, запрос данных из TI-фидов, функционал XPath-запросов, пересылку и централизацию событий с помощью Windows Event Forwarding, а также настраиваемые задачи с гибкими условиями выполнения скриптов, можно получить фактически бесплатную (по цене лицензии на ОС) систему защиты конечных точек и реагирования на киберинциденты, используя лишь штатный функционал Windows.