Overview

SMB/Windows Admin Shares (T1021.002) is a lateral movement technique where attackers use valid credentials — stolen, brute-forced, or obtained through credential dumping — to access hidden administrative network shares such as C$, ADMIN$, and IPC$ on remote Windows systems. Once connected, attackers can copy files, drop payloads, execute code remotely via scheduled tasks or services, and pivot deeper into the network while blending in with legitimate administrative traffic.

This technique is used in virtually every significant Windows intrusion, from ransomware operators spreading encryptors to nation-state actors moving through enterprise environments. Because SMB is a foundational Windows protocol and admin shares are legitimately used by IT operations, detection requires careful baselining — but the payoff is catching lateral movement before attackers reach their objectives.

Attacker Perspective

Attackers exploit SMB admin shares because they provide authenticated, native-protocol access to remote systems without requiring any additional tooling beyond what Windows already provides.

• PsExec-based execution: Attacker runs psexec.exe \\192.168.1.50 -u DOMAIN\admin -p Password1 cmd.exe to drop a service binary via ADMIN$ and execute it remotely — a staple of both red teams and ransomware gangs like Conti and LockBit.
• Pass-the-Hash with net use: Using Mimikatz-extracted NTLM hashes, attacker runs net use \\TARGET\C$ /user:DOMAIN\admin authenticated via an overwritten LSASS credential — no plaintext password required.
• Impacket SMBExec/WMIExec: Linux-based attacker tools like impacket-smbexec domain/admin:[email protected] connect to IPC$ and execute commands via service creation or WMI without touching disk on the attacker’s machine.
• Cobalt Strike’s jump psexec: Within a Beacon session, the operator runs jump psexec64 TARGET listener_name, which copies a payload to ADMIN$ and creates a temporary service to execute it — automating the entire SMB lateral movement chain.

This technique is attractive to attackers because it uses built-in Windows protocols and legitimate credentials, making it inherently difficult to distinguish from normal IT administration without proper baselining and context-aware detection.

Detection Strategy

Required Telemetry

• Windows Security Event Log — Logon Events: Enable “Audit Logon” and “Audit Account Logon” via GPO (Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Logon/Logoff). Generates Event ID 4624 (successful logon) and Event ID 4625 (failed logon). For SMB lateral movement, focus on Logon Type 3 (network logon). Also enable “Audit Object Access” to generate Event ID 5140 (network share access) and Event ID 5145 (share object access check). Enable via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Object Access → Audit File Share.
• Windows Security Event Log — Service Creation: Enable “Audit Security System Extension” to generate Event ID 7045 (new service installed) in the System log — critical for catching PsExec-style execution where a temporary service is created on the remote host.
• Sysmon — File Creation and Network Connections: Deploy Sysmon with a configuration that captures Event ID 11 (FileCreate) on paths under C:\Windows\ and Event ID 3 (NetworkConnect) for outbound SMB on port 445. Also enable Event ID 7 (ImageLoad) to catch DLL hijacking scenarios like the DCOM iertutil case. Use the SwiftOnSecurity or Olaf Hartong Sysmon configs as a baseline.
• Sysmon — Process Creation: Enable Event ID 1 (ProcessCreate) to capture parent-child relationships when remote services or scheduled tasks spawn child processes on the target host. This is how you’ll see services.exe spawning unexpected binaries.
• Windows Security Event Log — Process Creation: If Sysmon is not deployed, enable “Audit Process Creation” via GPO and enable command-line logging via registry: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1. Generates Event ID 4688 with full command line.
• Zeek Network Logs — SMB: Deploy Zeek with the SMB analyzer enabled. This generates smb_files.log (file operations over SMB) and smb_mapping.log (share mapping events). Key fields: path (the share accessed, e.g., \\HOST\ADMIN$), name (filename written), action (SMB_FILE_OPEN, SMB_FILE_WRITE). Zeek provides network-level visibility independent of endpoint logging and is your backstop when Windows logs are cleared.
• Windows System Event Log — Service Control Manager: Event ID 7045 is generated on the target host when PsExec or similar tools create a new service. No special audit policy is required — System log is on by default, but verify log size and retention are adequate (minimum 1 GB recommended).
• Named Pipe Activity: Enable Sysmon Event ID 17 (Pipe Created) and Event ID 18 (Pipe Connected) to catch IPC$-based named pipe usage. This catches Impacket, Cobalt Strike SMB named pipe comms (e.g., \\.\pipe\mojo, \\.\pipe\status_), and other post-exploitation frameworks that use SMB for C2.

