TryHackMe: Sysmon Complete Walkthrough (SOC Level 1)

Welcome to this walkthrough of the Sysmon Room on TryHackMe. In this room we learn about how to utilize Sysmon to monitor and log your endpoints and environments. Part of the Windows Sysinternals package, Sysmon is similar to Windows Event Logs with further detail and granular control.

Room URL:
https://tryhackme.com/room/sysmon

I am making these walkthroughs to keep myself motivated to learn cyber security, and ensure that I remember the knowledge gained by these challenges on HTB and THM. Join me on learning cyber security. I will try and explain concepts as I go, to differentiate myself from other walkthroughs.

Now, let’s move on! This is going to be a long one!

Task 1: Introduction

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.

This room uses a modified version of the Blue and Ice boxes, as well as Sysmon logs from the Hololive network lab.

Questions

Complete the prerequisites listed above and jump into task 2.

Answer: No answer needed

Task 2: Sysmon Overview

Sysmon (System Monitor) is a Windows service and driver that logs detailed system activity to the Windows event log, persisting across reboots. It helps identify malicious or anomalous behavior by monitoring processes, network connections, and file changes. Sysmon is commonly used with SIEM systems for event aggregation and analysis. Events are stored in Applications and Services Logs/Microsoft/Windows/Sysmon/Operational.

Sysmon Configuration
Sysmon requires a configuration file that defines how events are analyzed. Config files typically filter out normal activity to reduce noise. Popular configurations include SwiftOnSecurity’s Sysmon-Config (exclusion-based) and ION-Storm’s ruleset (inclusion-based).

Key Event IDs

• Event ID 1: Process Creation – Logs process starts to detect suspicious activity.
• Event ID 3: Network Connection – Monitors network events, including suspicious binaries and open ports.
• Event ID 7: Image Loaded – Tracks DLL loads, useful for detecting DLL Injection/Hijacking.
• Event ID 8: CreateRemoteThread – Detects code injection into processes.
• Event ID 11: File Created – Logs file creation, useful for ransomware detection.
• Event IDs 12-14: Registry Events – Monitors registry changes for persistence mechanisms.
• Event ID 15: FileCreateStreamHash – Detects alternate data stream file creations, often used to hide malware.
• Event ID 22: DNS Event – Logs DNS queries; common domains can be excluded to reduce noise.

Sysmon configuration files can be customized based on security needs, using predefined rulesets or custom modifications.

Questions

Read the above and become familiar with the Sysmon Event IDs.

Answer: No answer needed

Task 3: Installing and Preparing Sysmon

Installation

Sysmon can be installed by downloading its binary from the Microsoft Sysinternals website. Alternatively, all Sysinternals tools can be downloaded using PowerShell:

Download-SysInternalsTools C:\Sysinternals

For better event tracing, it is recommended to use a configuration file. The SwiftOnSecurity Sysmon config is a popular choice, but other configurations like ION-Storm can also be used.

Starting Sysmon

1. Open PowerShell or Command Prompt as Administrator.
2. Run the following command to install Sysmon with the SwiftOnSecurity config: cmdKopiérRedigerSysmon.exe -accepteula -i ..\Configuration\swift.xml
3. If installed correctly, Sysmon will start, and logs can be viewed in:
   Event Viewer → Applications and Services Logs → Microsoft → Windows → Sysmon → Operational

Questions

Deploy the machine and start Sysmon. 

Answer: No answer needed

Task 4: Cutting out the Noise

Sysmon helps filter out normal network activity, allowing analysts to focus on meaningful security events. Effective threat detection requires using multiple techniques, and this guide focuses on identifying ransomware, persistence mechanisms, Mimikatz, Metasploit, and Command and Control (C2) beacons. A well-configured Sysmon setup significantly improves efficiency in detecting threats.

Sysmon Best Practices:

1. Exclude > Include: Prioritize excluding noise rather than including specific events to avoid missing critical threats.
2. Use CLI for Control: Command-line tools like Get-WinEvent and wevutil.exe provide better filtering and control compared to GUI tools.
3. Know Your Environment: Understanding normal activity in your network helps in distinguishing legitimate from suspicious behavior.

