Stuxbot

The present Threat Intelligence report highlights the ongoing and immediate threat posed by the cybercrime collective identified as Stuxbot. This group initiated widespread phishing campaigns earlier this year and demonstrates an opportunistic, non-targeted strategy, exploiting vulnerabilities across a broad range of victims. Their operating pattern suggests an "anyone, anytime" targeting philosophy.

Motivation and Objective

Unlike many financially motivated actors, Stuxbot appears to operate primarily for espionage purposes. There is no current evidence of data monetization activities such as ransomware deployment, blackmail, or theft of intellectual property for resale. Their behavior is consistent with long-term access and covert surveillance objectives.

Target Profile

• Targeted Platforms: Microsoft Windows
• Primary Victims: Windows Users
• Impact Potential: Full system compromise and possible domain escalation
• Risk Level: Critical

Initial Access Techniques

Stuxbot primarily relies on opportunistic phishing to gain initial access. Their campaigns leverage information harvested from social media platforms, exposed credentials from prior data breaches, and publicly available corporate contact data. There is limited evidence of targeted spear-phishing efforts against specific individuals or high-value targets.

Initial Compromise Sequence

The preliminary attack sequence observed in compromised environments is outlined below:

The Available Data

The cybersecurity strategy implemented is predicated on the utilization of the Elastic stack as a SIEM solution. Through the "Discover" functionality we can see logs from multiple sources. These sources include:

Hunt 1 statement: Create a KQL query to hunt for "Lateral Tool Transfer" to C:\Users\Public. Enter the content of the user.name field in the document that is related to a transferred tool that starts with "r" as your answer.

Introduction

Before creating a KQL query to hunt for "Lateral Tool Transfer" to C:\Users\Public, it's important to understand what this technique entails:

Adversaries may transfer tools or other files between systems in a compromised environment. Once brought into the victim environment (i.e., Ingress Tool Transfer) files may then be copied from one system to another to stage adversary tools or other files over the course of an operation.

Adversaries may copy files between internal victim systems to support lateral movement using inherent file sharing protocols such as file sharing over SMB/Windows Admin Shares to connected network shares or with authenticated connections via Remote Desktop Protocol.

Files can also be transferred using native or otherwise present tools on the victim system, such as scp, rsync, curl, sftp, and ftp. In some cases, adversaries may be able to leverage Web Services such as Dropbox or OneDrive to copy files from one machine to another via shared, automatically synced folders.

Source: MITRE ATT&CK - T1570: Lateral Tool Transfer

Exercise

The objective of this exercise is to create a KQL query that identifies instances where files have been copied to the C:\Users\Public directory, which is a common location for adversaries to stage tools or files during lateral movement. With the following query, we can search for events that indicate file transfers to this directory:

event.code:11 AND message:"C:\Users\Public*" AND file.name:R*

event.code:11 : File creation event (Sysmon)
message : Full log message content
file.name : Name of the file involved

This query filters for Sysmon event code 11, which indicates file creation events, and looks for messages that contain the path C:\Users\Public along with file names that start with the letter "r". The result will provide a list of files that have been copied to the public directory, which may indicate lateral tool transfer activity.

The query results show that a file named Ruveus.exe was copied to the C:\Users\Public directory. This file is a known tool used for Kerberos ticket manipulation and is often associated with lateral movement techniques. The user responsible for this action is identified as svc.sql1.

Hunt 2 statement: Create a KQL query to hunt for "Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder". Enter the content of the registry.value field in the document that is related to the first registry-based persistence action as your answer.

Introduction

Before creating a KQL query to hunt for "Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder", it's important to understand what this technique entails:

Adversaries may achieve persistence by adding a program to a startup folder or referencing it with a Registry run key. Adding an entry to the "run keys" in the Registry or startup folder will cause the program referenced to be executed when a user logs in.[1] These programs will be executed under the context of the user and will have the account's associated permissions level.

The following run keys are created by default on Windows systems:

HKEY_CURRENT_USER\Software\Microsoft\ Windows\CurrentVersion\Run

HKEY_CURRENT_USER\Software\Microsoft\ Windows\CurrentVersion\RunOnce

HKEY_LOCAL_MACHINE\Software\Microsoft\ Windows\CurrentVersion\Run

HKEY_LOCAL_MACHINE\Software\Microsoft\ Windows\CurrentVersion\RunOnce

Source: MITRE ATT&CK - T1547: Registry Run Keys / Startup Folder Tool Transfer

Exercise

The objective of this exercise is to craft a KQL query that detects instances where programs have been added to the startup folder or registry run keys—a technique commonly leveraged by adversaries to maintain persistence on a compromised system. However, it is important to note that legitimate software installations may also modify these locations. The following query is designed to identify events that suggest registry-based persistence activity:

event.code:13 AND message:"*\Software\Microsoft\Windows\CurrentVersion\Run*"

event.code:11 : File creation event (Sysmon)
message : Full log message content

The result will display a list of registry modifications associated with startup programs, as returned by the following image:

As we can see, the query results show up to 12 hits. So, how could we identify the malicious first registry-based persistence action? First, we could ignore the entries that are related to legitimate software installations, such as Microsoft Edge coming from msedge.exe. Finally, we could focus on the entries that are suspicious, such as default.exe, powershell.exe and svchost.exe

A sequence of events revealed a multi-stage persistence mechanism, where each binary creates a RunKey entry that launches the next one. The chain begins with powershell.exe, followed by default.exe, which then sets persistence for a suspicious svchost.exe.

Event Timeline

Persistence Chain

  powershell.exe
    ⇓
  default.exe
    ⇓
  svchost.exe (suspicious)

Why svchost.exe is Considered Suspicious

This file is not flagged as suspicious due to its name alone, but because of its non-standard location, execution chain, lack of signature, and use of registry persistence. It is likely a fake svchost.exe deployed as part of the attack chain.

Conclusion

Although default.exe and svchost.exe exhibit clearly malicious behavior, the correct answer for the Hunt is the first registry persistence action: the RunKey created by powershell.exe is LgvHsviAUVTsIN.

Hunt 3 statement: Create a KQL query to hunt for "PowerShell Remoting for Lateral Movement". Enter the content of the winlog.user.name field in the document that is related to PowerShell remoting-based lateral movement towards DC1.

Introduction

Before creating a KQL query to hunt for "PowerShell Remoting for Lateral Movement", it's important to understand what this technique entails:

Adversaries may leverage PowerShell Remoting to execute commands or scripts on remote systems across the network. This capability, built on top of WinRM (Windows Remote Management), facilitates lateral movement by allowing remote execution under valid user contexts. It is commonly used alongside other techniques to expand access, maintain persistence, or escalate privileges. Activity related to PowerShell Remoting is logged under event ID 4104, which captures the content of executed PowerShell script blocks and is a key artifact for detection.

Exercise

As we have said, we could use the event ID 4104 to hunt for PowerShell Remoting activity, but why we can not use the event ID 4648 ? Although event ID 4648 can be associated with the use of explicit credentials, it is not sufficient for detecting remote execution via PowerShell. Instead, event ID 4104 provides direct evidence of such activity.

Event ID Comparison

So the query to hunt for PowerShell Remoting activity towards DC1 is as follows:

event.code:4104 AND message:"DC1"

Once the matching document is found, extract the value from the winlog.user.name field. This is the answer to Hunt 3.