Вадим стеркин

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

Включить политику аудита доступа к объектам файловой системы Windows

По умолчанию в Windows отключен аудит событий доступа к файлам и папкам. Включить аудит можно с помощью групповой политики. На отдельностоящем сервере для настройки политика аудита используется консоль редактора локальной групповой политики (
gpedit.msc
). Если вам нужно включить аудит сразу на множестве компьютеров в домене AD, используйте консоль управления доменными GPO (
gpmc.msc
).

1. Откройте редактор GPO и перейдите в раздел Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> System Audit Policies -> Object Access;
2. Откройте политику Audit File System и укажите, что вы хотите сохранять в журнал только успешные события доступа к объектам файловой системы (Configure the following audit events -> Success);
3. Сохраните изменения и обновите настройки локальной групповой политики с помощью команды
   gpupdate /force
   .

Можно включить локальную политику аудита файловой системы из командной строки. Вывести доступные категории аудита:

Включить аудит успешных событий доступа к объектам файловой системы:

Вывести настройки категории аудита:

Настройка аудита событий на файлах и папках Windows

Несмотря на то, что в Windows включена политика аудита доступа к файлам и папкам, фактически событий в Event Viewer еще не попадают. Администратор должен вручную настроить параметры аудита на файлах и папках, которые нужно отслеживать.

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

1. Откройте свойства папки и перейдите на вкладку Security -> Advanced -> Auditing;
2. Нажмите кнопку Add и в поле Principal выберите пользователя или группы, чью события доступа нужно отслеживать. Если нужно отслеживать доступ для всех пользователей, выберите Users (или Everyone, если нужно контролировать доступ системных процессов);
3. В списке Type укажите, что нужно отслеживать только успешные событий (
   Success
   );
4. В Applies to можно указать, нужно ли применить аудит для папки, файлов, вложенных объектов (по умолчанию выбрано This folder, subfolders and files);
5. В списке Advanced permissions выберите только те действия с файлами и папками, которые вы хотите отправлять в журнал аудита. Например: события чтения (List folder/read data) и изменения файлов (Create files or folders / write or append data)
6. Сохраните настройки аудита.

При настройке политик аудита файловой системы старайтесь включать аудит только для тех папок и файлов, которые вам нужны. Включайте аудит только для тех файлов и событий, который вам нужны. Большое количество объектов аудита файловой системы приводит к значительному росту журнала событий Event Viewer.

Можно включить аудит для каталога с помощью PowerShell:

Настройки аудита папки можно вывести с помощью PowerShell:

