Threat Detection Engineering

• Threat Detection: Detecting a Webserver Attack
• Threat Intelligence for SOC
• Detection Engineering vs Threat Hunting
• Yara 101
• Threat Intelligence Tools – Abuse.ch
• Threat Intelligence Tools – URLScan.io
• Custom detection rule with the MITRE ATT&CK framework in Splunk
• Investigate SQLi attacks using Splunk
• Splunk: Search Processing Language (SPL) Basics
• Practical Threat Hunting using Elastic SIEM: Hunting for Stuxbot
• MITRE Framework
• SOC Tools and Useful Links
• ELASTIC SIEM: Kibana Query Language (KQL) 
• SOC Home LAB: Elastic SIEM Installation
• MISP (Malware Information Sharing Platform)

Views: 171

Based on the INTRODUCTION TO THREAT HUNTING & HUNTING WITH ELASTIC module from HTB-Academy

Hunting for Stuxbot

The Stuxbot cybercrime group operates with a broad scope, seizing upon opportunities as they arise, without any specific targeting strategy – their motto seems to be anyone, anytime.  The primary motivation behind their actions appears to be espionage (no indications for data exfiltration or ransomware blackmails).

Tactical Threat Intelligence Information

The group primarily leverages opportunistic-phishing for initial access, exploiting data from social media, past breaches, and corporate websites.

Initial Breach

Initial Breach is though a phishing email – posing as an invoice remainder- with a link to malware hosted on a file hosting service. The hosted OneNote file (invoice.one) features a HIDDEN button that triggers an embedded batch file. This batch file -acting as a stager- then fetches PowerShell scripts.

RAT Characterstics

The RAT deployed in this attack is capable of capture screen dumps, execute Mimikatz, provide an interactive CMD shell on compromised machines, and so forth.

Persistence

All persistence mechanisms utilized to date have involved an EXE file deposited on the disk.

Lateral Movement

Stuxbot utilises two distinct methods for lateral movement:

• Leveraging the original, Microsoft-signed PsExec
• Using WinRM

Indicators of Compromise (IOCs)

As found in the threat intel report, the following provides a comprehensive inventory of all identified IOCs to this point.

OneNote File:

• https://transfer.sh/get/kNxU7/invoice.one
• https://mega.io/dl9o1Dz/invoice.one

Staging Entity (PowerShell Script):

• https://pastebin.com/raw/AvHtdKb2
• https://pastebin.com/raw/gj58DKz

Command and Control (C&C) Nodes:

• 91.90.213.14:443
• 103.248.70.64:443
• 141.98.6.59:443

Cryptographic Hashes of Involved Files (SHA256):

• 226A723FFB4A91D9950A8B266167C5B354AB0DB1DC225578494917FE53867EF2
• C346077DAD0342592DB753FE2AB36D2F9F1C76E55CF8556FE5CDA92897E99C7E
• 018D37CBD3878258C29DB3BC3F2988B6AE688843801B9ABC28E6151141AB66D4

Hunting For Stuxbot With The Elastic Stack

The Task

Our task centers around a threat intelligence report concerning a malicious software known as “Stuxbot”. We’re expected to use the provided Indicators of Compromise (IOCs) to investigate whether there are any signs of compromise in our organization.

The Hunt

The sequence of hunting activities is premised on the hypothesis of a successful phishing email delivering a malicious OneNote file. If our hypothesis had been the successful execution of a binary with a hash matching one from the threat intelligence report, we would have undertaken a different sequence of activities.

 The Threat Intelligence indicates that initial compromises all took place via “invoice.one” files. A comprehensive search can be initiated based on Sysmon Event ID 15 (FileCreateStreamHash), which represents a browser file download event. We’re assuming that a potentially malicious OneNote file was downloaded from the organization’s email provider.

event.code:15 AND file.name:*invoice.one

The query returns 3 hits.

However, we are not yet sure if this file is the same one as mentioned in the Threat Intell. If we further analyze the event log by inspecting the entire content, it reveals that the MSEdge browser was the application used to download the file (refer process.name and process.executable fields).