Filtering Events:

• Event Viewer: Basic filtering by EventID and keywords, but lacks scalability.
• PowerShell (Get-WinEvent): Allows advanced filtering using XPath queries for precise event log analysis.
  • Example: Filtering for network connections on port 4444: powershellCopyEditGet-WinEvent -Path <Path to Log> -FilterXPath '*/System/EventID=3 and */EventData/Data[@Name="DestinationPort"] and */EventData/Data=4444'

Questions

Read the above and practice filtering events.

Answer: No answer needed

How many event ID 3 events are in C:\Users\THM-Analyst\Desktop\Scenarios\Practice\Filtering.evtx?

Open the evtx file in Event Viewer. In the actions menu select Filter Current Log. Enter 3 in the Event ID input field to filter on event ID 3.

A bunch of events get filtered way:

There are 73,591 events after filtering.

Answer: 73,591

What is the UTC time of the first network event in the same logfile? Note that UTC time is shown only in the “Details” tab.

Keep the same filter, and start by sorting on the Date and Time column and make sure the earliest event shows first.

The full timestamp is visible in the Details tab.

Answer: 2021-01-06 01:35:50.464

Task 5: Hunting Metasploit

Metasploit is a widely used framework for penetration testing, often deploying meterpreter shells via exploits. To detect these, security analysts can monitor network connections on suspicious ports like 4444 and 5555, which Metasploit uses by default.

Investigation Steps:

1. Analyze Network Traffic: Check packet captures for suspicious connections.
2. Inspect Event Logs: Look for network activity using Windows Event Viewer and event logs.
3. Identify Suspicious Processes: Correlate logs with process IDs and executables.

Detection Techniques:

• Custom Event Rule (Ion-Security):
  A rule can monitor event ID 3 (network connections) and flag ports 4444 and 5555.
• PowerShell Hunting:
  Using Get-WinEvent with XPath queries, analysts can filter logs for events linked to these ports, providing deeper insight beyond GUI tools.

Resources:

• MITRE ATT&CK Software for additional detection techniques.
• Malware Common Ports Spreadsheet to understand network behavior of threats.

This method can also be applied to other Remote Access Trojans (RATs) and Command & Control (C2) beacons, improving overall threat hunting capabilities.

Questions

Read the above and practice hunting Metasploit with the provided event file.

Answer: No answer needed

Task 6: Detecting Mimikatz

Mimikatz is a well-known tool used for credential dumping, primarily targeting LSASS.exe. Detection methods include monitoring file creation, process access, and network activity using Sysmon and PowerShell.

Detecting File Creation

• Simple but limited technique: Look for files named “mimikatz”.
• Example Sysmon rule: xmlCopyEdit<RuleGroup name="" groupRelation="or"> <FileCreate onmatch="include"> <TargetFileName condition="contains">mimikatz</TargetFileName> </FileCreate> </RuleGroup>

Hunting Abnormal LSASS Behavior (ProcessAccess Event ID 10)

• Mimikatz and similar tools access LSASS, which is abnormal unless done by svchost.exe.
• Sysmon can log process access events to detect this behavior.

Initial detection rule:

<RuleGroup name="" groupRelation="or">
  <ProcessAccess onmatch="include">
    <TargetImage condition="image">lsass.exe</TargetImage>
  </ProcessAccess>
</RuleGroup>

• This logs all processes accessing LSASS, but generates noise from svchost.exe.

Optimized rule (excludes svchost.exe):

<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>

• Reduces noise by ignoring legitimate svchost.exe activity.

3. Detecting LSASS Behavior with PowerShell

