share-enumeration

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.