Windows security event log id 4624

4624: An account was successfully logged on

On this page

• Description of this event
• Field level details
• Examples
• Discuss this event
• Mini-seminars on this event

This is a highly valuable event since it documents each and every successful attempt to logon to the local computer regardless of logon type, location of the user or type of account.  You can tie this event to logoff events 4634 and 4647 using Logon ID.

Win2012 adds the Impersonation Level field as shown in the example.

Win2016/10 add further fields explained below.

Free Security Log Resources by Randy

• Free Security Log Quick Reference Chart
• Windows Event Collection: Supercharger Free Edtion
• Free Active Directory Change Auditing Solution
• Free Course: Security Log Secrets

Description Fields in
4624

Subject:

Identifies the account that requested the logon — NOT the user who just logged on.  Subject is usually Null or one of the Service principals and not usually useful information.  See New Logon for who just logged on to the sytem.

• Security ID
• Account Name
• Account Domain
• Logon ID

Logon Information:

• Logon Type: See below

Remaining logon information fields are new to Windows 10/2016

• Restricted Admin Mode: Normally «-«.»Yes» for incoming Remote Desktop Connections where the client specified /restrictedAdmin on the command line.  Restricted admin mode is an important way to limit the spread of admin credentials in ways they can be harvested by malware using pass-the-hash and related techniques.  You should only see with for logon type 10.  When you remote desktop into a server with /restrictedAdmin you get full authority on that server but it doesn’t carry with you if you access other systems from within that RDP session.  This field allows you to detect RDP sessions that fail to use restricted admin mode.
• Virtual Account: Normally «No». This will be Yes in the case of services configured to logon with a «Virtual Account».  Virtual Accounts only come up in Service logon types (type 5), when Windows starts a logon session in connection with a service starting up.  You can configure services to run as a virtual account which is what Microsoft calls a «managed local account».  They’re «domain» is «NT Service» as in an instance of MS SQL Server named Supercharger running as NT SERVICEMSSQL$SUPERCHARGER.  
• Elevated Token:  Yes or No.  It will be Yes if the user is a member of Administrators — kind of… The «kind of» applies to interactive logons, when you are an admin and you have User Account Control (UAC) enabled. Then when you logon you actually get 2 logon sessions.  One without the Administrators SID and related privileges in your security token and another session with all that authority.  Everything you do happens under the unprivileged logon session until you attempt to run something requiring admin authority.  After you approve the UAC dialog box, Windows runs that one operation under the other logon sesson.  So in the log you will see 2 of these events, one where this field is Yes and other No.  The 2 logon sessions are connected by the Linked Logon ID described below.

Logon Type:

This is a valuable piece of information as it tells you HOW the user just logged on:
 

Impersonation Level: (Win2012 and later)

From MSDN

New Logon:

The user who just logged on is identified by the Account Name and Account Domain.  You can determine whether the account is local or domain by comparing the Account Domain to the computer name.  If they match, the account is a local account on that system, otherwise a domain account.

• Security ID: the SID of the account
• Account Name: Logon name of the account
• Account Domain: Domain name of the account in either the DNS name (can be upper or lowercase) or pre-Win2k NETBIOS domain name.  In the case of special subjects (well known security principals) like SYSTEM, LOCAL SERVICE, NETWORK SERVICE, ANONYMOUS LOGON this field will be «NT AUTHORITY».  It can also be «NT Service» as in the case of virtual accounts for services.  See above.  Finally, if the account is a local account, this field will be the name of the computer.
• Logon ID: a semi-unique (unique between reboots) number that identifies the logon session just initiated.  Any events logged subsequently during this logon session will report the same Logon ID through to the logoff event 4647 or 4634.
• Linked Login ID: (Win2016/10) This is relevant to User Account Control and interactive logons.  When an admin logs on interactively to a system with UAC enabled, Windows actually creates 2 logon sessions — one with and one without privilege.  This is called a split token and this fields links the 2 sessions to each other.  See Elevated Token above.
• Network Account Name: (Win2016/10)  This appears to always be «-«.  It seems connected to LogonUser() with LOGON32_LOGON_NEW_CREDENTIALS but I’ve not been able to produce an example.  If you have an event with this field filled in please open a forum posting on this page and let us see it.
• Network Account Domain: (Win2016/10)  see above
• Logon GUID: Supposedly you should be able to correlate logon events on this computer with corresonding authentication events on the domain controller using this GUID.  Such as linking 4624 on the member computer to 4769 on the DC.  But the GUIDs do not match between logon events on member computers and the authentication events on the domain controller.

