T1021.002
SMB/Windows Admin Shares
Adversaries abuse Windows Admin Shares and the Server Message Block (SMB) protocol to move laterally and stage payloads for execution.
Pairs with this song Threat sounds
Although Ke$ha dropped hers, Windows still uses the $ sign to mark a shared drive or folder, e.g., ADMIN$
Analysis
Why do adversaries abuse SMB/Windows Admin Shares?
Windows Admin Shares are enabled by default to allow administrators and software to remotely manage hosts on an internal network using the SMB protocol. These shares give adversaries the ability to stage payloads for execution, move laterally throughout a network, and elevate their privilege level. As is often the case with legitimate operating system utilities, benign SMB and Windows Admin Share activity is common on nearly any network, and so adversary actions often blend in with routine software and administrative behavior.
Common shares include:
ADMIN$IPC$C$FAX$PRINT$
How do adversaries abuse SMB/Windows Admin Shares?
One of the most common ways adversaries leverage SMB and Windows Admin Shares is in conjunction with another technique, T1570: Lateral Tool Transfer. In other words, they move payloads from one endpoint to another and execute them. Adversaries do this with native utilities like net.exe or through functionality provided by command and control (C2) frameworks—to name just a couple of the many options available. Additionally, adversaries can use Admin Shares for privilege escalation using tools like PsExec, a Sysinternals tool that enables remote system management.
The following subsections describe two common patterns of malicious activity that we see in detections associated with SMB/Windows Admin Shares:
Remote file copy and retrieval
The following scenario is a good representation of remote file copy and retrieval activity enabled by SMB/Windows Admin Shares. Red Canary detected an adversary leveraging Impacket’s secretsdump feature to remotely extract ntds.dit from the domain controller. Ntds.dit is the database that stores Active Directory information, including NTLM hashes, plaintext credentials (if available), and Kerberos keys. Based on the process lineage and command lines we observed, the adversary leveraged the -use-vss parameter, the default execution method for SMBexec, which uses SMB over port 445 and creates a temporary share to copy the ntds.dit file and remotely parse its contents. An adversary could accomplish this similarly by leveraging tools like WMIexec or MMCexec.
Lateral Movement and Privilege Escalation
Most C2 Frameworks provide built-in functionality for lateral movement or privilege escalation utilizing PsExec-like functionality. In the case of Cobalt Strike, beacons leverage the Service Control Manager to copy a binary to the ADMIN$ share on the target endpoint and leverage a service for execution.
Associated threats
While we frequently detect and stop these threats before they get to the ugly business of lateral movement, we know from incident response and intelligence work that the following threats abuse SMB/Windows Admin Shares:
Common offensive and dual-use tools that leverage SMB/Windows Admin Shares include:
- PsExec
- Impacket’s SMBexec and WMIexec
net.exe- Every C2 framework on the planet
Take Action
While detecting the use of Admin Shares is great, preventing an adversary from being able to leverage them is even better. Most organizations can probably implement the following mitigations with limited impact:
Block SMB connections inbound
Depending on what controls your organization has, it may be possible to block inbound SMB connections to workstations and most servers, depending on their functionality. It’s possible to do this via Group Policy Objects (GPO).
Disable administrative/hidden shares
Beyond limiting SMB-based connections, it may be possible or worthwhile to investigate disabling Admin Shares altogether. As with any preventive action, investigating the viability of this is important before implementing. Within GPO or by directly modifying the registry, you can disable the shares with a simple registry modification.
To disable Admin Shares on a workstation, the key is:
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
DWORD Name = AutoShareWks
Value = 0
To disable Admin Shares on a server, the key is:
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
DWORD Name = AutoShareServer
Value = 0
Disable the Lanman Server service
Another option is to disable the Lanman Server. This service enables support for file, print, and named-pipe sharing over the network.
Deploy Windows Local Administrator Password Policy
Per Microsoft, Windows Local Administrator Password Solution (LAPS) is a Windows feature that backs up the password of local administrator accounts within Azure Active Directory and Windows Active Directory-joined devices. This allows administrators to prevent the reuse of local administrator passwords across devices. By extending the schema of Active Directory, each endpoint configured would generate a unique password and be stored within Active Directory to be retrieved as needed. Implementing LAPS reduces the attack surface when an adversary compromises a single set of local credentials, preventing their use across multiple endpoints. Since Admin Shares require administrative permissions, LAPS can help limit local account usage across the environment.
Additional considerations
- Restrict Service Accounts from being able to:
- log on locally
- log on through Remote Desktop Services
- limit who has the ability to access Admin Shares
References: Mandiant Ransomware Protection and Containment Strategies
Visibility
Note: The visibility sections in this report are mapped to MITRE ATT&CK data sources and components.
Process monitoring
Abuse of SMB/Windows Admin Shares commonly involves the execution of one or more processes, such as PSexec. Defenders can use all varieties of process monitoring to collect information on the execution tools that leverage SMB/Windows Admin Shares, including Impacket’s SMBexec and WMIexec.
Command monitoring
The above processes commonly execute with corresponding command lines, and the relationship between those processes and these commands are two of the primary building blocks for detection.
File monitoring
Whether the intent is lateral movement, privilege escalation, or payload execution, files are created when adversaries abuse SMB/Windows Admin Shares. As such, security teams will want to look out for the creation of files in common shares such as ADMIN$, IPC$, and C$.
Named pipe monitoring
Named pipes can be a great resource for observing SMB activity and lateral movement. While normal SMB activity will use pipes like \wkssvc and \srvsvc, C2 frameworks that implement an SMB-style beacon provide functionality to customize the name of the pipe. In instances where an endpoint does not have direct internet access, adversaries can leverage an SMB beacon and connect via named pipes.
Logon session monitoring
Authentication is required to access Windows Admin Shares, which will generate logon events in Windows. Logon session telemetry is therefore a great source of supplementary detection logic.
Network share monitoring
While the focus is on Admin Shares, it’s common and possible for adversaries to stage payloads or tools on overly permissive network shares, which makes them a relevant data source for detecting malicious activity.
Network traffic monitoring
The SMB protocol leverages port 445 and port 139 in certain circumstances. Tools that collect network traffic will provide visibility into potentially useful data transiting these ports.
Collection
Note: The collection sections of this report showcase specific log sources from Windows events, Sysmon, and elsewhere that you can use to collect relevant security information.
Endpoint detection and response (EDR) tools
Most EDR tools provide some level of visibility into the data sources mentioned above and are a great starting point for collection as security teams start to build out detection coverage for malicious SMB/Windows Admin Share activity.
Sysmon Event ID 1: Process Creation
Sysmon Event ID 1 is a great one-stop-shop for all of your process execution and command-line needs.
Windows Security Event ID 4688: A new process has been created
Similar to Sysmon Event ID 1, 4688 events with command-line argument logging enabled is the best native log source for collecting process telemetry and commands.
Sysmon Event ID 11: FileCreate
As we mentioned above, file creation is often a byproduct of SMB/Windows Admin Share activity, and Sysmon Event ID 11 is a comprehensive source of telemetry for file creation and modification.
Symon Event ID 17 and Event ID 18: Pipe Created and Pipe Connected
Event ID 17 and Event ID 18 create records when pipes are created or connected and contain named pipe names, along with the image paths that either created or connected to the named pipe.
Zeek
Network monitoring tools like Zeek have the ability to capture telemetry directly related to SMB and DCERPC.
Windows Security Event IDs 4624 and 4679
Leveraging Event ID 4624 – Logon, Type 3 can be used to determine remote, network authentication. Additionally, Event ID 4679 – Special Logon can be used to assist in detecting SMBexec execution by correlating Event 4624 and 4679 by Logon ID.
Windows Security Event IDs 5140, 5142, 5143, 5144, and 5145
Collectively, these native logging sources will provide auditing capabilities for whenever network shares are accessed, added, modified, deleted, or checked for access rights.
Sysmon Event ID 3: Network connection
Sysmon Event ID 3 collects network connection activity as well.
Detection opportunities
As of this writing, we have 22 detection analytics that look for SMB/Windows Admin Share abuse. The following detection analytics may require tuning but should offer a good starting point for rooting out suspicious activity in your environment.
Process execution from Admin Share
Depending on the tools your organization uses, process execution from an Admin Share might be infrequent enough that it warrants examination whenever it happens. Certain remote management tools, such as PsExec, may require baselining and exclusions for legitimate use. The following analytic should alert whenever a process executes from an Admin Share.
process == [any process]
&&
command_includes ("ADMIN$" || "IPC$" || "C$")
File writes within Admin Shares
Similar to process execution from an Admin Share, a file write or file modification may occur right before execution—and could be suspicious in certain environments.This analytic should let you know when a potentially suspicious file is written to or modified in an Admin Share.
file_name == (”.exe”,”.dll”,”.bat”)
&&
file_path == (”ADMIN$”,”C$”,”IPC$”)
Default Impacket service creation via registry keys
When creating a service, Impacket’s default naming convention is BTOBTO. In the detection below, we are focusing on services writing registry keys with the default service name of BTOBTO from Impacket.
process_name == services.exe
&&
registry_path == ”HKLM\System\CurrentControlSet\Services\BTOBTO”
There may be other detection opportunities that involve looking for non-standard processes creating services, but the efficacy of these will vary from one environment to the next. Program installation and updates or upgrades, for example, may create or modify services and generate high volumes of false positives on some systems. This is worth monitoring for, as a standard end-user workstation may not be creating services often.
Network-based SMB detection
One option could be to identify a single host making multiple SMB connections to many hosts in a small timespan. While it may not be indicative of malicious behavior by itself, depending on the environment, it could be a starting point for investigation.
Looking for anomalous inbound SMB connections on ports 445 or 135-139 could yield results, but does require baselining for normal activity from printers and file shares. Focusing purely on inbound connections without identifying normal activity will produce a tremendous amount of noise. Determining which hosts should make inbound connections to specific hosts can help you set your baseline.
Testing
Atomic Red Team has four tests currently available for testing Admin Shares.
Execute command writing output to local Admin Share
This atomic test will execute systeminfo and redirect the output to a file within the ADMIN$ share. In order to execute this, administrative permissions will be needed. Open an elevated command prompt or PowerShell terminal and run the following command:
cmd.exe /Q /c C:\Windows\system32\systeminfo.exe 1> \\127.0.0.1\ADMIN$\AtomicAdminTest 2>&1
Map Admin Share
This atomic test will connect to the Admin Share on the localhost. You can remove the password and username parameters or change them to specify the credentials to use. Additionally, you can change the IP address to connect to a remote share.
cmd.exe /c "net use \\127.0.0.1\ADMIN$ #{password} /u:#{user_name}"