Windows Event Logs & Finding Evil

Event logs can be accessed using the Event Viewer application or programmatically using APIs such as the Windows Event Log API.

"Forwarded Events" section is unique, showcasing event log data forwarded from other machines.

1. Log Name: The name of the event log (e.g., Application, System, Security, etc.).

2. Source: The software that logged the event.

3. Event ID: A unique identifier for the event.

4. Task Category: This often contains a value or name that can help us understand the purpose or use of the event.

5. Level: The severity of the event (Information, Warning, Error, Critical, and Verbose).

6. Keywords: Keywords are flags that allow us to categorize events in ways beyond the other classification options. These are generally broad categories, such as "Audit Success" or "Audit Failure" in the Security log.

7. User: The user account that was logged on when the event occurred.

8. OpCode: This field can identify the specific operation that the event reports.

9. Logged: The date and time when the event was logged.

10. Computer: The name of the computer where the event occurred.

11. XML Data: All the above information is also included in an XML format along with additional event data.

4624(S) An account was successfully logged on. - Windows SecurityMicrosoftLearn

"Filter Current Log" -> "XML" -> "Edit Query Manually"

Advanced XML filtering in the Windows Event ViewerTECHCOMMUNITY.MICROSOFT.COM

4907(S) Auditing settings on object were changed. - Windows SecurityMicrosoftLearn

https://learn.microsoft.com/en-us/windows/win32/secauthz/access-control-listslearn.microsoft.com

Audit Generation - Win32 appsMicrosoftLearn

SACL Access Right - Win32 appsMicrosoftLearn

ACE Strings - Win32 appsMicrosoftLearn

Understanding SDDL SyntaxIT Connect

Privilege Constants (Winnt.h) - Win32 appsdocsmsft

useful Windows event logs.

1. Windows System Logs

   • Event ID 1074 (System Shutdown/Restart): This event log indicates when and why the system was shut down or restarted. By monitoring these events, you can determine if there are unexpected shutdowns or restarts, potentially revealing malicious activity such as malware infection or unauthorized user access.
   • Event ID 6005 (The Event log service was started): This event log marks the time when the Event Log Service was started. This is an important record, as it can signify a system boot-up, providing a starting point for investigating system performance or potential security incidents around that period. It can also be used to detect unauthorized system reboots.
   • Event ID 6006 (The Event log service was stopped): This event log signifies the moment when the Event Log Service was stopped. It is typically seen when the system is shutting down. Abnormal or unexpected occurrences of this event could point to intentional service disruption for covering illicit activities.
   • Event ID 6013 (Windows uptime): This event occurs once a day and shows the uptime of the system in seconds. A shorter than expected uptime could mean the system has been rebooted, which could signify a potential intrusion or unauthorized activities on the system.
   • Event ID 7040 (Service status change): This event indicates a change in service startup type, which could be from manual to automatic or vice versa. If a crucial service's startup type is changed, it could be a sign of system tampering.
