DFIR Breakdown: Impacket Remote Execution Activity – Smbexec

Smbexec is part of the Impacket tools and allows an attacker to remotely launch programs. It’s like PsExec, but it uses the SMB protocol to get command outputs. In this post, we dive into how it works, what artifacts it will leave behind on the target system, and what it looks like in Cyber Triage.

This is the second post in our series discussing how to detect Impackets remote execution activity. We previously covered using AtExec. 

A quick recap: Impacket is a collection of python classes designed to provide low level access to numerous network protocols. In addition to the python classes, Impacket contains a folder of sample scripts that demonstrate how to use many of the python classes for various use cases such as: dumping passwords from memory, executing commands remotely, interacting with kerberos tickets, and more. Unfortunately, many of these scripts are abused by threat actors. 

Cyber Triage will parse and detect the smbexec artifacts from live and dead systems and we’ll show you what that looks like. You can try the latest Cyber Triage using the 7-day evaluation.

This blog post will discuss the following topics:

• Smbexec Basics
• Smbexec Artifacts
• How Cyber Triage Helps

Smbexec Basics

Basic Use Case

The basic use case is when an attacker wants to execute commands on another system without performing an interactive login. smbexec is one of many ways for them to do this. smbexec requires them to have credentials on the target system, either from running as a domain authenticated user or having password hashes. We’ll cover details later, but the basic steps are:

• The attacker authenticates on the target system and a service is created
• The service runs the command (the program needs to be already on the system)
• The command output is saved to a file
• The attacker gets the output from either the tool accessing the C$ share on the target system and copying it or the target system will access a share on the source system.

The attacker can use this technique if the target system is public facing or within an enterprise.

Semi-Interactive Shell

smbexec.py provides a “semi-interactive” shell, which provides the appearance of a shell (allowing users to type in commands to execute on the remote system and get output back) but lacks full shell capability such as changing directory.

Details

Let’s breakdown the key actions that occur when running smbexec without optional arguments:

1. A Windows Service is created via RCreateService
   1. Service Name: random 8 character name containing only ascii letters (upper and lower case)
   2. Service User: NT Authority\System
   3. Service Path:
      %COMSPEC% /Q /c echo cd ^> \\%COMPUTERNAME%\C$\__output 2^>^&1 > %SYSTEMROOT%\alzwlHHg.bat & %COMSPEC% /Q /c %SYSTEMROOT%\alzwlHHg.bat & del %SYSTEMROOT%\alzwlHHg.bat
2. The service is started via RStartService. There are a few important steps that occur here
   1. Cmd.exe (%COMSPEC%) echos the command plus additional output redirection logic into a randomly named 8 character bat file.
      • %COMSPEC% /Q /c echo cd ^> \\%COMPUTERNAME%\C$\__output 2^>^&1 > %SYSTEMROOT%\alzwlHHg.bat
   2. The bat file is executed from a new cmd.exe which in turn runs the command provided. In the case of the initial connection, the command is always “cd”
      • %COMSPEC% /Q /c %SYSTEMROOT%\alzwlHHg.bat
   3. The bat file is deleted
      • .del %SYSTEMROOT%\alzwlHHg.bat
3. The service is deleted via RDeleteService
4. The command output is displayed to the user by reading the content of the file “__output”  via target systems C$ share 
5. The output file “c:\__output” is deleted
6. User is prompted for input (command that should be ran on the remote system)
7. Each time the user provides a command steps 1-5 occur with the only changes being: the command included in the service path, the randomly named service, and the randomly named .bat file. 

There are several optional arguments that impact what artifacts are left behind:

1. -service-name: Allows the user to control the name of the service instead of having a randomly named service.
2. -share: Allows the user to control the network share location where output will be written to and grabbed from. The default share is C$. 
3. -mode: Controls if an SMB server will be set up on the system running smbexec. This will result in the __output file being written to the local system SMB server instead of the remote system.
4. -shell-type: Determines if powershell will be used to wrap around the user provided command. Note that cmd.exe will still be used as the service executable and that powershell only comes into play for the user provided command. The initial “cd” command that runs on connection will not use powershell. 

Example “whoami” 
%COMSPEC% /Q /c echo powershell.exe -NoP -NoL -sta -NonI -W Hidden -Exec Bypass -Enc JABQAHIAbwBnAHIAZQBzAHMAUAByAGUAZgBlAHIAZQBuAGMAZQA9ACIAUwBpAGwAZQBuAHQAbAB5AEMAbwBuAHQAaQBuAHUAZQAiADsAdwBoAG8AYQBtAGkA ^> \\%COMPUTERNAME%\C$\__output 2^>^&1 > %SYSTEMROOT%\NaEiMBgJ.bat & %COMSPEC% /Q /c %SYSTEMROOT%\NaEiMBgJ.bat & del %SYSTEMROOT%\NaEiMBgJ.bat

We will focus on the latest version of smbexec.py when it comes to discussion around the artifacts generated and detection rules. However, it is important to be aware of the changes that have been made to smbexec.py that have altered its behavior over time. Below are all of the changes we found to impact data in the various artifacts we will be discussing.

