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.

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!

Veil-PowerView v1.4

Veil-PowerView has gone through another large set of modifications, resulting in its versioning to 1.4. Here are the changes in no particular order:

  • Get-UserProperties was built, stealing directly from @obscuresec‘s great post on the topic located here. Related, Invoke-UserDescSearch was expanded and changed to Invoke-UserFieldSearch, which now allows you to specify the user field to search for wildcard terms. We’ll have a post up soon on using these methods together.
  • Get-NetGroupUsers was combined into Get-NetGroup for standardization.
  • The -Debug flag for meta-functions now replaces the old -Verbose functionality, with the -Verbose flag now outputting a status for when several machines are processed.
  • Invoke-Sharefinder had serveral additional exclusion options added and its output changed to just spit out raw share paths.
  • Set-MacAttribute was added in from Powersploit- see @obscuresec‘s post on the topic on his blogInvoke-CopyFile automatically invokes this when replacing files in order to match a target’s MAC properties.
  • Invoke-SearchFiles was added, which recursively searches a local or remote network path for files with various specifications. Terms can be specific, MAC attributes filtered one, and more – check out the source for complete flags and options.
  • Invoke-FileFinder was added, which utilizes Invoke-SearchFiles to crawl the network for target data. Lots of flags here too.
  • Several methods were added that attempt to enumerate local machine information: Get-NetLocalGroups to get local groups on a target, Get-NetLocalGroup to get members of a local group, and Get-NetLocalServices to enumerate local services.
  • Invoke-HostEnum was added, which will run all available host enumerate functions on a single target (note: this potentially produces a good chunk of data, just for a single host).
  • A lingering bug was finally fixed that would crash execution of some of the meta-functions when executed against large numbers of machines, usually in the 2000-4000 range. Have to be careful of those access violations when playing with raw memory and API access :)

Thanks again to @obscuresec for posting some great Powershell information that I shameless stole and integrated into PowerView – all credit to Chris for coming up with those ideas. We’re also going to have a few PowerView posts coming up in the next few weeks, including a usage guide, information on abusing user description fields, and an exe trojanation guide. Oh, and the Veil-Framework was recently accepted to Blackhat Arsenal– come stop by to talk about all the tools in the framework, including a new post-exploitation tool being released at Defcon.

 

June 15th V-Day

Welcome!  For our June 15th V-Day, we have two different updates for Veil-Evasion.

First off, Josh Pitts (@midnite_runr) has pushed multiple updates to the Backdoor Factory last month.  We’ve incorporated his updates into Veil-Evasion, and everything works great!  By the way, he also released a new tool called the Backdoor Factory Proxy, check it out!  It’s an awesome tool that can backdoor executables mid-download when performing a man-in-the-middle attack against your target.

The other addition we’ve made is adding the heap injection memory allocation technique to our C shellcode injection payloads.  Originally, we had two shellcode injection payloads, virtual and void.  Now, these have been combined into a single C payload (flat) which contains all three memory injection techniques.

We like to release these “base” methods for injecting shellcode so the community has an example to base their own obfuscation methods off of.  Have an interesting method to bypass Antivirus in C, or any other language?  Send us a pull request and we’ll get it added in!

Thanks!

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.

 

Veil-PowerView v1.3

Veil-PowerView has had even more recent changes, culminating in the release of version 1.3:

  • The optional “-CheckShareAccess” flag that can be passed to Invoke-Netview and Invoke-ShareFinder should now accurately record shares that you currently have access to.
  • Get-NetGroups and Get-NetGroupUsers now accept wildcards for the -GroupName passed.
  • Get-NetServers was combined into Get-NetComputers, which now accepts wildcards for the -HostName, -OperatingSystem, and -ServicePack to query AD for.
  • Invoke-FindVulnSystems was implemented, which uses Get-NetComputers to query AD for machines that are likely vulnerable to MS08-067.

There’s also been a major rewrite in how PowerView invokes various Windows API methods (such as NetShareEnum). The standard approach most resources recommend for .dll access is through using the Add-Type method and a member definition to expose specific methods, documented here. You might ask, if this works, why change anything? Two main reasons- first, while this method actually compiles C# code on the fly in memory, some temporary files actually touch disk. As an attacker, refraining from any/all disk access when possible is a good philosophy to maintain. And second, since some code has to be JIT compiled, this method will actually fail in some environments, where some csc.exe/.NET wonkiness can mess stuff up.

Luckily, @mattifestation wrote an excellent post on an alternative method to access the Windows native API. His post can explain it better than I can, but a tldr; is that you can use some native .NET functionality to resolve the address of any method in a loaded .dll. You can then build a custom delegate that models the method you’re intending to call and invoke whatever functionality you need. Graeber also has an article on building structs and enums without having to invoke the csc compilation method as well. All .dll imports and structs in PowerView were rewritten using these methods, leaving disk pristine and expanding the environments you can run PowerView in.

Happy (user) hunting :)

April 15th V-Day Release

For the April 15th V-Day release, we have uploaded a single payload into the master branch of our github repo.  This is a new payload “type” for Veil-Evasion.  As of yet, all of Veil-Evasion’s payloads are started in their own process, create a thread, and execute their embedded shellcode.

Payload pid info

The “pidinject” payload, takes the shellcode embedded inside it, and runs it inside of another process, essentially allowing you to migrate your shellcode into another running process (assuming you have the permissions to interact with said process).  All you need to do is provide the process ID of the process you wish to have your shellcode run inside of, and then you’ll be set.

Set PID Value

From here, you would just generate your payload like normal.

If you have any questions, be sure to post about it in our forums!

Veil-PowerView v1.1

Veil-PowerView has gotten a few changes over the past week or so. As mentioned previously, right after its release, Carlos Perez and the PowerSploit guys, @obscuresec and @mattifestation, gave some great feedback on how to make PowerView standards compliant. At the short March 2014 NovaHackers presentation given on PowerView, Rob Fuller (@mubix) gave some more great feedback on tweaks and features to add. Veil-Powerview v1.1 is the implementation of those suggestions, and integrates the following changes:

  • The verbs for all “Net-*” functions have been changed to “Get-Net*” and “Invoke-Net*” as appropriate.
  • The verbs for the meta functions have all been changed to “Invoke-*” (i.e. Invoke-Netview).
  • The method Invoke-UserDescSearch has been added, and will pull all AD user data and search account descriptions for particular keywords, defaulting to “password”.
  • Invoke-Netview and Invoke-ShareFinder now both have a “-CheckShareAccess” flag that will only display found shares that the local user has access to (through the use of the Check-Path cmdlet).
  • Invoke-ShareFinder now includes all shares by default, with an “-ExcludeShares” flags to exclude common shares.
  • Use of ‘return’ has been greatly reduced.
  • adsi is implemented in more places instead of straight API calls – for example, Get-NetServers now uses an adsisearcher instead of API calls to get ALL server host names from Active Directory.
  • Write-Host and Write-Output have been eliminated, with functions now returning pure objects.

I’m sure a few things were missed, so let us know as problems or suggestions arise. Also, the functions Get-NetConnections and Get-NetFiles were implemented to enumerate the connections and open files on servers with more granularity. Unfortunately, these calls need a user to be local admin on a target server, but they still have their specific uses. For anyone wanting to get going on writing powershell, I highly recommend checking out Carlos’ style guide, some of his examples, as well as the awesome examples from the PowerSploit project.

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.