I have been toying around within my test environment now for a few weeks preparing some payloads and getting to grips with AV evasion. Moving from test and CTF environments to live protected environments, it was the first thing I had to overcome to get anything I know working. I have managed to get quite a few viable payloads working. I am using empire stagers as the initial starting point for these, as I’m working within a windows AD environment and I am familiar with Empire and its features. The next steps will be to explore some of the newer CnC systems and rework their stagers.
These principles should apply to most stagers or payloads. I am not going to provide line for line the payloads or exact steps I used but instead work through the various methods of creating your own payloads and the methodology and tools I have come across. There is no single tool or magic bullet I have found for AV evasion. I expect even the working payloads I have now will become useless eventually. It really is a game of cat and mouse keeping ahead of AV, particularly with new cloud analysis features and sand boxing etc.
My test environment consists of 5 windows VM’s at present.
One a completely unprotected windows 10 client with various tools installed to compile and create and test raw windows payloads.
I have further clients, one a Server 2019 box with the latest defender definitions and everything apart from cloud analysis enabled. Another up to date windows 10 client again with defender, along with another win10 box with Symantec this time. The final machine is a another defender box, this time with full cloud analysis turned on and internet access. This is the final test box.
It is crucial to have your own environment that you can specifically tailor to the specs of your targets. The differences between the antivirus is pretty big. I have found the latest and greatest Defender on 2019 to be the hardest to bypass out of others I have tried but that may just be me.
As mentioned there is not single tool or method to create a viable payload but these are the ones used by me in my process.
- Powershell Studio
- Good understanding of the payload you are using.
- Ability to rewrite / modify PowerShell or python default payloads.
- AMSI bypass techniques
- Good understanding of how your CnC server is working, how to alter its standard settings to look more “normal”.
The Starting point:
During my own tests I found a lot of older documentation basically pointing at single tools and obfuscation methods to bypass older AV. This works great until you hit anything from the last couple of years. Many of the older methods do not take into account or work with newer detection methods. There used to be a time where simply base64 encoding your powershell commands and firing them off would of worked. Now if any one or monitoring system see’s a bunch of base64 being passed by powershell its fairly safe to assume someone is up to no good.
As the basic stager for empire shows it is simply the actual payload encoded into base64 and passed to powershell. As I said before, this used to be a fantastic method. However people and AV are now more than aware of the proliferation of powershell hacking tools and reverse shells. The introduction of AMSI now within modern systems adds yet another layer of complication to using powershell payloads. However it does not make it impossible. Ultimately the AV can not block everything without greatly limiting legitimate processes. There are just a number of steps you have to take to keep the look and running of your program under the scoring systems of most AV’s. As I said this may only get you so far these days with cloud and sand box analysis of your payloads eventually being caught by AV’s and then you have to adapt again.
So the first step, decode that payload and strip off the launcher section. It’s not necessarily needed as is it is a giant red flag for any half decent AV. It can be re added later if you choose to re-encode your payload back in to base64.
Now to examine the raw payload. In the case of the powershell one fling it into a decent editor, I use powershell studio. These same practises can be applied to the python payload. You can also combine that with py2exe to create nice undetectable windows exe’s. Break up the code and make it look a bit more readable.
So now the fun begins. Can you rewrite this? Can you change variable names? Use different functions? Use different methods? Basically can you get this code to work as before but change its makeup. There are great big chunks that can be removed and still maintain functionality. Along with certain AMSI evasion functions we can add later. As I worked through the script and made alterations I checked this on my unprotected windows box to ensure the script was still working as it should. I would also recommend working through the default options on your chosen platform. In empire for example change out the default user agents. Any option that could be identified as a known default option for an empire stager should be changed.
Once you have a working “different” payload now for the cool tools! invoke-obfuscation. What a tool this is. Its a powershell module that allows you to invoke numerous different obfuscation techniques on PowerShell payloads. Its an awesome tool! I would recommend installing powershell on you kali/parrot installs if you haven’t already. It’s a great tool to have in your pocket to quickly encode or obfuscate useful powershell commands to bypass basic AV setups.
Set the script location to your script:
From here you can use “test” to run the powershell command and see if it is running. If you are using this on your Kali box you may encounter normal errors when running the test command due to missing modules or other features. Again often it is best to do this on your test unrestricted windows machine. As you apply more and more layers of obfuscation keep testing.
Once you have a nicely obfuscated script again, test it as you go either by running the script within invoke-obs using test command or output it and test it on your unprotected machine to ensure it works. From here its time to step onto another machine, your machine with AV or if your using a single host enable protection. You may find off the bat with some AV vendors a well obfuscated script will still bypass its AV detection and you are good to go, this I have definitely encountered, except on defender… Again I was pretty impressed with how defender handled my attacks. Particularly for being a freebie. But it has an advantage of being directly integrated into new windows versions allowing for different issues. Time to handle AMSI…
If you attempt to run any “malicious” scripts through powershell on modern systems, you may encounter this.
Powershell basically stabs you in the back. It passes your input to the AV engine for analysis and if what you are trying to run is known or suspicious the AV will block the running of the program. This is where the problem comes in. From what I have seen and understand, most obfuscation will fail against this as it is passing the raw powershell to the AV engine as it executes so it doesn’t matter if its encoded or how it is presented ultimately AV will be inspecting the program as it executes allowing it to pick up the majority of attack attempts with stupid levels of obfuscation. What a pain. However fortunately there are people on the case, much smarter than me. There are a number of AMSI bypass techniques and scripts that can be used to shut down this little inconvenience. For a deeper dive into AMSI explained, have a google round for numerous write ups or have a read here or from Microsoft themselves here. Its a pretty complicated beast but for now I’m just interested in shutting it off. You will need to follow the same steps as used earlier to get an AMSI bypass script working with AV as many of them are flagged by antivirus as they are. I listed a great repo with a few different examples above in the Tools section. So again, break the script down. Change what you can, run the code in segments to find where and what aspects the AV is blocking and alter, obfuscate and encode. Keep testing this against your target OS until you get a working example.
AMSI is also tied into VBscript execution and Microsoft now feeds a lot of program execution back to its AV engine. However all tests are definitely not created equal. There are numerous workarounds described and used by using the excel macro engines and VB scripts that are not subject to as stringent checks. So that is another thing to look into however I have not delved into this so it is out of scope for this article.
Composing the final payload:
I guess you can now see a pattern to this AV evasion malarkey. Its a case of testing editing and taking things apart. I expect there are more technical and smarter ways of doing this but I found it to just be a case by case and step by step process of testing and altering and retesting, this is again why having your own isolated test environment specific to your target is important, testing is key!
So you now should have a working AMSI bypass method tested against your target. Now for the final payload test. I combined a working altered powershell stager with a working AMSI bypass script. So the payload will disable AMSI then run the malicious payload allowing for execution of your chosen stager.
There are then further steps you can take with this. I used powershell studio to export this as an exe or even as a windows service binary, for those nice priv esc situations to get a nice malicious service. The same process can be applied to python payloads and these can also be converted into a windows exe using py2exe, I have had great success with some exes created in this way.
So that about rounds it off. This is far from an indepth step by step of how to “master” AV evasion, but more of a fly through of some of the interesting tools and ticks I have learnt whilst toying around with this. Hopefully it will prove helpful for handling AV.