1. May 24, 2023: Default service name was updated from “BTOBTO” to random 8 character ASCII name
2. April 27, 2023: Default UNC path in service args changed from \\127.0.0.1\ to \\%COMPUTERNAME%\
3. February 23, 2023: .Bat file in service args changed from %TEMP%\execute.bat to random 8 ASCII character name in %SYSTEMROOT%
4. March 15, 2021: Added -shell-type arg to smbexec script –  for powershell “support”
5. January 7, 2020: Added -service-name to smbexec script – to allow user to rename default service (BTOBTO)
6. August 7, 2017: Changed service startup type from auto start to start on demand
7. May 7, 2016: Changed default output from c:\Windows\Temp\__output to \\127.0.0.1\C$\__output’
8. April 29, 2013: Original release of script. 

How Threat Actors Use smbexec

smbexec is used by threat actors to achieve remote execution capability. This allows a threat actor to perform many tactics such as: reconnaissance, discovery, lateral movement, execution, and collection. Smbexec can be executed from an attacker’s system resulting in DFIR artifacts only on the targeted systems. However, there is nothing preventing an adversary from bringing smbexec into a compromised environment and using it to access other machines. This can be noisy for an attacker as they would need to install python (if not already present) and bring the necessary Impacket python classes. To overcome this issue, threat actors will compile the python script into an executable that can be run without any dependencies. Two common tools that provide such ability are PyInstaller and Auto PY to EXE.

MITRE attack references several groups that are known to use smbexec. The groups Cinnamon Tempest and FIN8 are both documented using smbexec as well as other Impacklet tools. There are write ups from several security companies that document threat actors abusing smbexec such as secureworks review of a ransomware operator. Several other sources for threat actors abusing smbexec can be found here, here, and here. 

Smbexec Artifacts 

There are numerous artifacts created by smbexec.py on the targeted endpoint depending upon  the audit policy in place and the arguments passed to smbexec. We will briefly touch on a few high-value artifacts, so we can discuss detection rules that can be used to identify remote execution via smbexec. 

Event log activity will be the most interesting due to the short lifespan of the Windows services being used (service is created/ran/deleted within milliseconds for each command executed). As a result, we will look at the following event logs:

• Security event log
• System event log

There are numerous other artifacts that can be left behind related to process execution, logon sessions, file creation/deletion, etc… but most if not all require correlation across multiple different events to build up enough information to detect smbexec activity. For example, the NTFS $UsnJrnl can be used to find evidence of the __output file being created/deleted multiple times which can provide insight into when commands were run but not what was run. From here, a timeline of other artifacts like prefetch could be made to see what events correlate to the file creation/deletion events. 

Service Creation – Security Event Log

Within the Security event log, we are interested in 3 groups of artifacts: service created, process created, and network share access. 

Event 4697 is logged each time a Windows service is created. This event provides the following information:

• The time the service was created
• The name of the service
• The path and arguments to the service
• The user that the service will run as
• The user that created the service 

Event 4697 is a key artifact that should be examined when looking for smbexec activity as services are how smbexec achieves its remote execution capability. However, it is not logged by default as it requires Security System Extension auditing to be enabled and is not found on systems older than Windows 2016 and Windows 10. 

Process Creation – Security Event Log

Next is event 4688 (process created) to record process execution history. Key details that can be pulled from this event are:

• Time of command execution == time of service execution
• User that the process ran as == service user
• Command line == service path and arguments
• Parent process. If this is services.exe, we know that the process is a service.

This is the next best event to have when trying to detect smbexec activity if a service created event is not found. However, like the previous events, process creation is not enabled by default and must have Audit process creation turned on as well as a group policy enabled for command line auditing to get the process arguments.

Share Access – Security Event Log

Lastly, we have network share access events. The most interesting event is 5145 (detailed share access) which requires Audit detailed file sharing to be enabled. This event can provide a few unique pieces of information. First, when the service is created, there will be an IPC$ share access with a relative target of “svcctl” indicating service manipulation via RPC. 

The second is when smbexec.py is reading and deleting the temporary output file (__output) via UNC path. For this, look for a relative target name of “__output”.

In both scenarios, the source IP will point to the system that initiated the smbexec activity. Aside from being less verbose than the previously mentioned events, this event is also extremely noisy as it is logged every time a file is accessed via a network share.  

Service Creation – System Log

Event 7045 is nearly identical in information to 4697 in the security event log. A major advantage in monitoring for event 7045 is that the event is logged by default and can be found on systems as early as Windows 7. Note that event 7045 does not contain the user that created the service in the event details. However, this information can be obtained via the user SID in the event system details.

Service Timeout – System Log

Event 7009 indicates that the service did not respond to the Service Control Manager (SCM). Services are not normal executables; they must implement specific methods that can be called by the SCM to start/stop a service. Smbexec.py uses cmd.exe as the service binary which is not setup to be controlled as a service.  As a result, cmd.exe runs and executes its commands but never responds to the SCM which will result in the generation of event 7009. This can be a good indicator that a service is being abused to execute a binary that is not meant to run as a Windows service. 

Detecting Smbexec Activity

