Resources:

Sysmon Event ID Reference

  • Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -FilterXPath "*[System[(EventID=1)]]": This cmdlet fetches the Sysmon logs from the specified log file where the Event ID is 1.
  • ForEach-Object { ... }: This cmdlet processes each event log entry.
  • $_: Represents the current event log entry object.
  • $_Properties[4]: Accesses the fifth property of the current event log entry, which corresponds to the image name.
  • .Value: Retrieves the actual value of that property.

All Sysmon Event IDs

  1. Event ID 1: Process Creation - Logs when a process is created. Includes details such as the process’s name, command line arguments, and the parent process.
  2. Event ID 2: File creation time changed - Logs when the creation time of a file is changed. Useful for detecting tampering or file timestamp modifications.
  3. Event ID 3: Network Connection - Logs when a network connection is initiated or terminated. Provides details such as source and destination IP addresses and ports.
  4. Event ID 4: Sysmon Service State Changed - Logs changes to the state of the Sysmon service (start, stop, etc.).
  5. Event ID 5: Process Terminated - Logs when a process terminates.
  6. Event ID 6: Driver Loaded - Logs when a driver is loaded. Includes the driver’s name and file hash.
  7. Event ID 7: Image Loaded - Logs when an image (DLL or EXE) is loaded. Includes the image’s name, hash, and signature information.
  8. Event ID 8: CreateRemoteThread - Logs when a remote thread is created. Can be indicative of process injection.
  9. Event ID 9: RawAccessRead - Logs when raw read access is performed on a volume.
  10. Event ID 10: ProcessAccess - Logs when a process requests access to another process.
  11. Event ID 11: FileCreate - Logs when a file is created or overwritten.
  12. Event ID 12: RegistryEvent (Object create and delete) - Logs when a registry object (key or value) is created or deleted.
  13. Event ID 13: RegistryEvent (Value Set) - Logs when a registry value is set or modified.
  14. Event ID 14: RegistryEvent (Key and Value Rename) - Logs when a registry key or value is renamed.
  15. Event ID 15: FileCreateStreamHash - Logs when a stream is created in a file. Useful for detecting alternate data streams (ADS).
  16. Event ID 16: Sysmon Configuration Change - Logs when the Sysmon configuration is changed.
  17. Event ID 17: PipeEvent (Pipe Created) - Logs when a named pipe is created.
  18. Event ID 18: PipeEvent (Pipe Connected) - Logs when a connection is made to a named pipe.
  19. Event ID 19: WmiEvent (WmiEventFilter activity detected) - Logs when WMI filter activity is detected.
  20. Event ID 20: WmiEvent (WmiEventConsumer activity detected) - Logs when WMI consumer activity is detected.
  21. Event ID 21: WmiEvent (WmiEventConsumerToFilter activity detected) - Logs when a WMI consumer is bound to a filter.
  22. Event ID 22: DNSEvent (DNS query) - Logs when a DNS query is made.
  23. Event ID 23: FileDelete (File Delete archived) - Logs when a file deletion event is archived.
  24. Event ID 24: ClipboardChange (New clipboard content) - Logs when the content of the clipboard changes.
  25. Event ID 25: ProcessTampering (Process image change) - Logs when a process’s image is tampered with.
  26. Event ID 26: FileDeleteDetected (File Delete logged) - Logs when a file delete operation is detected.

Listing Sysmon Event Properties

# Retrieve Sysmon events from the Operational log
$sysmonEvents = Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 10

# Loop through each event and list its properties
foreach ($event in $sysmonEvents) {
    Write-Output "Event ID: $($event.Id)"
    Write-Output "Properties:"
    foreach ($property in $event.Properties) {
        Write-Output " - $($property.Value)"
    }
    Write-Output ""
}

Task 1. Has msbuild executed malware on the machine?

To begin with, we will look at Sysmon logs to attempt to answer the question at hand. A generic hunt is to look for any process creation, where the image of the process contains “msbuild.exe”:

To parse the logs using PowerShell and search for the presence of MSBuild, use the following PowerShell command (“$_Properties[4]” refers to the Image name field in Sysmon log with Event ID 1):

Get-WinEvent -FilterHashtable @{logname="Microsoft-Windows-Sysmon/Operational"; id=1} | Where-Object {$_.Properties[4].Value -like "*msbuild*"} | fl

PowerShell returns no results. Was this it?

The filename itself, alone, is a weak indicator as its easy to circumvent by simply renaming it. There are other options available, ranging from the file hash, other known fields or parameters. Observing MSBuild on a regular Windows 10 machine, we’ll notice that the “Description” field is set to “MSBuild.exe”. Let’s utilize PowerShell and look for that in our data set (“$_Properties[6]” represents to the Description field in Sysmon log with Event ID 1):