We can corroborate this information by examining Sysmon Event ID 11 (File create) and the “invoice.one” file name. This method is especially effective when browsers aren’t involved in the file download process. The query is similar to the previous one, but the asterisk is at the end as the file name includes only the filename with an additional Zone Identifier, likely indicating that the file originated from the internet.

event.code:11 AND file.name:invoice.one*

How Does Windows Identify the Source of the Files?

In a phishing attack, data downloaded from the internet is handled by a browser application running on Windows. Browsers create an Alternate Data Stream named “Zone.Identifier,” whenever such data is downloaded and a “ZoneId” is added to this stream, representing the zone from which the file originated. For additional info on Zone.Identifier

So far, we have the following information,

Let’s inspect if there were any network connections around the time of the download happened. We can use Sysmon Event ID 3 for this purpose. We’ll find that Sysmon has no entries. This is a common configuration to avoid capturing network connections created by browsers, which could lead to an overwhelming volume of logs, particularly those related to our email provider.

This is where IDS logs prove invaluable. We should filter and examine the DNS queries that Zeek has captured from WS001 during the interval from 22:05:00 to 22:05:48, when the file was downloaded.

source.ip:192.168.28.130 AND dns.question.name:*

There are 22074 hits.

There are 22074 hits for the query. Let’s try to identify major sources of noise and apply filters on the known noisy ones. Also let’s limit the search period to the specified time March 26th 2023 @ 22:05:00 to March 26th 2023 @ 22:05:48.

Now the results are reduced to 256 hits after applying the filters.

Let’s now investigate the entries for any DNS queries related to file hosting services and other correlated actions on the victim computer.

User accessed the email:

External file hosting services were contacted from the victim machine:

Defender SmartScreen scanning a file (normally occurs when a file is downloaded in Edge):

From this data, we infer that the user accessed Google Mail, followed by interaction with “file.io”, a known hosting provider. Subsequently, Microsoft Defender SmartScreen initiated a file scan, typically triggered when a file is downloaded via Microsoft Edge. Expanding the log entry for file.io reveals the returned IP addresses (dns.answers.data or dns.resolved_ip or zeek.dns.answers fields) as follows.

34.197.10.85, 3.213.216.16

This information corroborates that a user, Bob, successfully downloaded the file “invoice.one” from the hosting provider “file.io”.

Hypothetically, if “invoice.one” was accessed, it would be opened with the OneNote application. So, the following query will flag the event, if it transpired. 

event.code:1 AND process.command_line:*invoice.one*

Indeed, we find that the OneNote file was accessed shortly after its download, with a delay of roughly 6 seconds. Now, with OneNote.exe in operation and the file open, we can speculate that it either contains a malicious link or a malevolent file attachment. In either case, OneNote.exe will initiate either a browser or a malicious file. Therefore, we should scrutinize any new processes where OneNote.exe is the parent process. The corresponding query is the following. Sysmon Event ID 1 (Process creation) is utilized.

event.code:1 AND process.parent.name:"ONENOTE.EXE"

There were 3 hits, however the third one falls outside the investigation window. So, let’s ignore it for now.

 Examining the other two results:

• The middle entry documents (when expanded) a new process, OneNoteM.exe, which is a component of OneNote and assists in launching files.
• The top entry reveals “cmd.exe” in operation, executing a file named “invoice.bat”. Here is the view upon expanding the log.

Now we can establish a connection between “OneNote.exe”, the suspicious “invoice.one”, and the execution of “cmd.exe” that initiates “invoice.bat” from a temporary location (highly likely due to its attachment inside the OneNote file). The question now is, has this batch script instigated anything else? Let’s search if a parent process with a command line argument pointing to the batch file has spawned any child processes with the following query.

event.code:1 AND process.parent.command_line:*invoice.bat*

This query returns a single result: the initiation of PowerShell, and the arguments passed to it appear conspicuously suspicious (note that we have added process.name, process.args, and process.pid as columns)! A command to download and execute content from Pastebin, an open text hosting provider! We can try to access and see if the content, which the script attempted to download, is still available (by default, it won’t expire!).

