Event ID 4624 - An account was successfully logged on

Event ID 4624 - An account was successfully logged on

Json log sample:

{

"EventTime": "2017-10-09 05:00:00",

"Hostname": "LPWXDC.ChangeMe.local",

"Keywords": -9214364837600034816,

"EventType": "AUDIT_SUCCESS",

"SeverityValue": 2,

"Severity": "INFO",

"EventID": 4624,

"SourceName": "Microsoft-Windows-Security-Auditing",

"ProviderGuid": "{54849625-5478-4994-A5BA-3E3B0328C30D}",

"Version": 1,

"Task": 12544,

"OpcodeValue": 0,

"RecordNumber": 409583434,

"ProcessID": 824,

"ThreadID": 19048,

"Channel": "Security",

"Message": "An account was successfully logged on.",

"Category": "Logon",

"Opcode": "Info",

"SubjectUserSid": "S-1-0-0",

"SubjectUserName": "-",

"SubjectDomainName": "-",

"SubjectLogonId": "0x0",

"TargetUserSid": "S-1-5-18",

"TargetUserName": "LPW",

"TargetDomainName": "LP",

"TargetLogonId": "0x1828eb397",

"LogonType": "3",

"LogonProcessName": "Kerberos",

"AuthenticationPackageName": "Kerberos",

"LogonGuid": "{FD1B49BA-A5E9-5D7D-D3F4-D925B43807F2}",

"TransmittedServices": "-",

"LmPackageName": "-",

"KeyLength": "0",

"ProcessName": "-",

"WorkstationName": "LPLONSERVDBVM",

"IpAddress": "10.0.2.10",

"IpPort": "60208",

"ImpersonationLevel": "%%1833",

"EventReceivedTime": "2017-10-09 05:00:00",

"SourceModuleName": "wineventlog_in",

"SourceModuleType": "im_msvistalog"

}

This event is very important and highly valuable. It documents all successful attempt to logon to the local computer regardless of logon type, location of the user or type of account.

Subject User Information:
"SubjectUserSid"
"SubjectUserName"
"SubjectDomainName"
"SubjectLogonId"
This provides an information of account that request logon but not the actual user who logged on. This information are in general not that important from audit perspective but still there could be some cases where you would want to look into this. To find information regarding user who logged on we need to refer to Target User Information as below.

Target User Information:
"TargetUserSid" -> SID of an account
"TargetUserName" -> user who logged in
"TargetDomainName" -> domain name of user
"TargetLogonId" -> This is unique number between each reboot and it identifies each logon  session. This can be used to correlate with logoff events 4634, 4647.
This provides an information about the user who just logged. To determine whether the account is local or domain compare TargetDomainName to the computer name.  If they match, the account is a local account on that system, otherwise a domain account.

Type of logon:
"LogonType" -> This defines the type of logon. Possible values are as follows

	logon_type	description
	2	Interactive
	3	Network
	4	Batch
	5	Service
	7	Unlock
	8	NetworkCleartext
	9	NewCredentials
	10	RemoteInteractive
	11	CachedInteractive

Impersonation Level:

	impersonation level	description
	%%1832	Identification
	%%1833	Impersonation
	%%1840	Delegation
	%%1841	Denied by Process Trust Label ACE
	%%1842	Yes
	%%1843	No
	%%1844	System
	%%1845	Not Available
	%%1846	Default
	%%1847	DisallowMmConfig
	%%1848	Off
	%%1849	Auto

Network Information:

"IpAddress" -> IP address of the computer where the user is physically present
"IpPort" -> source TCP port of the logon request

"WorkstationName" -> the computer name of the computer where the user is physically present.  Workstation may be blank in some Kerberos logons.

Windows Account Logon Type

There are various types of logon possible in windows operating system like Network, Interactive, Remote etc.

