Search
  • malwrr

A modern take on Windows Event Log analysis



U.S. Government's Office of Personnel Management (OPM) Data Breach 2013 - 2015 is one of the largest in the government sector globally, with over 22 million government employees records stolen by cyber attackers.

OPM did not detect or monitor abnormal behaviors and the compromise of privileged users' credentials or implement any recommended security measures. Check Poorly Configured SIEM section in https://duo.com/blog/opm-security-audit-no-two-factor-authentication

The following Windows Active Directory event IDs and anomalies related to privileged users could've been monitored and correlated to prevent the data theft:

1102, 4625, 4670, 4672, 4673, 4704, 4724, 4728, 4738, 4964.


While there are multiple blogs and cheat sheets that assists an analyst detect critical security events in a Windows environment, this should be a good resource to skim through. After years on the defensive line, fighting deafening noise, numerous rabbit hole journeys and lessons learned - here is my take on few of the windows event IDs. I will keep updating this post with more interesting findings from my experience.



True Positives

  • 1100 - The event logging service has shut down

This event triggers as part of the shutdown process and can be used as a change control identifier. but not the most accurate technique to detect if a machine is being shutdown. Though this event occurs during a shutdown routine, It can also be used to track malicious activities. Correlating 1100 with Windows System Event - 6006 (the last event logged during the shutdown of the machine) increases the accuracy for change control use case. 
  • 104 / 1102 - The audit log was cleared

System event 104 or Security event 1102 is used for tracking MITRE ATT&CK T1070.003, a sub-techniques of Indicator Removal on Host (T1070). Make note that this could be a benign true positive if your systems engineer was running an internet script (which is never a good idea) as part of reimaging.
  • 4698 to 4702 - Changes to scheduled task

This is an important change control event. The user made change to a scheduled task (Start menu\Accessories\System Tools\Task Scheduler). Traditionally the preferred method for attackers to setup persistence. 
  • 4624 4625 4740 / Logon types

Make note that the 4624 and 4625 has some critical information like the Status and Sub Status Codes and logon type codes. It's important that these fields are extracted and used for additional correlation that can save an analyst a lot of time. 
Example: Logon type 2 + status code 0xC0000234 = Interactive logon fails as the account is currently locked out. 
  • 4825 - A user was denied the access to Remote Desktop. By default, users are allowed to connect only if they are members of the Remote Desktop Users group or Administrators group

This event is generated when an authenticated user who is not allowed to log on remotely attempts to connect to this computer through Remote Desktop
  • 4688: A new process has been created

This is the noisiest windows event ID but can also help as an End-Point protection use case. I've rarely seen defenders taking this route but it's possible. To get useful information monitor only specific processes using the New Process Name, Creator Process Name and Process Command Line.
Note that Process Command Line is an important field that can be enabled to correlate the command line arguments (including any passwords) passed into the EXE when the process was started.  Can be enabled in Group Policy: Administrative Templates\System\Audit Process Creation\Include command line in process creation events
Example:
New Process Name: <path>\PowerShell.exe
Creator Process Name: <path>\WINWORD.exe
Process Command Line: *<ignore case>PowerShell -ENCOD*

  • 4608 - Windows is starting up

This event is logged when LSASS.EXE starts and the auditing subsystem is initialized. you can also use System Event ID 6005 (Event log service was started) or 12 (The operating system started) to get useful information like the Boot Type (normal, safemode w/ networking, etc.)


Benign True Positives / False Positives

  • Event ID 4649: A replay attack was detected

This is one of those popular alerts that an analyst usually slides it under the rug, That's because if you investigate it using an EDR there is no security threat to it. Being an out of the box, too good to be true security event from Microsoft - This is by default monitored by MSSPs and recommended on popular SIEM tool manuals. I'm not sure if I can categorize this event ID as a BTP or a FP as the alert title is misleading and the event poses no impact to any security policies within an organization. I stress on the word NO IMPACT because I was not able to find any historical records of this event ID - 4649 being triggered as part of an attack. This is the information provided in the description of the event:

This event indicates that a Kerberos replay attack was detected- a request was received twice with identical information. This condition could be caused by network misconfiguration.

https://thisismyclassnotes.blogspot.com/2019/09/detect-replay-attack-in-windows-system.html

When the DC receives the KRB_AP_ERR_REPEAT per RFC 1510 (September 1993 - Kohl & Neuman), The DC is expected to drop the request marking it invalid if I've understood it correctly.

https://www.ietf.org/rfc/rfc1510.txt

if (req.kdc-options.VALIDATE is set) then
                if (tgt.flags.INVALID is reset) then
                        error_out(KDC_ERR_POLICY);
                endif
                if (tgt.starttime > kdc_time) then
                        error_out(KRB_AP_ERR_NYV);
                endif
                if (check_hot_list(tgt)) then
                        error_out(KRB_AP_ERR_REPEAT);
                endif
                tkt := tgt;
                reset new_tkt.flags.INVALID;
                
  • 4609 - Windows is shutting down.

Unlike event ID 1100 (The event logging service has shut down) which is a sure event; In my experience, have never seen a use case relying on this event for change control monitoring. This is because the event logging service stops first (event 1100) and so the event 4609 will never be written to the event logger. Randy points out that this was an old problem and Microsoft fixed it in Win.NT/2000 but left it broken again. 

I will continue to update this post with more interesting events. Do reach out @ malwrra@gmail.com to share your experience with different windows events.


1 view0 comments

Recent Posts

See All