The System-Account Fingerprint of Files Pushed Over SMB

Copying a payload onto the next box over an admin share is one of the oldest moves in the lateral-movement playbook, and it’s still one of the most common things I see in real intrusions. ATT&CK files it under SMB/Windows Admin Shares (T1021.002) for the access and Lateral Tool Transfer (T1570) for the file that rides along. The behavior is dead simple: reach \\target\C$\Windows\Temp, drop a binary, then execute it with a service or a scheduled task. Simple to do, and annoyingly slippery to catch cleanly.

The events everyone reaches for first

When I ask a team how they’d catch this, I almost always hear the same two answers, and both are fine as far as they go. Security Event ID 5140 records that a network share was accessed, with the share name, the requested access, the source address, and the account. Event ID 5145 is the detailed version and adds the relative file path, which is the piece you actually want. If you can afford to run detailed file-share auditing, 5145 is genuinely useful.

The catch is volume and coverage. On a file server, 5145 is a firehose that most SIEM budgets refuse to swallow, so teams turn it off exactly where sharing is busiest and leave it on where nothing much happens. The other option people mention is watching TCP 445 connections, which tells you two hosts talked over SMB but nothing about what crossed. Without packet inspection, and with SMB signing on, port 445 telemetry can’t tell a payload drop from a printer driver sync. Usually.

The trick: watch the receiving end

Here’s the angle I lean on when 5145 isn’t available or isn’t trustworthy. When a file arrives on a host over SMB, the local machine doesn’t write it as the remote user. The SMB server driver in the kernel writes it, and it writes it in the context of the System process, PID 4. Sysmon file-creation telemetry (Event ID 11) captures that write, and the Image field on the event reads as System rather than a normal user-mode process like explorer.exe or a copy utility.

Sit with that for a second, because it’s the whole idea. A file created locally by a person or a normal program shows a real user-mode Image. A file created because someone pushed it in over a network share shows Image as System. So a Sysmon Event ID 11 with Image ending in the System process, landing in a sensitive directory, is a strong signal that a file arrived from somewhere else over SMB rather than being written by anything running on the box. You get this from ordinary process-and-file telemetry, no detailed share auditing required.

What the event actually looks like

In my lab, MDE-backed Sysmon 15 on a Windows Server 2022 target, copying a file to \\target\C$\Windows\Temp\payload.exe from another host produced a Sysmon Event ID 11 where the Image was the System process and the TargetFilename was the full destination path under the admin share. The reason it reads as System is that the inbound write is handled by the server-side SMB driver in kernel context, not by the client utility on the sending machine, so the local file creation genuinely has no user-mode process behind it to name. The user who initiated the copy doesn’t appear on that Event ID 11 at all, which is the one real limitation, so the file-creation event tells you what landed and where, but not who sent it. That’s fine, because I don’t use this rule alone. I pair the Sysmon 11 with the corresponding 5145 or a 4624 network logon around the same timestamp on the same host, and the network logon or share event supplies the source address and the account. One event gives me the artifact, the other gives me attribution.

The other pairing I care about is what comes next. A staged file that just sits there is a nuisance; a staged file that executes is an intrusion. Lateral tool transfer almost always precedes remote execution, so I keep a follow-on correlation that watches for a service install (System Event ID 7045) or a scheduled-task registration referencing a path close to where the System-context write just landed. When the file-drop event and the execution event share a directory and a tight time window, the sequence tells the whole story in two lines, and it moves straight to an analyst rather than sitting in a hunt backlog.

Writing the rule

The rule I run is narrow. Sysmon Event ID 11 where Image is the System process (or ProcessId equals 4) and TargetFilename falls inside a directory an attacker actually stages into: the Windows directory, System32, Temp, ADMIN$ territory, startup folders, anything you’d never expect to receive files over the network during normal operation. I deliberately do not alert on every System-context file write, because there are legitimate ones, and I’ll get to those. Scoping by destination path is what turns this from noise into a catch. Then a second correlation stitches the file-creation event to a network logon on the same asset inside a tight time window, so the alert that reaches an analyst already carries the source host and the account that pushed the file.

The false positives

I want to be straight about where this trips. Enterprise software distribution is the main source of benign System-context writes over SMB: patch tooling, configuration management, DFS replication on file servers, and backup agents restoring data all move files onto hosts in ways that can resemble the pattern. The good news is those are predictable. Your patch server pushes from a known address, on a schedule, to known paths, and it does it constantly, so it baselines out quickly with a source-and-path exclusion. Clustered and DFS-replicated file servers are the noisiest environment for this technique and honestly the place I’d reach for 5145 instead if I could afford it. On endpoints and non-file-servers, which is where lateral movement actually lands, the System-context write into a sensitive directory is quiet enough to alert on directly. This catches a lot of it, not all of it, and I’d never sell it as a single-rule solution. It’s a cheap, high-signal tripwire that works when the expensive telemetry is missing.

If you’re building out lateral-movement coverage more broadly, the 2026 lateral movement detection overview puts this technique next to the credential and remote-execution pieces it usually travels with, and the older lateral movement via administrative protocols notes cover the execution half that tends to follow a file drop like this one.