Get-WinEvent -FilterHashtable @{logname="Microsoft-Windows-Sysmon/Operational"; id=1} | Where-Object {$_.Properties[6].Value -like "*msbuild*"} | fl

Note that the binary image is “C:\Users\Public\Downloads\Windows_Reporting.exe” which starts with a command line parameter of “Windows_Reporting.xml”.

Task 2. What was the initial stager?

Search for the presence of CMD (Command Prompt), use the following PowerShell command (“$_Properties[4]” refers to the Image name field in Sysmon log with Event ID 1): now focusing on the ParentImage and ParentCommandLine parameters:

Get-WinEvent -FilterHashtable @{logname="Microsoft-Windows-Sysmon/Operational"; id=1} | Where-Object {$_.Properties[4].Value -like "*Cmd*"} | fl

The parent image is “mshta.exe”, which has executed “report.hta”. Based on the temporary location (of Microsoft Edge), we can conclude that the file was executed in a browser, which then started Windows_Reporting.exe.

The initial stager is an HTA file, however we are still not sure how and/or why MSBuild is renamed to Windows_Reporting.exe and located in an odd location.

Task 3. How was the malware downloaded? Why did the attacker choose this method?

Let’s begin tracing backwards - so far we know that MSBuild is present in an odd location under different name, and that an HTA file was used to execute the file. Since we know the file is called “Windows_Reporting.exe”, let’s look at all process creation events that have referenced this file with the following command (“$_.Properties[10]” represents to the CommandLine field in Sysmon log with Event ID 1):

Get-WinEvent -FilterHashtable @{logname="Microsoft-Windows-Sysmon/Operational"; id=1} | Where-Object {$_.Properties[10].Value -like "*Windows_Reporting.exe*"} | fl

Observing the output, we note that an event entry has logged the same HTA file copying MSBuild to C:\Users\Public\Downloads\Windows_Reporting.exe.

From the first task, we know that Windows_Reporting.exe was executed with command line argument of “Windows_Reporting.xml”. To find out how that XML file was created, we will look into Sysmon event 11 - File create event. Execute the following command (“$_.Properties[5]” represents to the TargetFilename field in Sysmon log with Event ID 11):

Get-WinEvent -FilterHashtable @{logname="Microsoft-Windows-Sysmon/Operational"; id=11} | Where-Object {$_.Properties[5].Value -like "*Windows_Reporting.xml*"} | fl

Note that the file was created by “certutil.exe”. Let’s review the information that ATT&CK has on certutil.exe. It states “certutil can be used to download files from a given URL”. Following this information, we can dig up process creation events with certutil.exe with the following command:

Get-WinEvent -FilterHashtable @{logname="Microsoft-Windows-Sysmon/Operational"; id=1} | Where-Object {$_.Properties[4].Value -like "*certutil.exe*"} | fl

It appears that certutil.exe was utilized to download the XML file from http://52.77.211.51:8443.

The attacker has chosen to “Live off the land”, presumably to avoid detection and throw off analysts by renaming MSBuild into a file, seemingly looking like a Windows tool.

Task 4. What was the attacker’s IP and Port?

Reviewing the discovered Windows_Reporting.xml reveals the attacker’s C2 IP and Port.

The same can be observed by Sysmon logs, in particular event id 3 filtering for Windows_Reporting.exe with the following command:

Get-WinEvent -FilterHashtable @{logname="Microsoft-Windows-Sysmon/Operational"; id=3} | Where-Object {$_.Properties[4].Value -like "*Windows_Reporting.exe*"} | fl
Get-WinEvent -FilterHashtable @{logname="Microsoft-Windows-Sysmon/Operational"; id=3} | Where-Object {$_.Properties[4].Value -like "*Windows_Reporting.exe*"} | fl | measure

Overall, there are 51 connections.

Task 5. What known .NET offensive tools were executed?

NOTE - logs are continuous and excessive, and they may get overwritten. Make sure to revert the machine to its original state when starting this task. Ideally, disable “SilkService”.

The machine is preset to log .NET activity. As hinted in the task itself, we’ll focus on detection of GhostPack. FuzzySec released detection rules in his talk in Black Hat in this video. Utilizing the rules and/or variations of them, we locate the following event entry which confirms the usage of SeatBelt and its association to Windows_Reporting.exe.

Key Takeaways

  1. Robust detection rules as well as alternative/additional data sources are required to perform high quality hunts
  2. Adversaries often choose to hide in plain sight