There are several detection rules that can be used to detect smbexec activity from the previously discussed artifacts. Some rules are more accurate at identifying smbexec activity. Our recommendation is to combine multiple rules together when possible depending on the data available for the given artifacts. 

We should note that the rules below are based on the latest version of the smbexec.py script. All of the detection rules we will discuss can be evaded by making modifications to the script. That is why it is best to apply multiple rules when possible to account for an attacker modifying one indicator but ignoring or missing others. Even with this risk, many threat actors still use the Impacket scripts as is. 

Writing to Output Location

Flag output folder in command line args. “\__output 2^>^&1 >”  or “\__output 2>&1 >”

Rule 1 focuses on detecting the hard coded pattern for the output file that is in the command line arguments of the service. Note that “>” is escaped with “^” in one version of the pattern. This is because when we match against the arguments from 7045 or 4697 (service created events) the redirect characters must be escaped so the echo command works as intended. 

However, when we look at 4688 (process creation) the full command line without any characters escaped will be recorded.

This pattern will catch any activity run from the latest version of smbexec.py regardless of args used. However, it is trivial to evade this detection rule by modifying the hardcoded output file name in the script.

Batch File Name

Flag on 3 instances of execute.bat or [a-zA-Z]{8}.bat in command line arguments

Rule 2 focuses on another pattern that is hardcoded into the smbexec.py script. The .bat file name cannot be changed nor can the number of times it appears (without manual modification). The rule covers both the old smbexec.py script where the .bat file was named execute.bat and the latest where the .bat file is a randomly named 8 ASCII character name. This can be seen in events 4688, 7045, and 4697. 

Legacy Service Name

Flag service name if “BTOBTO” or a random looking name matching pattern [a-zA-Z]{8}

Rule 3 is targeted specifically at service created events 7045 and 4697. The service name of BTOBTO is no longer the default service name; however, it was one of the most recent changes to smbexec.py, so it is likely to still be used. The random 8 character service name is likely to have false positives but should be easy to weed out by manual review. 

CD Command

Flag initial connection command by searching command line args for  “/Q /c echo cd >” 

Rule 4 aims to identify when smbexec.py was executed. If you recall, when smbexec.py runs, it executes an initial “cd” command to get the current working directory for the user. Following this, all subsequent commands will be from user input and will not have cd unless specifically typed in by the user. 

Reading Output Location

Flag on network share access to __output

Rule 5 is similar to rule 1; however, the goal of this rule is to find network share events referencing access to __output. This is not specific to smbexec.py as a few other Impacket scripts follow the same output file name pattern.

Cmd.exe Services

Flag service created with binary point to cmd.exe or %COMPSPEC%

Rule 6 is not specific to smbexec.py but is important to mention. Any service with a binary of cmd.exe or %COMPSPEC% (powershell.exe and pwsh.exe could also be included) is highly suspicious as they are not service binaries and are often used by attackers to run other commands via the Windows service infrastructure. This mainly pertains to event 7045 and 4697 for service created events. However, it can also be expanded to 4688 (process creation) if the parent process is services.exe.

The rules outlined above can be combined and expanded to flag other sources of evidence that we may not have touched on. The idea is to give readers solid indicators to detect smbexec.py activity rather than specific rules written in a specific rule format. 

How Cyber Triage Can Help

Cyber Triage’s goal is to speed up investigations by aiding users in their detection of suspicious and malicious activity and to build context around events that have occurred. It parses the artifact sources discussed above and will score smbexec activity as “Bad”. 

Processes

Cyber Triage will convert the Event Id 4688 Process Creation events into “Process Artifacts”, which will can show smbexec commands:

You can see in the above table that they were flagged as Bad.  It’s because they match command line patterns used by smbexec.py. One example is shown below and we can infer that this is the first command run for this smbexec.py session as the command being executed is “cd”. Jumping to timeline and looking at the other flagged activity can show us what other commands the threat actor ran. 

Services

Similarly, event 7045 (Service Creation) gets turned into a triggered task in Cyber Triage because the services are started each time the system starts. You’ll see evidence of the smbexec services here, alongside other persistence mechanisms like scheduled tasks and WMI. 

You can see that the above were flagged as bad because they matched smbexec command line patterns (like the process flagging). 

Conclusion

In summary, smbexec allows an attacker to remotely launch commands. Each time a user executes a command, a new service must be created, started, and then deleted, making smbexec fairly noisy. Nonetheless, smbexec is still abused by attackers for remote command execution. 

The most valuable events are 7045 (service created), 4697 (service created), and 4688 (process created). All three of these events contain nearly identical information. The service created events contain the service name, which can be used in detection rules if the default service names are used. An important detail to recall is that 7045 is logged by default while the other two events need to have audit policies enabled for logging to occur. Furthermore, the command lines are slightly different between the service created events and process created events as some characters in the service created command line are escaped. This is important to know when writing up detection rules. 

If you would rather have software look for these indicators instead of you needing ot remember them, then try Cyber Triage. It will quickly identify smbexec activity on devices you are investigating.  You can download a free one week trial version here: https://www.cybertriage.com/download-eval/