• Use Get-WinEvent and XPath queries to analyze logs dynamically.
• Example query for LSASS access: powershellCopyEditGet-WinEvent -Path <Path to Log> -FilterXPath '*/System/EventID=10 and */EventData/Data[@Name="TargetImage"] and */EventData/Data="C:\Windows\system32\lsass.exe"'
• Example query for Mimikatz-related events: powershellCopyEditGet-WinEvent -Path C:\Users\THM-Analyst\Desktop\Scenarios\Practice\Hunting_Mimikatz.evtx -FilterXPath '*/System/EventID=10 and */EventData/Data[@Name="TargetImage"] and */EventData/Data="C:\Windows\system32\lsass.exe"'

Questions

Read the above and practice detecting Mimikatz with the provided evtx.

Definitely try analyzing the evtx file by running the following Get-WinEvent command:

Get-WinEvent -Path C:\Users\THM-Analyst\Desktop\Scenarios\Practice\Hunting_Mimikatz.evtx -FilterXPath '*/System/EventID=10 and */EventData/Data[@Name="TargetImage"] and */EventData/Data="C:\Windows\system32\lsass.exe"'

Answer: No answer needed

Task 7: Hunting Malware

This guide focuses on detecting and hunting malware, specifically Remote Access Trojans (RATs) and backdoors. RATs function as payloads that grant remote access and often include evasion techniques. They typically use a client-server model with an administrative interface, examples being Xeexe and Quasar.

Hunting Malware Techniques

1. Hypothesis-Based Hunting:
   • Identify the malware to hunt.
   • Modify configuration files to detect suspicious behavior.
   • Detect open back connect ports used by malware.
2. Detecting RATs & C2 Servers:
   • Use known suspicious ports (e.g., 1034, 1604) in configuration files to detect threats.
   • Exclude common benign network connections (e.g., OneDrive) to reduce noise.
   • Avoid blindly using configuration files as attackers may exploit overlooked ports (e.g., port 53).
3. Hunting Back Connect Ports with PowerShell:
   • Use Get-WinEvent and XPath queries to filter event logs based on NetworkConnect event ID and DestinationPort.
   • Example: powershellCopyEditGet-WinEvent -Path <Path to Log> -FilterXPath '*/System/EventID=3 and */EventData/Data[@Name="DestinationPort"] and */EventData/Data=<Port>'
   • View live RAT events in Event Viewer (Hunting_Rats.evtx) to analyze network connections.

By using structured detection methods and avoiding unnecessary exclusions, analysts can effectively track and mitigate malware threats.

Questions

Read the Above and practice hunting rats and C2 servers with back connect ports. 

Answer: No answer needed

Task 8: Hunting Persistence

Persistence allows attackers to maintain access to a compromised machine. Two common techniques are modifying the registry and placing startup scripts. Using Sysmon and the SwiftOnSecurity configuration file, defenders can detect persistence by monitoring file creation and registry modification events.

Hunting Startup Persistence

• Attackers may drop malicious executables into Startup or Start Menu directories.
• Sysmon rules can detect these events, such as MITRE ATT&CK T1547.
• Example: A log file (T1023.evtx) in Event Viewer shows persist.exe placed in the Startup folder.
• Analysts should investigate changes in startup locations and refine alert configurations for better detection.

Hunting Registry Key Persistence

• Attackers may modify registry keys like CurrentVersion\Windows\Run to execute malware on startup (MITRE ATT&CK T1112).
• Sysmon rules help detect such modifications.
• Example: A log file (T1060.evtx) reveals malicious.exe added to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run.
• Analysts should check both the registry and the malicious file location to investigate anomalies.

By filtering event logs using Rule Names (T1023, T1060) and refining detection rules, defenders can effectively hunt for persistence mechanisms.

Questions

Read the above and practice hunting persistence techniques.

Answer: No answer needed

Task 9: Detecting Evasion Techniques

Attackers use evasion techniques to bypass antivirus and detection systems. This includes Alternate Data Streams (ADS) and DLL Injection, which can be detected using Sysmon and the SwiftOnSecurity configuration file.

Hunting Alternate Data Streams (ADS) – MITRE ATT&CK T1564

