Admin share executable write
An executable was written to this host over an administrative share (ADMIN$, C$).
What it detects
An executable was written to this host over an administrative share (ADMIN$, C$). That is the transfer half of remote execution: the service binary lands in \Windows\System32 via ADMIN$, then a service is created over the svcctl pipe to run it as SYSTEM. PsExec and every reimplementation of it work this way.
The rule pairs the share with the file extension, because ADMIN$ access alone is routine for management tooling while a binary arriving through it is not.
MITRE ATT&CK mapping
False positives and triage
Software deployment and patching systems push binaries to admin shares by design; in an estate that uses one, this rule needs the deployment server excluded or it will be noisy.
To confirm: take the filename and the source IP together. A deployment tool writes predictable names from a known server on a schedule. A random or single-word filename (blabla.exe, an eight-character string) from a workstation is the finding. Then look for a service created within seconds of the write, and for the same source touching svcctl — the write and the service creation together are conclusive, and the binary itself should be recovered from System32 while it is still there.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 85%. Source: rules/windows/admin_share_executable_write.yaml, licensed under the Apache License 2.0.
id: windows.lateral_movement.admin_share_executable_write
version: 1.0.0
status: stable
severity: critical
confidence: 0.85
platforms: [windows]
mitre_techniques: [T1021.002, T1570]
description: |
An executable was written to this host over an administrative share (`ADMIN$`,
`C$`). That is the transfer half of remote execution: the service binary lands in
`\Windows\System32` via ADMIN$, then a service is created over the `svcctl` pipe
to run it as SYSTEM. PsExec and every reimplementation of it work this way.
The rule pairs the share with the file extension, because ADMIN$ access alone is
routine for management tooling while a binary arriving through it is not.
match:
native_event_id: '5145'
raw_message_regex: '(?i)RelativeTargetName=\S*\.(exe|dll|sys|bat|cmd|ps1)\b'
correlation_keys: [hostname, source_ip]
false_positive_guidance: |
Software deployment and patching systems push binaries to admin shares by design;
in an estate that uses one, this rule needs the deployment server excluded or it
will be noisy.
To confirm: take the filename and the source IP together. A deployment tool writes
predictable names from a known server on a schedule. A random or single-word
filename (`blabla.exe`, an eight-character string) from a workstation is the
finding. Then look for a service created within seconds of the write, and for the
same source touching `svcctl` — the write and the service creation together are
conclusive, and the binary itself should be recovered from System32 while it is
still there.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.
