top of page
  • Writer's pictureA.P. Hofleitner

How do I check for a specific event ID in logs? What even IDs are important to monitor for security?

Event Viewer -> *right click* Create Custom View -> Event Level: check all -> By log: select all -> <All Event IDs>: Enter Event ID here


Event IDs to monitor for Intrusion Detection:

Source: https://www.criticalstart.com/windows-security-event-logs-what-to-monitor/

1102 - Audit log cleared

A common strategy for attackers once in an environment is to cover their tracks. While some attackers are sophisticated and will use equally sophisticated – and manual – methods to accomplish this, many attackers will just blast the Windows audit log away.


1104 - Security log is now full

For this event and 1108, we want to make sure we’re collecting security logs at all times. A cessation in logging can cause a major headache for investigations, compliance, etc – most importantly, you can’t know what you don’t see.


1108 - Event logging service error

See above, though this one is less common.


4624 - Account successfully logged on

Monitor this event code in tandem with 4625 – all the failed authentications in the world will mean nothing if you don’t know if it was ever successful or not.


4625 - Account failed to log on

A bread and butter security event to monitor, this lets you detect all sorts of potentially malicious behavior as brute force attacks are some of the most common out there.


4648 - A logon was attempted using explicit credentials

This is good to track for monitoring where credentials are being used explicitly. It doesn’t necessarily indicate a security risk, however it’s good to keep an eye on where these are coming from.


4672 - Special privileges assigned to new logon

This event is a bit confusing in its name – it’s not denoting that a logon has been given special privileges, more that an account that has special privileges has logged on – so you’ll see this in tandem with 4624 events. This should be monitored to detect rogue superuser accounts or over-privileged accounts.


4698 - Scheduled task created

Attackers and malicious programs will frequently create scheduled tasks to provide them persistence within an environment. By monitoring this event along with 4700 you can watch for suspicious or unknown scheduled tasks being created.


4700 - Scheduled task enabled

See 4698


4720 - User account created

This is more of an environment tracking event code, however attackers will sometimes create accounts for them to utilize and pivot from if they’ve gained an amount of access. These should be tracked both to detect that activity and to just generally see what’s going on in your environment.


4723 - An attempt was made to change the password of an account

Due to how Windows logs, this event probably doesn’t mean what you think it does. It detects a user attempting to change their own password, not that of another account – most times you’ll see this will be when a user is failing to change their password due to the new password not meeting the password policy. As such you may want to monitor this only for accounts that should never be having their password changed.


4725 - User account disabled

More of an environment review event code as the disabling of an account is usually not what attackers are aiming to do. However it can help to detect anomalous activity that should be investigated.


4727 - Group created (global)

This along with other group creations should be monitored mostly for environment review, however attackers will sometimes create groups to pivot from or to give multiple accounts footholds should one of them be taken down.


4728 - User added to global group

See 4727


4731 - Group created (local)

See 4727


4732 - User added to local group

See 4727


4740 - Account locked out

This is a valuable event code to monitor for privileged accounts as it gives us a good indicator that someone may be trying to gain access to it. This code can also indicate when there’s a misconfigured password that may be locking an account out, which we want to avoid as well. Also, your guess is as good as mine as to why this is located in the middle of the group change events.


4754 - Group created (universal)

See 4727


4756 - User added to universal group

See 4727


4767 - User account unlocked

See 4727


4768 - Kerberos authentication ticket was requested

Kerberos authentication event codes should be monitored in the same way 4625 and 4624 authentication events are. These Kerberos event codes will tend to give you a clearer picture on the entire logon attempt process, including at what point in the process the logon failed – pre-authentication or post.


4771 - Kerberos preauthentication failed

This event code should be logged and treated similarly to 4625 events, as they represent the other “half” of authentication failures. Windows has different rules for when a 4625 vs a 4771 is logged, and it represents a much more in depth authentication discussion. For our purposes here, know that 4771s will be loud (think cached passwords) but that they can be refined down by keying off their result code field.


4776 - The domain controller attempted to validate the credentials for an account

Bit of a misnomer on this one – this event will fire from workstations and servers in the same way it’d fire from a domain controller. This is also the event code you’ll see if something is authenticated via NTLM rather than Kerberos, so it’s also important to include in your authentication logging


4780 - The ACL was set on accounts which are members of administrators groups

Equal parts environment review and security risk, we want to investigate these to see why the ACL was changed for these accounts and to ensure it was both intentional and permitted.


4782 - The password hash of an account was accessed

Monitor these as hash accesses should be planned, and unplanned hash accesses may represent a security risk or malicious activity


4798 - A user’s local group membership was enumerated

For this and 4799, a group’s membership being checked can be a sign of suspicious behavior, as many attackers – once gaining access to an account – will aim to check how valuable their accessed account is. We want to monitor this behavior and note the process name that’s calling this action, as some are expected to be doing this while others are not (mmc.exe vs cain.exe)


4799 - A security-enabled local group membership was enumerated

See 4798

8 views0 comments

Recent Posts

See All

Comments


bottom of page