2. Windows Security Logs

   • Event ID 1102 (The audit log was cleared): Clearing the audit log is often a sign of an attempt to remove evidence of an intrusion or malicious activity.
   • Event ID 1116 (Antivirus malware detection): This event is particularly important because it logs when Defender detects a malware. A surge in these events could indicate a targeted attack or widespread malware infection.
   • Event ID 1118 (Antivirus remediation activity has started): This event signifies that Defender has begun the process of removing or quarantining detected malware. It's important to monitor these events to ensure that remediation activities are successful.
   • Event ID 1119 (Antivirus remediation activity has succeeded): This event signifies that the remediation process for detected malware has been successful. Regular monitoring of these events will help ensure that identified threats are effectively neutralized.
   • Event ID 1120 (Antivirus remediation activity has failed): This event is the counterpart to 1119 and indicates that the remediation process has failed. These events should be closely monitored and addressed immediately to ensure threats are effectively neutralized.
   • Event ID 4624 (Successful Logon): This event records successful logon events. This information is vital for establishing normal user behavior. Abnormal behavior, such as logon attempts at odd hours or from different locations, could signify a potential security threat.
   • Event ID 4625 (Failed Logon): This event logs failed logon attempts. Multiple failed logon attempts could signify a brute-force attack in progress.
   • Event ID 4648 (A logon was attempted using explicit credentials): This event is triggered when a user logs on with explicit credentials to run a program. Anomalies in these logon events could indicate lateral movement within a network, which is a common technique used by attackers.
   • Event ID 4656 (A handle to an object was requested): This event is triggered when a handle to an object (like a file, registry key, or process) is requested. This can be a useful event for detecting attempts to access sensitive resources.
   • Event ID 4672 (Special Privileges Assigned to a New Logon): This event is logged whenever an account logs on with super user privileges. Tracking these events helps to ensure that super user privileges are not being abused or used maliciously.
   • Event ID 4698 (A scheduled task was created): This event is triggered when a scheduled task is created. Monitoring this event can help you detect persistence mechanisms, as attackers often use scheduled tasks to maintain access and run malicious code.
   • Event ID 4700 & Event ID 4701 (A scheduled task was enabled/disabled): This records the enabling or disabling of a scheduled task. Scheduled tasks are often manipulated by attackers for persistence or to run malicious code, thus these logs can provide valuable insight into suspicious activities.
   • Event ID 4702 (A scheduled task was updated): Similar to 4698, this event is triggered when a scheduled task is updated. Monitoring these updates can help detect changes that may signify malicious intent.
   • Event ID 4719 (System audit policy was changed): This event records changes to the audit policy on a computer. It could be a sign that someone is trying to cover their tracks by turning off auditing or changing what events get audited.
   • Event ID 4738 (A user account was changed): This event records any changes made to user accounts, including changes to privileges, group memberships, and account settings. Unexpected account changes can be a sign of account takeover or insider threats.
   • Event ID 4771 (Kerberos pre-authentication failed): This event is similar to 4625 (failed logon) but specifically for Kerberos authentication. An unusual amount of these logs could indicate an attacker attempting to brute force your Kerberos service.
   • Event ID 4776 (The domain controller attempted to validate the credentials for an account): This event helps track both successful and failed attempts at credential validation by the domain controller. Multiple failures could suggest a brute-force attack.
   • Event ID 5001 (Antivirus real-time protection configuration has changed): This event indicates that the real-time protection settings of Defender have been modified. Unauthorized changes could indicate an attempt to disable or undermine the functionality of Defender.
   • Event ID 5140 (A network share object was accessed): This event is logged whenever a network share is accessed. This can be critical in identifying unauthorized access to network shares.
   • Event ID 5142 (A network share object was added): This event signifies the creation of a new network share. Unauthorized network shares could be used to exfiltrate data or spread malware across a network.
   • Event ID 5145 (A network share object was checked to see whether client can be granted desired access): This event indicates that someone attempted to access a network share. Frequent checks of this sort might indicate a user or a malware trying to map out the network shares for future exploits.
   • Event ID 5157 (The Windows Filtering Platform has blocked a connection): This is logged when the Windows Filtering Platform blocks a connection attempt. This can be helpful for identifying malicious traffic on your network.
   • Event ID 7045 (A service was installed in the system): A sudden appearance of unknown services might suggest malware installation, as many types of malware install themselves as services.

xfreerdp /u:Administrator /p:'password' /v:10.10.101.10 /dynamic-resolutio

Create a Custom ViewMicrosoftLearn

Event Queries and Event XMLMicrosoftLearn

Consuming Events (Windows Event Log) - Win32 appsMicrosoftLearn

Sysmon Basics

Event ID 4624 provides insights into new logon events

Event ID 4688 furnishes information about newly created processes

System Monitor (Sysmon) is a Windows system service and device driver that remains resident across system reboots to monitor and log system activity to the Windows event log.Sysmon provides:

1. detailed information about process creation

2. network connections

3. changes to file creation time

4. more

Event ID 1 corresponds to "Process Creation" events

Event ID 3 refers to "Network Connection" events

Sysmon - Sysinternalsdocsmsft

Sysmon uses an XML-based configuration file

C:\Tools\Sysmon> sysmon.exe -c filename.xml