Process Information:

• Process ID is the process ID specified when the executable started as logged in 4688.
• Process Name: identifies the program executable that processed the logon.  This is one of the trusted logon processes identified by 4611.

Network Information:

This section identifies WHERE the user was when he logged on.  Of course if logon is initiated from the same computer this information will either be blank or reflect the same local computers.

• Workstation Name: the computer name of the computer where the user is physically present in most cases unless this logon was intitiated by a server application acting on behalf of the user.  Workstation may also not be filled in for some Kerberos logons since the Kerberos protocol doesn’t really care about the computer account in the case of user logons and therefore lacks any field for carrying workstation name in the ticket request message.
• Source Network Address: the IP address of the computer where the user is physically present in most cases unless this logon was intitiated by a server application acting on behalf of the user.  If this logon is initiated locally the IP address will sometimes be 127.0.0.1 instead of the local computer’s actual IP address.  This field is also blank sometimes because Microsoft says «Not every code path in Windows Server 2003 is instrumented for IP address, so it’s not always filled out.»
• Source Port: identifies the source TCP port of the logon request which seems useless since with most protocols source ports are random.

Detailed Authentication Information:

• Logon Process: (see 4611) CredPro indicates a logon initiated by User Account Control
• Authentication Package: (see 4610 or 4622)
• Transited Services: This has to do with server applications that need to accept some other type of authentication from the client and then transition to Kerberos for accessing other resources on behalf of the client.  See http://msdn.microsoft.com/msdnmag/issues/03/04/SecurityBriefs/.  MS says: Transmitted services are populated if the logon was a result of a S4U (Service For User) logon process. S4U is a Microsoft extension to the Kerberos Protocol to allow an application service to obtain a Kerberos service ticket on behalf of a user – most commonly done by a front-end website to access an internal resource on behalf of a user. For more information about S4U, see https://msdn.microsoft.com/en-us/library/cc246072.aspx
• Package name: If this logon was authenticated via the NTLM protocol (instead of Kerberos for instance) this field tells you which version of NTLM was used.  See security option «Network security: LAN Manager authentication level».  This field only populated if Authentication Package = NTLM.  Possible values: “NTLM V1”, “NTLM V2”, “LM”
• Key Length: Length of key protecting the «secure channel».  See security option «Domain Member: Require strong (Windows 2000 or later) session key».  If value is 0 this would indicate security option «Domain Member: Digitally encrypt secure channel data (when possible)» failed.  MS says the length of NTLM Session Security key. Typically it has 128 bit or 56 bit length. This parameter is always 0 if “Authentication Package” = “Kerberos”, because it is not applicable for Kerberos protocol. This field will also have “0” value if Kerberos was negotiated using Negotiate authentication package.

Event Id 4624 is generated when a user logon successfully to the computer. This event was written on the computer where an account was successfully logged on or session created.

Event Id 4624 logon type specifies the type of logon session is created. The most commonly used logon types for this event are 2 – interactive logon and 3 – network logon.

This event logs on the account logged on, it helps to monitor actions on the computer like anomalies or malicious actions, non-active accounts login attempts, external accounts and so many.

In this article, we will discuss event id 4624 logon types, event fields information, and security monitoring recommendations.

Event Id 4624 – Description

Event code 4624 provides detailed information about an account, logon information, network, and detailed authentication information.

This event is generated on domain controllers (DC), workstations, and systems.

An account was successfully logged on.

Subject:
	Security ID:		SYSTEM
	Account Name:		Corp-EU-S17$
	Account Domain:		SHELLGEEK
	Logon ID:		0x4C5

Logon Information:
	Logon Type:		7
	Restricted Admin Mode:	-
	Virtual Account:	No
	Elevated Token:		No

Impersonation Level:		Impersonation

New Logon:
	Security ID:		SHELLGEEKadmin
	Account Name:		admin
	Account Domain:		SHELLGEEK
	Logon ID:		0xBC7D5C3C
	Linked Logon ID:	0x0
	Network Account Name:	-
	Network Account Domain:	-
	Logon GUID:		{00000000-0000-0000-0000-000000000000}

