Admin share executable write

Severity criticalWindowsSingle eventstablewindows.lateral_movement.admin_share_executable_write · v1.0.0

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

  • T1021.002Remote Services: SMB/Windows Admin Shares· Lateral Movement
  • T1570Lateral Tool Transfer· Lateral Movement

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.

Browse all detections