Category: Veil-Evasion

February 2016 V-Day

This February we have a few updates to Veil-Evasion.  First, we’ve upgraded the version of PyInstaller that’s used by Veil-Evasion from pyinstaller 2 to 3.1.  One extra feature that this allows is the ability to encrypt the bytecode that pyinstaller outputs.  We’re using this feature by generating a random key each time Veil-Evasion runs and supplying that when using PyInstaller to convert the python code into a Windows executable.

The other modification to Veil-Evasion is I’ve added some obfuscation to the python payloads themselves.  I’ve identified some areas where different AVs are trying to flag the python payloads, so this should help with some of the detection issues.  Other possibly signatures have been found as well, but I’m waiting to see how AV companies respond to this new obfuscation.

Thanks, hope that this can help, and good luck!  #avlol

Posted on by Christopher Truncer 1

Honor Amongst Thieves – Building Trust in Veil-Evasion Payloads

Anytime that a professional pen tester, or red teamer, uses a tool on an assessment, your customer is trusting you to not introduce additional vulnerabilities into their network.  When you create a backdoor through Veil-Evasion, or any other payload generator, you need to be sure that the payload you are creating connects back to you and only you.  So how can you ensure that the payloads generated by Veil-Evasion only connects to where it is explicitly specified to connect to?  One way would be to perform a complete source code review of Veil-Evasion and perform an environmental analysis of the generated payload.  This method would provide the highest level of assurance.

There is also another way.  There are a number of scripts that can be used to extract the Python source code from a PyInstaller executable.  One such script is called PyInstaller Extractor and written by extremecoders.  This script will extract all files within the PyInstaller executable, including the Python source code.  We can then compare the extracted Python source code with the source code file that’s created alongside of the PyInstaller executable when using Veil-Evasion.  The two Python source code files will match up and prove that there is not any additional code added inside the “compiled” payload, thus the original source code output can be reviewed and trusted as being the actual source code in the resulting payload.  Ironically, as long as the original source code is reviewed and understood to be non-malicious, then you can trust Veil-Evasion payloads.  So, let’s get along with proving this!

Note: This article only discusses PyInstaller payloads.

First, download the PyInstaller Extractor script and place it in the same directory as your Python payload.  Call the PyInstaller Extractor script and pass the Veil-Evasion payload in as the script’s only option.  The script will now extract the files from the PyInstaller executable.  When you ls you should see the different files that were contained within the payload.

Extracted Payload

In this case, since the payload we are looking at was named veilpayload.exe, the extracted file we are looking for is therefore veilpayload.  The veilpayload file contains the Python code that is carried out when running the original executable.  Now, lets perform a comparison of the source code output from Veil-Evasion, and the extracted source code.

Original Source Code

 Original Source Code Output from Veil-Evasion

Extracted Python Code

Extracted Source Code from Veil-Evasion Payload

Performing a quick visual check against the two scripts shows that they are virtually identical outside of small formatting differences and the additional null byte at the end of the extracted source code.  Performing a diff of the two files also verifies this information.

Scripts diffed

In retrospect, this probably should have been among the first few published posts since Veil-Evasion’s initial release.  However, hindsight is always 20/20, so we’re happy we’re able to provide some level of assurance that your Veil-Evasion payloads aren’t backdoored in any way.  Please feel free to follow the steps outlined in this blog post to verify for yourself.  If you have any additional questions, feel free to hit us up on Twitter, Github, E-mail, or on Freenode in #veil!

Posted on by Christopher Truncer 1

August 15th V-Day: Smash and Pillage

We have a two-part release for everyone this V-Day. First, we have two new PowerShell stagers for Veil-Evasion, powershell/meterpreter/rev_http and powershell/meterpreter/rev_https. For some more background on how the reverse_http[s] stagers work, check out the post on the Python versions of those stagers. As with the other versions of these stagers, we get Beacon compatibility for free as well.

Second, a new tool for the Veil-Framework was released last week at Defcon 22. Veil-Pillage is a modular post-exploitation framework that subsumes Veil-Catapult and implements a ton more features. The slides for the presentation on pillage given at Defcon, “Veil-Pillage: Post-Exploitation 2.0” are located here on slideshare, and the three recorded demos given during the presentation are available here. Once the video of the presentation is online this post will be updated. We’ll have some posts in the upcoming weeks covering Veil-Pillage’s feature set, modules, use cases and more. We also have a few Pillage module ideas in the pipeline, which will be released on the 1st of each month.

