During engagements, often times you want to remain in memory as much as possible. In some edge cases however, you might need to drop something to disk. This is often the case when leveraging a persistence mechanism for example.
Quite often I’ve seen inexperienced red team(er)s make the mistake of dropping things to disk without any regards of operational security (OPSEC).
There are two things that I want to discuss in this blog:
- binary properties
- code signing
In the vast majority of cases, all legitimate binaries on your computer will have some sort of item properties attached to them, let us take FireFox for example:
On top of that, most binaries will also be signed:
This is true for all binaries, so not just .exe’s, in this case a .dll
But Jean, who cares?
Glad you asked! Let us compare this to your default project that rolls out of your compiler ( in this case a C++ DLL)
Or what about a C# binary?
It should not come as a surprise that your own compiled payloads are pretty obviously standing out when checking them, and obviously they will also not be signed by default.
This makes it pretty much a dead giveaway to analysts that this is not a binary that should live on the system.
Okay Jean, you make a good point… How can we fix this?
Wow, excellent question again random stranger!
Filling up the binary details:
The process to fill out the properties differs from language to language, from an operational point of view. Let us take a look at C# and C++.
Note: it’s not really desired to drop C# Binaries to disk as they are pretty easily reversed unless you have spectacular anti-reversing skills and/or obfuscation, but then again, why would you be reading this?
C#
In Visual Studio, right click your project, select properties and press the Assembly Information button
From here you should be able to put in whatever you like. Please note, if you would spoof a vendor, know that this can cause legal issues. I will not be held responsible for your actions 🙂
Alternatively you could edit the AssemblyInfo.cs file directly as well
If we would check our C# binary now, it looks like this
Which already seems better 🙂
C++
For C++ the workflow is slightly different
You will need to add a resource file by clicking on Resource Files -> add -> new item -> resource file
You will land in a new Resource view browser where you can again right click -> add resource select version
From here you land in a new version file where you can start filling out stuff
Code Signing
You can sign code using a code signing certificate. However, when doing this that would also mean that everything you sign, is immediately traced back to you. So we can use fake code signing as well. The tool I like to use for this is https://github.com/Tylous/Limelighter
This tool allows you to sign software using either a real code signing cert or fake sign it with an arbitrary domain.
Once again, note that spoofing a vendor could potentially have SERIOUS LEGAL implications. Be responsible and think twice before doing it, I will not be held accountable for your shenanigans
Let’s take our implant dll and sign it using a fake code signing cert from redteamer.tips
looking at the properties of this dll, we see a new tab called digital signatures which now includes our fake redteamer.tips certificate. 🙂
Conclusions and other noteworthy projects
I hope this blogpost gives you a bit of an understanding that simply compiling stuff and dropping to disk, hoping for the best, is not really the best approach from a red team perspective.
From a blue team perspective, if you are doing IR, it is always a good thing to check these certs and information for their validity, and if they are missing, this should already give you an indication that you might wanna dig deeper.
Some other noteworthy projects to mention are:
Resource Hacker which allows you to modify your resources post compilation.
ScareCrow: which is able to create shellcode runners with fake certs and fake project details, which is also leveraging Limelighter by the way.. 🙂
Be First to Comment