Sysmon
Utilize Sysmon to monitor and log your endpoints and environments.
Sysmon Overview
Sysmon (System Monitor) is a tool used to monitor and log Windows Events. This monitoring and logging solution is commonly used by enterprises as it has further detail and granular control that Windows Event Logs.
Sysmon is a Windows system service and device driver that will remain resident across system reboots to monitor and log system activity to Windows event log by providing detailed information about process creations, network connections, and changes to file creation file. By collecting the generated events using Windows Event Collection or SIEM agents and subsequently analyzing them to identify malicious or anomalous activity and understand how intruders and malware operate on a network.
Additional to detailed and high-quality logs, Sysmon gathers event tracing that assists in identifying anomalies in the environment and will start early in the boot process.
Events within Sysmon are stored in Applications and Services Logs/Microsoft/Windows/Sysmon/Operational
Sysmon Config Overview
A config file is required for Sysmon to tell the binary how to analyze the events it receives. This config file can be downloaded or created, such as the one here. Sysmon includes 29 different types of Event IDs, all of which can be used within the config to specify how the events should be handled and analyzed.
A majority of rules in sysmon-config will exclude rather than include events which is noticable when creating or modifying configuration files. This helps to filter out normal activity in the environment to decrease events and alerts that may be manually audited or searched in a SIEM.
Alternately, there are rulesets such as ION-Storm sysmon-config fork that takes a more proactive approach with it's ruleset by using considerable amount of include rules. Configuration preferences will vary depending on the SOC team so flexibility is important when monitoring.
Event ID 1: Process Creation
This event will look for any processes that have been created to look for known suspicious processes or processes with typos that would be considered an anomaly. This event will use the CommandLine and Image XML tags.
The code above is specifying the Event ID to pull from as well as what condition to look for. In this case, it is excluding the svchost.exe process from the event logs.
Event ID 3: Network Connection
The network connection event will look for events that occur remotely. This will include files and sources of suspicious binaries as well as opened ports. This event will use the Image and DestinationPort XML tags.
This code snippet includes two ways to identify suspicious network connection activity. The first way will identify files transmitted over open ports. In this case, specifically looking for nmap.exe which will be reflected within the event logs. The second method identifies open ports and specifically port 4444 which is commonly used with Metasploit. If the condition is met an event will be created and ideally trigger an alert for the SOC to further investigate.
Event ID 7: Image Loaded
This event will look for DLLs loaded by processes, which is useful when hunting for DLL Injection and DLL Hijacking attacks. It is recommended to exercise caution when using this Event ID as it causes a high system load. This event will use the Image, Signed, ImageLoaded, and Signature XML tags.
This ill look for any DLLs that have been loaded within the \Temp\ directory. If a DLL is loaded within this directory it can be considered an anomaly and should be further investigated.
Event ID 8: CreateRemoteThread
The CreateRemoteThread Event ID will monitor for processes injecting code into other processes. The CreateRemoteThread function is used for legitimate tasks and applications. However, it could be used by malware to hide malicious activity. This event will use the SourceImage, TargetImage, StartAddress, and StartFunction XML tags.
This code shows two ways of monitoring for CreateRemoteThread. The first method will look at the memory address for a specific ending condition which could be an indicator of a Cobalt Strike beacon. The second method will look for injected processes that do not have a parent process. This should be considered an anomaly and require further investigation.
Event ID 11: File Created
This event ID is will log events when files are created or overwritten the endpoint. This could be used to identify file names and signatures of files that are written to disk. This event uses TargetFilename XML tags.
The above code snippet is an example of a ransomware event monitor. This is just one example of a variety of different ways to utilize Event ID 11.
Event ID 12 / 13 / 14: Registry Event
This event looks for changes or modifications to the registry. Malicious activity from the registry can include persistence and credential abuse. This event uses TargetObject XML tags.
The above code snippet will look for registry objects that are in the "Windows\System\Scripts" directory as this is a common directory for adversaries to place scripts to establish persistence.
Event ID 15: FileCreateStreamHash
This event will look for any files created in an alternate data stream. This is a common technique used by adversaries to hide malware. This event uses TargetFilename XML tags.
The above code snippet will look for files with the .hta extension that have been placed within an alternate data stream.
Event ID 22: DNS Event
This event will log all DNS queries and events for analysis. The most common way to deal with these events is to exclude all trusted domains known to be very common "noise" in the environment. Once rid of the noise, look for DNS anomalies. This event uses QueryName XML tags.
The above code snippet will get exclude any DNS events with the .microsoft.com query. This will get rid of the noise within the environment.
Installing and Preparing Sysmon
Installing Sysmon
The installation for Sysmon only requires downloading the Sysmon binary from the Microsoft Sysinternals website.Moreover, download all of the Sysinternals tools with a PowerShell command instead of grabbing a single binary. It is also recommended to use a Sysmon config file along with Sysmon to get more detailed and high-quality event tracing.
Download the Microsoft Sysinternal Suite or use the below command to run a PowerShell module download and install all of the Sysinternals tools.
PowerShell command: Download-SysInternalsTools C:\Sysinternals
To fully utilize Sysmon, download or creat aSysmon config: SwiftOnSecurity sysmon-config.
A Sysmon config will allow for further granular control over the logs as well as more detailed event tracing. These demonstrations will use both the SwiftOnSecurity configuration file as well as the ION-Storm config file.
Starting Sysmon
To start Sysmon, open a new PowerShell or Command Prompt as an Administrator. Run the below command to execute the Sysmon binary, accept the end-user license agreement, and use SwiftOnSecurity config file.
Command Used: Sysmon.exe -accepteula -i ..\Configuration\swift.xml
Now that Sysmon is started with the configuration file, look at the Event Viewer to monitor events. The event log is located under Applications and Services Logs/Microsoft/Windows/Sysmon/Operational
Note: At any time you can change the configuration file used by uninstalling or updating the current configuration and replacing it with a new configuration file. For more information look through the Sysmon help menu.
Cutting out the Noise
Malicious Activity Overview
Most normal activity or "noise" seen on a network is excluded or filtered out with Sysmon, allowing for focus toward meaningful events to quickly identify and investigate suspicious activity. Best practice is to use multiple detections and techniques simultaneously in an effort to identify threats when actively monitoring a network.
Sysmon "Best Practices"
Because Sysmon offers a fairly open and configurable platform, there are ways to implement practices to ensure efficient operations and not missing an potential threats.
Exclude > Include
Prioritize excluding event rather than including events when creating Sysmon rules to prevent from accidentally missing crucial events and only seeing the events that matter the most.
CLI gives you further control
CLI gives the most control and filtering allowing for further granular control. Use Get-WinEvent or wevutil.exe to access and filter logs. These tools will be less used/needed as Sysmon is incorporated into SIEMs and other detection solutions.
Know the environment before implementation
When implementing a platform or tool, it is important to know your environment and have a firm understanding of the network for baselining activity and effectively crafting rules for suspicious activity.
Filtering Events with Event Viewer
Event Viewer may not be the best for filtering events and out-of-the-box offers limited control over logs. The main filter used with Event Viewer filters the EventID and keywords and filter by writing XML can also be chosen but is a tedious process that doesn't scale well.
To open the filter menu select Filter Current Log from the Actions menu.
If the filter menu is successfully opened, it should look like the menu below:
From this menu, any filters or categories can be added.
Filtering Events with PowerShell
To view and filter events with PowerShell using Get-WinEvent along with XPath queries, use any XPath queries that can be found in the XML view of events. wevutil.exe will be used to view events once filtered. The command line is typically used over the Event Viewer GUI as it allows for further granular control and filtering whereas the GUI does not. For more information about using Get-WinEventand wevutil.exe check out the Windows Event Log notes.
Filter by Event ID: */System/EventID=<ID>
Filter by XML Attribute/Name: */EventData/Data[@Name="<XML Attribute/Name>"]
Filter by Event Data: */EventData/Data=<Data>
We can put these filters together with various attributes and data to get the most control out of our logs. Look below for an example of using Get-WinEvent to look for network connections coming from port 4444.
How many event ID 3 events are in C:\Users\THM-Analyst\Desktop\Scenarios\Practice\Filtering.evtx?
What is the UTC time created of the first network event in C:\Users\THM-Analyst\Desktop\Scenarios\Practice\Filtering.evtx?
Hunting Metasploit
Hunting Metasploit
Metasploit is an exploit framework used to run exploits on a machine for penetration testing and red team operations to connect back to a meterpreter shell. To hunt the meterpreter shell and it's functionality, begin looking for connections that originate from suspicious ports such as 4444 and 5555. Metasploit using port 4444 by default and any IP connected to this port should be investigated. To begin an investigation, examine packet captures from the date of the log as well as suspicious processes that were created. This hunting method can be applied to other RATs and C2 beacons.
For more information about how malware and payloads interact with the network check out the Malware Common Ports Spreadsheet.
Hunting Network Connections
This modified Ion-Security configuration to detect the creation of new network connections and will use event ID 3 along with the destination port to identify active connections specifically connections on port 4444 and 5555.
Now that the event is identified, it can provide some important information for further investigation like the ProcessID and Image.
Hunting for Open Ports with PowerShell
Powershell module Get-WinEvent and XPath queries can be used to hunt for open ports. The same queries used to filter out event from NetworkConnect with DestinationPort can use used in the instance.
Get-WinEvent -Path -FilterXPath '*/System/EventID=3 and */EventData/Data[@Name="DestinationPort"] and */EventData/Data=4444'
The script is first filtering by Event ID 3 which is the network connection ID. It is then filtering by the data name (in this case DestinationPort) as well as the specific port to filter. Adjust this syntax along with the events to get the data wanted in return.
Detecting Mimikatz
Detecting Mimikatz Overview
Although it is mainly known for dumping LSASS, Mimikatz is used to dump credentials from memory along with other Windows post-exploitation activity. Mimikatz creates a file, executes it from elevated process, creates a remote thread and other processes that can all be hunted. Anti-Virus typically finds the Mimikatz signature unless it is obfuscated or a dropper is used to get the file on to the device.
Detecting File Creation
To begin hunting for Mimikatz, look for files created with the the name "Mimikatz". This simple techniques allows for finding anything that might have bypassed Anti-Virus. While this technique is useful, dealing with an advanced threat will require more advanced techniques stuch as searching for LSASS behavior.
This is a very simple way of detecting Mimikatz activity that has bypassed AV or other detection measures.
This method will not be commonly used to hunt for anomalies.
Hunting Abnormal LSASS Behavior
To hunt for abnormal LSASS behavior, use the ProcessAccess event ID as this event along with LSASS will shoiw potential LSASS abuse usually connected to Mimikatz or other credential dumping tools.
If LSASS is accessed by a process other than svchost.exe, it should be considered suspicious behavior and further investigated. To aid in the search, use a filter to look for processes besides svchost.exe. Sysmon will provide further details such as the file path the process originated from to help lead investigations.
Below is a snippet of the config that will aid in the hunt.
The event that has the Mimikatz process accessed but svchost.exe events are also shown. Alter the config to exclude events with the SourceImage event coming from svhost.exe.
Modifying the configuration file to include this exception to cut down events significantly and focus on only the anomalies is a technique can be used throughout Sysmon and events to cut down on "noise" in logs.
Detecting LSASS Behavior with PowerShell
Powershell module Get-WinEvent and XPath queries can be used to detect abnormal LSASS behavior. The same queries used to filter out other processes from TargetImage can use used in the instance as this alongside a well-built configuration file with a precise rule will do a lot of the heavy lifting.
Get-WinEvent -Path -FilterXPath '*/System/EventID=10 and */EventData/Data[@Name="TargetImage"] and */EventData/Data="C:\Windows\system32\lsass.exe"'
Hunting Malware
Hunting Malware Overview
Remote Access Trojans (RATs) are used to gain remote access to a machine and come with AV and detection evasion techniques. A RAT may use a Client-Server model and comes with an interface for easy user administration. Some RAT examples are Xeexe and Quasar.
To detect and hunt malware, first identify the malware and ways to modify the configuration files as a technique called hypothesis-based hunting.
Hunting Rats and C2 Servers
One useful technique for detecting open ports on an endpoint that are known to be suspicious is to include them in logs. This will add to the hunting methodology as the logs can be used to identify adversaries on the network with the help of packet captures or other detection strategies for continued investigation.
The code below is from the Ion-Storm configuration file which will alert when specific ports like 1034 and 1604 are being used as well as exclude common network connections like OneDrive. Excluding events will cut down on noise without missing anything.
When using configuration files in a production environment, be careful and understand exactly what is happening within the configuration file an example of this is the Ion-Storm configuration file excludes port 53 as an event. Attackers and adversaries have begun to use port 53 as part of their malware/payloads which would go undetected if this this configuration file is blindly used as-is.
For more information about the ports that this configuration file alerts on check out this spreadsheet.
Hunting for Common Back Connect Ports with PowerShell
Get-WinEvent -Path -FilterXPath '*/System/EventID=3 and */EventData/Data[@Name="DestinationPort"] and */EventData/Data='
Powershell module Get-WinEvent and XPath queries can be used to filter events and gain granular control over logs. The same queries used to filter out event from NetworkConnect with DestinationPort can use used in the instance.
Hunting Persistence
Persistence Overview
To maintain access to a compromised machine, an attacker will need to gain persistence which can be done in a multitude of ways. Sysmon can be used to hunt persistence by looking for File Creation and Registry Modification events.
Hunting Startup Persistence
Below is a snippet of the config that will aid in event tracing for this technique looking at the SwiftOnSecurity detections for a file being placed in the \Startup\ or \Start Menu directories.
Via Event Viewer it is shown that persist.exe was placed in the Startup folder. Threat Actors will almost never be this obvious but any changes to the Start Menu should be investigated. Adjustments to the configuration file can be made to be more granular and create alerts past just the File Created tag.
Once it has been identified that a suspicious binary or application has been placed in a startup location, an investigation can begin on the directory.
Hunting Registry Key Persistence
This SwiftOnSecurity detection looks for a registry modification that adjusts and places a script inside CurrentVersion\Windows\Run and other registry locations.
Event logs show the registry was modified and malicious.exe was added to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\Persistence while the exe can be found at %windir%\System32\malicious.exe
Like the startup technique, filter by the RuleName T1060 to make finding the anomaly easier.
To investigate this anomaly, look at the registry as well as the file location itself. Below is the registry area where the malicious registry key was placed.
Detecting Evasion Techniques
Evasion Techniques Overview
Examples of evasion techniques used by malware authors:
Alternate Data Streams - Used to hid its files from normal inspection by saving the file in a different stream apart from
$DATAInjections - Thread Hijacking, PE Injection, DLL Injection, etc
Masquerading
Packing/Compression
Recompiling
Obfuscation
Anti-Reversing
Sysmon comes with an event ID to detect newly created and accessed streams allowing for quick detection and hunting malware that uses ADS.
DLL Injection and backdooring DLLs is done by taking an already used DLL used by an application and overwriting or including malicious code within the DLL.
Hunting Alternate Data Streams
Event ID 15 will hash and log any NTFS Streams included within the Sysmon configuration file, allowing for hunting malware that evades detections using ADS.
The code snippet below will hunt for files in the Temp and Startup folder as well as .hta and .bat extension.
The event will show the location of the file name as well as the contents of the file this will be useful if an investigation is necessary.
Detecting Remote Threads
Adversaries' use of remote threads is common to evade detections alongside other techniques. Remote threads are created using Windows API CreateRemoteThread and can be accessed using OpenThread and ResumeThread. Knowing this, these techniques are used in evasion for DLL Injection, Thread Hijacking, and Process Hollowing.
The code snippet below uses Sysmon event ID 8 from the SwiftOnSecurity configuration rule which will exclude common remote threads without including any specific attributes this allows for a more open and precise event rule.
powershell.exe is creating a remote thread and accessing notepad.exe. This is an obvious PoC and could in theory execute any other kind of executable or DLL. The specific technique used in this example is called Reflective PE Injection.
Detecting Evasion Techniques with PowerShell
Powershell module Get-WinEvent and XPath queries can be used to filter and search for files that use an alternate data stream or create a remote thread. The same query only needs to filter by the EventID because the rule used within the configuration file is already doing a majority of the heavy lifting.
Detecting Remote Thread Creation
Get-WinEvent -Path <Path to Log> -FilterXPath '*/System/EventID=8'
Practical Investigations
Investigation 1 - ugh, BILL THAT'S THE WRONG USB!
What is the full registry key of the USB device calling svchost.exe in Investigation 1?
What is the device name when being called by RawAccessRead in Investigation 1?
What is the first exe the process executes in Investigation 1?
Investigation 2 - This isn't an HTML file?
What is the full path of the payload in Investigation 2?
What is the full path of the file the payload masked itself as in Investigation 2?
What signed binary executed the payload in Investigation 2?
What is the IP of the adversary in Investigation 2?
What back connect port is used in Investigation 2?
Investigation 3.1 - 3.2 - Where's the bouncer when you need him
What is the IP of the suspected adversary in Investigation 3.1?
What is the hostname of the affected endpoint in Investigation 3.1?
What is the hostname of the C2 server connecting to the endpoint in Investigation 3.1?
Where in the registry was the payload stored in Investigation 3.1?
What PowerShell launch code was used to launch the payload in Investigation 3.1?
What is the IP of the adversary in Investigation 3.2?
What is the full path of the payload location in Investigation 3.2?
What was the full command used to create the scheduled task in Investigation 3.2?
What process was accessed by schtasks.exe that would be considered suspicious behavior in Investigation 3.2?
Investigation 4 - Mom look! I built a botnet!
What is the IP of the adversary in Investigation 4?
What port is the adversary operating on in Investigation 4?
What C2 is the adversary utilizing in Investigation 4?
Last updated
