Sysmon, a tool used to monitor and log events on Windows, is commonly used by enterprises as part of their monitoring and logging solutions. Part of the Windows Sysinternals package, Sysmon is similar to Windows Event Logs with further detail and granular control.
System Monitor (Sysmon) is a Windows system service and device driver that, once installed on a system, remains resident across system reboots to monitor and log system activity to the Windows event log. It provides detailed information about process creations, network connections, and changes to file creation time. By collecting the events it generates using Windows Event Collection or SIEM agents and subsequently analyzing them, you can identify malicious or anomalous activity and understand how intruders and malware operate on your network."
Note:Events within Sysmon are stored in Applications and Services Logs/Microsoft/Windows/Sysmon/Operational
Sysmon requires a config file in order to tell the binary how to analyze the events that it is receiving. You can create your own Sysmon config or you can download a config.
Example of a high-quality config that works well for identifying anomalies created by SwiftOnSecurity:
Sysmon-Config(Per creare un file sysmon config, si puo creare semplicemente con blocconote con estensione .xml, rispettando la sintassi)
This event will look for any processes that have been created. You can use this 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.
RuleGroup name="" groupRelation="or">
ProcessCreate onmatch="exclude">
CommandLine condition="is">C:\Windows\system32\svchost.exe -k appmodel -p -s camsvc
/ProcessCreate>
/RuleGroup>
The above code snippet 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.
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.
RuleGroup name="" groupRelation="or">
NetworkConnect onmatch="include">
Image condition="image">nmap.exe
DestinationPort name="Alert,Metasploit" condition="is">4444
/NetworkConnect>
/RuleGroup>
The above code snippet includes two ways to identify suspicious network connection activity. The first way will identify files transmitted over open ports. In this case, we are specifically looking for nmap.exe which will then 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.
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.
RuleGroup name="" groupRelation="or">
ImageLoad onmatch="include">
ImageLoaded condition="contains">\Temp\ < /ImageLoaded>
/ImageLoad>
/RuleGroup>
The above code snippet will 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 investigateded.
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.
RuleGroup name="" groupRelation="or">
CreateRemoteThread onmatch="include">
StartAddress name="Alert,Cobalt Strike" condition="end with">0B80 < /StartAddress>
SourceImage condition="contains">\ < /SourceImage>
/CreateRemoteThread>
/RuleGroup>
The above code snippet 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.
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.
RuleGroup name="" groupRelation="or">
FileCreate onmatch="include">
TargetFilename name="Alert,Ransomware" condition="contains">HELP_TO_SAVE_FILES < /TargetFilename>
/FileCreate>
/RuleGroup>
The above code snippet is an example of a ransomware event monitor. This is just one example of a variety of different ways you can utilize Event ID 11.
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.
RuleGroup name="" groupRelation="or">
RegistryEvent onmatch="include">
TargetObject name="T1484" condition="contains">Windows\System\Scripts < /TargetObject>
/RegistryEvent>
/RuleGroup>
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.
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.
RuleGroup name="" groupRelation="or">
FileCreateStreamHash onmatch="include">
TargetFilename condition="end with">.hta < /TargetFilename>
/FileCreateStreamHash>
/RuleGroup>
The above code snippet will look for files with the .hta extension that have been placed within an alternate data stream.
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 that you know will be very common "noise" in your environment. Once you get rid of the noise you can then look for DNS anomalies. This event uses QueryName XML tags.
RuleGroup name="" groupRelation="or">
DnsQuery onmatch="exclude">
QueryName condition="end with">.microsoft.com < /QueryName>
/DnsQuery>
/RuleGroup>
The above code snippet will get exclude any DNS events with the .microsoft.com query. This will get rid of the noise that you see within the environment.
Torna all'indice!Download-SysInternalsTools C:\Sysinternals)Sysmon.exe -accepteula -i ..\Configurations\swift.xmlLogs/Microsoft/Windows/Sysmon/OperationalThe main filter you will be using with Event Viewer is by filtering the EventID and keywords.
To view and filter events with PowerShell we will be using Get-WinEvent along with XPath queries. We can use any XPath queries that can be found in the XML view of events. We will be using wevutil.exe to view events once filtered.
*/System/EventID=< ID>< / ID> */EventData/Data[@Name="< XML Attribute/Name>"] */EventData/Data=< Data>< / Data>Get-WinEvent -Path -FilterXPath '*/System/EventID=3 and */EventData/Data[@Name="DestinationPort"] and */EventData/Data=4444'
Get-WinEvent -Path C:\Users\THM-Analyst\Desktop\Scenarios\Practice\Hunting_Metasploit.evtx -FilterXPath '*/System/EventID=3 and */EventData/Data[@Name="DestinationPort"] and */EventData/Data=4444'
Esempio: Conta Logs con ID 3
Get-WinEvent -Path "C:\Users\THM-Analyst\Desktop\Scenarios\Practice\Filtering.evtx" -FilterXPath '*/System/EventID=3' | Group-Object Id | Sort-Object Count
We will be hunting the meterpreter shell itself and the functionality it uses. To begin hunting we will look for network connections that originate from suspicious ports such as 4444 and 5555. By default, Metasploit uses port 4444. If there is a connection to any IP known or unknown it should be investigated. To start an investigation you can look at packet captures from the date of the log to begin looking for further information about the adversary. We can also look for suspicious processes created. This method of hunting can be applied to other various RATs and C2 beacons.
How malware and payloads interact with the network
We will first be looking at a modified Ion-Security configuration to detect the creation of new network connections. The code snippet below will use event ID 3 along with the destination port to identify active connections specifically connections on port 4444 and 5555.
< RuleGroup name="" groupRelation="or">
< NetworkConnect onmatch="include">
< DestinationPort condition="is">4444 < / DestinationPort >
< DestinationPort condition="is">5555 < / DestinationPort >
< / NetworkConnect>
< / RuleGroup>
Once we identify the event it can give us some important information we can use for further investigation like the ProcessID and Image.
To hunt for open ports with PowerShell we will be using the PowerShell module Get-WinEvent along with XPath queries. We can use the same XPath queries that we used in the rule to filter out events from NetworkConnect with DestinationPort
Get-WinEvent -Path "C:\Users\THM-Analyst\Desktop\Scenarios\Practice\Hunting_Metasploit.evtx" -FilterXPath '*/System/EventID=3 and */EventData/Data[@Name="DestinationPort"] and */EventData/Data=4444'
Poi Da EventViewer -> Details :
< Data Name="ProcessId">3660< / Data>
< Data Name="Image">C:\Users\THM-Threat\Downloads\shell.exe< / Data>
< Data Name="SourceIp">10.10.98.207< / Data>
< Data Name="SourcePort">50872< / Data>
< Data Name="DestinationIp">10.13.4.34< / Data>
< Data Name="DestinationHostname">ip-10-13-4-34.eu-west-1.compute.internal< / Data>
Mimikatz is well known and commonly used to dump credentials from memory along with other Windows post-exploitation activity. Mimikatz is mainly known for dumping LSASS. We can hunt for the file created, execution of the file from an elevated process, creation of a remote thread, and processes that Mimikatz creates.
For more information about this technique and the software used check out MITRE ATTACK T1055 and S0002.
The first method of hunting for Mimikatz is just looking for files created with the name Mimikatz.
This is a simple technique but can allow you to find anything that might have bypassed AV. Most of the time when dealing with an advanced threat you will need more advanced hunting techniques like searching for LSASS behavior but this technique can still be useful.
This is a very simple way of detecting Mimikatz activity that has bypassed anti-virus or other detection measures. But most of the time it is preferred to use other techniques like hunting for LSASS specific behavior. Below is a snippet of a config to aid in the hunt for Mimikatz.
< RuleGroup name="" groupRelation="or">
< FileCreate onmatch="include">
< TargetFileName condition="contains">mimikatz< / TargetFileName>
< / FileCreate>
< / RuleGroup>
As this method will not be commonly used to hunt for anomalies we will not be looking at any event logs for this specific technique.
We can use the ProcessAccess event ID to hunt for abnormal LSASS behavior. This event along with LSASS would show potential LSASS abuse which usually connects back to Mimikatz some other kind of credential dumping tool.
< RuleGroup name="" groupRelation="or">
< ProcessAccess onmatch="include">
< TargetImage condition="image">lsass.exe< / TargetImage>
< / ProcessAccess>
< / RuleGroup>
< RuleGroup name="" groupRelation="or">
< ProcessAccess onmatch="exclude">
< SourceImage condition="image">svchost.exe< / SourceImage>
< / ProcessAccess>
< ProcessAccess onmatch="include">
< TargetImage condition="image">lsass.exe< / TargetImage>
< / ProcessAccess>
< / RuleGroup>
By modifying the configuration file to include this exception we have cut down our events significantly and can focus on only the anomalies. This technique can be used throughout Sysmon and events to cut down on "noise" in logs.
To detect abnormal LSASS behavior with PowerShell we will again be using the PowerShell module Get-WinEvent along with XPath queries.
Get-WinEvent -Path -FilterXPath '*/System/EventID=10 and */EventData/Data[@Name="TargetImage"] and */EventData/Data="C:\Windows\system32\lsass.exe"'
Torna all'indice!
RAT = REMOTE ACCESS TROJANS
The two types of malware that we will be focusing on are RATs and backdoors. RATs or Remote Access Trojans are used similar to any other payload to gain remote access to a machine. RATs typically come with other Anti-Virus and detection evasion techniques that make them different than other payloads like MSFVenom. A RAT typically also uses a Client-Server model and comes with an interface for easy user administration. Examples of RATs are Xeexe and Quasar. To help detect and hunt malware we will need to first identify the malware that we want to hunt or detect and identify ways that we can modify configuration files, this is known as hypothesis-based hunting. There are of course a plethora of other ways to detect and log malware however we will only be covering the basic way of detecting open back connect ports.
The first technique we will use to hunt for malware is a similar process to hunting Metasploit. We can look through and create a configuration file to hunt and detect suspicious ports open on the endpoint. The code snippet below is from the Ion-Storm configuration file which will alert when specific ports like 1034 and 1604 as well as exclude common network connections like OneDrive, by excluding events we still see everything that we want without missing anything and cutting down on noise. When using configuration files in a production environment you must 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 you blindly used this configuration file as-is.
< RuleGroup name="" groupRelation="or">
< NetworkConnect onmatch="include">
< DestinationPort condition="is">1034< / DestinationPort>
< DestinationPort condition="is">1604< / DestinationPort>
< / NetworkConnect>
< NetworkConnect onmatch="exclude">
< Image condition="image">OneDrive.exe< / Image>
< / NetworkConnect>
< / RuleGroup>
We are detecting a custom RAT that operates on port 8080. This is a perfect example of why you want to be careful when excluding events in order to not miss potential malicious activity.
We will need to filter on the NetworkConnect event ID and the DestinationPort data attribute.
Get-WinEvent -Path -FilterXPath '*/System/EventID=3 and */EventData/Data[@Name="DestinationPort"] and */EventData/Data='
Torna all'indice!
Persistence is used by attackers to maintain access to a machine once it is compromised.
We can hunt persistence with Sysmon by looking for File Creation events as well as Registry Modification events.
We will first be looking at the SwiftOnSecurity detections for a file being placed in the \Startup\ or \Start Menu directories. Below is a snippet of the config that will aid in event tracing for this technique. For more information about this technique check out MITRE ATT&CK T1547.
< RuleGroup name="" groupRelation="or">
< FileCreate onmatch="include">
< TargetFilename name="T1023" condition="contains">\Start Menu< / TargetFilename>
< TargetFilename name="T1165" condition="contains">\Startup\< / TargetFilename>
< / FileCreate>
< / RuleGroup>
When looking at the Event Viewer we see that persist.exe was placed in the Startup folder. Threat Actors will almost never make it this obvious but any changes to the Start Menu should be investigated. You can adjust the configuration file to be more granular and create alerts past just the File Created tag. We can also filter by the Rule Name T1023
Once you have identified that a suspicious binary or application has been placed in a startup location you can begin an investigation on the directory.
We will again be looking at another SwiftOnSecurity detection this time for a registry modification that adjusts that places a script inside CurrentVersion\Windows\Run and other registry locations. For more information about this technique check out MITRE ATT&CK T1112.
< RuleGroup name="" groupRelation="or">
< RegistryEvent onmatch="include">
< TargetObject name="T1060,RunKey" condition="contains">CurrentVersion\Run< / TargetObject>
< TargetObject name="T1484" condition="contains">Group Policy\Scripts< / TargetObject>
< TargetObject name="T1060" condition="contains">CurrentVersion\Windows\Run< / TargetObject>
< / RegistryEvent>
< / RuleGroup>
When looking at the event logs we see that the registry was modified and malicious.exe was added to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\Persistence We also see that the exe can be found at %windir%\System32\malicious.exe
Torna all'indice!Some examples of evasion techniques are Alternate Data Streams, Injections, Masquerading, Packing/Compression, Recompiling, Obfuscation, Anti-Reversing Techniques.
In this task, we will be focusing on Alternate Data Streams and Injections. Alternate Data Streams are used by malware to hide its files from normal inspection by saving the file in a different stream apart from $DATA. Sysmon comes with an event ID to detect newly created and accessed streams allowing us to quickly detect and hunt malware that uses ADS. Injection techniques come in many different types: Thread Hijacking, PE Injection, DLL Injection, and more. In this room, we will be focusing on DLL Injection and backdooring DLLs. This is done by taking an already used DLL that is used by an application and overwriting or including your malicious code within the DLL.
For more information about this technique check out MITRE ATT&CK T1564 and T1055.
The first technique we will be looking at is hiding files using alternate data streams using Event ID 15. Event ID 15 will hash and log any NTFS Streams that are included within the Sysmon configuration file. This will allow us to hunt for malware that evades detections using ADS. To aid in hunting ADS we will be using the SwiftOnSecurity Sysmon configuration file. The code snippet below will hunt for files in the Temp and Downloads folder as well as .hta and .bat extension.
< RuleGroup name="" groupRelation="or">
< FileCreateStreamHash onmatch="include">
< TargetFilename condition="contains">Downloads< / TargetFilename>
< TargetFilename condition="contains">Temp\7z< / TargetFilename>
< TargetFilename condition="ends with">.hta< / TargetFilename>
< TargetFilename condition="ends with">.bat< / TargetFilename>
< / FileCreateStreamHash>
< / RuleGroup>
As you can see the event will show us the location of the file name as well as the contents of the file this will be useful if an investigation is necessary.
Adversaries also commonly use remote threads to evade detections in combination with other techniques. Remote threads are created using the Windows API CreateRemoteThread and can be accessed using OpenThread and ResumeThread. This is used in multiple evasion techniques including DLL Injection, Thread Hijacking, and Process Hollowing. We will be using the Sysmon event ID 8 from the SwiftOnSecurity configuration file. The code snippet below from the rule will exclude common remote threads without including any specific attributes this allows for a more open and precise event rule.
< RuleGroup name="" groupRelation="or">
< CreateRemoteThread onmatch="exclude">
< SourceImage condition="is">C:\Windows\system32\svchost.exe< / SourceImage>
< TargetImage condition="is">C:\Program Files (x86)\Google\Chrome\Application\chrome.exe< / TargetImage>
< / CreateRemoteThread>
< / RuleGroup>
In Event Viewer to observe a Process Hollowing attack that abuses the notepad.exe process. As you can see in the above image powershell.exe is creating a remote thread and accessing notepad.exe. This is obviously a 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.
We have already gone through a majority of the syntax required to use PowerShell with events. Like previous tasks, we will be using Get-WinEvent along with the XPath to filter and search for files that use an alternate data stream or create a remote thread. In both of the events, we will only need 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: Syntax: Get-WinEvent -Path
Get-WinEvent -Path C:\Users\THM-Analyst\Desktop\Scenarios\Practice\Detecting_RemoteThreads.evtx -FilterXPath '*/System/EventID=8'
Considerazioni Finali:Ho trovato le investigazioni molto facili, in quanto basta seguire l'ordine dei processi e analizzarli manualmente con event viewer > XML Segnando le info chiave, facilmente si arriva alle risposte per logica e ordine cronologico . Non saprei se ci fossero tutti gli event logs, sarebbe cosi semplice (o forse si, filtrando con FilterXPath)