And a big thank you to everyone at Hacker Summer Camp. We have a great time talking to everyone about the Veil-Framework at Blackhat Arsenal (slides here), and the response to the Defcon presentation has been awesome. We appreciate everyone’s support and hope to keep releasing more cool stuff over the next year!

Posted on by Harm J0y 1

July 15th V-Day

For our V-Day release this month, we have some more PowerShell goodness for everyone. Veil-Evasion v2.10.0, now in the master branch, includes powershell/meterpreter/rev_tcp, a native shellcode-less stager conceptually similar to some of our previous releases. Utilizing similar .dll import functionality as some of our previous modules, and originally drawn from Matthew Graeber’s article on shellcode injection with PowerShell, we can achieve the same native-stager functionality without having to rely on shellcode.

The Backdoor Factory payload within Veil-Evasion, which now uses the Capstone Engine, has also been updated (and just had its own wiki stood up)! Be sure to rerun Veil-Evasion’s ./setup/setup.sh script to install the necessary dependencies for the new BDF version.

We’ve also got a big release coming up next month, with the debut of a newest tool in the Veil-Framework, Veil-Pillage, going down at Defcon. If you’re around at Blackhat, come check out the Veil-Framework presentation at Blackhat Arsenal. We’ll also have two new Veil-Evasion payload modules ready for release on August 15th. And on a sidenote, Veil-PowerView was a part of Powershell Magazine’s security special– be sure to check out the other great articles in the series!

Posted on by Harm J0y 1

May 15th V-Day Release

This month’s V-Day has a few new C# payloads, and some nice new Python obfuscation. Veil-Evasion 2.8.0, just pushed to the master branch, now implements two new C# payloads, cs/meterpreter/rev_http and it’s SSL wrapped brother cs/meterpreter/rev_https. These are similar to the C stagers released a few months ago, as well as the Python reverse http[s] payloads released in January. The Python posting has some more detailed information. These payloads also have the MSF http checksum algorithm built in as well, so each run should request a shiny new resource URI for staging. Oh, and these work great against a beacon handler.

We also have some newly-developed Python obfuscation integrated. Last week, I released a project named Pwnstaller, which generates an obfuscated version of the Pyinstaller runw.exe loader used by Veil-Evasion Python payloads. A detailed blog post on its workings was released here. Pwnstaller has now been integrated into Veil-Evasion for all Python payloads, with “2 – Pwnstaller” now being an option on the Python compilation menu:

pwnstaller

pwnstaller_evasion

There is also a “–pwnstaller” cli flag added that can force Pwnstaller usage. A backup of the original Pyinstaller runw.exe loader is now located in ./tools/runw_orig.exe, and can be restored to /opt/pyinstaller-2.0/support/loader/Windows-32bit/ if desired. A presentation at BSidesBoston was given on Pwnstaller this past Saturday (5/10/14) and the slides are can be found here.

 

Posted on by Harm J0y 0

March 15th V-Day Release

This month’s V-Day will be quick, but we promise still useful. Veil-Evasion 2.6.0, just pushed to the master branch, now implements two new obfuscated C payloads, c/meterpreter/rev_http and it’s service-version brother c/meterpreter/rev_http_service. These are the http flavors of the rev_tcp stagers released a while back, and function the same way the python reverse_http stagers do. They have the MSF http checksum algorithm built in as well, so each run should request a shiny new resource URI for staging. Oh, and these work great against a beacon handler as well.

We also have a shiny new update from @midnite_runr‘s awesome Backdoor Factory tool, check it out!