Key Indicators

• Unusual Network Logon to Admin Share: In Windows Security log, Event ID 4624 where LogonType = 3 AND ShareName in subsequent Event ID 5140 equals \\*\ADMIN$, \\*\C$, or \\*\IPC$. Flag especially when SubjectUserName is a privileged account or service account not expected to perform lateral movement.
• Service Created Immediately After Network Logon: On the target host, System Event ID 7045 where ServiceFileName contains paths like %SystemRoot%\ or %TEMP%\, especially when followed within seconds by a 4624 Logon Type 3 from an external source IP. PsExec service names often look like random strings or PSEXESVC.
• PsExec Artifacts — Named Pipe Pattern: In Zeek smb_files.log, path contains \IPC$ AND name ends with -stdin, -stdout, or -stderr AND name does NOT start with PSEXESVC (indicating a renamed PsExec binary). Example: name = "randomtool-stdin".
• File Written to ADMIN$ Share: In Zeek smb_files.log, path contains \ADMIN$ AND action = SMB_FILE_WRITE. In Sysmon Event ID 11, Image = System AND TargetFilename matches C:\Windows\*.exe or C:\Windows\*.dll where the file was newly created.
• Unexpected Parent Process on Remote Execution: In Sysmon Event ID 1 or 4688 on the target host, ParentImage equals services.exe or svchost.exe AND Image is not a recognized service binary (e.g., cmd.exe, powershell.exe, rundll32.exe, or an unknown executable in C:\Windows\Temp\).
• Pass-the-Hash Indicator: In Windows Security Event ID 4624, LogonType = 3 AND AuthenticationPackage = NTLM AND KeyLength = 0 (indicating an LM hash was used or NTLM with no session key exchange, characteristic of PtH). Combined with access to C$ or ADMIN$, this is high-confidence.
• Unusual Named Pipe via IPC$: In Zeek smb_files.log, path matches \\*\IPC$ AND name is not in the known-good list: samr, lsarpc, winreg, netlogon, srvsvc, svcctl, spoolss, wkssvc. Unknown pipe names connecting to IPC$ indicate post-exploitation framework activity.
• High Volume of Admin Share Access Across Multiple Hosts: A single source account or IP accessing C$ or ADMIN$ on more than 5 distinct hosts within a 10-minute window — a strong worm/ransomware propagation signal. Use Event ID 5140 with ShareName filtered to admin shares and count distinct IpAddress targets.

Detection Logic

Rule 1 — Admin Share Access from Non-Standard Source: Broad catch for any admin share connection
IF EventID = 5140 AND ShareName IN ["\\*\\C$", "\\*\\ADMIN$", "\\*\\IPC$"] AND IpAddress NOT IN [trusted_admin_jump_hosts] AND SubjectUserName NOT IN [approved_admin_accounts] THEN alert(medium)

This rule catches the broadest category of admin share access. Expect moderate volume in environments where IT admins directly RDP or manage endpoints — tuning against jump host IPs and known admin accounts is essential before promoting to high priority. It is your widest net and will surface the most noise initially.