Whenever successful login event occurs event id 4624 is generated, while 4625 is logged for failed logins. On top of what logon event took place you should also look into logon methods used by the user who attempted to login. This information is provided by LogonType in the log. Following are various logon type supported by windows system.

Type of logon:
"LogonType" -> This defines the type of logon. Possible values are as follows

	logon_type	Information
	2	Interactive
	3	Network
	4	Batch
	5	Service
	7	Unlock
	8	NetworkCleartext
	9	NewCredentials
	10	RemoteInteractive
	11	CachedInteractive

More Detail

• 2 (Interactive)

Console logon of a computer. This event is logged when you attempt to log on at a Windows computer’s local keyboard and screen.

• 3 (Network)

A user or computer logged on to this computer from the network. This logon event is generated when remote file shares or printers are accessed.

Most logons to Internet Information Services (IIS) are classified as network logons, other than IIS logons that use the basic authentication protocol (those are logged as logon type 8).

• 4 (Batch)

This is used for scheduled tasks. Batch logon type is used by batch servers, where processes may be executing on behalf of a user without their direct intervention.

• 5 (Service)

A service was started by the Service Control Manager. This is used for services and service accounts that log on to start a service. When a service starts, Windows first creates a logon session for the user account that is specified in the service configuration.

• 7 (Unlock)

This workstation was unlocked and this logon type is used whenever you unlock your Windows machine.

• NetworkCleartext

This is used when logging on over the network - when the password is sent in clear text. 

A user logged on to this computer from the network, howerver, user's password was passed to the authentication package in its unhashed form i.e. in cleartext. The credentials should not traverse the network in plaintext.

• NewCredentials

This is used when you run an application using the RunAs command. A caller cloned its current token and specified new credentials for outbound connections. The new logon session has the same local identity, but uses different credentials for other network connections.

• RemoteInteractive

This is used for the RDP applications like Terminal Services or Remote Assistance. A user logged on to this computer remotely using Terminal Services or Remote Desktop.

• CachedInteractive

This is logged when users log on using cached credentials. A user logged on to this computer with network credentials that were stored locally on the computer. The domain controller was not contacted to verify the credentials.


Below is a Json log sample for Network logon.

{
"EventTime": "2017-12-04 05:00:00",
"Hostname": "LPWXDC.ChangeMe.local",
"Keywords": -9214364837600034816,
"EventType": "AUDIT_SUCCESS",
"SeverityValue": 2,
"Severity": "INFO",
"EventID": 4624,
"SourceName": "Microsoft-Windows-Security-Auditing",
"ProviderGuid": "{54849625-5478-4994-A5BA-3E3B0328C30D}",
"Version": 1,
"Task": 12544,
"OpcodeValue": 0,
"RecordNumber": 409583434,
"ProcessID": 824,
"ThreadID": 19048,
"Channel": "Security",
"Message": "An account was successfully logged on.",
"Category": "Logon",
"Opcode": "Info",
"SubjectUserSid": "S-1-0-0",
"SubjectUserName": "-",
"SubjectDomainName": "-",
"SubjectLogonId": "0x0",
"TargetUserSid": "S-1-5-18",
"TargetUserName": "LPW",
"TargetDomainName": "LP",
"TargetLogonId": "0x1828eb397",
"LogonType": "3",
"LogonProcessName": "Kerberos",
"AuthenticationPackageName": "Kerberos",
"LogonGuid": "{FD1B49BA-A5E9-5D7D-D3F4-D925B43807F2}",
"TransmittedServices": "-",
"LmPackageName": "-",
"KeyLength": "0",
"ProcessName": "-",
"WorkstationName": "LPLONSERVDBVM",
"IpAddress": "10.0.2.10",
"IpPort": "60208",
"ImpersonationLevel": "%%1833",
"EventReceivedTime": "2017-10-09 05:00:00",
"SourceModuleName": "wineventlog_in",
"SourceModuleType": "im_msvistalog"
}

Windows Account Logon Impersonation Level

Impersonation level is seen in Windows Server 2012 and above.

A new logon event is generated on the computer where the resource is located, on behalf of the user for whom effective access is being checked. When analyzing security audit logs for user sign-in activity, to differentiate between logon events that are generated because of effective access and those generated because of an interactive network user sign in, the Impersonation Level information is included. When the logon event is generated because of effective access, the Impersonation Level will be Identity. A network interactive user sign in typically generates a logon event with the Impersonation Level = Impersonation or Delegation.

Various degrees of impersonation is provided by windows through impersonation levels. This levels indicate how much authority is given to server when it is impersonating the client.

Currently, there are four impersonation levels are available: 

• Anonymous

RPC_C_IMP_LEVEL_ANONYMOUS. The client is anonymous to the server. The server process can impersonate the client, but the impersonation token does not contain any information about the client. This level is supported only over the local interprocess communication transport. All other transports silently promote this level to identify.

• Identify

RPC_C_IMP_LEVEL_IDENTIFY. The system default level. The server can obtain the identity of the client, and the server can impersonate the client in order to do ACL checks.

• Impersonate

RPC_C_IMP_LEVEL_IMPERSONATE. The server can impersonate the security context of the client while acting for the client. The server can access local resources as the client. If the server is local, it can access network resources as the client. If the server is remote, it can access only resources that are on the same machine as the server.

• Delegate

RPC_C_IMP_LEVEL_DELEGATE: The most powerful impersonation level. When this level is selected, the server (whether local or remote) can impersonate the security context of the client while acting on behalf of the client. During impersonation, the client credentials (both local and network) can be passed to any number of machines.

Impersonation Level:

	impersonation level	description
	%%1832	Identification
	%%1833	Impersonation
	%%1840	Delegation
	%%1841	Denied by Process Trust Label ACE
	%%1842	Yes
	%%1843	No
	%%1844	System
	%%1845	Not Available
	%%1846	Default
	%%1847	DisallowMmConfig
	%%1848	Off
	%%1849	Auto

Json log sample:

{

"EventTime": "2017-12-04 05:00:00",

"Hostname": "LPWXDC.ChangeMe.local",

"Keywords": -9214364837600034816,

"EventType": "AUDIT_SUCCESS",

"SeverityValue": 2,

"Severity": "INFO",

"EventID": 4624,

"SourceName": "Microsoft-Windows-Security-Auditing",

"ProviderGuid": "{54849625-5478-4994-A5BA-3E3B0328C30D}",

"Version": 1,

"Task": 12544,

"OpcodeValue": 0,

"RecordNumber": 409583434,

"ProcessID": 824,

"ThreadID": 19048,

"Channel": "Security",

"Message": "An account was successfully logged on.",

"Category": "Logon",

"Opcode": "Info",

"SubjectUserSid": "S-1-0-0",

"SubjectUserName": "-",

"SubjectDomainName": "-",

"SubjectLogonId": "0x0",

"TargetUserSid": "S-1-5-18",

"TargetUserName": "LPW",

"TargetDomainName": "LP",

"TargetLogonId": "0x1828eb397",

"LogonType": "3",

"LogonProcessName": "Kerberos",

"AuthenticationPackageName": "Kerberos",

"LogonGuid": "{FD1B49BA-A5E9-5D7D-D3F4-D925B43807F2}",

"TransmittedServices": "-",

"LmPackageName": "-",

"KeyLength": "0",

"ProcessName": "-",

"WorkstationName": "LPLONSERVDBVM",

"IpAddress": "10.0.2.10",

"IpPort": "60208",

"ImpersonationLevel": "%%1833",

"EventReceivedTime": "2017-12-04 05:00:00",

"SourceModuleName": "wineventlog_in",

"SourceModuleType": "im_msvistalog"

}

Account Logon Fail Status in Windows

Status and Sub Status Code:

