Логирование входа в систему windows

При расследовании различных инцидентов администратору необходимо получить информацию кто и когда заходил на определенный компьютер Windows. Историю входов пользователя в доменной сети можно получить из журналов контроллеров домена. Но иногда проще получить информацию непосредсвенно из логов компьютера. В этой статье мы покажем, как получить и проанализировать историю входа пользователей на компьютер/сервер Windows. Такая статистика поможет вам ответить на вопрос “Как в Windows проверить кто и когда использовал этот компьютере”.

Настройка политики аудита входа пользователей в Windows

Сначала нужно включить политик аудита входа пользователей. На отдельностоящем компьютере для настройки параметров локальной групповой политики используется оснастка gpedit.msc. Если вы хотите включить политику для компьютеров в домене Active Directorty, нужно использовать редактор доменных GPO (
gpmc.msc
).

1. Запустите консоль GPMC, создайте новую GPO и назначьте ее на Organizational Units (OU) с компьютерами и / или серверами, для которых вы хотите включить политику аудита событий входа;
2. Откройте объект GPO и перейдите в раздел Computer Configuration -> Policies -> Windows Settings -> Security Settings –> Advanced Audit Policy Configuration -> Audit Policies -> Logon/Logoff;
3. Включите две политики аудита Audit Logon и Audit Logoff. Это позволит отслеживать как события входа, так и события выхода пользователей. Если вы хотите отслеживать только успешные события входа, включите в настройках политик только опцию Success;
   

   Картинка с сайта: winitpro.ru

4. Закройте редактор GPO и обновите настройки политик на клиентах.

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

После того как вы включили политики аудита входа, при каждом входе пользователя в Windows в журнале Event Viewer будет появляться запись о входе. Посмотрим, как она выглядит.

1. Откройте оснастку Event Viewer (
   eventvwr.msc
   );
2. Разверните секцию Windows Logs и выберите журнал Security;
3. Щелкните по нему правой клавишей и выберите пункт Filter Current Log;
4. В поле укажите ID события 4624 и нажмите OK;
   

   Картинка с сайта: winitpro.ru

5. В окне события останутся только события входа пользователей, системных служб с описанием
   An account was successfully logged on
   ;
6. В описании события указано имя и домен пользователя, вошедшего в систему:

   New Logon:
   Security ID: WINITPRO\a.khramov
   Account Name: a.khramov
   Account Domain: WINITPRO

Если полистать журнал событий, можно заметить, что в нем присутствуют не только события входа пользователей на компьютер. Здесь также будут события сетевого доступа к этому компьютеру (при открытии по сети общих файлов или печати на сетевых принтерах), запуске различных служб и заданий планировщика и т.д. Т.е. очень много лишний событий, которые не относятся ко входу локального пользователя. Чтобы выбрать только события интерактивного входа пользователя на консоль компьютера, нужно дополнительно сделать выборку по значению параметра Logon Type. В таблице ниже перечислены коды Logon Type.

Код Logon Type	Описание
0	System
2	Interactive
3	Network
4	Batch
5	Service
6	Proxy
7	Unlock
8	NetworkCleartext
9	NewCredentials
10	RemoteInteractive
11	CachedInteractive
12	CachedRemoteInteractive
13	CachedUnlock

При удаленном подключении к рабочему столу компьютера по RDP, в журнале событий появится записи с Logon Type 10 или 3. Подробнее об анализе RDP логов в Windows.

В соответствии с этой таблицей событие локального входа пользователя на компьютер должно содержать Logon Type: 2.

Для фильтрации события входа по содержать Logon Type лучше использовать PowerShell.

Анализ событий входа пользователей в Windows с помощью PowerShell

Допустим, наша задача получить информацию о том, какие пользователи входили на этот компьютер за последнее время. Нам интересует именно события интерактивного входа (через консоль) с
LogonType =2
. Для выбора события из журналов Event Viewer мы воспользуемся командлетом Get-WinEvent.

Следующий PowerShell скрипт выведет история входа пользователей на текущий компьютер и представит ее в виде графической таблицы Out-GridView.

$query = @'
<QueryList>
<Query Id='0' Path='Security'>
<Select Path='Security'>
*[System[EventID='4624']
and(
EventData[Data[@Name='VirtualAccount']='%%1843']
and
EventData[Data[@Name='LogonType']='2']
)
]
</Select>
</Query>
</QueryList>
'@
$properties = @(
@{n='User';e={$_.Properties[5].Value}},
@{n='Domain';e={$_.Properties[6].Value}},
@{n='TimeStamp';e={$_.TimeCreated}}
@{n='LogonType';e={$_.Properties[8].Value}}
)
Get-WinEvent -FilterXml $query | Select-Object $properties|Out-GridView

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

|Where-Object {$_.TimeStamp -gt '5/10/22'}

Командлет Get-WinEvent позволяет получить информацию с удаленных компьютеров. Например, чтобы получить историю входов с двух компьютеров, выполните следующий скрипт:

