Post-Exploitation on Disk
Dropping offensive tooling to disk isn't the greatest idea
Last updated
Dropping offensive tooling to disk isn't the greatest idea
Last updated
The official Mimikatz binary is heavily signatured by Windows Defender, as a result as soon as it drops to disk, it is flagged and deleted.
Signatures, or hashes, are unique identifiers of files or software. This string, or hash, acts like a digital footprint: even a small change in a file's content results in a completely different hash.
Here's how you can get the SHA256 hash of a file from Powershell:
And, chucking this hash into VirusTotal confirms that the hash is known:
... even a small change in a file's content results in a completely different hash...
We can try to use UPX to pack the binary, and change the hash without modifying functionality.
UPX is an advanced executable file compressor. UPX will typically reduce the file size of programs and DLLs by around 50%-70%, thus reducing disk space, network load times, download times and other distribution and storage costs.
Seems like the file hash is different now, we can chuck it back to VirusTotal
There are less detections than before- but still gets detected by Windows Defender
Of course, there are many more things you can do to further obfuscate the mimikatz binary so that you can run it from disk. However, I won't be going into any more detail as I believe that you probably just shouldn't drop offensive tooling to disk.
Recompiling mimikatz from source with bad strings replaced
Invoking mimikatz via Invoke-Mimikatz.ps1 and patching amsi.dll
Instead of directly dropping your post-exploitation tools to disk, an alternative approach is to load your tools directly into memory. This can be achieved using toolkits provided by Command and Control (C2) frameworks, or building your own custom loader (but we're lazy).