Rule 2 — New Service Created Shortly After Remote Network Logon: Catches PsExec-style execution on the target
IF EventID = 7045 AND ServiceFileName MATCHES ["*\\Temp\\*", "*\\Windows\\[a-z0-9]{6,10}\.exe*"] THEN correlate: WITHIN 60 seconds on same host, EventID = 4624 AND LogonType = 3 AND IpAddress != "127.0.0.1" THEN alert(high)

This rule requires correlation between a new service install (System log) and a recent network logon on the same host within 60 seconds. PsExec always creates a service on the target — this is the most reliable behavioral indicator. Expected to be low volume and high fidelity once tuned against known SCCM or RMM tools that also install services remotely.

Rule 3 — Renamed PsExec Detected via Named Pipe Pattern (Zeek): Network-level detection of obfuscated PsExec
IF zeek.smb_files.path CONTAINS "\\IPC$" AND zeek.smb_files.name ENDSWITH ["-stdin", "-stdout", "-stderr"] AND zeek.smb_files.name NOT STARTSWITH "PSEXESVC" THEN alert(high)

The standard SysInternals PsExec creates named pipes prefixed with PSEXESVC. Attackers using custom or renamed PsExec binaries (Impacket’s psexec.py, PAExec, or modified builds) use different pipe names while keeping the -stdin/-stdout/-stderr suffix. This rule has near-zero false positives in most environments and should alert immediately.

Rule 4 — Single Account Accessing Admin Shares on Multiple Hosts (Lateral Movement Sweep): Detects propagation behavior
IF EventID = 5140 AND ShareName IN ["\\*\\C$", "\\*\\ADMIN$"] GROUP BY SubjectUserName, IpAddress COUNT DISTINCT TargetHostname WHERE count > 5 WITHIN 10 minutes THEN alert(critical)

This rule identifies fan-out behavior characteristic of ransomware propagation or automated lateral movement tools. A legitimate admin rarely needs to access the C$ share on more than five distinct hosts in ten minutes. This rule should be treated as a critical alert requiring immediate response. Expected volume: near-zero in most environments — one or two alerts per quarter if the threshold is set correctly.

Tuning Guidance

• SCCM / MECM Software Distribution: Microsoft Endpoint Configuration Manager writes to ADMIN$ and C$ on managed endpoints constantly during patch cycles and software deployments. Exclude by adding the SCCM server’s IP and the SCCM service account (e.g., svc-sccm) to your allowlist: IpAddress IN [sccm_server_ips] AND SubjectUserName = "svc-sccm". Verify the SCCM server’s IP doesn’t change unexpectedly.
• Remote Monitoring and Management (RMM) Tools: Tools like ConnectWise Automate, Kaseya, Datto RMM, and NinjaRMM all use SMB admin shares to deploy agents and scripts. They will generate significant 5140 and 7045 noise. Identify their service accounts and source IPs and build named exclusions: ServiceName STARTSWITH "CW_" OR SubjectUserName = "svc-rmm".
• Backup Agents: Backup software (Veeam, Commvault, Backup Exec) frequently accesses C$ to back up data. These will trigger Rule 1 heavily. Exclude backup server IPs and service accounts: IpAddress IN [backup_server_ips].
• IT Helpdesk and Jump Servers: Admins connecting from a dedicated jump server or bastion host will trigger admin share alerts regularly. Build a maintained list of authorized jump host IPs and admin accounts and exclude them from Rule 1 while still alerting if those accounts are seen initiating SMB from a non-jump-host IP — the latter is a strong compromise indicator.
• Domain Controllers and SYSVOL/NETLOGON Replication: DCs access IPC$ and occasionally ADMIN$ on other DCs during replication. Exclude DC-to-DC traffic on IPC$ by filtering on known DC IP ranges, but do not globally exclude all DC traffic — lateral movement targeting DCs is high-value and must remain visible.
• False Positive on Rule 4 (Sweep Detection): Automated inventory tools (Nessus, Qualys, Rapid7 InsightVM) running credentialed scans will map admin shares across the environment in bursts. Schedule exclusions during known scan windows rather than permanently excluding scanner IPs, to preserve detection capability outside maintenance windows.