• ADS allows malware to hide files by attaching them to existing files in NTFS.
• Sysmon Event ID 15 logs newly created and accessed streams.
• Example: Hunting_ADS.evtx in Event Viewer reveals a hidden file inside another file (not_malicious.txt:malicious.txt:$DATA).
• Analysts can list ADS using dir /r in PowerShell.

Detecting Remote Threads – MITRE ATT&CK T1055

• Attackers use remote thread creation for DLL Injection, Thread Hijacking, and Process Hollowing.
• Sysmon Event ID 8 detects suspicious remote thread creation.
• Example: Detecting_RemoteThreads.evtx shows powershell.exe creating a remote thread in notepad.exe, a common Reflective PE Injection technique.

Using PowerShell for Evasion Detection

• Analysts can filter logs using Get-WinEvent with XPath queries.
• Example command to detect remote thread creation: powershellCopyEditGet-WinEvent -Path <Path to Log> -FilterXPath '*/System/EventID=8'

By leveraging Sysmon logs and PowerShell queries, analysts can detect malware that attempts to evade security measures.

Questions

Read the above and practice detecting evasion techniques

Answer: No answer needed

Task 10: Practical Investigations

Alright, it is time for a lot of practice! We are going to look at the following scenarios:

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.evtx.

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.evtx.

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.evtx

and C:\Users\THM-Analyst\Desktop\Scenarios\Investigations\Investigation-3.2.evtx.

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.evtx.

A total of 20 questions to answer. Are you ready? Let’s go!

Questions

What is the full registry key of the USB device calling svchost.exe in Investigation 1? 

Load up the investigation 1 log file.

Before just rushing to the answer, it is important to understand what we are looking at. Let’s start looking at the bottom one (the earliest process);

This shows the process WUDFHost.exe being created.

WUDFHost.exe (Windows User-Mode Driver Framework Host Process) is a legitimate Windows process that helps user-mode drivers communicate with the system. This process is being executed by svchost.exe, which is normal behavior since Windows services often rely on svchost.exe. This seems expected as WUDFHost is often involved in handling USB devices, such as USB flash drives, external hard drives, or other Plug and Play devices.

In the event above (with event ID 3), we see more interesting things:

Network connection detected:
RuleName: 2018-03-06 06:57:48.708
UtcTime: {2ca4c7ef-396e-5a9e-0000-00104e1a0100}
ProcessGuid: 804
ProcessId: 0
Image: NT AUTHORITY\LOCAL SERVICE
User: udp
Protocol: true
Initiated: false
SourceIsIpv6: 172.30.1.169
SourceIp: WIN-7JKBJEGBO38
SourceHostname: 68
SourcePort: 0
SourcePortName: false
DestinationIsIpv6: 255.255.255.255
DestinationIp: 
DestinationHostname: 67
DestinationPort: 0
DestinationPortName: %18

In this we see a DHCP traffic, more specifically a DHCP Discovery:

• UDP port 68 is used by DHCP clients.
• UDP port 67 is used by DHCP servers.
• A system will broadcast a DHCP Discover packet from port 68 to port 67 on 255.255.255.255 when requesting an IP address.

