Hunting Red Team Activities With Forensic Artifacts
Hunting Red Team Activities With Forensic Artifacts
Hunting Red Team Activities With Forensic Artifacts
By Haboob Team
1
Research@haboob.sa
Table of Contents
1. Introduction.............................................................................................................................................. 5
2. Why Threat Hunting?............................................................................................................................. 5
3. Windows Forensic.................................................................................................................................. 5
4. LAB Environment Demonstration ..................................................................................................... 6
4.1 Red Team ......................................................................................................................................... 6
4.2 Blue Team ........................................................................................................................................ 6
4.3 LAB Overview .................................................................................................................................. 6
5. Scenarios.................................................................................................................................................. 7
5.1 Remote Execution Tool (Psexec) ............................................................................................... 7
5.2 PowerShell Suspicious Commands ....................................................................................... 16
5.3 Dumping NTDS.dit File ............................................................................................................... 20
5.4 Persistence with Schedule Task ............................................................................................. 22
5.5 Persistence with Autorun .......................................................................................................... 25
5.6 Dumping LSASS Process (Procdump) .................................................................................. 29
6. Hunting with SIEM ............................................................................................................................... 31
6.1 Psexec Use Case .......................................................................................................................... 31
6.2 Suspicious Commands Use Case............................................................................................ 31
6.3 Dumping NTDS.dit file Use Case ............................................................................................. 31
6.4 Procdump Use Case.................................................................................................................... 31
7. Hunting Tips........................................................................................................................................... 32
8. Conclusion .............................................................................................................................................. 33
9. References ............................................................................................................................................. 34
3. Windows Forensic
You can't protect what you don't know about, and understanding forensic capabilities and
artifacts is a core component of information security. In Windows forensic analysis, you’ll
recover, analyze, and authenticate forensic data on Windows systems, track particular user
activity on your network, and organize findings for use in incident response, compromised
assessment, internal investigations, and civil/criminal litigation. Whether you know it or not,
Windows is silently recording an unbelievable amount of data about you and your users.
In this LAB environment, we will suppose that there is no security solution in place on the
network or in the endpoints (like EDR, SIEM, AV, etc.). In fact, we will rely only on the default
Windows logs and artifacts for the purpose of collecting data and investigating the suspicious
activities. However, we are going to use some Open-Source tools that can help us (as a blue
team) to analyze some of the forensic artifacts.
As you can see above, the attacker or the red teamer has executed the malicious command
(from PC-02) and has successfully got a cmd session (PC-01) and has run such commands.
On the above event, you can see that the event type is (Security Event) and the event ID is
4648 and all the details of this activity that captured from the source machine like the user
being used to execute command (Haboob\Ali), the target server which (PC-01.Haboob.local)
and the IP of the server (10.10.10.20) as well as the time of the activity and the source of
machine.
It will also generate an event of a service that has been created (from system events) for the
same service (PSEXECSVC.exe) with the event ID (7045):
Speaking of the registry, there is an artifact in which you can detect any Sysinternals tool
(Psexec in our case). The registry value will log the first execution of the tool (after accepting
the Eula in the command line or in GUI):
Figure 8. Registry Value for the Psexec Execution from Source Machine.
As you can see in figure 8, the registry has logged a value for the Sysinternals tool (Psexec)
when it has been executed for the first time on the source machine. This also will help you to
know if any of the Sysinternals tools has ever been executed on a machine.
This is a good way to avoid some of the detection techniques used by the blue team. Think
about if there is a rule to detect any file created with the name (PSEXESVC), with the switch
(-r), the service name will be changed to a custom name chosen by the malicious user.
As a blue teamer, you have to be careful with the above red teaming techniques and always
check the path C:\Windows for any created abnormal file with a suspicious name, also you
can check the registry value to detect any random service name like the one we just created
(HaboobSVC):
We can clarify that there are a number of executed files (as shown in figure 13), one of them
is Psexec tool. You can also see how many times the Psexec has been run, the path of the
file, and last run times (figure 14). Prefetch is a great forensic artifact which any DFIR
specialist or blue teamer has to use it in order to hunt their enemies.
As a threat hunter, we can hunt the Psexec activity (and other activities) with Shimcache:
You can see on the above figures that we used a Shimcache parser tool to extract the cache
information from the registry hive (SYSTEM). The results are a quite number of tools and files
that whether has an execution flag or not. In our case, the Psexec tool is indeed has been
executed and the execution flag is set to (true).
As a threat hunter, we have to always check the PowerShell events in order to detect any
kind of malicious or suspicious commands:
In the above events, we see that some users have bypassed the execution policy of the
PowerShell. This activity is usually done by malicious users to allow them for running such
scripts which by default the policy is set to “Restricted”. Therefore, it prevents the execution
of PowerShell scripts. The events that triggered this activity can be found on (PowerShell
events “Figure 17”) and (Microsoft-Windows-PowerShell events “Figure 18”).
We can see that a malicious script has been executed on the target machine (PC-02). The
script is PowerView which is a famous PowerShell module that its main goal to enumerate
the target domain (like enumerating domain users, groups, computers, GPOs, ACLs).
This time we have detected the Mimikatz PowerShell script from Benjamin (the author of this
tool). It’s clearly that the attacker has first enumerated the machine with PowerView then
downloaded the Mimikatz and dumped the passwords of the logged in users from memory.
There is another great source for the PowerShell history commands which is a file called
(ConsoleHost_history.txt). The file records all the commands typed by any user in the
PowerShell terminal. By default, it will save all the typed commands (starting from
PowerShell V5 on Windows 10). Actually, this is a good forensic artifact in which we can hunt
for malicious commands of any suspected compromised user (or se it proactively for
hunting). See the figure 22 for the location of the file.
We can confirm that the whole target domain is compromised from the above commands
(Figure 23). Basically, the attacker or the red teamer has used the malicious scripts as we
explained before (PowerView.ps1 and Mimikatz.ps1). Then, he dumped the passwords of
another computer (PC-01) from the memory by using the (Invoke-Mimikatz). After that, he
enumerated the Domain Controllers of the current domain (Haboob.local). Then, he
connected to the DC-01 using a Domain Admin credentials (Ali) with the PowerShell Remoting
(PSSession). Moreover, we can confirm this activity by checking the Windows security events:
This activity (stealing the NTDS.dit file from DC) is usually done by using the vssadmin utility
from Windows which will enable the creation of shadow copies for any drive (C drive in our
case). This will allow the attacker to copy any file on the disk even if the file is running and
cannot be copied in a normal case (such as NTDS.dit file which cannot be copied). Below is
the command to create a shadow copy for C drive and copy the NTDS.dit file:
We can detect this activity from the Windows events (system events) with the ID (7036):
Also, this activity has been triggered in the Windows event (application event):
There is a great artifact for which you can observe and detect any shadow copy has been
created on the Domain Controller. This artifact can be found in the registry and you can know
how many shadow copies have been created:
In figure 29, you can see that there are two registry keys for the two shadow copies that have
been created. As a threat hunter, you have to not rely only on the windows event for detecting
this kind of activities, in fact, you have to investigate all the artifacts on the machine as well
as guessing what an attacker can do in a critical server like the DC? Asking yourself such
questions will help you to speed up the investigation.
We will check the Windows event (schedule task events) to see if there is any abnormal
schedule task has been created:
The above events from the TaskScheduler events type show that there is a task schedule has
been created by NT AUTHORITY\SYSTEM with a task name (update_software). Although the
name of the task schedule seems to be normal and not suspicious, but as a threat hunter we
have to investigate more on this task and confirm whether the task is a normal or indeed it’s
a malicious task.
We opened the file (update_software) on the notepad to see the content of the task:
After checking the content of the file, we can find that the task is scheduled to execute a bat
file called (update.bat) on C:\Windows\Temp.
The file is indeed there, we opened the bat file to see its content:
The content of the bat file is a PowerShell command which uses the Net.WebClient class to
download a file called (run.ps1) from a suspicious IP. As a threat hunter, we will check the
suspicious IP in VirusTotal to see if the IP is marked as a malicious on some AV engines:
We can confirm that this is a malicious activity and the IP seems to be a server owned by an
attacker which is being used to download and execute a malicious PowerShell script file
(run.ps1) in a scheduled time.
The name of the file as well as the path seem to be normal but remember that as a threat
hunter we have to always investigate. We will go to the location of the file (ExExporrt.exe):
In figure 38, We can observe that there are two files with almost the same name. We don’t
know which of them is a suspicious file and the other is a normal or a legitimate file.
After comparing the two files, it’s clearly that this file (ExtExporrt) is a suspicious file. The
suspicious file has a product name “Apache HTTP Server” which could be an HTTP reverse
shell. On the other hand, the normal file has a Microsoft signature. Also, the modified data of
the suspicious file comparing to the normal file is a big difference which gives us a sign. We
can also detect this activity by using the Sysinternals tool “autorun” from Microsoft:
Then we ran the rule on the machine (PC-02) to look for those strings over all the files/folders:
We have actually found three malicious files with the same malicious executable that we
previously found (ExtExporrt.exe). The new malicious files are found on multiple location on
the machine (PC-02) with different names. You can note that one of them is on the Recycle
Bin which it has been deleted.
For this purpose, we used this Yara Rule only on one machine, imagine if we are in a domain
that has a lot of computers (such as more than 500 Domain-Joined Computers) and we run
such a rule on those machine. Also, think about if we have an EDR that supports the use of
Yara rule, with this way, we can run a Yara rule from the EDR management over all the agent-
connected machines. With this way, we can save a lot of time for hunting and investigating.
We can see that two malicious files (install.exe & test.exe) have been executed on the machine
with different times. Note that Amcache stores SHA1 hash (same hash for the two files).
In figure 45, we demonstrated that an attacker or a red teamer has executed the Procdump
tool to dump the LSASS process to get the DMP file (lssas.dmp in our case).
We can hunt this activity by reviewing the below registry key (as explained previously):
As you can see in figure 46, there is a registry key to record any executed Sysinternals tools.
Whenever an attacker (or any user) has accepted the Eula (accepteula), a new record will be
created in this registry key: HKEY_CURRENT_USER\Software\Sysinternals\
In figure 47, you can see the Prefetch results for the Procdump activity as well as some data
like the last execution time, how many times has been run, the created time, the path of the
executed tool and other information that Prefetch provides.
Benjamin, the author of the Mimikatz, has created a YARA Rule to detect any use of DMP file
by LSASS process. If you are not sure if there is any LSASS DMP file in your machine or in
the domain, simply use the rule and fire it on the machine:
We can see in figure 49 that the YARA rule has detected a DMP file. The DMP file is indeed an
LSASS DMP file that has been matched to the rule. (which is the same we found previously).
Note that you can find all the used tools and resources for the all the demonstrated scenarios
in the reference section.
The above use cases are just examples (and not limited to) for creating effective use cases.
It might generate false-positive, but as a blue team, it’s worth further investigating the
matched rules and make sure if it’s indeed a false positive or a real malicious activity.
However, you could create better use cases than the previously created.