Introducing FalconZero v1.0 - a stealthy, targeted Windows Loader for delivering second-stage payloads(shellcode) to the host machine undetected
Reading Time: 10 minutes
You could dominate the world if you read this post from top to bottom and follow all the instructions written here. Proceed at your own discretion, operator!
It is available here: https://github.com/slaeryan/FALCONSTRIKE
Let’s take a quick look at a demo of the FalconZero Implant Generation Utility and then we shall get down to the technicalities.
Ever since I completed my SLAE, I am completely enchanted by the power of shellcode. This feeling was only augmented when I heard a podcast by the wonderful guys at FireEye’s Mandiant Red Team where they advocated the usage of shellcode in red teaming engagements for its flexibility and its ability to evade AV/EDRs among other things.
That’s when I decided to play around with various shellcode injection techniques. Along the way, I thought of a cool technique and made an implant based on it that could deliver Stage-2 payloads to the target machine in a stealthy manner. But why stop there? Why not add some neat features to it and create a framework to aid red teamers to generate these implants as quickly and cleanly as possible.
That was the inception of the FALCONSTRIKE project and FalconZero is the first public release version Loader/Dropper of the FALCONSTRIKE project. It implements the BYOL(Bring Your Own Land) approach as opposed to LotL(Living off the Land). But it’s not your standard run-off-the-mill shellcode loader(more on this later).
You may think of FalconZero as a loading dock for malware. In other words, FalconZero is comparable to an undetectable gun that will fire a bullet(payload) on the host machine.
This is the reason it may not be classified as malware per se but rather a facilitator of sorts that helps the malware get undetected on the host.
But there’s plenty of tools that already do that. So what makes FalconZero special?
While there are many excellent existing projects, this is not designed to be a replacement for them.
This is designed to be unique in its own way and there are quite a few of those features that separate it from the rest. So let’s discuss them one by one.
Separation of the final-stage payload from the Loader
As the real attackers often do, we need to separate the payload into 2 stages:
- Stage-1 payload - A stealthy, lightweight Loader - downloads and injects the Beacon shellcode into a benign host process.
- Stage-2 payload - A full-fledged interactive C2 Agent - Meterpreter/Beacon etc.
Some of the ways of storing the Stage-2 payload(shellcode) in the Stage-1 payload(Dropper) are:
- Storing shellcode in .text section of Dropper
- Storing shellcode in .data section of Dropper
- Storing shellcode in .rsrc section of Dropper etc.
While these techniques remain quite popular but keeping both the shellcode and Dropper bundled together(even if it is encrypted) is probably not a good idea from an OPSEC & risk management perspective.
Why risk combining all the functionality into a single tool?
Imagine if the blue-teams get a hold of an undetonated implant, not only will the Dropper get compromised but also the Stage-2 payload which can’t be any good. Instead, hosting the Stage-2 payload on a server is beneficial because you even have a kill-switch in your hands now(say you want to stop the op. simply delete the payload from the server and that’s it).
This technique also helps us to evade some AV/EDRs if the Stage-1 implant is designed in such a way since Stage-2 has more chances of getting detected.
So it’s best practise from an OPSEC and risk mitigation perspective to separate the Dropper and the shellcode over the network. In other words, the Dropper can connect to a remote server where the shellcode is hosted provided some conditions are met, fetch it from over there, prep it and then proceed to inject it into a host process on-the-fly which is exactly what has been implemented. Remember BYOL? Hopefully, it makes a lot more sense now.
Usage of Github for fetching the Stage-2 payload
Yep! You read that correctly. Github is used as the payload storage area. The implant connects to the appropriate Github repository and fetches the payload from there.
Why such a choice?
Simply because Github is largely considered a legitimate website and network traffic observed to Github will not be flagged as malicious by security products and will probably not even be blocked in most organisations/offices as opposed to using some attacker-owned web server hosting a payload which could be noisy as hell.
Last time I checked, I could not find any publicly available tools that utilised Github as the shellcode docking station so this would be the first of it’s kind. I sincerely hope Github doesn’t ban me from their platform now :)
As a brownie point, this would save the operator precious time and money too ;)
Sensitive string obfuscation
All the sensitive strings in this implant are encrypted using the XOR algorithm with a key that is commonly found in binaries. This would make the job of extracting the URL string and other information from the binary using static analysis impossible.
Feel free to test it using FLOSS. Extract it, chmod +x and test using:
This is something that I have spoken of before. Instead of having malicious code that executes on arbritrary systems, FalconZero comes with a targeting feature which prevents its execution on non-targeted assets and ensuring deployment only happens iff host is the intended target.
But we as red teams why should we care about it? This is why:
- To prevent the accidental breaking of the rules of engagement. This will ensure that the malcode doesn’t end being executed on any unintended host which are out of the scope.
- To hinder the efforts of blue teams trying to reverse engineer the implant on non-targeted assets and thwart analysis on automated malware sandboxes.
Okay, but how do we implement this?
Using something known as an environmental keying factor which could be any network/host specific identifier that is found out previously by reconnoitering the target.
By hard-coding that value in the implant and comparing it at runtime, we can verify whether the executing host is the intended target or not.
One problem that arises from this approach is that it would be trivial to extract that identifier from the binary if left in a plaintext format.
So why don’t we hash it? And compare the hashes at runtime instead of the original string?
FalconZero uses the hostname as the environmental keying factor, hashes it using MD5 algorithm and what’s more? It even encrypts that hash using XOR before hard-coding it to thwart all kinds of static analysis. Should the checks fail, the implant shall not execute on the host.
As a result, reverse engineering this implant should be non-trivial.
Think of killdates like a sort of expiry date for implants beyond which the implant will simply not execute. Obviously, this is quite an important feature as you’d want your implants to be rendered useless after the engagement ends.
Address Of Entry Point Injection technique
Thanks to @spotheplanet, FalconZero utilises a shellcode injection technique that goes under the radar of many AV/EDRs since we do not need to allocate RWX memory pages in the host process which is a very noisy action.
Quoting from his blog,
This is a shellcode injection technique that works as follows: 1. Start a target process into which the shellcode will be injected, in suspended state. 2. Get AddressOfEntryPoint of the target process 3. Write shellcode to AddressOfEntryPoint retrieved in step 2 4. Resume target process
Credit goes to Mantvydas Baranauskas for describing this wonderful technique! In the current form, FalconZero injects the payload to
explorer.exe. Of course, this could be modified to suit the purpose of the operator.
There are many hard things in life but generating an implant shouldn’t be one. This is the reason the
generate_implant.py script has been created to make your life a breeze.
The process is as simple as:
First generate your shellcode as a hex string Upload it on Github and copy the Github raw URL For testing(MessageBox shellcode): https://raw.githubusercontent.com/slaeryan/DigitalOceanTest/master/messagebox_shellcode_hex_32.txt git clone https://github.com/slaeryan/FALCONSTRIKE.git cd FALCONSTRIKE pip3 install -r requirements.txt python3 generate_implant.py
Follow the on-screen instructions and you’ll find the output in
bin directory if everything goes well.
AV Scan of FalconZero implant
Upgrades expected in the next release
This is an alpha release version and depending on the response many more upgrades to existing functionalities are coming soon.
Some of them are:
- Integrate various Sandbox detection algorithms.
- Integrate support for more stealthy shellcode injection techniques.
- Integrate function obfuscation to make it stealthier.
- Include a network component to callback to a C2 when a Stage-2 payload is released or to change targets/payloads and configure other options on-the-fly etc.
- Inject to a remote process from where network activity is not unusual for fetching the shellcode - better OPSEC
- Include active hours functionality - Loader becomes active during a specified period of day etc.
Feel free to communicate any further feature that you want to see in the next release. Suggestions for improving existing features are also warmly welcome :)
Support this project
If you find this project useful, consider buying me coffee or a beer(depending on the mood) as a token of appreciation.
You can do it right here: