[BUG]Executable File Written in Administrative SMB Share" uses exact-match AccessMask, missing combined bitmask values

[thegreatmhn]

Search affected

Executable File Written in Administrative SMB Share
(EventCode=5145, admin share write detection)

Current logic

`wineventlog_security` EventCode=5145 RelativeTargetName IN ("*.exe","*.dll")
ObjectType=File ShareName IN ("\\\\*\\C$","\\\\*\\IPC$","\\\\*\\admin$")
AccessMask="0x2"

Problem

AccessMask in EventCode 5145 is a bitmask, not an enum — Windows OR's together every access right requested in a single hex value (per the standard file/pipe access-right bit layout: 0x1=ReadData, 0x2=WriteData, 0x4=AppendData, 0x20=Execute, 0x10000=Delete, 0x20000=ReadControl, 0x100000=Synchronize, etc.).

In practice, SMB clients (including the tooling attackers actually use — psexec, smbclient, Impacket's smbclient.py, CrackMapExec, native net use + copy) rarely request WriteData in isolation. The logged AccessMask is commonly something like:

• 0x100002 (WriteData + Synchronize)
• 0x12019f (generic write/full access bundle)
• 0x1301bf

None of these string-match "0x2", so the rule silently fails to fire on the majority of real-world write events. This is a straightforward, low-effort detection bypass — an attacker doesn't even need to evade deliberately; default tooling behavior already avoids the exact-match condition.

Reproduction

1. From an attacker host, drop an .exe/.dll onto a target's C$/ADMIN$ share using any standard SMB client (e.g. smbclient.py target -c "put implant.exe" or copy implant.exe \\target\C$\Windows\Temp\).
2. Inspect the resulting EventCode 5145 on the target — AccessMask will almost always be a combined value (e.g. 0x100002), not 0x2.
3. Confirm the ESCU search does not fire despite a genuine executable write to the admin share.

Suggested fix

Replace the exact string match with a bitwise check on the WriteData bit (and optionally AppendData, since some write paths use 0x4). SPL supports bitwise operators in eval/where:

`wineventlog_security` EventCode=5145 RelativeTargetName IN ("*.exe","*.dll")
ObjectType=File ShareName IN ("\\\\*\\C$","\\\\*\\IPC$","\\\\*\\admin$")
| eval AccessMask_dec = tonumber(AccessMask, 16)
| where (bit_and(AccessMask_dec, 2) > 0) OR (bit_and(AccessMask_dec, 4) > 0)
| stats min(_time) as firstTime max(_time) as lastTime count by EventCode ShareName RelativeTargetName ObjectType AccessMask src_user src_port IpAddress dest
| `security_content_ctime(firstTime)`
| `executable_file_written_in_administrative_smb_share_filter`

This preserves intent (flag any write to an exe/dll on an admin share) while correctly matching AccessMask values where the WriteData (0x2) or AppendData (0x4) bit is set, regardless of what else is OR'd in.

Impact

• Severity: High for this detection's stated purpose — it's a full logic bypass, not an edge case. Most legitimate SMB write clients set additional bits by default, so the false-negative rate in practice is likely very high.
• Detection coverage lost: Lateral movement / remote implant staging via admin shares (a common precursor to PsExec-style execution) goes undetected.