Process Information:
	Process ID:		0x438
	Process Name:		C:WindowsSystem32lsass.exe

Network Information:
	Workstation Name:	Corp-EU-S17
	Source Network Address:	-
	Source Port:		-

Detailed Authentication Information:
	Logon Process:		Negotiate
	Authentication Package:	Negotiate
	Transited Services:	-
	Package Name (NTLM only):-
	Key Length:		0

This event is generated when a logon session is created. It is generated on the computer that was accessed.

The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).

The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.

The network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The impersonation level field indicates the extent to which a process in the logon session can impersonate.

The authentication information fields provide detailed information about this specific logon request.
	- Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.
	- Transited services indicate which intermediate services have participated in this logon request.
	- Package name indicates which sub-protocol was used among the NTLM protocols.
	- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

Fields Description:

Subject:

• Security Id:SID of an an account
• Account Name: It specify name of the account.
• Account Domain: Computer domain or subject domain name.
• Logon ID: hexadecimal number which helps you to correlate this event id 4624 with recents event that might contains the same Logon ID. For ex. Event Id 4634:”An account was logged off”

Logon Information

• Logon Type: It provide integer value which provides information about type of logon occured on the computer.
• Restricted Admin Mode: It provides value if RemoteInteractive logon type sessions occured. It contains Yes/No flag value which indicates if the credentials used during rdp session using Restricted Admin mode. If it is not RemoteInteractive logon, this field will display “-” string.
• Virtual Account:It provides Yes or No flag value which indicates if the account is a virtual account.
• Elevated Token: It provides Yes or No flag value. If it has Yes value, it means created logon session is elevated and has administrator privileges.

Impersonation Level

Impersonation level can have one of these value

• SecurityAnonynymous: displayed as empty string.The server process cannot object identification information about the client and cannot impersonate the client.
• SecurityIdentification: dispalyed as “Identification“. The server process can obtain the information about the client, but it cannot impersonate the client.
• SecurityImpersonation: displayed as “Impersonation“. The server process can impersonate the client’s information.This is most common type.
• SecurityDelegation: displayed as “Delegation“. The server process can impersonate the client information on remote system.

New Logon

• Security ID: SID of an account for which logon was occured.
• Account Name: The name of account for which logon was occured.
• Account Domain: The computer domain name or subject’s domain name.
• Logon ID: Hexadecimal value which help you to correlate the recent events that might contain the same Logon Id.
• Linked Logon ID: Hexadecimal value of the paired session.
• Network Account Name: It provide domain for the user and value for NewCredentials logon type. Mostly its value is “-“.
• Logon GUID: It provides GUID which can help you to corelate this event id 4624 with another event which might contain the same Logon GUID.

Process Information

• Process ID: Process id the process that attempeted logon.
• Process Name: Full path and name of executable forthe process.

Network Information

• Workstation Name: computer name from which logon attempt was occurred.
• Source Network Address:IP address of machine from which logon attempt was performed.
• Source Port: Source port of machine from which logon attempt was occured.

Detailed Authentication Information:

• Logon Process: It specify the trusted logon process that was used for logon.
• Authentication Package: It specify the name of authentication package that was used for logon authentication process.
• Transited Services:The list of transmitted services.
• Package Name: The name of the LAN manager sub-package which was used during logon.
• Key Length: The length of NTLM session security key.

Cool Tip: How to manipulate Active Directory UserAccountControl flags in PowerShell!

Event ID 4624 logon types

Logon type is of type Int32. It specifies the type of logon which was occurred.

Refer to the list of event code 4624 logon types with logon title and their description.

Get Event log for event id 4624 using PowerShell

You can retrieve the event logs for event id 4624 using PowerShell cmdlets like Get-EventLog or Get-WinEvent

Let’s try to get event id 4624 event log using Get-EventLog cmdlet in PowerShell.

$Date = [DateTime]::Now.AddDays(-1) 
Get-EventLog -LogName "Security" -After $Date | Where -FilterScript {$_.EventID -eq 4624}      

In the above script,

Get-EventLog gets event id 4624 logs for a date using the $Date variable.

It uses the LogName parameter to specify log name as Security for this event and Event Id equal to 4624.

The output of the above Get-EventLog to get this event id log is

 Index Time          EntryType   Source                 InstanceID Message
   ----- ----          ---------   ------                 ---------- -------