When the Alert Fires: Investigation Steps

1. Verify the alert against the raw event. Pull the originating log event directly from your SIEM — confirm the Event ID 5140 or Zeek smb_files.log entry exists with the expected fields (ShareName, IpAddress, SubjectUserName). A missing or malformed raw event may indicate a parsing issue or a synthetic alert; do not proceed with response actions until the raw event is confirmed.
2. Identify and profile the source account and host. Look up SubjectUserName in Active Directory (via your IAM tool or a Get-ADUser query) to determine whether it is a privileged account, a service account, or a standard user. Check the source IP against your asset inventory — if the originating host is a workstation connecting to another workstation’s C$, that is immediately suspicious since workstation-to-workstation admin share access is rare in most enterprises.
3. Pull the full logon and activity context on the source host. On the originating machine, review Sysmon Event ID 1 and Event ID 3 within 10 minutes before the alert. Look for processes like psexec.exe, net.exe, wmic.exe, or unknown binaries initiating the SMB connection. Check Event ID 4688 or Sysmon Event ID 1 for the full command line — a command like net use \\TARGET\C$ /user:DOMAIN\admin or a PsExec invocation confirms attacker activity.
4. Examine what was written to the target share. On the target host, check Sysmon Event ID 11 for files created in C:\Windows\, C:\Windows\Temp\, or the root of C:\ around the time of the alert. In Zeek smb_files.log, filter on action = SMB_FILE_WRITE for the same time window. Hash any identified files and check against VirusTotal or your EDR’s threat intelligence — focus on .exe, .dll, and .bat files.
5. Check for remote execution on the target host. On the target host, review System Event ID 7045 for newly installed services within the activity window — a service installed with a random name or executing from Temp is a near-certain indicator of PsExec-style execution. Also review Sysmon Event ID 1 for processes spawned by services.exe or svchost.exe that are not recognized services, and check Event ID 4688 for command-line execution under those parent processes.
6. Search for further lateral movement originating from the target host. Query your SIEM for Event ID 5140 and 4624 LogonType=3 events where the source IP is now the target host from Step 2 — attackers frequently pivot through multiple hops. Also query Zeek conn.log for outbound port 445 connections from the target host to identify additional victim systems. Build a hop graph: Source → Target → Next Target.
7. Make the escalation decision based on evidence quality. Escalate to a confirmed incident if you observe any two of the following: a file written to an admin share followed by service creation; processes spawned under services.exe that are not recognized; NTLM authentication with KeyLength = 0 (Pass-the-Hash indicator); fan-out to more than three additional hosts; or the source account has no documented reason to access the target host. If all activity maps cleanly to a known admin account, a known management tool, and a scheduled maintenance window, document and close as a false positive — but still verify the exclusion logic is correctly scoped.

Response Playbook

Containment

• Isolate affected hosts — do not power off. Use your EDR (CrowdStrike Network Contain, Defender for Endpoint Isolate, Carbon Black Quarantine) to isolate both the source host and any confirmed target hosts from the network immediately. Leave systems powered on so volatile memory (running processes, network connections, logged-in sessions) is preserved for forensic collection. If no EDR is available, work with network operations to place the host’s switch port into a quarantine VLAN.
• Disable the compromised user account. In Active Directory, immediately disable the account identified in SubjectUserName: run Disable-ADAccount -Identity [username] or use the AD Users and Computers console. If the account is a service account, coordinate with the application owner before disabling, but do not delay more than 15 minutes — prioritize stopping the attacker over application availability.
• Invalidate active sessions and Kerberos tickets. Run Invoke-TrgtKerberosTicketPurge or use AD to reset the account password twice (to cycle the Kerberos key), which invalidates all existing TGTs and service tickets for that account. If Pass-the-Hash is suspected, also reset the machine account password for any hosts the account touched.
• Block lateral movement at the firewall and network level. If the attacker’s source IP is external or from an unexpected subnet, block port 445 (SMB) and 135 (RPC) from that IP at the perimeter and internal firewall immediately. For host-based containment, use Windows Firewall GPO to block inbound SMB on all workstations from non-management subnets: this should be a standing security configuration but apply it as an emergency policy if not already in place.
• Preserve forensic artifacts before remediation. Collect a memory image using WinPMEM or your EDR’s memory acquisition capability from both source and target hosts. Export the relevant Windows event logs (Security.evtx, System.evtx) and Sysmon logs from all involved hosts before any remediation action that might overwrite evidence.