(Get-Acl "C:\Docs\" -Audit).Audit

Чтобы рекурсивно просканировать все каталоги и найти папки, на которых включен аудит файловой системы, воспользуйтесь таким скриптом:

Просмотр событий аудита доступа к файлам и папкам в Windows

Теперь, если с файлами в указанной папке выполняются какие-то действия, политика аудита записывает их в Event Viewer. Чтобы просмотреть события:

1. 1. Запустите консоль Event Viewer (
      eventvwr.msc
      );
   2. Перейдите в раздел Windows Logs -> Security и отфильтруйте лог по источнику:
      Microsoft Windows security auditing
      , Task Category:
      File System
      ; .
   3. Откройте содержимое любого события. Например в событии с EventID 4663 (
      An attempt was made to access an object
      ) содержится информация:О пользователе, который произвел действие над фалйов:
      Subject: Account Name:
      
      Имя файла:
      Object Name:
      
      Тип операции (изменение файла в этом случае):
      Accesses: WriteData (or AddFile)
      

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

Для вывода всех событий, связанных с определенным объектом лучше использовть PowerShell. Следующий PowerShell скрипт выведет все события доступа, связанные с указанным файлом (для получения списка событий исопльзуется производительный командлет Get-WinEvent):

$fileName = "C:\\docs\\13131.txt"
$results = Get-WinEvent -FilterHashtable @{logname='Security'; id=4663,4659} |`
Where-Object { $_.message -match $fileName -and $_.message -notmatch "Account Name:\s*machine$*"}`
foreach ($result in $results) { $Account = $result.properties[1].Value $objectName = $result.properties[6].Value $accessMask = $result.properties[8].Value if ( $accessMask -like "*00000000-*") { $accessMask=$result.properties[9].Value} $accessMask2 = $result.properties[9].Value $fileOperation = "" switch -Wildcard ($accessMask) { "*%%1538*" { $fileOperation = "READ_CONTROL" } "*%%4416*" { $fileOperation = "ReadData (or ListDirectory)" } "*%%4417*" { $fileOperation = "WriteData (or AddFile)" } "*%%4418*" { $fileOperation = "AppendData (or AddSubdirectory or CreatePipeInstance)" } "*%%4419*" { $fileOperation = "ReadEA" } "*%%4420*" { $fileOperation = "WriteEA" } "*%%4423*" { $fileOperation = "ReadAttributes" } "*%%4424*" { $fileOperation = "WriteAttributes" } "*%%4426*" { $fileOperation = "Delete" } "*%%4428*" { $fileOperation = "ReadControl" } "*%%4429*" { $fileOperation = "WriteDAC" } "*%%4430*" { $fileOperation = "WriteOwner" } "*%%4432*" { $fileOperation = "Synchronize" } "*%%4433*" { $fileOperation = "AccessSystemSecurity" } "*%%4434*" { $fileOperation = "MaximumAllowed" } "*%%4436*" { $fileOperation = "GenericAll" } "*%%4437*" { $fileOperation = "GenericExecute" } "*%%4438*" { $fileOperation = "GenericWrite" } "*%%4439*" { $fileOperation = "GenericRead" } "*%%1537*" { $fileOperation = "DELETE" } default { $fileOperation = "Unknown" } } Write-Host $result.Id $result.TimeCreated $Account $objectName $fileOperation
} 

Вы можете отправлять собранные события аудита в вашу систему сбора логов, базу данных, текстовый лог файл или отправлять email уведомление через Send-MailMessage при доступе/модификации отслеживаемого файла.

Automating Azure AD Auditing PowerShell: Simplifying Log Analysis. Do you want to simplify Azure AD auditing by automating it with PowerShell? We guide you through the various ways to accomplish this, starting with an overview of Azure AD auditing.

In the overview section, explain the Azure Active Directory audit and sign-in logs and the information they provide. After that, the article dives into 2 ways to use PowerShell to automate Azure AD auditing: log analysis and retention configuration. 

Automating Azure AD Auditing with PowerShell

The PowerShell commands required to analyse Azure AD audit and sign-in logs are part of the AzureADPreview module. Therefore, before running the commands, you must install and import this module on your computer. 

After installing the module, it is also required to run the connect-AzureAD command before running any other command. The first subsection below explains how to install the module and run the connect-AzureAD command. 

Install AzureADPreview and Connect to Azure AD Tenant

2. Once PowerShell opens, modify the execution policy to allow PowerShell to run downloaded modules. 

powershell.exe -ExecutionPolicy RemoteSigned

3. To install the Azure AD public preview module, run this command. Including the AllowClobber parameter allows PowerShell to overwrite existing commands as any new command installed. 

Install-module AzureADPreview -Force -AllowClobber

4. After installing the module, run the import-module command to import the module’s commands into the current PowerShell session. Perform an optional step that confirms if the module is available in the current session by running the Get-Module command. 

Import-Module AzureADPreview
Get-Module AzureADPreview

This screenshot shows all the commands in this subsection in PowerShell. 

When you run this command, PowerShell displays a sign-in pop-up requesting the password for the Azure AD account. Enter the password and click OK.

Connect-AzureAD -Credential (Get-Credential username@domainname.com)

If the sign-in is successful, PowerShell displays your Azure tenant information. 

Try our Active Directory & Office 365 Reporting & Auditing Tools

Try us out for .  100’s of report templates available. Easily customise your own reports on AD, Azure AD & Office 355.

Analyse Azure AD Audit Logs with PowerShell

The Get-AzureADAuditDirectoryLogs command is used to report Azure AD audit logs. Running this command without any parameters returns too much information.

To reduce the amount of information, we utilise the Top and Filter parameters. The Top parameter allows you to specify the number of records to return. 

This command displays the last three records in the Azure Active Directory audit log. 

Get-AzureADAuditDirectoryLogs -Top 3

Here is the result. As you see, this report lists the results, which is not very useful. 

To display the result in a table, we pipe Get-AzureADAuditDirectoryLogs to Format-Table. 

Get-AzureADAuditDirectoryLogs -Top 3 | Format-Table

With this last modification, the report is displayed in a table!

Although the Top parameter is great, the most useful parameter is Filter. This parameter allows you to return specific results from the Azure AD audit logs. 

For example, to return all audit logs about an object with a display name, ‘WordPress Site (Azure CLI)’ I execute this command:

Get-AzureADAuditDirectoryLogs -Filter "targetResources/any(tr:tr/displayName eq 'WordPress Site (Azure CLI)')"

Beyond filtering results by target resource, we could use other filtering methods. For instance, filter by the status of the action: Success or failure. 

The command below returns the last three failure actions recorded in the audit log.  

Get-AzureADAuditDirectoryLogs -Filter "result eq 'failure'" -Top 3 | Format-Table

Get-AzureADAuditDirectoryLogs -Filter "initiatedBy/user/userPrincipalName eq 'name@DomainName.com'"

Analyse Azure AD Sign-in Logs with PowerShell

The Azure AD sign-in log report is run using the Get-AzureADAuditSignInLogs command. This AzureADPreview PowerShell command has the same parameters as the Get-AzureADAuditDirectoryLogs command. 

Get-AzureADAuditSignInLogs -Filter "userDisplayName eq 'Victor Ashiedu'"

Since the above command returned too many results, I modify the command to display the last 3. 

Get-AzureADAuditSignInLogs -Filter "userDisplayName eq 'Victor Ashiedu'" -Top 3 | Format-Table

The last command displays less information allowing for better analysis of the sign-in logs. 

Get-AzureADAuditSignInLogs -Filter "(userDisplayName eq 'Victor Ashiedu') and (createdDateTime gt 2023-08-28)" | Format-Table

Automating Azure AD Auditing with PowerShell

Azure Active Directory audit logs are retained for 12 months by default. However,  modify the default log retention period by creating a custom audit log retention policy. 

The commands required for this section are part of the ExchangeOnlineManagement module. So, in the first subsection below, weinstall this module. 

Install the ExchangePowerShell PowerShell Module

Install-Module -Name ExchangeOnlineManagement -AllowClobber -Force

2. Once the command runs successfully, use the Import-Module command to import the module to your PowerShell session. Additionally, you may execute the Get-Module command to confirm that the module is available on your PC. 

Import-Module ExchangeOnlineManagement
Get-Module ExchangeOnlineManagement

Connect-ExchangeOnline -Credential (Get-Credential name@domainname.com)
Connect-IPPSSession -UserPrincipalName name@domainname.com

Create and Modify Azure AD Audit Log Retention using PowerShell

Once you’ve connected successfully, create a new audit log retention policy with this command. 

New-UnifiedAuditLogRetentionPolicy -Name "Microsoft AzureAD Audit Policy" -Description "One-year retention policy for all Azure AD activities" -RecordTypes AzureActiveDirectory -RetentionDuration TwelveMonths -Priority 99

The command creates a new one-year AzureAD audit retention policy with a priority of 99. 

The New-UnifiedAuditLogRetentionPolicy command allows you to specify the type of audit log retention using the RecordTypes parameter. Get the names of the retention record types from the RecordTypes link. 

To modify this audit log retention policy to include this record type, I’ll run the command below. 

Get-UnifiedAuditLogRetentionPolicy | ForEach-Object { Set-UnifiedAuditLogRetentionPolicy -Identity $_ -Priority 101 -RetentionDuration TwelveMonths -RecordTypes AzureActiveDirectory, SharePoint }

View Azure AD Audit Log Retention Policies using PowerShell

To display all azure AD audit logs, run this command. 

Get-UnifiedAuditLogRetentionPolicy -RecordType AzureActiveDirectory

The command returns all Azure Active Directory retention policies. However, we filter the report using the Where-Object command. Here is a sample command that returns the retention policy, “Microsoft AzureAD AuditPolicy.”

Get-UnifiedAuditLogRetentionPolicy | Where-Object Name -eq "Microsoft AzureAD AuditPolicy"

Finally, the result is displayed in a table by piping the last result to Format-Table. 

Get-UnifiedAuditLogRetentionPolicy | Where-Object Name -eq "Microsoft AzureAD AuditPolicy" | Format-Table

Delete Azure AD Audit Log Retention Policies using PowerShell

To delete an Azure AD audit retention policy, pipe the output of Get-UnifiedAuditLogRetentionPolicy to Remove-UnifiedAuditLogRetentionPolicy. For instance, the command below deletes the audit retention policy I created earlier. 

Get-UnifiedAuditLogRetentionPolicy | Where-Object Name -eq "Microsoft AzureAD AuditPolicy" | Remove-UnifiedAuditLogRetentionPolicy

By running the command without including the Force parameter, PowerShell prompts for confirmation. 

To avoid this prompt, include the Force parameter. 

Get-UnifiedAuditLogRetentionPolicy | Where-Object Name -eq "Microsoft AzureAD AuditPolicy" | Remove-UnifiedAuditLogRetentionPolicy -ForceDeletion

Unfortunately, trying to force deletion returns an error that states that the policy cannot be force deleted since it is not in a “pending deletion state.” So, the only option is to respond to the prompt to confirm the deletion. 

Automating Azure AD Auditing PowerShell

Azure Active Directory audit and sign-in logs provide essential information for monitoring the health and security of the tenant. Although the Azure Portal provides the option to run reports, PowerShell provides a way to automate the reporting of these logs. 

In this article, we explained some information provided by these logs. Additionally, we discussed how to use PowerShell to automate the analysis and configure the retention policies of these all-important Azure AD logs. 

Try InfraSOS for FREE

Try InfraSOS Active Directory, Azure AD & Office 365 Reporting & Auditing Tool

• Free 15-Days Trial

• SaaS AD Reporting & Auditing Solution

Для проведения задач «Инвентаризация» и «Аудит» необходимо активное подключение
к узлам исследуемой сети с заведенными учетными записями для этих узлов.

Для корректного подключения к узлу исследуемой сети по протоколу WinRM
необходимо произвести предварительную настройку узла исследуемой сети.

Настройка подключения по протоколу WinRM с помощью поставляемого скрипта​

Для настройки необходимо выполнить следующие действия:

• Убедиться, что на узле, к которому планируется подключение, установлены
  powershell 5.1 и

  .Net framework 4

• Запустить Windows PowerShell от имени администратора

• Выполнить скрипт изначальной настройки WinRM с помощью команды:

• После успешного выполнения данного скрипта становится возможным подключение
  к узлу исследуемой сети по протоколу WinRM через basic аутентификацию

Для работы с парами ключей (WinRM KeyPair) необходимо дополнительно выполнить
следующие действия:

• Скопировать на АРМ оператора, с которого производится управление Сканер ВС,
  публичный ключ в формате CER или PEM в файл

• путь к файлу с ключом
  

<путь к файлу с ключом> – путь к сохраненному файлу, содержащему публичный
ключ в формате CER или PEM

<имя пользователя> и <пароль> – аутентификационные данные, которые будут
использоваться для подключения к узлу исследуемой сети по протоколу WinRM

• После успешного выполнения данного скрипта становится возможным подключение к
  узлу исследуемой сети по протоколу WinRM с использованием пары ключей WinRM KeyPair.

Для установки подключения по протоколу WinRM с использованием пары ключей типа
EC P521 в командной строке Windows PowerShell необходимо выполнить
следующую команду:

Ручная настройка подключения по протоколу WinRM​

Поставляемый со Сканер-ВС скрипт настройки удаленного подключения по протоколу
WinRM работает только в том случае, если на узле, к которому необходимо
подключиться для проведения задач «Инвентаризация» или «Аудит», установлены
powershell 5.1 и .Net framework 4 или более поздние их версии.

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

Для ручной настройки удаленного подключения по протоколу WinRM необходимо
выполнить следующие действия:

Для подключения с использованием сертификата необходимо выполнить следующие действия:

1. Импортировать сертификат, используя следующие команды:

   $certpath = "путь к сертификату"
   Import-Certificate -FilePath $certpath -CertStoreLocation cert:\LocalMachine\root
   Import-Certificate -FilePath $certpath -CertStoreLocation cert:\LocalMachine\TrustedPeople
   

2. Скопировать отпечаток сертификата открыв сертификат и скопировать значение из
   поля CertificateThumbprint

3. Выполнить следующие команды в Windows PowerShell:

   $thumbprint = "отпечаток"
   $credential = New-Object -TypeName System.Management.Automation.PSCredential 
   New-Item -Path WSMan:\localhost\ClientCertificate `
   -Subject "*" `
   -URI * `
   -Issuer $thumbprint `
   -Credential $credential `
   

Для установки подключения по протоколу WinRM с использованием пары ключей типа
EC P521 в командной строке Windows PowerShell необходимо выполнить команду:

Ручная настройка подключения по протоколу WinRM для Windows Server 2008 и Windows 7​

Для подключения к узлам исследуемой сети, функционирующим на базе старых версий
ОС семейства Windows (Windows 7 и Windows Server 2008) по протоколу WinRM,
необходима их дополнительная настройка.

Для настройки таких узлов исследуемой сети необходимо выполнить следующие действия:

После выполнения скрипта winrm.ps1 станет доступным подключение по протоколу
WinRM методом Basic.

Для установки подключения методом KeyPair помимо настройки описанной ранее
необходимо выполнить следующие дополнительные действия:

Удаление внесенных во время настройки подключения по протоколу WinRM изменений с помощью поставляемого скрипта​

После завершения исследования узла необходимо отменить внесенные в узел
исследуемой сети во время настройки подключения по протоколу WinRM изменений.

Для отмены внесенных изменений необходимо выполнить следующие действия:

• Перейти в командную строку от имени администратора

Последняя команда отключает удаленное управление не только с помощью WinRM
через PowerShell, но и по всем остальным протоколам и утилитам также

Если при выполнении команд появляется ошибка выполнения, необходимо предварительно выполнить команду:

Привет! Сегодня мы рассмотрим важную тему – проверку безопасности паролей в Active Directory. Зачем это нужно? Потому что безопасные пароли – залог безопасности вашей организации. В этой статье вы узнаете, как администраторы и специалисты по информационной безопасности могут убедиться в работоспособности парольных политик и обнаружить слабые пароли.

Шаг 1: Предварительные требования:

Шаг 2: Копирование базы NTDS из теневой копии:

Теперь, так как прямое копирование базы NTDS невозможно, нам нужно воспользоваться теневой копией. Запустите PowerShell с правами администратора и выполните следующие команды:

$path="C:\New folder\"
cd $path
$vss=$null
$vss=Get-CimInstance -ClassName Win32_ShadowCopy -Property * | Select-Object DeviceObject,ID
vssadmin create shadow /for=C:
$vss=Get-CimInstance -ClassName Win32_ShadowCopy -Property * | Select-Object DeviceObject,ID
$vss[0]

К сожалению, при копировании данных непосредсвенно из PowerShell у меня возникали ошибки, поэтому выполните копирование из cmd, запущенном от имени администратора:

copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy317\Windows\NTDS "C:\new folder"

Шаг 3: Извлечение хешей паролей и анализ:

После создания теневой копии вернитесь в PowerShell, удалите теневую копию и выполните следующие команды для извлечения хешей паролей всех активных пользователей:

vssadmin.exe delete shadows /shadow="$($vss[0].ID)" /quiet
esentutl /r edb /d
import-module -name .\dsinternals
$key=Get-BootKey -Online
$dump=Get-ADDBAccount -all -DBPath '.\ntds.dit' -BootKey $key | Where-Object {$_.enabled -eq "True"}
$dump | where-object {$_.samaccounttype -eq "user"} | Format-Custom -View PwDump | out-file -FilePath users.pwdump -Encoding utf8
remove-item *edb*
remove-item *ntds*

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

Упрощённый вариант предыдущих шагов:

Я сделал программу, которая выполняет предущие шаги в атоматическом режиме за несколько секунд.

Проект программы на github, если кому-то нужны будут исходники – тут.

Если посчитаете, что прогамма вам полезна – донаты приветсвуются.

Шаг 4: Анализ хешей паролей и взлом:

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

В папке с программой можно сделать подпапку Dictionaries, и скопровать в неё нужные словари.

Также, в папке с программой нужно создать список уникальных хешей с имененм hacklist.txt. Оставить только уникальные хэши, можно, например, удалив дубликаты, импортировав ранее полученные данные в Excel.

Запускаем взлом командой:

hashcat.exe hacklist.txt Dictionaries\* -m 1000

После завершения взлома, можно посмотреть список паролей в файле hashcat.potfile. Cопоставив хэши ненадёжных паролей с пользователями, можно заставить их сменить такие пароли.

Заканчивая наш разговор о проверке паролей в Active Directory, помните, что обеспечение безопасности данных – это ключевая задача. Анализ и улучшение политик паролей помогут сделать вашу организацию более защищенной от потенциальных угроз.

Не забывайте при этом про нормы закона и этики.

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

В этой статье мы посмотрим, как можно организовать эффективный аудит узлов под управлением ОС 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   – пользователь отключен

0xC0000070   – ограничение рабочей станции или нарушение изолированной политики аутентификации (найдите идентификатор события 4820 на контроллере домена)

0xC0000193   – срок действия учетной записи истек

0xC0000071   – истек пароль

0xC0000133   – часы между DC и другим компьютером слишком сильно рассинхронизированы

0xC0000224   – пользователю необходимо сменить пароль при следующем входе в систему

0xc000015b    Пользователю не был предоставлен запрошенный тип входа в систему (он же право входа в систему) на этом компьютере

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

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

В следующей статье мы посмотрим, как средствами PowerShell можно извлекать различные значения из событий и делать обработку логов более “человеко-удобной.

Заключение

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

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

EventTime : 2022-12-05T22:08:33.3566298Z
SubjectUserName : Vadim
SubjectUserSid : S-1-5-21-3770827514-527019215-2194716761-1001
ObjectName : \REGISTRY\USER\S-1-5-21-3770827514-527019215-2194716761-1001_Classes\CLSID\{018D5C66-4533-4307-9B53-224D E2ED1FE6}
ObjectValueName : System.IsPinnedToNameSpaceTree
NewValue : 1
OldValue : 0
ProcessName : C:\Program Files\Microsoft OneDrive\OneDrive.exe

Похожее:

Политики аудита изменений в Active Directory Аудит успехов это Sysadminium Топ-3 модуля power shell