'msk-comp1', 'msk-comp2' |
ForEach-Object {
Get-WinEvent -ComputerName $_ -FilterXml $query | Select-Object $properties
}

Уровень сложностиСредний

Время на прочтение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.

Login events play a crucial role in maintaining the security of a Windows Server. They provide valuable information about who accessed the server, when they accessed it, and whether any suspicious activity occurred. By reviewing login events, you can identify potential security threats, ensure that user accounts are being used appropriately, and maintain a secure server environment. 

In this blog post, we will guide you through the steps of enabling logon event auditing, viewing and filtering login events, and interpreting and taking action on login events. By following these steps, you can strengthen your server’s security and protect your organization from cyber threats.

Enable Logon Event Auditing

Enabling logon event auditing is the first step in reviewing login events in a Windows Server. Windows Server includes a built-in feature called Event Auditing, which records security-related events, such as logon events, in a log file. However, by default, Windows Server does not audit logon events, so you need to enable it manually.

To enable logon event auditing, follow these simple steps:

1. Open the Local Group Policy Editor by typing “gpedit.msc” in the search bar and pressing Enter.

1. Navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > Audit Policy.

1. Double-click the Audit logon events policy.
2.  Click OK after Selecting the Success and Failure check boxes.

1. Close the Local Group Policy Editor.

Once you have enabled logon event auditing, Windows Server will start recording logon events in the Security log. You can access the Security log through the Windows Event Viewer. With this feature enabled, you can now review login events and identify potential security threats on your server.

Windows Event Viewer

The Windows Event Viewer is a powerful tool that enables you to view and manage event logs on your Windows Server. It is a built-in feature and can be accessed through the Control Panel or the Start menu.

To access the Windows Event Viewer, follow these simple steps:

1. Click on the Start menu. In the search bar, type “Event Viewer”.
2. In the search results, click on “Event Viewer”.

1. Expand the “Windows Logs” folder.
2. Click on the “Security” log.

By following these steps, you can access the Security log, which contains important information about login events on your Windows Server. The Windows Event Viewer provides an easy-to-use interface for reviewing login events, enabling you to quickly identify any suspicious activity and take action to prevent potential security threats.

Viewing Logon Events

Once you have enabled logon event auditing and accessed the Security log in the Windows Event Viewer, you can start reviewing the logon events that have been recorded. By default, the Security log displays all events, not just logon events. To filter the log and show only logon events, you need to follow these steps:

1. In the Security log, click on the “Filter Current Log” button in the “Actions” pane on the right-hand side of the screen.

1. In the “Filter Current Log” dialog box, click on the “Event sources” drop-down list, and choose “”.
2. Select both the “Audit Success” and “Audit Failure” checkboxes in the “Keywords” field
3. In the “User” field, enter the name of the user whose logon events you want to view, or leave it blank to view all users.
4. Click “OK” to apply the filter.

Once you have applied the filter, the Security log will display only logon events that match your criteria. This makes it easier to review and analyze login activity on your Windows Server and identify any potential security threats. By regularly reviewing logon events and filtering the Security log, you can stay on top of your server’s security and prevent unauthorized access to your system.

Filter Only Logon Events

To filter the Security log to show only successful or failed logon events, you can use the Event IDs that are associated with these events. The Event ID for a successful logon event is 4624, and the Event ID for a failed logon event is 4625. Here are the steps to filter the log and view only successful logon events:

1. Open the Security log in the Windows Event Viewer.
2. Click the “Filter Current Log” button in the “Actions” pane on the right-hand side of the screen.
3. Choose “Microsoft Windows security auditing” from the “Event sources” drop-down list in the “Filter Current Log” dialog box.
4. In the “Keywords” field, select the “Audit Success” check box.
5. In the “Event IDs” field, enter 4624.
6. In the “User” field, enter the name of the user whose logon events you want to view, or leave it blank to view all users.
7. Click “OK” to apply the filter.

To filter the log and view only failed logon events, follow the same steps as above, but in step 4, select the “Audit Failure” check box, and in step 5, enter 4625 in the “Event IDs” field. By filtering the log to show only successful or failed logon events, you can quickly identify any suspicious activity and take appropriate action.

Interpreting and Taking Action on Login Events

After filtering the log to show only the logon events that you want to investigate, you can interpret and take action on the information provided in the event log. There are several key pieces of information that are important to review when analyzing logon events:

• Event ID: The Event ID indicates whether the logon event was successful or failed. As noted earlier, Event ID 4624 is for a successful logon event, and Event ID 4625 is for a failed logon event.
• Date and Time: The date and time of the logon event can help you identify when the event occurred and whether it coincides with any other events or activities.
• User Account: The user account associated with the logon event can help you identify who accessed the server. This information can be used to determine whether the logon event is expected or not.
• Logon Type: The logon type indicates how the user logged on to the server. There are various logon types, such as interactive, remote, and service logons.
• Source Network Address: The source network address helps you identify where the user was when they accessed the server. This information can be used to determine whether the logon event is suspicious or not.