Also, a few people have been having problems with some Veil-Evasion payloads crashing, often with the powershell/* modules. We figured that this was due to the Metasploit Framework modifying the output format for msfvenom, which is where we pull our generated shellcode from. The specific commit is here. We put a patch into Veil-Evasion that attempts to determine the build version of your local Metasploit installation and pulls shellcode output appropriately depending on version. Let us know if there are any additional problems.

Lastly, to offer another option to utilize Veil-Evasion in external tools, we’ve implemented a basic JSON RPC interface for payload generation. Invoking it with ./Veil-Evasion.py –rpc will open up a local listener to handle the RPC connections, spitting back out the paths to successfully generated payloads. We’ll have a quick blog post up in the next week on utilizing this functionality.

Posted on by Harm J0y 0

Veil-Evasion Cortana Integration

During our second Shmoocon demo, we briefly demonstrated the newly released Cortana script, veil_evasion.cna, included at Veil-Evasion/tools/cortana/veil_evasion.cna. We wanted to go over exactly what this script is and how it can be used effectively.

Cortana is an attack scripting language based on Sleep, both written by Raphael Mudge. Cortana allows for advanced manipulation of Armitage or Cobalt Strike, the free and paid versions of a gui-type environment (and more) for Metasploit. (Note: armitage is freely available in Kali with apt-get install armitage). With Cortana, you can trigger on specific events or user actions, interact with the full Metasploit backend, modify menus, and more. There are some great examples on Raffi’s github of what you can do with this powerful language at your fingertips.

We wanted to fully integrate Veil-Evasion’s capabilities into Armitage/Cobalt Strike utilizing Cortana. In order to get the menu structure desired, Armitage (bsd-licensed) backend code was stripped apart and custom menus were constructed using Raffi’s existing code examples. We were finally able to get our graphical menus to what we wanted. To load up the veil_evasion.cna script in Armitage, go to Armitage -> Scripts, select the Load button and navigate to the veil_evasion.cna script:

load_cortana

On first run, you will be prompted for your Veil-Evasion installation path:

veil_evasion_path

After loading the Cortana script, a Veil-Evasion menu will be opened in the top menu bar. Clicking on it will allow you to Generate a payload, check the Current PSEXEC Payload, or Set Veil-Evasion Path to your current installation. Choosing Generate will present the main Veil-Evasion menu:

veil_evasion_cortana_main

Double-clicking on Payload will fill a dynamically-generated list of all current Veil-Evasion payloads in your installation:

veil_cortana_payload

Double-clicking MSFPayload will present a set of selectable msfpayload options for shellcode_inject payloads:

veil_cortana_msfpayload

Clicking Generate will run the appropriate Veil-Evasion command in the backend and generate the output path for your generated payload If you select Set as PSEXEC Payload, then all straight Metasploit psexec module executions will be hooked and your generated payload will be substituted in:

veil_cortana_generate

If you ever want to chance the hooked PSEXEC payload to something else, choose Veil-Evasion -> Current PSEXEC Payload and either enter a custom .EXE path or clear to eliminate the custom .EXE hooking. If you’re utilizing Cobalt Strike, selecting Use Listener will allow you to select one of your existing listeners and fill in all appropriate options for payload generation.

If you’re interested in Cortana, check out Raffi’s master github, his tutorial, and/or the Cortana script pack I’ll be maintaining here. And if you happen to be in Austin in mid-to-late March, check out my talk on Cortana scripting at @BSidesAustin, “Wielding a Cortana” where I’ll cover this particular Cortana effort and others in more detail. The slides are up on slideshare and the video is posted here.

 

Posted on by Harm J0y 1

Veil-Evasion 2.4.0 – Reverse HTTP

For our January V-Day, we’re introducing two new payload modules, python/meterpreter/rev_http and python/meterpreter/rev_https. These stagers are shellcode-less, ‘pure’ Meterpreter stagers somewhat similar to traditional reverse_tcp stagers.

Meterpreter reverse_https[s] stagers are actually a bit simpler than reverse_tcp. The general idea is the same- the handler serves up a .dll file that the client then injects using the VirtualAlloc/etc. methodology. However, instead of having to patch the .dll ourselves with assembly instructions and the socket file descriptor, the Metasploit handler patches the user-agent, transport method (http/https), url and expiration/communication timeout dynamically as it serves the Meterpreter .dll:

rev_http_patch

The only slightly tricky part is reversing the http checksum method that a Metasploit stager uses for requesting the specific resource from the handler (that /aIc0 above) . This URI resource generation method is ‘generate_uri_checksum()’ in metasploit-framework/lib/msf/core/handler/reverse_http/uri_checksum.rb (formally in metasploit-framework/lib/msf/core/handler/reverse_http.rb) . The algorithm can be implemented in Python as follows:

# adds up all character values and mods the total by 256
def checksum8(s):
	return sum([ord(ch) for ch in s]) % 0x100

# generate a metasploit http handler compatible checksum for the URL
def genHTTPChecksum():
	chk = string.ascii_letters + string.digits
	for x in xrange(64):
		uri = "".join(random.sample(chk,3))
		r = "".join(sorted(list(string.ascii_letters+string.digits), key=lambda *args: random.random()))
		for char in r:
			if checksum8(uri + char) == 92:
				return uri + char

Since http[s] stagers are packet-based instead of stream-based, the MSF devs put a system into the handlers that corrals ‘orphaned’ sessions. That is, if you close your reverse_http handler, then start it up later (within the specified reconnect window) the handler will pick the session back up and reregister it. We talked about this during our Building in the Meterpreter .dll post. Here, since we’re registering a session in the correct way, we stay with the ’92’ checksum value (which corresponds to URI_CHECKSUM_INITW).

With the checking algorithm implemented in the stagers, you’ll get a nice and different checksum value every time each stager is run, instead of having to rely on a single hardcoded value. Another nice little bonus with the rev_http is that it plays functions nicely as a native stager for Cobalt Strike’s beacon. We talked about using beacon with Veil previously and this gives a nice alternative to using straight shellcode stagers. 

Posted on by Harm J0y 2

How to Safely Check Veil Payloads Against VirusTotal

In hindsight, this post is probably one of the first ones that we should have written, but better late then never.

As many of you know, we heavily state on our website, within Veil, and within the license, that you should not be submitting your payloads to VirusTotal, or any online virus scanner. We still heavily believe in this, and if you want the best chance to not get caught, just don’t do it.

With that said, there’s another option. In case no one has used it before, Rob Fuller (@mubix) created a great tool called VT-Notify. VT-Notify works by sending a SHA1 hash of a binary to VirusTotal through its API. The key thing to note here is that your payload is not uploaded to VirusTotal, simply its SHA1 hash. VirusTotal then uses the SHA1 hash against its AV solutions, and let’s you know if any of the SHA1 hashes have been flagged/detected by any of the antivirus solutions it has available. Again, while we still think it’s best to not submit any information anywhere, this is the best solution for checking to see if your payloads have been flagged.

First, in case you haven’t noticed, Veil is now creating a list within the ~/veil-output/ directory called hashes.txt.

Hashestxt

This file contains the SHA1 hashes of all payloads you’ve created, along with their name. This is what VT-Notify will use when interacting with VirusTotal.

VT-Notify has been added to Veil in two different areas, and can be accessed either way. To use it within Veil’s menu, simply start Veil, and then at the main menu you should see the new option. This is for a quick single check. Simply call the command “checkvt”, and you should see the following output if all your payloads are “clean”.

Checktvclean

Now, if one of your payloads have been flagged, you should see something similar to the following.

Checkvtcaught

This essentially concludes how to use it within Veil’s menu system. You also can use the tool, like normal with all its command line options from the command line. To to this, just simply browse to its location at /path/to/veil/tools/vt-notify/ and call it from within that directory.

Vtnotify

If anyone has any questions, feel free to hit us up in our forums! Thanks!

Posted on by Christopher Truncer 1

Self-Expiring Payloads

The Veil-Framework team loves getting feedback from the community and like to hear if Veil works well for you, and learn about new ways we can add to the software that we hadn’t yet thought of/done. We were recently asked if any Veil payloads expire, and up until this point, they never did. This was a really interesting request as we hadn’t thought about adding this feature to Veil payloads, and we immediately began looking into it. In our latest V-Day release, we updated our Python payloads to support a date based expiration.

Expiring Payloads

As you can see in the picture above, we now have an extra option for Python payloads, the “expire_payload” option. To force a payload to expire after a certain number of days (in this instance, we’ll go with 10), we need to change the default value of “X”. You can change it exactly how you change any Veil payload’s options, using the set command.

Expire After 10 Days

ExpirePayloadInfo

The way that option works, is upon the creation of the backdoor, Veil stores the current date within the payload. Upon running on your victim machine, the payload will compare the current date on the victim system, to the date that it is supposed to expire. If it is past the expiration date, the payload will simply exit. If the payload is still within the allowed timeframe, it will inject your shellcode into memory and operate as it always does.

We hope that this feature helps, and we’d love to hear any feedback and/or additional feature requests!

Posted on by Christopher Truncer 1