Event Log Analysis for Responders and Hunters
Event Log Fundamentals
Where to Find Logs
For NT/ Win2000/ XP/ Server 2003:
.evtfile type%systemroot%\System32\configFilenames:
SecEvent.evt,AppEvent.evt,SysEvent.evt
For Vista / Win7 / Win8 / 2008/ 2012 / Win10 / 2016.evtxfile type%systemroot%\System32\winevt\logsRemote log server
Filenames:
Security.evtx,Application.evtx,System.evtx, etc.
Default locations can be changed in the registry.
Logs are stored in binary format, complicating byte-level string searching, and are implemented using a circular buffer. The circular buffer loops around to (eventually) overwrite the oldest entries to the most recent.
Options when maximum size of a log is reached:
Overwrite events as needed (Default): Events in the log are overwritten when the maximum file size is reached.
Archive the log when full; do not overwrite events: When the log is full, an archive is created (look for files named “Archive-Security-”). If not watched, this has the potential to fill the drive to capacity.
Do not overwrite events: When the max log size is reached, error messages are generated to indicate that the event log is full. The administrator must manually clear the logs.
Types of Event Logs
Security Logs
Most reviewed logs in Windows forensics.
Although almost all event logging has the potential to be useful during an investigation, most of the questions we are looking to answer during a forensic investigation tend toward answers found in the Security log.
The System and Application logs store information more useful for troubleshooting by system administrators.
An important concept is that the audit policy can be set to trigger events for both successful and failed attempts.
It is possible to tailor auditing for a specific user account using Group Policy.
Only user accounts with administrator permissions can review, export, or clear the log.
What is recorded?
Audit account logon events: Audit each instance of a user logging on to or logging off from another computer in which this computer is used to validate the account.
Audit account management: Audit each event of account management on a computer. Examples of account maintenance include password changes, user account, and group modifications.
Audit directory service access: Audit the event of a user accessing an Active Directory object that has its own system access control list (SACL) specified.
Audit logon events: Audit each instance of a user logging on or logging off a computer. Note that this is different than the “Audit account logon events” category. This tracks the logon event to a specific server; the former tracks which domain controller authenticated the user.
Audit object access: Audit the event of a user accessing an object that has its own system access control list (SACL) specified. Examples of objects are files, folders, registry keys, printers, etc.
Audit policy change: Audit every incident of a change to user rights assignment policies, audit policies, or trust policies.
Audit privilege use: Audit each instance of a user exercising a user right.
Audit process tracking: Audit detailed tracking information for events such as program activation, process exit, handle duplication, and indirect object access.
Audit system events: Audit when a user restarts or shuts down the computer or when an event occurs that affects either the system security or the security log.
Analysis Scenarios
Tracking Account Usage (1)
Goals:
Determine which accounts have been used for attempted logons.
Track account usage for known compromised accounts.
Relevant Events IDs
4624: Successful Logon
4625: Failed Logon
4634/4647: Successful Logoff
4648: Logon using explicit credentials (RunAs)
4672:Account logon with superuser rights (Administrator)
4720 / 4726: An account was created / deleted
Notes
Windows is not always consistent with recording logoff events (type 4634), so it is wise to also look for 4647 events (user initiated logoff for interactive and remote interactive sessions).
4625 events indicate logon failures and are often reviewed for evidence of password guessing attacks.
When explicit (different) credentials are used, an ID 4648 event is recorded. A good example of this is the runas command, or if an application is run as an administrator, and those admin credentials are entered by the user.
Event ID 4672 is recorded for administrator-equivalent logons in addition to the standard 4624 event.
Finally, event ID 4720 is recorded whenever a new account is created and 4726 recorded for account deletion.
When a hacker gains access to a system through some sort of an exploit (remote code execution, privilege escalation, service exploitation, client-side attacks resulting in backdoors, etc.), there is typically no record of “logon” within the event logs.
Tracking Account Usage (2)
When auditing account usage events, we focus on five fields of the event record.
Logon Type: The type of the logon (i.e. RDP, Console, SMB, etc..)
Account: The name of the account that logged-on.
Timestamp: The date and time of the logon.
Event ID: What type of Logon/Logoff event this is.
Computer: The hostname of the system that the event was recorded on.
Although these are the most important elements, each recorded event contains additional information defining the event and providing valuable information regarding why that event was triggered.
Logon Type Codes
| Code | Explanation |
|---|---|
2 | Log on via console (keyboard, server KVM, or virtual client) |
3 | Network logon |
4 | Batch Logon—Often used by Scheduled Tasks |
5 | Windows Service Logon |
7 | Credentials used to lock or unlock screen; RDP session reconnect |
8 | Network logon sending credentials in cleartext |
9 | Different credentials used than logged on user — RunAs/ netonly |
10 | Remote interactive logon (Remote Desktop Protocol) |
11 | Cached credentials used to log on |
12 | Cached Remote Interactive (similar to Type 10) |
13 | Cached unlock (similar to Type 7) |
This information is important because it can help us determine whether an actual "hands-on-keyboards)
The logon ID is a unique ID assigned to a session, it can be used to link a logon with a logoff and determine session length. In addition to determining the session length, the Logon ID can also tie together other actions like special user privileges assigned to the session, process tracking and object access events, and granular views of user activity like screen locking and unlocking.
Built-in Accounts
By design, every process and service within Windows must ran using an account with some associated security privileges.
Because many Windows processes ran before a user is even logged on (that is, boot time), or without explicit user knowledge (system maintenance processes), Windows has a set of service accounts that can be used to allow processes to mn within different security contexts.
Built-in Accounts:
SYSTEM: Prior to Windows 2003, this was the primary account used for non-user related actions (As part of the Microsoft Trustworthy Computing Initiative, more limited accounts were added, which were more in line with the security principal of least privilege.)
LOCAL SERVICE: Designed to have limited privileges (similar to the standard USER account) and used for services that do not require network access.
NETWORK SERVICE: Similar to LOCAL SERVICE, but with slightly higher privileges, which allow it to impersonate standard computer accounts and authenticate over the network. It is assigned for processes or services that require network access.
<Host Name>$: Eveiy domain-joined Windows system has a computer account. The account provides the means for the computer to be authenticated when communicating with Active Directory and accessing network and domain resources. The account is named according to the system name and must contain the dollar sign symbol “$” at the end.
DWM and UMFD: Microsoft has provided almost no documentation on these built-in accounts that recently have become much more prevalent. They are apparently related to the windows manager (DWM) and driver activity (UMFD), but more information is needed.
ANONYMOUS LOGON: This account is the most often misunderstood. It was originally created as a means for Windows systems to communicate without requiring explicit credentials. In older or insecure systems, anonymous logons, or Null Sessions, can be used to enumerate account information, security policy, registry data, and network shares. These abilities have slowly been removed (by default) in newer versions of Windows starting with XP and 2003. That being said, the account is still commonly used by Windows networks to facilitate things like file and print sharing and maintaining the network browse list. If these services are present in your environment, there is a good chance that you will see Anonymous Logon usage. The key takeaway is to not automatically assume the system has been under some sort of enumeration attack.
Tracking Administrator Account Activity
Tracking superuser account activity can be an excellent means for discovering anomalous activity.
When an account assigned privileges associated with an administrator logs on, an event ID 4672 is recorded.
The account technically does not have to be a full administrator—assignment of privileges like SeTakeOwnership, SeDebug, and Selmpersonate are all admin-cquivalent and will trigger this event.
This event type is particularly interesting on systems where administrative logins are rare. It can also be a way to identify highly privileged accounts like service accounts (useful for account auditing, planning for password resets, and identifying compromised service accounts)
Scheduled tasks run with administrative or “highest privileges” will also trigger this event type.
Once an adversary has administrator privileges, they can easily create additional accounts. Local administrators have the ability to create local accounts, and domain administrators can create domain-wide accounts of nearly any type.
While less common today due to the popularity of pass-the-hash and ticket-based attacks, rogue accounts are still a very viable way to evade some auditing and create “sleeper” accounts that can be used by attackers in times of distress.
Detecting account creation is very easy via proper auditing of account management events. Event ID 4720 is recorded when an account is created.
Complementary Events:
4722: A user account was enabled
4724: An attempt was made to reset an account’s password
4728: A member was added to a security-enabled global group
4732: A member was added to a security-enabled local group
4735: A security-enabled local group was changed
4738: A user account was changed
4756: A member was added to a security-enabled universal group
Tracking Account Usage: Remote Desktop Protocol
RDP is used extensively within many enterprises and as such is often also used by those with malintent.
When piecing together evidence of RDP connections, two event IDs can provide significant value: ID 4778 indicates that an RDP session was reconnected and ID 4779 indicates that a remote session was disconnected.
Keep in mind that they will not provide a historical view of every RDP connection. They are really designed to track session “reconnects” instead of brand-new RDP sessions and will only show a subset of RDP activity.
RDP session reconnects are often recorded as Event ID 4624 Logon Type 7 events (typically assumed to be screen lock/unlock as opposed to the “standard” Type 10 RDP Logon Type). If an analyst is only focusing on EID 4624 Logon Type 10 RDP events, they could miss any session reconnects, but discover their existence via EID 4778 and 4779 events.
Another big advantage of Event IDs 4778 and 4779 is that they include the IP address AND the hostname of the system that established the connection (the client hostname is not recorded in 4624 events).
We should also expect to see a near-simultaneous ID 4624 event (successful logon) because ID 4778 indicates only a successful remote session was reconnected, and ID 4624 indicates that the credentials provided were accepted. The same goes for ID 4779 and ID 4647 (successful logout) events.
Not every 4778/4779 event will be due to RDP usage. Windows also uses this same event to record the changing of Windows stations due to the “Fast User Switching” feature and the session name will be “Console”.
Depending on how the RDP client is used (full logout or just closing the client), session reconnects and disconnects may not present for every RDP access. Event ID 4624 (Logon Types 7 and 10) is usually the most comprehensive view.
Event ID 131 within the RDPCoreTS log and event IDs 1024 and 1102 in the TerminalServices-RdpClient log record outbound RDP connections, including destination hostname and IP address.
It is important to note that this RDP connection will be logged only on the receiving system.
Note that, the Logon ID information does not match between the 4624 and the corresponding 4778 event. Because 4778 and 4779 events are session reconnect/disconnect events, they take on the Logon ID of the earliest non-terminated interactive session from the same user. This is often the interactive session started after the last 4647 event (user-initiated logoff) by that account. In this example, there was an earlier session and hence the IDs do not match
RDP is logged in multiple places apart from the TerminalServices-RDPClient, all the other logs are logged on the destination. This is why the TerminalServices-RDPClient provides a unique overview where one can determine where the attacker came from.
Account Logon Events
Both
Account Logon EventsandLogon Eventsare 2 different things that are usually confused (because of the poor name choice).Logon Events refer to login/logoff activity that happens on the actual system being logged into. Thus, they are stored locally on that end system.
Account Logon Events refer to third-party authorization of credentials provided during that logon session. In a Windows domain environment, the vast majority of user accounts are actually domain accounts, with their credentials stored on the domain controller, NOT the local system.
Behind the scenes, before that user can log on to a workstation in a domain environment, his or her username and password must be validated by the domain controller using either the NTLM or Kerberos authentication protocol. Account Logon events record this process and, in this case, would be stored on the domain controller that verified the credentials. Thus, a single user logon can lead to several different events being spread across the workstation (Logon Events 4624, 4634, etc.) and across the domain controller (Account Logon Events 4776, or 4768, 4769).
There is one crucial exception to all of this. If the user is logging in using a local account, an account created only on the workstation itself and not part of any domain, then the workstation itself will be doing the final authentication (using the local SAM database) and hence we will see both Logon Events and Account Logon Events in the event logs of the workstation.
Last updated