status and sub_status_code	description
0XC000005E	There are currently no logon servers available to service the logon request.
0xC0000064	user name does not exist
0xC000006A	user name is correct but the password is wrong
0XC000006D	This is either due to a bad username or authentication information
0XC000006E	Unknown user name or bad password.
0xC000006F	user tried to logon outside his day of week or time of day restrictions
0xC0000070	workstation restriction or Authentication Policy Silo violation (look for event ID 4820 on domain controller)
0xC0000071	expired password
0xC0000072	account is currently disabled
0XC00000DC	Indicates the Sam Server was in the wrong state to perform the desired operation.
0xC0000133	clocks between DC and other computer too far out of sync
0xc000015b	The user has not been granted the requested logon type (aka logon right) at this machine
0XC000018C	The logon request failed because the trust relationship between the primary domain and the trusted domain failed.
0XC0000192	An attempt was made to logon but the netlogon service was not started.
0XC0000193	account expiration
0XC0000224	user is required to change password at next logon
0xC0000225	evidently a bug in Windows and not a risk
0xC0000234	user is currently locked out
0XC0000413	Logon Failure: The machine you are logging onto is protected by an authentication firewall. The specified   account is not allowed to authenticate to the machine.

Log Sample: 

{

"EventTime": "2017/08/25 14:09:12"

"Hostname": "CIVDCS-ADC1.changeme.com"

"Keywords": -9218868437227405312

"EventType": "AUDIT_FAILURE"

"SeverityValue": 4

"Severity": "ERROR"

"EventID": 4625

"SourceName": "Microsoft-Windows-Security-Auditing"

"ProviderGuid": "{54849625-5478-4994-A5BA-3E3B0328C30D}"

"Version": 0

"Task": 12544

"OpcodeValue": 0

"RecordNumber": 56611365

"ProcessID": 528

"ThreadID": 4672

"Channel": "Security"

"Message": "An account failed to log on."

"Category": "Logon"

"Opcode": "Info"

"SubjectUserSid": "S-1-0-0"

"SubjectUserName": "-"

"SubjectDomainName": "-"

"SubjectLogonId": "0x0"

"TargetUserSid": "S-1-0-0"

"TargetUserName": "MININT-UP26I95$"

"TargetDomainName": "changeme"

"Status": "0xc000006d"

"FailureReason": "%%2313"

"SubStatus": "0xc000006a"

"LogonType": "3"

"LogonProcessName": "NtLmSsp "

"AuthenticationPackageName": "NTLM"

"WorkstationName": "MININT-UP26I95"

"TransmittedServices": "-"

"LmPackageName": "-"

"KeyLength": "0"

"ProcessName": "-"

"IpAddress": "172.23.130.64"

"IpPort": "65284"

"EventReceivedTime": "2017/08/25 14:09:12"

"SourceModuleName": "wineventlog_in"

"SourceModuleType": "im_msvistalog"

}

Failure Reason:

%%2305	The specified user account has expired.
%%2309	The specified account's password has expired.
%%2310	Account currently disabled.
%%2311	Account logon time restriction violation.
%%2312	User not allowed to logon at this computer.
%%2313	Unknown user name or bad password.

Why IP Address is only Present in Account Logon

Have you ever noticed that in many cases of account logon, in windows system, only ip address is present and not the actual workstation name. If you are not sure what I mean, then look into some of the logon events like 4624, 4625 etc. In audit log for this events you can easily find the ip address of the machine from where logon event were generated but not the name of the workstation. There are various reasons for this happening but importantly there are three specific reason.