20033758 Jan 26 22:04  SuccessA... Microsoft-Windows...         4624 An account was successfully logged on....
20033006 Jan 26 21:49  SuccessA... Microsoft-Windows...         4624 An account was successfully logged on....
20032288 Jan 26 21:34  SuccessA... Microsoft-Windows...         4624 An account was successfully logged on....
20031576 Jan 26 21:19  SuccessA... Microsoft-Windows...         4624 An account was successfully logged on....
20031572 Jan 26 21:19  SuccessA... Microsoft-Windows...         4624 An account was successfully logged on....
20031303 Jan 26 21:14  SuccessA... Microsoft-Windows...         4624 An account was successfully logged on....

You can also get event logs for event code 4624 using the Get-WinEvent cmdlet in PowerShell.

Get-WinEvent -FilterHashtable @{LogName = 'Security'; ID = 4624} -MaxEvents 10   

In the above PowerShell script,

Get-WinEvent gets event log for event id 4624.

It uses the FilterHashtable parameter and LogName as Security to get these events.

The output of the above command is:

   ProviderName: Microsoft-Windows-Security-Auditing

TimeCreated                     Id LevelDisplayName Message
-----------                     -- ---------------- -------
26-01-2022 22:04:21           4624 Information      An account was successfully logged on....
26-01-2022 21:49:21           4624 Information      An account was successfully logged on....
26-01-2022 21:34:21           4624 Information      An account was successfully logged on....
26-01-2022 21:19:57           4624 Information      An account was successfully logged on....
26-01-2022 21:19:54           4624 Information      An account was successfully logged on....
26-01-2022 21:14:27           4624 Information      An account was successfully logged on....
26-01-2022 21:07:51           4624 Information      An account was successfully logged on....
26-01-2022 20:50:07           4624 Information      An account was successfully logged on....
26-01-2022 20:45:50           4624 Information      An account was successfully logged on....
26-01-2022 20:36:21           4624 Information      An account was successfully logged on....

Window Security Event Id 4624 – Examples

Event Code 4624 logon type 5 – Service started by SCM

Event Id 4624 logon type 5 logs message when the service was started by Service Control Manager (SCM).

An account was successfully logged on.

Subject:
	Security ID:		SYSTEM
	Account Name:		Corp-EU-S17$
	Account Domain:		SHELLGEEK
	Logon ID:		0x3E7

Logon Information:
	Logon Type:		5
	Restricted Admin Mode:	-
	Virtual Account:	No
	Elevated Token:		Yes

Impersonation Level:		Impersonation

New Logon:
	Security ID:		SYSTEM
	Account Name:		SYSTEM
	Account Domain:		NT AUTHORITY
	Logon ID:		0x3E7
	Linked Logon ID:		0x0
	Network Account Name:	-
	Network Account Domain:	-
	Logon GUID:		{00000000-0000-0000-0000-000000000000}

Process Information:
	Process ID:		0x41c
	Process Name:		C:WindowsSystem32services.exe

Network Information:
	Workstation Name:	-
	Source Network Address:	-
	Source Port:		-

Detailed Authentication Information:
	Logon Process:		Advapi  
	Authentication Package:	Negotiate
	Transited Services:	-
	Package Name (NTLM only):	-
	Key Length:		0

This event is generated when a logon session is created. It is generated on the computer that was accessed.

The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).

The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.

The network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The impersonation level field indicates the extent to which a process in the logon session can impersonate.

The authentication information fields provide detailed information about this specific logon request.
	- Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.
	- Transited services indicate which intermediate services have participated in this logon request.
	- Package name indicates which sub-protocol was used among the NTLM protocols.
	- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

Event Id 4624 displays the logon process name as Advapi which was used for logon.

Conclusion

I hope the above article on Event Id 4624 is useful to you.

This event helps you to monitor the type of account logon activity on the computer system.

Using Event Code 4624, you can monitor high-value accounts, anomalies, or malicious actions on the computer using New log on Security Id to monitor how and when a particular account is being used.

Cool Tip: Event Id 4771 – Kerberos pre-authentication failed!

You can find more topics about PowerShell Active Directory commands and PowerShell basics on the ShellGeek home page.

You can read more on other windows security and system event logs as given:

• Event Id 4625 0xc000006a – Account Failed to Log on
• Event Id 4634 – An Account was logged off
• Error Code 0xc0000234 – Event Id 4776 – Fix
• Event Id 4670 – System restart or shutdown

При расследовании различных инцидентов администратору необходимо получить информацию кто и когда заходил на определенный компьютер 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;
4. Закройте редактор GPO и обновите настройки политик на клиентах.

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

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

1. Откройте оснастку Event Viewer (
   eventvwr.msc
   );
2. Разверните секцию Windows Logs и выберите журнал Security;
3. Щелкните по нему правой клавишей и выберите пункт Filter Current Log;
4. В поле укажите ID события 4624 и нажмите OK;
5. В окне события останутся только события входа пользователей, системных служб с описанием
   An account was successfully logged on
   ;
6. В описании события указано имя и домен пользователя, вошедшего в систему:

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

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

При удаленном подключении к рабочему столу компьютера по 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
}

Attackers frequently rely on lateral movement techniques to infiltrate corporate networks and obtain privileged access to credentials and data. In particular, one common technique is pass-the-hash: Hackers use stolen password hashes to authenticate as a user without ever having the user’s cleartext password. This tactic enables them to bypass normal system access controls to move laterally within the environment. 

This post explains exactly what to look for in the native Windows event logs to detect pass the hash, and offers additional options for spotting — and even preventing — these attacks. 

Getting a Baseline: Understanding the Events Logged during the Normal NTLM Authentication Process

Pass the hash relies on NTLM authentication, so we need to first understand what events are normally generated during normal NTLM logon activity.

Authenticating as an Administrative User

To generate these events, I launch a new command prompt as an administrative user, using the account’s actual password:

Next, I used the Sqlcmd utility to connect to a Microsoft server by its IP address. This command will generate NTLM authentication to the SQL database:

Sqlcmd –S [IP ADDRESS]

For good measure, I will also run the SELECT SYSTEM_USER command to show the user I am authenticated as:

Reviewing the Events Generated

Now let’s see what native Windows events were logged. That gives us a baseline for normal NTLM authentication behavior that does not involve pass the hash.

Workstation Logs

On my local workstation, I will see the following events:

• 4648 – A logon was attempted using explicit credentials.

• 4624 – An account was successfully logged on.

A 4624 event was logged with a Logon Type of 2, which means an interactive logon. This aligns with the way I used runas and entered my credentials interactively.

• 4672 – Special privileges assigned to new logon.

Because the account I used (Franklin.Bluth) is an administrative account, event 4672 gets logged to show what privileges are being assigned. This is a useful way to track the activity of administrative accounts. 

Target Server Logs

On my SQL server, I see the following events:

• 4624 – An account was successfully logged on.

On the SQL Server, there is a similar 4624 event; however, the Logon Type is 3, indicating a network logon. 

The details show that the Authentication Package was NTLM, which confirms that we are performing NTLM authentication. 

• 4672 – Special privileges assigned to new logon.

Because we used a privileged account, we also see a 4672 event, as illustrated earlier in the description of the workstation logs. 

Domain Controller Logs

On the domain controller, we will find artifacts of both Kerberos and NTLM authentication. The Kerberos authentication, which is the default authentication method for Active Directory, happens first. That generated two events:

• 4768 – A Kerberos authentication ticket (TGT) was requested.

• 4769 – A Kerberos service ticket was requested.

Once the TGT is received, a TGS was requested for the host. With this, the user Franklin Bluth can now interact with the PC to launch the command prompt. 

• 4776 – The computer attempted to validate the credentials for an account.

The 4776 event is specific to NTLM and will come last. It occurs when we execute the Sqlcmd command to force NTLM authentication. 

Detecting Pass the Hash: Understanding Events Logged during an Attack

Now, let’s take a look at what events are generated when we use pass the hash to authenticate. 

Authenticating using Pass the Hash

I can easily get the NTLM hash for the Franklin Bluth account from memory with this Mimikatz command:

sekurlsa::logonpasswords

Then I authentication using pass the hash with the following command:

Sekurlsa::pth /user:Franklin.Bluth /ntlm:[ntlm] /domain:jefflab.local

A new command window will open. By using the same Sqlcmd command to connect to the IP address of my SQL Server, we can see that I am now authenticated there as Franklin Bluth:

Reviewing the Events Generated

Let’s take a look at what events were generated by this pass-the-hash authentication.

Workstation Logs

On my local workstation, I will see the same events as for the legitimate NTLM authentication (4648, 4624 and 4672). However, there are a few key differences.

• 4624 event — This event now has a Logon Type of 9, which is NewCredential. This was identified by a security researcher, and I reliably reproduced it in my lab. It a very useful way to identify that a pass-the-hash event took place. 

Logon Type 9 is very rare. However, I was able to generate some false positives running applications that use impersonation. The main difference to key off of is the Logon Process will always be “seclogo” for pass the hash (from my tests), so you can filter on that to reduce false-positive rates. 

• 4672 event— In the normal authentication scenario, this event identified a privileged logon for the Franklin Bluth account. With pass-the-hash authentication, it registers the user that I am logged into my workstation as. 

Target Server Logs

The logs on the SQL server are identical to those we saw doing legitimate NTLM authentication:

• 4624 – An account was successfully logged on. Logon Type 3, NTLM
• 4672 – Special privileges assigned to new logon.

Domain Controller Logs

On the domain controller, the key difference is that you will not see Kerberos authentication. However, that isn’t a very reliable way to detect pass the hash because it can happen for lots of valid reasons, including authentications originating from non-trusted domains.

Summary of Event Logs for Normal and Pass-the-Hash Authentication

Here’s a summary of the native Windows event logs we see when performing normal NTLM authentication:

And here is a summary of what we see when doing pass the hash, with the key differences bolded:

Detecting Pass the Hash using Sysmon

To conclusively detect pass-the-hash events, I used Sysmon, which helps to monitor process access events. With Sysmon in place when a pass the hash occurs, you will see Event ID 10 showing access to the LSASS process from Mimikatz (or other pass-the-hash tool).

Building Detections for Pass the Hash

Now that we’ve looked at all the evidence, the simplest way to build detections for pass the hash is to look for:

• 4624 events on your workstations with:
  • Logon Type = 9
  • Authentication Package = Negotiate
  • Logon Process = seclogo
• Sysmon 10 events for LSASS process access

With a custom event log filter, you can easily see when these two things happen at the same exact time, which indicates pass-the-hash activity on your network.

Here is a custom event filter you can use to surface that specific information.

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
     *[System[(EventID='4624')]
      and
     EventData[Data[@Name='LogonType']='9']
      and
     EventData[Data[@Name='LogonProcessName']='seclogo']
     and
     EventData[Data[@Name='AuthenticationPackageName']='Negotiate']
     ]
     </Select>
  </Query>
  <Query Id="0" Path="Microsoft-Windows-Sysmon/Operational">
    <Select Path="Microsoft-Windows-Sysmon/Operational">
    *[System[(EventID=10)]]
    and
    *[EventData[Data[@Name='GrantedAccess'] and (Data='0x1010' or Data='0x1038')]]
</Select>
  </Query>
</QueryList>

How Netwrix Solutions Can Help

Setting up and monitoring custom event filters is tedious, and it requires enabling logging on all endpoints. To simplify the work while leveraging more advanced techniques, consider a third-party threat detection solution.

Netwrix StealthDEFEND is an effective tool for detecting pass-the-hash attacks. Here are two techniques that the solution supports:

• Honey tokens — You can inject fake credentials into LSASS memory on target machines and monitor for the usage of those credentials. If you see the credentials in use, you know they were retrieved from memory on one of the honeypot machines and used for lateral movement.
• Abnormal behavior detection — Baselining normal user behavior helps you spot anomalous use of accounts that is indicative of pass-the-hash and other lateral movement attacks. Behavior to look for includes:
  • An account is used from a host it never authenticated before
  • An account is used to access a host it never before accessed
  • An account accessing a large number of hosts across the network in a way that contradicts normal access patterns

To mitigate the risk of pass-the-hash attacks being launched in the first place, use Netwrix StealthAUDIT, which empowers you to:

• • Minimize administrative rights on servers and desktops
  • Prevent users from logging into workstations using administrative rights
  • Monitor for suspicious PowerShell commands that can be used for performing credential extraction and pass the hash
  • Restrict highly privileged accounts from logging into lower privileged systems
  • Ensure that LSA Protection is enabled on critical systems to make it more difficult to extract credentials from LSASS