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.
TryHackMe windows sysmon utilize to monitor and log your endpoint and
environments
Task 2 Sysmon Overview
Sysmon Overview
From the Microsoft Docs,
"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."
Sysmon is used to get better
detailed and high-quality logs and event tracing to aid in identify anomalies
in your environment. Sysmon is most commonly used in conjunction with a
SIEM or other log parser to ingest and visualize/filter the events.
Sysmon
is a binary executed on endpoints to then be forwarded to a SIEM. In this
room, we will focus on Sysmon itself and the events that it provides.
Events within Sysmon are stored in Applications and Services Logs/Microsoft/Windows/Sysmon/Operational
Sysmon Config Overview
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. An example of a high-quality config that works well for
identifying anomalies in the Sysmon-Config by SwiftOnSecurity. Sysmon includes
24 different types of Event IDs all of which can be used within the config to
specify how the events should be handled and analyzed. Below we will go over a
few of the most important Event IDs and show examples of how they are used
within config files.
When creating or modifying configuration
files you will notice that a majority of rules in sysmon-config will exclude
events rather than include events. This is because there will be a lot more
noise in your environment than anomalies by excluding normal activity will
decrease the number of events and alerts you will have to manually audit or
search through in a SIEM. This can also change to have a lot of include
rules this is typically a much more proactive ruleset rather than using mainly
exclude rules, an example of this is the ION-Storm sysmon-config fork. You
will have to play with and modify configuration files to find what you prefer
this may also be already set up for you if you're coming onto an existing SOC
team. prepare to be flexible when monitoring.
Note: As there
are so many Event IDs Sysmon analyzes we will only be going over a few
of the ones that we think are most important to understand
Event ID 1: Process Creation
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</CommandLine>
</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.
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.
<RuleGroup name="" groupRelation="or">
<NetworkConnect onmatch="include">
<Image
condition="image">nmap.exe</Image>
<DestinationPort name="Alert,Metasploit"
condition="is">444</DestinationPort>
</NetworkConnect>
</RuleGroup>
The above code snippet includes two ways of looking for suspicious activity
within network connections. The first way will look for files transmitted over
open ports in this case it is specifically looking for
nmap.exe this will then be reflected within the event logs. The
second method will look for open ports in this case 444 is a
known port that is used with Metasploit so it will create the
event as well as generate an alert for the event.
Event ID 7: Image Loaded
This event will look for DLLs loaded by processes, this can
be useful when hunting for DLL Injection, DLL Hijacking, etc. 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 require further investigation.
Event ID 8: CreateRemoteThread
The CreateRemoteThread Event ID will monitor for
processes injecting code into other processes. This can be used for legitimate
tasks and applications or it can be used by malware to hide its actions. 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 analyzing for
CreateRemoteThread. The first method will look at the memory address for a
specific ending condition, this specific condition is an indicator of a Cobalt
Strike beacon. The second method will look for injected processes that do not
have a parent process this is considered an anomaly and requires further
investigation.
Event ID 11: File Created
This event will analyze events for file names or signatures
that have been created on the endpoint. This will be one of the easiest ways
to cut down a lot of alerts as well as quickly identify a lot of simple
attacks simply by identifying names and signatures of files on 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.
Event ID 12 / 13 / 14: Registry Event
This event will analyze and 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 this is a common directory for
adversaries to place persistence scripts.
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.
<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.
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 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.
There are a variety of ways and
tags that you can use to customize your configuration files. We will be using
the ION-Storm and SwiftOnSecurity config files for the rest of this room
however feel free to use your own configuration files.
Read the above
and become familiar with the Sysmon Event IDs.
Investigating File Download Here :-
Task 3 Installing and Preparing Sysmon
Installing Sysmon
The installation for Sysmon is
fairly straightforward and only requires you to download a binary from the
Microsoft website. You can also download all of the Sysinternals tools with a
PowerShell command if you wanted to rather than 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. As an example config file we will be
using the sysmon-config file from the SwiftOnSecurity GitHub repo.
You can find the Sysmon binary from the Microsoft
Sysinternals website. You can also 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 you will also need to
download a Symon config or create your own config. We suggest downloading the
SwiftOnSecurity sysmon-config. A Sysmon config will allow for further granular control over the
logs as well as more detailed event tracing. In this room, we will be using
both the SwiftOnSecurity configuration file as well as the
ION-Storm
config file.
Starting Sysmon
To start Sysmon you will want to open a new
PowerShell or Command Prompt as an Administrator. Then run the below command it will execute the Sysmon binary as well as
accept the end-user license agreement and start Sysmon with the
SwiftOnSecurity config file.
Command Used: Sysmon.exe -accepteula -i sysmonconfig-export.xml
Now that Sysmon is started with the configuration file we want to use we can
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.
If installed correctly your event log should look similar to the
following.
For this room, we have already created an environment with Sysmon
and configuration files already installed. Deploy and use this machine for the
remainder of this room.
Machine IP: MACHINE_IP
User: THM-Analyst
Pass:
5TgcYzF84tcBSuL1Boa%dzcvf
Task 4 Cutting out the Noise
Malicious Activity Overview
Since most of
the normal activity or "noise" seen on a network is excluded or filtered out
with Sysmon we can focus on only the important stuff allowing us to quickly
identifying and investigate suspicious activity. When actively monitoring a
network you will want to use multiple detections and techniques simultaneously
to optimize your hunt. For this room, we will only be looking at what
suspicious logs will look like with both Sysmon configs and how to optimize
your hunt using only Sysmon. We will be looking at how to detect ransomware,
persistence, Mimikatz, Metasploit, and C2 beacons. Obviously, this is only a
small handful of events that can happen in an environment however the hunting
methodology is largely the same as Sysmon and the configuration file does a
majority of the analysis for you.
You can download the event
logs used in this room from this task or you can open them in the Practice
folder on the provided machine.
Sysmon "Best Practices"
Sysmon offers a fairly open and configurable platform for you to
use how you or your company want but there are generally a few best practices
that you can implement to ensure you're operating efficiently and not missing
any possible threats. A few common best practices are outlined and explained
below.
When creating rules
for your Sysmon configuration file it is typically best to prioritize
excluding events rather than including events this prevents you from
accidentally missing crucial events and only seeing the events that matter the
most.
- CLI gives you further control
As is common with most applications the CLI gives you the most control
and filtering allowing for further granular control. You can use either
Get-WinEvent
or
wevutil.exe
to access and filter logs. As you incorporate Sysmon into your SIEM or other
detection implementations these tools will become less used and needed.
- Know your environment before implementation
This should be considered with any platform or tool you implement into a
production environment but you should have a firm understanding of the network
or environment you are working within to fully understand what is normal and
what is suspicious so you can effectively craft your rules.
Filtering Events with Event Viewer
Event Viewer is not the best for filtering events but it
offers a small amount of control over logs. The main filter you will be using
with Event Viewer is by filtering the
EventID
and keywords; you can also choose to filter by writing XML but this is tedious
and typically not recommended.
To open the filter menu
select
Filter Current Log
from the Actions menu.
If you have successfully opened the filter menu it should look like the menu
below.
From this menu, we can add any filters or categories that we want.
Filtering Events with PowerShell
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. And we will be using
wevutil.exe
to view events once filtered. The command line is typically used over the
Event Viewer GUI because it can allow for further granular control and
filtering that the GUI does not offer. For more information about using
Get-WinEvent and wevutil.exe check out the Windows Event Log
room by Heavenraiza.
For this room, we will only be going
over a few basic filters as the Windows Event Log room already extensively
covers this topic.
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 444.
Get-WinEvent -Path <Path to Log> -FilterXPath '*/System/EventID=3
and */EventData/Data[@Name="DestinationPort"] and
*/EventData/Data=444'
1) How many event ID 3 events are in
C:\Users\THM-Analyst\Desktop\Scenarios\Practice\Filtering.evtx.
Ans :- 73,591
2) What is the UTC time created of the first network event in
C:\Users\THM-Analyst\Desktop\Scenarios\Practice\Filtering.evtx
Ans :- 2021-01-06 01:35:50.464
Task 5 Hunting Metasploit
Hunting Metasploit
Metasploit is a
commonly used exploit framework for penetration testing and red team
operations. Metasploit can be used to easily run exploits on a machine and
connect back to a meterpreter shell. 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
444
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.
For
more information about this technique and tools used check out
MITRE ATT&CK Software.
For more information about how malware and payloads
interact with the network check out the Malware Common Ports Spreadsheet. This will be covered in further depth in the Hunting Malware task.
You
can download the event logs used in this room from this task or you can open
them in the Practice folder on the provided machine.
Hunting Network Connections
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
444
and
5555.
<RuleGroup name="" groupRelation="or">
<NetworkConnect onmatch="include">
<DestinationPort
condition="is">4444</DestinationPort>
<DestinationPort
condition="is">5555</DestinationPort>
</NetworkConnect>
</RuleGroup>
Open
C:\Users\THM-Analyst\Desktop\Scenarios\Practice\Hunting_Metasploit.evtx
in Event Viewer to view a basic Metasploit payload being
dropped onto the machine.
Once we identify the event it can give us some important information we can
use for further investigation like the ProcessID and Image.
Hunting for Open Ports with PowerShell
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. The command line is typically used over the Event Viewer GUI
because it can allow for further granular control and filtering that the GUI
does not offer. For more information about using XPath and the command line
for event viewing, check out the
Windows Event
Log room by Heavenraiza.
Get-WinEvent -Path <Path to Log> -FilterXPath '*/System/EventID=3
and */EventData/Data[@Name="DestinationPort"] and
*/EventData/Data=444'
We can break this command down by its filters to see exactly what it is doing.
It 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 that we want to filter. We can adjust this
syntax along with our events to get exactly what data we want in return.
Read the above and practice hunting Metasploit with the provided event
file.
Task 6 Detecting Mimikatz
Detecting Mimikatz Overview
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. Anti-Virus will typically pick up Mimikatz as the signature is very
well known but it is still possible for threat actors to obfuscate or use
droppers to get the file onto the device. For this hunt, we will be using a
custom configuration file to minimize network noise and focus on the hunt.
For more information about this technique and the software
used check out
MITRE ATTACK
T1055 and
S0002.
You can download the event logs used in this room from
this task or you can open them in the Practice folder on the provided
machine.
Detecting File Creation
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.
Hunting Abnormal LSASS Behavior
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. Look below for more
detail on hunting with these techniques.
If LSASS is
accessed by a process other than svchost.exe it should be considered
suspicious behavior and should be investigated further, to aid in looking for
suspicious events you can use a filter to only look for processes besides
svchost.exe. Sysmon will provide us further details to help lead the
investigation such as the file path the process originated from. To aid in
detections we will be using a custom configuration file. Below is a snippet of
the config that will aid in the hunt.
<RuleGroup name="" groupRelation="or">
<ProcessAccess onmatch="include">
<TargetImage
condition="image">lsass.exe</TargetImage>
</ProcessAccess>
</RuleGroup>
Open
C:\Users\THM-Analyst\Desktop\Scenarios\Practice\Hunting_LSASS.evtx
in Event Viewer to view an attack using an obfuscated version of Mimikatz to
dump credentials from memory.
We see the event that has the Mimikatz process accessed but we also see a lot
of svchost.exe events? We can alter our config to exclude events with the
SourceImage event coming from svhost.exe. Look below for a modified
configuration rule to cut down on the noise that is present in the event
logs.
<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.
Detecting LSASS Behavior with PowerShell
To detect abnormal LSASS behavior with PowerShell we will again be using the PowerShell module Get-WinEvent along
with XPath queries. We can use the same XPath queries used in
the rule to filter out the other processes from TargetImage. If we use this
alongside a well-built configuration file with a precise rule it will do a lot
of the heavy lifting for us and we only need to filter a small amount.
Get-WinEvent -Path <Path to Log> -FilterXPath
'*/System/EventID=10 and */EventData/Data[@Name="TargetImage"] and
*/EventData/Data="C:\Windows\system32\lsass.exe"'
Task 7 Hunting Malware
Hunting Malware Overview
Malware has many forms
and variations with different end goals. 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.
For more information about this technique and examples of
malware check out
MITRE ATT&CK Software.
You can download the event logs used in this room from
this task or you can open them in the Practice folder on the provided
machine.
Hunting Rats and C2 Servers
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. By using known
suspicious ports to include in our logs we can add to our hunting methodology
in which we can use logs to identify adversaries on our network then use
packet captures or other detection strategies to continue the investigation.
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.
For
more information about the ports that this configuration file alerts on check
out this
spreadsheet.
<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>
Open
C:\Users\THM-Analyst\Desktop\Scenarios\Practice\Hunting_Rats.evtx
in Event Viewer to view a live rat being dropped onto the server.
In the above example, 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.
Hunting for Common Back Connect Ports with PowerShell
Just like previous sections when using PowerShell we will
again be using the PowerShell module Get-WinEvent
along with
XPath
queries to filter our events and gain granular control over our logs. We will
need to filter on the
NetworkConnect
event ID and the
DestinationPort
data attribute. If you're using a good configuration file with a reliable set
of rules it will do a majority of the heavy lifting and filtering to what you
want should be easy.
Get-WinEvent -Path <Path to Log> -FilterXPath '*/System/EventID=3
and */EventData/Data[@Name="DestinationPort"] and
*/EventData/Data=<Port>'
Task 8 Hunting Persistence
Persistence Overview
Persistence
is used by attackers to maintain access to a machine once it is compromised.
There is a multitude of ways for an attacker to gain persistence on a machine
we will be focusing on registry modification as well as startup scripts. We
can hunt persistence with Sysmon by looking for File Creation events as well
as Registry Modification events. The SwiftOnSecurity configuration file does a
good job of specifically targeting persistence and techniques used. You can
also filter by the Rule Names in order to get past the network noise and focus
on anomalies within the event logs.
You can download the
event logs used in this room from this task or you can open them in the
Practice folder on the provided machine.
Hunting Startup Persistence
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>
Open
C:\Users\THM-Analyst\Desktop\Scenarios\Practice\T1023.evtx in Event Viewer to view a live attack on the machine that involves
persistence by adding a malicious EXE into the Startup folder.
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.
Hunting Registry Key Persistence
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>
Open
C:\Users\THM-Analyst\Desktop\Scenarios\Practice\T1060.evtx
in Event Viewer to view an attack where the registry was modified to gain
persistence.
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
Just like the startup technique, we can filter by the
RuleName T1060 to make finding the anomaly easier.
If
we wanted to investigate this anomaly we would need to look at the registry as
well as the file location itself. Below is the registry area where the
malicious registry key was placed.
Task 9 Detecting Evasion Techniques
Evasion Techniques Overview
There are a number
of evasion techniques used by malware authors to both evade anti-virus and
evade detections. 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.
You can
download the event logs used in this room from this task or you can open them
in the Practice folder on the provided machine.
Hunting Alternate Data Streams
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
Startup
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>
Open
C:\Users\THM-Analyst\Desktop\Scenarios\Practice\Hunting_ADS.evtx in
Event Viewer to view hidden files using an alternate data stream.
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.
Detecting Remote Threads
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>
Open
C:\Users\THM-Analyst\Desktop\Scenarios\Practice\Detecting_RemoteThreads.evtx
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.
Detecting Evasion Techniques with PowerShell
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 Alternate Data Streams
Syntax: Get-WinEvent -Path <Path to Log> -FilterXPath
'*/System/EventID=15'
Detecting Remote Thread Creation
Syntax: Get-WinEvent -Path <Path to Log> -FilterXPath
'*/System/EventID=8'
Read the above and practice detecting evasion techniques
Task 10 Practical Investigations
Event files used within this task have been sourced from the
EVTX-ATTACK-SAMPLES and
SysmonResourcesGithub
repositories.
You can download the event logs used in this
room from this task or you can open them in the Investigations folder on the
provided machine.
Investigation 1 - ugh, BILL THAT'S THE WRONG USB!
In this investigation, your team has received reports that
a malicious file was dropped onto a host by a malicious USB. They have pulled
the logs suspected and have tasked you with running the investigation for
it.
Logs are located in
C:\Users\THM-Analyst\Desktop\Scenarios\Investigations\Investigation-1.
Investigation 2 - This isn't an HTML file?
Another suspicious file has appeared in your logs and has managed
to execute code masking itself as an HTML file, evading your anti-virus
detections. Open the logs and investigate the suspicious file.
Logs are located in
C:\Users\THM-Analyst\Desktop\Scenarios\Investigations\Investigation-2.
Investigation 3.1 - 3.2 - Where's the bouncer when you need him
Your team has informed you that the adversary has managed to set
up persistence on your endpoints as they continue to move throughout your
network. Find how the adversary managed to gain persistence using logs
provided.
Logs are located in
C:\Users\THM-Analyst\Desktop\Scenarios\Investigations\Investigation-3.1
and
C:\Users\THM-Analyst\Desktop\Scenarios\Investigations\Investigation-3.2.
Investigation 4 - Mom look! I built a botnet!
As the adversary has gained a solid foothold onto your
network it has been brought to your attention that they may have been able to
set up C2 communications on some of the endpoints. Collect the logs and
continue your investigation.
Logs are located in
C:\Users\THM-Analyst\Desktop\Scenarios\Investigations\Investigation-4.
1) What is the full registry key of the USB device calling svchost.exe in
Investigation 1?
Ans :-
HKLM\System\CurrentControlSet\Enum\WpdBusEnumRoot\UMB\2&37c186b&0&STORAGE#VOLUME#_??_USBSTOR#DISK&VEN_
SANDISK&PROD_U3_CRUZER_MICRO&REV_8.01#4054910EF19005B3&0
#\FriendlyName
2) What is the device name when being called by RawAccessRead in
Investigation 1?
Ans :- \Device\HarddiskVolume3
3) What is the first exe the process executes in Investigation 1?
Ans :- rundll32.exe
4) What is the full path of the payload in Investigation 2?
Ans :- C:\Users\IEUser\AppData\Local\Microsoft\Windows\Temporary
Internet Files\Content.IE5\S97WTYG7\update.hta
5) What is the full path of the file the payload masked itself as in
Investigation 2?
Ans :- C:\Users\IEUser\Downloads\update.html
6) What signed binary executed the payload in Investigation 2?
Ans :- C:\Windows\System32\mshta.exe
7) What is the IP of the adversary in Investigation 2?
Ans :- 10.0.2.18
8) What back connect port is used in Investigation 2?
Ans :- 4443
9) What is the IP of the suspected adversary in Investigation 3.1?
Ans :- 172.30.1.253
10) What is the hostname of the affected endpoint in Investigation 3.1?
Ans :- DESKTOP-O153T4R
11) What is the hostname of the C2 server connecting to the endpoint
in Investigation 3.1?
Ans :- empirec2
12) Where in the registry was the payload stored in Investigation 3.1?
Ans :- HKLM\SOFTWARE\Microsoft\Network\debug
13) What PowerShell launch code was used to launch the payload in
Investigation 3.1?
Ans :-
"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -c "$x=$((gp
HKLM:Software\Microsoft\Network debug).debug);start -Win Hidden -A \"-enc $x\"
powershell";exit;
14) What is the IP of the adversary in Investigation 3.2?
Ans :- 172.168.103.188
15) What is the full path of the payload location in Investigation 3.2?
Ans :- c:\users\q\AppData:blah.txt
16) What was the full command used to create the scheduled task in
Investigation 3.2?
Ans :- "C:\WINDOWS\system32\schtasks.exe" /Create /F /SC DAILY
/ST 09:00 /TN Updater /TR
"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NonI -W hidden -c
\"IEX ([Text.Encoding]::UNICODE.GetString([Convert]::FromBase64String($(cmd /c
''more < c:\users\q\AppData:blah.txt'''))))\""
17) What process was accessed by schtasks.exe that would be considered
suspicious behavior in Investigation 3.2?
Ans :- lsass.exe
18) What is the IP of the adversary in Investigation 4?
Ans :- 172.30.1.253
19) What port is the adversary operating on in Investigation 4?
Ans :- 80
20) What C2 is the adversary utilizing in Investigation 4?
Ans :- Empire
Disclaimer
This was written for educational purpose and pentest only.
The author will not be responsible for any damage ..!
The author of this tool is not responsible for any misuse of the information.
You will not misuse the information to gain unauthorized access.
This information shall only be used to expand knowledge and not for
causing malicious or damaging attacks. Performing any hacks without written permission is illegal ..!
All video’s and tutorials are for informational and educational purposes only.
We believe that ethical hacking, information security and cyber security should
be familiar subjects to anyone using digital information and computers. We believe that it is impossible to defend yourself
from hackers without knowing how hacking is done. The tutorials and videos
provided on www.hackingtruth.in is only for those who are interested to learn about Ethical Hacking,
Security, Penetration Testing and malware analysis. Hacking tutorials is against
misuse of the information and we strongly suggest against it. Please regard the word
hacking as ethical hacking or penetration testing every time this word is
used.
All tutorials and videos have been made using our own routers, servers, websites
and other resources, they do not contain any illegal activity. We do not
promote, encourage, support or excite any illegal activity or hacking without
written permission in general. We want to raise security awareness and inform
our readers on how to prevent themselves from being a victim of hackers. If you
plan to use the information for illegal purposes, please leave this website now.
We cannot be held responsible for any misuse of the given information.
- Hacking Truth by Kumar Atul Jaiswal
I hope you liked this post, then you should not forget to share this post at
all.
Thank you so much :-)
