| name | share-enumeration |
| description | Investigate whether an account is probing hidden/administrative network shares (admin$, c$, ipc$) across one or many systems, consistent with post-compromise discovery or lateral-movement staging. Use when given share-access logs and asked to check for share enumeration, SMB discovery, or admin-share abuse. |
Share Enumeration
MITRE ATT&CK: T1135 (Network Share Discovery); often a precursor to
T1021.002 (SMB/Windows Admin Shares) lateral movement or T1570
(Lateral Tool Transfer).
1. Which question am I trying to answer?
Did account X attempt to connect to multiple hidden/administrative
shares (e.g. admin$, c$, ipc$) on a single system or across multiple
systems — consistent with discovery/staging rather than routine file
access?
2. Which direct evidence do I need?
Per share-access event: Time, Destination, User, Requested Share Name,
plus Success/Failure and Logon Type from the associated
authentication event (share access is a Logon Type 3 — network — logon).
3. Where do I get that data?
- Windows Security.evtx: Event ID
5140 ("A network share object was
accessed") gives the share name and accessing account directly; 5145
("a network share object was checked to see whether client can be
granted desired access") is more granular (per-file) and noisier but
useful for confirming intent when 5140 alone is ambiguous. Both require
Object Access > File Share auditing to be enabled — verify this is
turned on before relying on absence of these events as absence of
activity.
- Windows Security.evtx Event ID
4624 with Logon Type 3 correlates
the share access back to a specific authentication event and source.
4648/4672 alongside share access to admin$/c$ is a stronger signal
of hands-on-keyboard remote administration/lateral tool transfer than
share access alone.
- Sysmon Event ID 3 (network connection) to destination port 445/139
can corroborate SMB activity when share-level auditing isn't enabled, but
won't give you the share name itself.
4. How do I analyze that data to answer the question?
Extend the shared schema with a share_name column (populated only on rows
representing a share-access event), then run:
python3 scripts/analyze.py --input share_events.csv \
--window-minutes 60 --min-distinct-shares 3
Logic: filter to rows with a non-empty share_name, group by user, and
within a sliding --window-minutes window count distinct (destination, share_name) pairs touched — with extra weight/flagging when the share name
matches a known administrative/hidden share (admin$, c$, d$, ipc$,
and other <drive>$ patterns). Windows meeting --min-distinct-shares are
flagged.
Tuning: legitimate backup agents, antivirus/EDR consoles, and
patch-management tools routinely touch admin$/c$ across the fleet —
baseline and exclude those service accounts rather than raising the
threshold enterprise-wide, or you'll lose sensitivity to real enumeration.
5. What answer does the analysis provide?
A list of (user, window, distinct share count, shares touched, hosts touched) findings, with administrative-share hits called out. Interpretation:
- A human/interactive account (not a known service account) hitting
admin$/c$/ipc$ on multiple hosts in a short window is a strong
discovery-phase indicator — this is a classic precursor to PsExec-style
lateral movement or lateral tool transfer.
ipc$ alone, without admin$/c$, is weaker evidence — ipc$ is
used for many legitimate inter-process/RPC purposes (including normal
Windows housekeeping) and enumerating it alone is common background noise.- Failed share-access attempts (access denied) across many hosts still
matter — they show reconnaissance intent even when the account didn't
have rights to actually use what it found; don't filter these out before
counting.
- Cross-reference the accessing account and window against
indiscriminate-lateral-movement and targeted-lateral-movement — share
enumeration is frequently the reconnaissance step immediately preceding
one of those.