This could be a concern if the source IP is unknown or unauthorized (possible rogue device or attacker trying to sniff traffic,

Following is the event with ID 9:

RawAccessRead detected:
RuleName: 2018-03-06 06:57:50.992
UtcTime: {2ca4c7ef-396e-5a9e-0000-00104f270100}
ProcessGuid: 892
ProcessId: 0
Image: \Device\HarddiskVolume3
Device: %6

A RawAccessRead event usually indicates that a process is directly reading from a disk at a low level, bypassing normal file system APIs. It is not clear if this is a system drive being accessed, or the USB key.

The next two events (with ID 13) show the registry being updated:

Registry value set:
RuleName: SetValue
EventType: 2018-03-06 06:57:51.007
UtcTime: {2ca4c7ef-3bec-5a9e-0000-0010d9070e00}
ProcessGuid: 2532
ProcessId: 0
Image: HKLM\SOFTWARE\Microsoft\Windows Portable Devices\Devices\WPDBUSENUMROOT#UMB#2&37C186B&0&STORAGE#VOLUME#_??_USBSTOR#DISK&VEN_SANDISK&PROD_U3_CRUZER_MICRO&REV_8.01#4054910EF19005B3&0#\FriendlyName
TargetObject: U
Details: %8

This event strongly suggests that a USB device (SanDisk U3 Cruzer Micro) was inserted and recognized by Windows.

and:

Registry value set:
RuleName: SetValue
EventType: 2018-03-06 06:57:51.007
UtcTime: {2ca4c7ef-396e-5a9e-0000-001007c50000}
ProcessGuid: 616
ProcessId: 0
Image: 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
TargetObject: U
Details: %8

This event indicates that the registry value for the SanDisk U3 Cruzer Micro USB device was updated once again, specifically related to its FriendlyName entry.

This is the registry key we are looking for. HKLM\System\CurrentControlSet\Enum is typically where system-level information about connected hardware devices (like USB storage devices) is stored. When looking for USB device details in an event involving svchost.exe, this is generally the registry path where the system stores essential device enumeration information.

Answer: 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

What is the device name when being called by RawAccessRead in Investigation 1?

Simply look at the events with event ID 9:

The device ID is right there under Image.

Answer: \Device\HarddiskVolume3

What is the first exe the process executes in Investigation 1?

Finally, let’s have a look at the first triggered event with event ID 1.

The first exe the process executed is rundll32.exe.

Answer: rundll32.exe

What is the full path of the payload in Investigation 2?

Open the investigation 2 log file. If we look at the first event (event ID 1) we can see a clear story:

Observations

• The process executed is mshta.exe, a legitimate Microsoft tool used to execute HTML Application (HTA) files.
• mshta.exe is often abused by attackers to execute malicious scripts.
• The executed command references:
  "C:\Windows\System32\mshta.exe" "C:\Users\IEUser\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\S97WTYG7\update.hta"
• This means mshta.exe is running an HTA file (update.hta) stored in the Temporary Internet Files folder, which suggests that it was likely downloaded from the internet. The hta file is the mentioned payload.

Answer: C:\Users\IEUser\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\S97WTYG7\update.hta

What is the full path of the file the payload masked itself as in Investigation 2?

The parent process is Internet Explorer (iexplore.exe), executed with the command:

"C:\Program Files\Internet Explorer\iexplore.exe" C:\Users\IEUser\Downloads\update.html

This suggests that the user accessed a malicious webpage (update.html), which likely triggered the download and execution of update.hta using mshta.exe.

The payload is masked by the HTML file, and the path to this HTML file is the answer.

Answer: C:\Users\IEUser\Downloads\update.html

What signed binary executed the payload in Investigation 2?

A signed binary is an executable file that has been digitally signed by a trusted authority (such as Microsoft). To remind you, the .hta file is the mentioned payload. As we discussed before, the binary executing this file is C:\Windows\System32\mshta.exe.

Since mshta.exe is a legitimate Microsoft-signed binary, an attacker abused it to execute a malicious HTA script. This is a common LOLBins technique used in malware attacks.

Answer: C:\Windows\System32\mshta.exe

What is the IP of the adversary in Investigation 2?

Time to look at the second log event. This time we look at the one with event ID 3.

The IP of the adversary is found as the destination IP here.

Here are some more reflections:

The process mshta.exe executed a malicious HTA file (update.hta), which likely contained scripts to download more malware or establish communication with an attacker-controlled server.

Port 4443 is commonly used by malware for encrypted communications with a remote attacker. The remote server (10.0.2.18) may be issuing commands to the infected machine (C&C).

The mshta.exe process could be downloading additional malicious scripts or exfiltrating data.

Answer: 10.0.2.18

What back connect port is used in Investigation 2?

The back connect port refers to the port used by the attacker to establish a reverse shell or command-and-control (C2) connection from the compromised machine back to their system.

From the network log:

DestinationIp: 10.0.2.18  
DestinationPort: 4443  

This means port 4443 on 10.0.2.18 is the back connect port.

Answer: 4443

What is the IP of the suspected adversary in Investigation 3.1?

Open the investigation 3.1 log file. We have 9 log entries this time. We can find the destination IP on the first event:

We see a connection being made from 172.16.199.179 towards the machine at 172.30.1.253 on port 80. This is likely an endpoint connecting to a C&C server running Empire.

Answer: 172.30.1.253

What is the hostname of the affected endpoint in Investigation 3.1?

The answer to this question is also on the above screenshot. Look for it next to SourceIp, or image.

Answer: DESKTOP-O153T4R

What is the hostname of the C2 server connecting to the endpoint in Investigation 3.1?

Once more, look at the above screenshot. This time look for the DestinationIp.

Answer: empirec2

Where in the registry was the payload stored in Investigation 3.1?

The next 5 events concern the registry so let’s look at these. They are the events with event ID 12 & 13. Have a look around. The third event (chronologically speaking) is of interest:

Here we see a obfuscated PowerShell script saved in Base64. Definitely suspicious!

PS: Using CyberChef we can actually read it:

Answer: HKLM\SOFTWARE\Microsoft\Network\debug

What PowerShell launch code was used to launch the payload in Investigation 3.1?

The answer to this question can be found in the second event with event ID 13:

Answer: “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;

What is the IP of the adversary in Investigation 3.2?

Time to change to the Investigation 3.2 log, which covers 24 events! Let’s start with the first one, in which we see a network connection being established between 172.168.103.167 and 172.168.103.188. This second IP is the answer we are looking for!

Answer: 172.168.103.188

What is the full path of the payload location in Investigation 3.2?

Have a look at the following event:

This is a very suspicious event!

A daily scheduled task named Updater is being created to execute hidden PowerShell commands. The payload is being delivered by the use of IEX (Invoke-Expression) – a known red flag in PowerShell for executing code.

The commands get Obfuscated: Uses FromBase64String() combined with: $(cmd /c 'more < c:\users\q\AppData:blah.txt') This means the script is hiding its base64-encoded payload in an Alternate Data Stream (ADS) named blah.txt.

This means that the attacker is storing a malicious payload in an ADS (AppData:blah.txt) to avoid detection. It gets decoded and executed silently every day via a scheduled task. This is to attempt persistence on the system in a stealthy manner. Anway, the payload is stored here:

Answer: c:\users\q\AppData:blah.txt”’

What was the full command used to create the scheduled task in Investigation 3.2?

See above.

Answer: “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”’))))\””.