C:\Tools\Sysmon> sysmon.exe -i -accepteula -h md5,sha256,imphash -l -n

Detect a DLL hijack

To detect a DLL hijack, we need to focus on Event Type 7

Sysmon - Sysinternalsdocsmsft

1. Download https://github.com/SwiftOnSecurity/sysmon-config
2. modify the sysmonconfig-export.xml

3. "include" comment signifies events that should be included

   1. 
4. DLL hijacks change the "include" to "exclude" to ensure that nothing is excluded to capture the necessary data

   1. 

<!--SYSMON EVENT ID 7 : DLL (IMAGE) LOADED BY PROCESS [ImageLoad]-->
		<!--COMMENT:	Can cause high system load, disabled by default.-->
		<!--COMMENT:	[ https://attack.mitre.org/wiki/Technique/T1073 ] [ https://attack.mitre.org/wiki/Technique/T1038 ] [ https://attack.mitre.org/wiki/Technique/T1034 ] -->

		<!--DATA: UtcTime, ProcessGuid, ProcessId, Image, ImageLoaded, Hashes, Signed, Signature, SignatureStatus-->
	<RuleGroup name="" groupRelation="or">
		<ImageLoad onmatch="include">
			<!--NOTE: Using "include" with no rules means nothing in this section will be logged-->
		</ImageLoad>
	</RuleGroup>

1. C:\Tools\Sysmon> sysmon.exe -c sysmonconfig-export.xml

   1. 
2. Event Viewer and access "Applications and Services" -> "Microsoft" -> "Windows" -> "Sysmon."

   1. 
   2. 

Hijacking DLLs in Windows

DLL Hijacking is a popular technique for executing malicious payloads."calc.exe" and "WININET.dll" as an example

https://github.com/stephenfewer/ReflectiveDLLInjection/tree/master/bin

1. Download reflective_dll.x64.dll

2. Rename reflective_dll.x64.dll to WININET.dll

3. Move calc.exe from C:\Windows\System32 to a writable directory

4. Move WININET.dll to a writable directory

5. Execute calc.exe

6. Instead of the Calculator application, a MessageBox is displayed.

1. Analyze the impact of the hijack.

   1. Filter the event logs to focus on Event ID 7

      1. Filter Current Log

1. search for instances of "calc.exe"

   1. Click "Find"

   2. Identify the DLL load associated with hijack

we can observe several indicators of compromise (IOCs) to create effective detection rules.

Compare this to an authenticate load of "wininet.dll" by "calc.exe".

1. Compare:

   1. Image:

   2. ImageLoaded:

   3. FileVersion:

   4. Description:

   5. Product:

   6. Company:

   7. OriginalFileName:

   8. Hashes

   9. Signed:

   10. Signature:

   11. SignatureStatus:

1. IOC:

   1. "calc.exe", originally located in System32

      1. should not be found in a writable directory

         1. should always reside in System32

         2. potentially Syswow64

   2. "WININET.dll", originally located in System32

      1. should not be loaded outside of System32 by calc.exe

"WININET.dll" loading occur outside of System32 with "calc.exe" as the parent process indicates a DLL hijack within calc.exe.

1. Original "WININET.dll" is Microsoft-signed, while our injected DLL remains unsigned.

Detecting Unmanaged PowerShell/C-Sharp Injection

C# requires a backend runtime to execute its code.

Common Language Runtime (CLR) overview - .NETMicrosoftLearn

What is managed code? - .NETMicrosoftLearn

detect unusual C# injections or executions within our environment

Overview - Process Hacker

Hovering over powershell.exe reveals the label "Process is managed (.NET)," confirming its managed status.

Examining the module loads for powershell.exe, by right-clicking on powershell.exe, clicking "Properties", and navigating to "Modules", we can find relevant information. The presence of "Microsoft .NET Runtime...", clr.dll, and clrjit.dll should attract our attention.

Cobalt Strike 3.11 - The snake that eats its tail | Cobalt StrikeCobalt Strike

GitHub - leechristensen/UnmanagedPowerShell: Executes PowerShell from an unmanaged processGitHub

GitHub - EmpireProject/PSInject: Inject PowerShell into any processGitHub