Example: Event id 4624
{
 "EventTime": "2017-10-09 05:00:00", "Hostname": "LPWXDC.ChangeMe.local", "Keywords": -9214364837600034816, "EventType": "AUDIT_SUCCESS", "SeverityValue": 2, "Severity": "INFO", "EventID": 4624, "SourceName": "Microsoft-Windows-Security-Auditing", "ProviderGuid": "{54849625-5478-4994-A5BA-3E3B0328C30D}", "Version": 1, "Task": 12544, "OpcodeValue": 0, "RecordNumber": 409583434, "ProcessID": 824, "ThreadID": 19048, "Channel": "Security", "Message": "An account was successfully logged on.", "Category": "Logon", "Opcode": "Info", "SubjectUserSid": "S-1-0-0", "SubjectUserName": "-", "SubjectDomainName": "-", "SubjectLogonId": "0x0", "TargetUserSid": "S-1-5-18", "TargetUserName": "LPW", "TargetDomainName": "LP", "TargetLogonId": "0x1828eb397", "LogonType": "3", "LogonProcessName": "Kerberos", "AuthenticationPackageName": "Kerberos", "LogonGuid": "{FD1B49BA-A5E9-5D7D-D3F4-D925B43807F2}", "TransmittedServices": "-", "LmPackageName": "-", "KeyLength": "0", "ProcessName": "-", "WorkstationName": "-", "IpAddress": "10.0.2.10", "IpPort": "60208", "ImpersonationLevel": "%%1833", "EventReceivedTime": "2017-10-09 05:00:00", "SourceModuleName": "wineventlog_in", "SourceModuleType": "im_msvistalog"
}

These are three reasons for this :

1. There is no secure method for the KDC to get the remote machine's name at the current time.  If the client provides the name (as in NTLM), then it's not trustworthy and can be spoofed.  There are Unix-based hacking tools which spoof workstation name in NTLM auth requests.
2. DNS and NetBIOS reverse lookup are not secure and are not reliable- if we tried this, we'd have a high incidence of incorrect or missing information, and hurt performance.
3. Even if we chose to do add the name anyway, when we could, there's no field for us to use to carry it in Kerberos AS REQ & TGS REQ messages- we'd have to overload some other field, and run a high risk of loss of compatibility with MIT's reference implementation.

Logon Rights in Windows System

What is Logon Rights?

Logon rights is a way to control how user accounts are allowed access to the computer. In other words logon rights controls how user accounts can logon to the computer system. There are various means of access: may be keyboard, a network connection, or as a service or a batch job. In general there are 5 logon types in Windows.

1. Interactive
2. Network
3. Remote Interactive
4. Service
5. Batch

For each logon method, there exists a pair of logon rights: one to allow logging on to the computer and another to deny logging on to the computer. If a user ends up with both the allow and deny rights for a given logon type, deny overrides allow.

Logon Type	Allow	Deny
Interactive	Allow log on locally	Deny log on locally
Network	Access this computer from the network	Deny access to this computer from the network
Remote Interactive	Allow log on through Terminal Services	Deny log on through Terminal Services
Service	Log on as a service	Deny log on as a service
Batch	Log on as a batch job	Deny log on as a batch job

Changes to these logon rights assignments in Windows are logged by event IDs 4717 and 4718.

Case Example:

Lets suppose Bob wants all users except the members of the domains Sales to be able to log on locally at his computer. What he needs to do is: create a local group named "LocalLogonDenied" Next he configures his computer as below

• He assigns the log on locally user right to the Users group.
• He assigns the deny local logon user right to the LocalLogonDenied group.
• He makes the Sales group a member of the LocalLogonDenied group.

As stated above deny rights take precedence over allow rights, so members of the Sales group are denied the right to log on locally even though they are also members of the Users group, which is allowed to log on locally.

--------------------------------------------------------------------------------------------------------------------------

The key here is "Allow a set, and then deny a subset."

-------------------------------------------------------------------------------------------------------------------------- 

Reversing the order can be disastrous. For example, Bob might want to allow no one but himself to log on locally. If he allowed himself the right to log on locally and denied the Users group the right to log on locally, he would be unpleasantly surprised to find he had locked himself out of the computer. Bob, after all, is a member of the Users group, so the deny right he assigned to the Users group would take precedence over the allow right he assigned to himself.