Yes, it is! This behavior resembles the IOCs stated in the Threat Intell report, that a PowerShell Script from Pastebin will be downloaded.

To figure out what PowerShell did, we can filter based on the process ID and name to get an overview of activities.

process.pid:"9944" and process.name:"powershell.exe"

Immediately, we can observe intriguing output indicating file creation, attempted network connections, and some DNS resolutions leverarging Sysmon Event ID 22 (DNSEvent). By adding some additional informative fields (file.path, dns.question.name, and destination.ip ) as columns to that view, we can expand it.

Now, this presents us with rich data on the activities. Ngrok was likely employed as C2 (to mask malicious traffic to a known domain). If we examine the connections above the DNS resolution for Ngrok, it points to the destination IP Address 443, implying that the traffic was encrypted.

We have already detected a C2 IP address (18.158.249.75) from the above process. Let’s investigate further by inspecting DNS queries for “ngrok.io” to see if there are any other C2 servers involved in the attack.

Yes, there is a second C IP address involved in the attack (3.125.102.39). The newly discovered IP also indicates that connections continued consistently over the following days.

Thus, it’s apparent that there is sustained network activity, and we can deduce that the C2 has been accessed continually. Now, as for the earlier uploaded executable file “default.exe” – did that ever execute? By probing the Sysmon logs for a process with that name, we can ascertain this. Note that the process.name, process.args, event.code, file.path, destination.ip, and dns.question.name fields were added as columns.

process.name:"default.exe"

If we scroll up there’s further activity from this executable, including the uploading of “payload.exe”, a VBS file, and repeated uploads of “svchost.exe”.

Indeed, it has been executed – we can instantly discern that the executable initiated DNS queries for Ngrok and established connections with the C2 IP addresses. It also uploaded two files “svchost.exe” and “SharpHound.exe”. SharpHound is a recognized tool for diagramming Active Directory and identifying attack paths for escalation. As for svchost.exe, we’re unsure – is it another malicious agent? The name implies it attempts to mimic the legitimate svchost file, which is part of the Windows Operating System.

At this juncture, we’re left with one question: did SharpHound execute? Did the attacker acquire information about Active Directory? We can investigate this with the following query (since it was an on-disk executable file).

process.name:"SharpHound.exe"

Indeed, the tool appears to have been executed twice, roughly 2 minutes apart from each other.

It’s vital to note that Sysmon has flagged “default.exe” with a file hash (process.hash.sha256 field) that aligns with one found in the Threat Intel report. This leads us to question whether this executable has been detected on other devices within the environment. Let’s conduct a broad search. Note that the host.hostname field was added as a column.

process.hash.sha256:018d37cbd3878258c29db3bc3f2988b6ae688843801b9abc28e6151141ab66d4

Files with this hash value have been found on WS001 and PKI, indicating that the attacker has also breached the PKI server at a minimum. It also appears that a backdoor file has been placed under the profile of user “svc-sql1”, suggesting that this user’s account is likely compromised.

Further down the same log, we notice “svc-sql1” in the user.name field, thereby confirming the compromise of this user.

From the available data so far, it seems that the earlier uploaded PowerShell script, seemingly designed for Password Bruteforcing. We know that this was uploaded on WS001, so we can check for any successful or failed password attempts from that machine, excluding those for Bob, the user of that machine (and the machine itself).

(event.code:4624 OR event.code:4625) AND winlog.event_data.LogonType:3 AND source.ip:192.168.28.130

The results are quite intriguing – two failed attempts for the administrator account, roughly around the time when the initial suspicious activity was detected. Subsequently, there were numerous successful logon attempts for “svc-sql1”. It appears they attempted to crack the administrator’s password but failed. However, two days later on the 28th, we observe successful attempts with svc-sql1.

At this stage, we have amassed a significant amount of information to present and initiate a comprehensive incident response, in accordance with company policies.