Eradication

• Remove any files dropped via the admin share. Based on the file paths identified in Step 4 of the investigation, delete identified payloads from C:\Windows\Temp\ or other drop locations. Verify deletion using your EDR’s file search capability and confirm the hash is no longer present on disk. Search all other endpoints in your environment for the same file hash using your EDR’s threat hunt capability.
• Remove malicious services created by PsExec or similar tools. If Event ID 7045 identified a rogue service, remove it: sc.exe delete [ServiceName] on the target host. Verify the service binary is also deleted. Check HKLM\SYSTEM\CurrentControlSet\Services\ in the registry for any remaining entries from the rogue service.
• Reset credentials for all accounts involved. Reset passwords for every account that touched any host in the lateral movement chain — not just the initially compromised account. If NTLM hashes were likely stolen (e.g., via Mimikatz), also reset the KRBTGT account password twice (with a 10-hour gap between resets to allow replication) if domain controller access is suspected.
• Hunt for additional persistence mechanisms on all affected hosts. Using your EDR or Autoruns from Sysinternals run remotely, check for new scheduled tasks (Event ID 4698), registry run keys (HKCU\Software\Microsoft\Windows\CurrentVersion\Run), new local accounts (Event ID 4720), and WMI subscriptions. Assume the attacker may have installed multiple persistence mechanisms and check all of them — not just the obvious one.
• Search for the same IOCs across the broader environment. Use your EDR to hunt for the identified payload hashes, the rogue service name, and the named pipe patterns across all endpoints — not just the confirmed victims. Ransomware operators and sophisticated actors often pre-position on many hosts before activating. Finding dormant implants at this stage prevents a second incident.

Recovery

• Re-image rather than clean if confidence is low. If the full scope of the attacker’s access cannot be determined — especially if the host was compromised for more than a few hours before detection — reimage the host from a known-good baseline rather than attempting to clean it. The risk of a missed persistence mechanism outweighs the operational cost of reimaging. Use your standard golden image and verify it is current before deployment.
• Re-enable the user account only after full credential reset and persistence verification. Before restoring account access, confirm that all identified persistence mechanisms have been removed from every host the account touched, passwords have been reset, and MFA is enforced on the account going forward. Document the account restoration with the approving manager and security team.
• Restore hosts to network connectivity in a staged manner. Reconnect hosts to the network one at a time, monitoring for immediate signs of re-infection (outbound port 445 connections, new service creation, unusual parent-child process relationships). Use your EDR to watch each host for at least 4 hours before declaring it clean and moving to the next.
• Monitor all affected accounts and hosts for 72 hours post-remediation. Create temporary high-sensitivity detection rules in your SIEM scoped to the affected accounts, source IPs, and payload hashes with a lower alert threshold than your standard rules. Review these alerts manually during the monitoring window — do not rely solely on automated triage during this period.
• Conduct a post-incident review and update detection coverage. Document the complete attack timeline from initial access through lateral movement, capturing every host touched and every account used. Identify any gaps where the attacker moved undetected and create new detection rules or tuning adjustments to close those gaps. Share new IOCs (hashes, pipe names, service names, C2 IPs) with your threat intelligence platform and contribute them to your ISAC if applicable. Close the incident ticket with a formal lessons-learned entry.