If you find a suspicious logon event, it’s essential to take immediate action. Depending on the severity of the event, you may need to disable the associated user account, change passwords, or investigate further. Additionally, it’s always a good idea to review your security policies and procedures to ensure that you’re taking all necessary precautions to prevent similar events in the future.

Conclusion

Monitoring login events in a Windows Server is crucial for maintaining a secure and protected server environment. By enabling logon event auditing, accessing the Security log in the Windows Event Viewer, filtering the log to show only logon events, and understanding and responding to the important information provided by these events, you can quickly identify potential security threats and take appropriate action. Additionally, it is important to regularly review and update your security policies and procedures to ensure that you are employing the best practices to safeguard your sensitive data and prevent cyberattacks.

• Home
  
• News
  
• How to Check Computer Login History on Windows 10/11?

By Stella | Follow |
Last Updated November 29, 2024

You may want to know who has logged into your computer and when. But do you know how to check it? To help you do this, MiniTool Software shows you a full guide on how to check computer login history on Windows 10/11. If you are running Windows 8/8.1 or Windows 7, this guide is also available.

Tip: If you are looking for a free file recovery tool, you can try MiniTool Power Data Recovery. This software can help you recover all kinds of files from hard drives, SD cards, memory cards, SSDs, and more, as long as the files are not overwritten by new data.

MiniTool Power Data Recovery TrialClick to Download100%Clean & Safe

Sometimes you may feel that someone is logged into your computer, but you are not sure. Well then, is it possible to check if someone logged into your Windows computer? Of course, yes. Windows 10/11 has an Audit logon events policy that allows you to view login history on Windows 10/11. However, this policy is not enabled by default on your device. So, you need to manually enable it. Then you can see the Windows login log to know which has logged into your PC.

How to Check Computer Login History on Windows 10/11?

Step 1: Enable Audit Logon Events on Windows 10/11

Tip: You need to enable Audit logon events using Local Group Policy, which is available in Windows 10/11 Pro or more advanced versions. If you are running Windows 10/11 Home, the thing is different because this feature is enabled by default on your computer. So, you can just skip to the next step to view login history on Windows 10/11.

The following guide is based on Windows 11. If you are running Windows 10, the steps are the same.

1. Click the search bar from the taskbar and search for gpedit.msc.
2. Click the first result to open Local Group Policy Editor.
3. Go to this path: Computer Configuration > Windows Settings > Security Settings > Local Policies > Audit Policy.
4. Find Audit logon events from the right panel. Then, double-click it to open Properties.
5. Check both Success and Failure under Local Security Setting.
6. Click Apply.
7. Click OK.

Картинка с сайта: www.minitool.com

After these steps, your Windows computer will begin to track the login attempts no matter it is successful or not.

Tip: If you don’t want to track the login history, you can uncheck Success and Failure in step 5.

Step 2: Find out Who Is Logged into Your Computer

You can use the Event Viewer to check who is logged into your computer and when. Here is a guide on how to find out who is logged into your computer:

1. Right-click Start and select Event Viewer.
2. Go to Windows Logs > Security.
3. Find the 4624 event ID and double-click it to open it.
4. Under the General section, check the Account Name. It is the account who have logged into your device. You can see when that account was logged in the computer under Logged.

Картинка с сайта: www.minitool.com

After clicking Security, you can see that there are many logon reports. It may take some time to find your needed log. Fortunately, you can use the filter feature of Event Viewer to make the task easier.

1. Right-click Custom Views and click Create Custom View.

2. Under the Filter section, you need to:

• Select a time range for Logged.
• Select By log and then select Security under Windows logs for Event logs.
• Type 4624 in the All Event IDs box.

Картинка с сайта: www.minitool.com

3. Click OK to save the changes.

Now, you can easily find the Windows 10/11 login history.

About The Author

Position: Columnist

Stella has been working in MiniTool Software as an English Editor for more than 8 years. Her articles mainly cover the fields of data recovery including storage media data recovery, phone data recovery, and photo recovery, videos download, partition management, and video & audio format conversions.

Есть несколько различных инструментов получения информации о времени логина пользователя в домен. Время последней успешной аутентификации пользователя в домене можно получить из атрибута lastLogon (обновляется только на контроллере домена, на котором выполнена проверка учетных данных пользователя) или lastLogonTimpestamp (реплицируется между DC в домене, но по умолчанию только через 14 дней). Вы можете получить значение этого атрибута пользователя в редакторе атрибутов AD или командлетом Get-ADUser. Однако иногда нужно получить историю активности (входов) пользователя в домене за большой период времени.

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

Политика аудита входа пользователя в домен

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

1. Запустите редактор доменных GPO – GPMC.msc;
2. Откройте настройки Default Domain Policy и перейдите в раздел Computer Configuration -> Policies -> Windows Settings -> Security Settings –> Advanced Audit Policy Configuration -> Audit Policies -> Logon/Logoff;