Network share created
A new SMB share was defined on this host (LanmanServer\Shares\<name>).
What it detects
A new SMB share was defined on this host (LanmanServer\Shares\<name>).
Attackers create shares for two reasons: to stage tooling somewhere reachable from other machines, and to collect data before exfiltration — copying to a share is quieter than uploading, and it survives the session that created it. A share created during an intrusion is also a persistence artefact, because it stays until someone notices and removes it.
Medium severity: sharing a folder is an ordinary administrative act, and the finding is in the circumstances rather than the event.
MITRE ATT&CK mapping
False positives and triage
File servers and anyone administering one create shares as part of the job, so on those hosts this is background. It is far more interesting on a workstation or on a server that has no file-sharing role.
To confirm: the share's path and name are in the event. A share rooted at a drive letter or a system directory grants far more than a folder share; a name ending in $ is hidden from browsing, which is a deliberate choice worth asking about. Then check WHO created it and what was written there afterwards — a share created minutes before a burst of file copies is staging, and the files involved are what you want to recover.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 60%. Source: rules/windows/network_share_created.yaml, licensed under the Apache License 2.0.
id: windows.lateral_movement.network_share_created
version: 1.0.0
status: stable
severity: medium
confidence: 0.6
platforms: [windows]
mitre_techniques: [T1135, T1039]
description: |
A new SMB share was defined on this host (`LanmanServer\Shares\<name>`).
Attackers create shares for two reasons: to stage tooling somewhere reachable from
other machines, and to collect data before exfiltration — copying to a share is
quieter than uploading, and it survives the session that created it. A share created
during an intrusion is also a persistence artefact, because it stays until someone
notices and removes it.
Medium severity: sharing a folder is an ordinary administrative act, and the finding
is in the circumstances rather than the event.
match:
registry_path_contains_any:
- '\Services\LanmanServer\Shares\'
correlation_keys: [hostname, user_name]
false_positive_guidance: |
File servers and anyone administering one create shares as part of the job, so on
those hosts this is background. It is far more interesting on a workstation or on a
server that has no file-sharing role.
To confirm: the share's path and name are in the event. A share rooted at a drive
letter or a system directory grants far more than a folder share; a name ending in
`$` is hidden from browsing, which is a deliberate choice worth asking about. Then
check WHO created it and what was written there afterwards — a share created minutes
before a burst of file copies is staging, and the files involved are what you want
to recover.
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.