Analysis
Windows Admin Shares experienced a dramatic shift in prevalence from 2018 to 2019, climbing from 10 to three and almost quintupling in threat volume.
Why do adversaries use Windows Admin Shares?
Windows Admin Shares are enabled by default on most Windows systems, and administrators regularly use them to conduct remote host management. Since Windows Admin Share activity is so common, it provides adversaries with a powerful, discreet way to move laterally within an environment. Self-propagating ransomware and cryptocurrency miners, both rapidly emerging threats, rely on Windows Admin Shares.
Many popular lateral movement and execution tools leverage Windows Admin Shares, including:
- PsExec
- RemCom
- CSExec
- PAExec
- Impacket wmiexec
Threat Volume
How do adversaries use Windows Admin Shares?
Adversaries commonly use administrative tools such as PsExec (and the various clones of it) to deploy malware from one machine to another. Admin shares can also be used to store the output of commands for easy access.
The rise of ETERNALBLUE—a prominent, publicly available exploit for a vulnerability in the Windows server message block (SMB) protocol—is a major factor in increased detection of Windows Admin Shares and related activity. To that point, many of our ETERNALBLUE-related analytics map partially to Windows Admin Shares and alert on threats such as:
- WannaCry
- TrickBot
- Several cryptocurrency miners
- Metasploit
- Cobalt Strike
- Other post-exploitation frameworks that use Impacket wmiexec
- Red teams
Sighted with
Windows Admin Shares are often used in conjunction with behaviors relating to Remote File Copy (T1105)—because adversaries commonly use the technique to remotely copy files—and Network Share Discovery (T1135). It can also occur with New Service (T1050) and Service Execution (T1035) because PsExec deploys its receiver executable to admin shares, scheduling a service to execute it.
Customers Affected
Definition
Detection
MITRE’s data sources
- Process use of network
- Authentication logs
- Process monitoring
- Process command-line parameters
Collection requirements
Process use of network
The malicious use of Windows Admin Shares is often accompanied by large numbers of internal network connections to hosts over the SMB protocol on port 445. Monitoring for this type of activity—high volumes of network connections over port 445—has been instrumental in helping us identify adversarial uses of Windows Admin Shares.
Authentication logs, process monitoring, process command-line parameters
Authentication logs are a useful data source for observing certain aspects of malicious Windows Admin Shares. So too is process monitoring, which is often used in conjunction with Scheduled Tasks, Service Execution, and Windows Management Instrumentation (WMI). Process command-line parameters are useful as well, particularly for localhost shares.
Network shares
While MITRE doesn’t list it explicitly, security teams should also consider monitoring network shares (e.g., ADMIN$, C$, and PRINT$), because malicious use of Windows Admin Shares frequently coincides with execution from network shares. An example of this might include the redirection of host or other data in the service of conducting reconnaissance on the localhost admin share.
Detection suggestions
Some telemetry patterns to help detect this type of behavior include the use of cmd.exe with the names of shares such as localhost\ADMIN$ or 127.0.0.1\ADMIN$.
Weeding out false positives
Because admin shares are often used within the enterprise, but are rarely used uniformly across enterprises, generic detection strategies frequently lead to high false positive rates.
If admin shares are being legitimately used, process and process command-line monitoring may allow you to build a list of processes and attributes that are known, so that you can alert on any deviations. For example, if you expect process ntoskrnl.exe to make a local admin share modification to a specific file at path 127.0.0.1\admin$\[name-of-file], then these can be suppressed and any other process may generate an alert.
Other common sources of false positives are inventory and asset discovery systems. Extend the whitelisting strategy above, adding criteria for initiating system(s), frequency, time of day, and other limiting factors. Just be sure to closely monitor the integrity of any system that you add to your list of trusted initiators, as these systems may be useful targets to an adversary.
Testing
Start testing your defenses against Process Injection using Atomic Red Team—an open source testing framework of small, highly portable detection tests mapped to MITRE ATT&CK.
Getting started
View Atomic tests for T1077: Windows Admin Shares. In most environments, these should be sufficient to generate a useful signal for defenders.
Run this test on a Windows system using Command Prompt:
cmd.exe /Q /c hostname 1> \\127.0.0.1\ADMIN$\output.txt 2>&1
Useful telemetry will include:
| Data Source | Telemetry |
|---|---|
| Data Source: Process monitoring | Telemetry: cmd.exe |
| Data Source: Process use of network | Telemetry: connection to 127.0.0.1, access to admin shares |
Review and repeat
Now that you have executed one or several common tests and checked for the expected results, it’s useful to answer some immediate questions:
- Were any of your actions detected?
- Were any of your actions blocked or prevented
- Were your actions visible in logs or other defensive telemetry?
Repeat this process, performing additional tests related to this technique. You can also create and contribute tests of your own.