What process was accessed by schtasks.exe that would be considered suspicious behavior in Investigation 3.2?

We need to have a look at the events with event ID 10. Both show us lsass.exe (Local Security Authority Subsystem Service) is trying to access schtasks.exe, the process responsible for creating the malicious task. lsass.exe is a critical Windows security component that should not usually interact directly with schtasks.

So, the process is lsass.exe.

Answer: No answer needed.

What is the IP of the adversary in Investigation 4?

Open the final investigation log, this time filled with 13 events. We can do this! This one is very similar to earlier questions. Look at the event with ID 3 and look for the DestinationIp.

Answer: 172.30.1.253

What port is the adversary operating on in Investigation 4?

Yay, easy one again. Port 80, found right underneath the previous question!

Answer: 80

What C2 is the adversary utilizing in Investigation 4?

Well, I lied before. This question is between the previous two answers 🙂

Answer: empire

Congratulations on completing Sysmon!!!

Congratulations on completing the Sysmon room! This was a great follow up on the earlier rooms of the Endpoint Security Monitoring module, including Windows Event Logs. I hope you learned as much as I did!

Come back soon for more walkthroughs of rooms on TryHackMe and HackTheBox, and other Cybersecurity discussions. Find more of my walkthroughs here.

Like my articles?

You are welcome to comment on this post, or share my post with friends. I would be even more grateful if you support me by buying me a cup of coffee:

I learned a lot through HackTheBox’s Academy. If you want to sign up, you can get extra cubes, and support me in the process, if you use the following link:

https://referral.hackthebox.com/mzwwXlg