Detecting and Mitigating SMB Admin Share Abuse (T1021.002)

Every Windows machine ships with hidden network shares that only administrators can reach. They exist so IT can copy files and manage systems remotely. They also give an intruder who holds an admin credential a quiet way to move from one machine to the next.

MITRE tracks this as SMB/Windows Admin Shares, technique T1021.002, under the Lateral Movement tactic. It applies to Windows. The common thread is that nothing here is an exploit. The attacker logs in with a valid account and uses a feature that was built for administrators.

How attackers use it

SMB (Server Message Block) is the protocol Windows uses for file, printer and serial port sharing on a network. Linux and macOS speak it too, usually through Samba.

MITRE names three default hidden shares: C$, ADMIN$ and IPC$. With an administrator-level account, an adversary can connect to one of them from another machine and do the following:

• Talk to the remote system through remote procedure calls (RPC).
• Copy files across.
• Run the files they copied, through a remote execution method.

MITRE lists three execution methods that ride on authenticated SMB and RPC sessions: Scheduled Task/Job, Service Execution and Windows Management Instrumentation. So the share access is often only the first half of the story. The second half is a new service, a new scheduled task or a WMI call on the target.

MITRE also notes that adversaries can use NTLM hashes to reach admin shares through Pass the Hash, on systems with certain configurations and patch levels. In that case the attacker never needs to know the actual password.

How to detect it

The MITRE detection strategy for this technique (DET0530) is a multi-event one. A single event is rarely enough. The pattern to look for is an SMB remote file share access followed by lateral movement actions on the target host. Those actions are remote service creation, task scheduling or suspicious process execution, all tied to use of ADMIN$ or C$.

In practice that means joining several log sources:

• Network logons to a server from a workstation that has no business administering it.
• File share access events for ADMIN$, C$ and IPC$. Windows records these as event IDs 5140 and 5145 when object access auditing for file shares is turned on.
• New services (event ID 7045 in the System log) or new scheduled tasks (event ID 4698) created within minutes of that share access.
• Process creation on the target that starts right after a file lands in a system directory.

Think about direction too. Admin shares are normal between a management server and its fleet. They are unusual from one user workstation to another, or from a server to a domain controller it has never touched. Build a baseline of who legitimately uses admin shares, then alert on everything outside it.

How to reduce the risk

MITRE lists four mitigations. In plain steps:

1. Deny remote use of local admin credentials. Do not let local administrator accounts log in over the network. Do not put domain user accounts into the local Administrators group on multiple systems.
2. Consider disabling Windows administrative shares on machines that do not need them. Workstations rarely do.
3. Use the host firewall to restrict SMB. File sharing traffic should reach only the systems that serve files.
4. Never reuse local administrator passwords across systems. Make them complex and unique so they cannot be guessed or cracked. If one machine falls, the password should open nothing else.

The first and fourth steps remove the thing the technique depends on: one credential that works in many places.

Check your own environment

These are read-only checks. Run them in an elevated PowerShell session on a Windows host.

# List shares, including hidden admin shares (Windows PowerShell)
Get-SmbShare

# Show whether automatic admin shares are enabled on a server and a workstation
Get-SmbServerConfiguration | Select-Object AutoShareServer, AutoShareWksta

# Show the members of the local Administrators group
Get-LocalGroupMember -Group "Administrators"

# Confirm file share auditing is on (look for File Share and Detailed File Share)
auditpol /get /category:"Object Access"

Then answer these questions:

• Do any domain user accounts sit in the local Administrators group on many machines?
• Is the local administrator password the same, or built from a pattern, across systems?
• Does the host firewall block inbound SMB (TCP 445) from user subnets to other user machines?
• Do you collect events 5140, 5145, 7045 and 4698 centrally, and can you search them together by host and time?

Quick check

Sources

• MITRE ATT&CK, SMB/Windows Admin Shares (T1021.002)