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.

Hunting for Domain Users With the Veil-Framework

Time for a followup on the remaining functionality of Veil-PowerView. Today I’ll cover the two most interesting features released, Invoke-UserHunter and Invoke-StealthUserHunter.

As detailed previously, Veil-PowerView started as a pure powershell replacement for various net domain enumeration commands used to gain situational awareness on a Windows network. It expanded into some metafunctions such as Invoke-Netview (a port of Rob Fuller’s netview.exe), Invoke-ShareFinder to find interesting network shares, and Invoke-FindLocalAdminAccess (a port of local_admin_search_enum.rb). These functions are interesting and useful, but we soon realized that we could do a few more really interesting tricks utilizing all this existing powershell AD functionality and Windows API calls.

Invoke-UserHunter chains together particular aspects of Invoke-Netview to find where specific users are logged in on the current network. It can utilize a delay/jitter between host enumerations and works as follows:

  1. The current user and domain are pulled with Get-NetCurrentUser and Get-NetDomain, respectively
  2. Machines on the domain are queried (and the resulting list shuffled) using Get-NetServers, or by reading in a host list
  3. A specific group is queried for users using Get-NetGroup (which defaults to ‘domain admins’), or a specific username is specified, or a user list is given
  4. For each machine in the target list, Get-NetSessions and Get-NetLoggedon are used to see what users are logged in and/or have current sessions (and from where). The script will sleep for a delay between each host enumeration, if specified
  5. The results are compared against the target user list, and matches are displayed
  6. Found machines can optionally be checked for local admin access with Invoke-CheckLocalAdminAccess

Invoke-StealthUserHunter takes a more subtle, ‘red-teamy’ approach to hunting down user locations. It will issue one group query to build a target user list with Get-NetGroup, and one query to find all users (and detailed user information) in the domain with Get-NetUsers. It will then extract all servers found from user HomeDirectory entries, and run one Get-NetSessions call against each found file server (after the delay/jitter if specified) to get current user sessions on those targets. The results of the sessions calls are compared against the target user list, and matches are highlighted. While not as accurate as Invoke-UserHunter as only the file servers in a domain are touched, Invoke-StealthUserHunter is significantly stealthier as only as a handful of queries are made.

The end result? As a normal domain user, running these functions can tell you exactly where domain administrators (or other target users) are logged into, and  can optionally tell whether you have local admin access to those boxes. One some domains this can help you point -> click -> get DA :)

Quick sidenote- I received some great feedback from Carlos Perez concerning how to make PowerView standards compliant. I’ll be integrating his suggestions over the next week or so, but a side effect is that many of the method names are likely going to change. This post and last weeks will be updated appropriately with the updated usage. Also, I’m going to be helping @obscuresec and @mattifestation get some of PowerView’s functionality into PowerSploit soon, so keep your ears open for updates.


We like to envision the Veil-Framework as extended beyond just generating and delivering AV-evading executables. The theme underlying our development efforts has been one of evasion and stealth, leading us to view the Veil-Framework not as a single program, but as a collection of tools that aim to bridge the gap between pentesting and red-team toolsets. Some of the releases in the coming year will extend beyond just executable generation, and may not integrate into existing codebases the same way Veil-Catapult was able to. However, the theme of evasion will still link together everything in spirit, if not in code.

With that said, I’d like to announce the most recent addition to the Veil-Framework, Veil-PowerView, a pure powershell tool for network situational awareness.  First off, thanks to @davidpmcguire for inspiration, @mubix for building netview.exe and open sourcing it, the offensive powershell community (@obscuresec@mattifestation, and DarkOperator) for showing how proper powershell is done, and @zeknox, @smilingraccoon, and r3dy for the local_admin_search_enum idea in Metasploit.

We recently were on an pentest where a client had implanted an interesting defense- the disabling of all “net *” commands on domain machines. At first, this might appear like a novel attack mitigation, as it initially thew a wrench in some of our normal post-exploitation activities. During our post assessment breakdown however, we started brain storming way around this particular defense in case we encountered it again. Bypassing it completely ended up being trivial through the use of powershell.

This assessment started the development of Veil-PowerView, released today. By taking advantage of native powershell AD hooks and the ability to invoke Win32 API functionality, a complete, pure powershell replacement for the common “net *” commands we typical use was implemented. These include common things like Get-NetGroup for listing detailed information about specific domain groups, Get-NetShare to get share information for a specific host, Get-NetUser to get information for a specific domain user, and so on. There are also the slightly more non-traditional functions of Invoke-CheckLocalAdminAccess to see if the current user has local admin access on a target host, Get-NetGroupUsers to get complete, detailed information on all users in a particular group (not just usernames), Get-NetLoggedon to get users currently logged onto a machine, and so on.

Inspired by Rob Fuller (@mubix)’s netview.exe tool, more interesting metafunctions were then built, chaining together the previously implemented net functionality. The first endeavor was a full powershell implementation of netview.exe, Invoke-Netview, with a few tweaks added in. Very similar to the original netview.exe, here’s how the core functionality works:

  1. Get-NetDomain is run to query the principal domain
  2. Get-NetServers is run to pull a complete list of all active machines on the domain, which is then randomized (Get-NetServers utilizes a Win32-api implementation of NetServerEnum to query for active machines of server type 2). A host list can optionally be specified with “-HostList HOSTS.txt”
  3. Get-NetServers is run three additional times, querying for three specific server types- domain controllers, backup domain controllers, and SQL servers (i.e. Get-NetServers -ServerType 8)
  4. For each machine found in the domain, Get-NetSessions is run each host to query the current sessions on the machine (Get-NetSessions utilizes a Win32-api implementation of NetSessionEnum)
  5. Get-NetLoggedon is then run against each server to get the users currently logged onto the machine (Get-NetLoggedon utilizes a Win32-api implementation of NetWkstaUserEnum).
  6. Get-NetShare is then run against each host to numerate all available shares on the machine (Get-NetShare utilizes a Win32-api implementation of NetShareEnum)
  7. Nicely formatted output is displayed for each host as appropriate

Invoke-Netview has a few additional options missing from the original netview.exe implementation. “-ExcludeShares” will exclude common fileshares (C$, IPC$, PRINT$, etc.) from the results. “-Delay X” introduces a delay of X seconds between each host enumeration, and “-Jitter .X” adds a +/- .X percent jitter to the delay interval to randomize behavior.

Invoke-ShareFinder utilizes similar functionality to Invoke-Netview. It runs Get-NetServers to get all domain machines (or accepts an optional host list as well), randomizes the list, and then runs Get-NetShare to get all active shares on each target machine. Common shares are filtered out by default, giving you a nice list of interesting shares to investigate. The delay/jitter specification is also available.

Invoke-FindLocalAdminAccess is a powershell port of the metasploit local_admin_search_enum.rb module written by zeknox, smilingraccoon, and r3dy. It does the same Get-NetServers/hostlist/shuffle stuff, and then runs Invoke-CheckLocalAdminAccess against each host, which utilizes the Win32-api call OpenSCManagerW with full permissions to see if the local user current has local admin access on target machines. Again, the delay/jitter specification is also available in case you don’t want to try to connect to the service manage of every machine in domain as quickly as possible.

All functions should hopefully be documented and attributed appropriately. I put links and references for every source I drew from, and did my best to cite all prior art. If I accidentally put in functionality already implemented previously by the badass offensive powershell community, please please please let me know so I can put proper attribution in.

That should hopefully be enough for initial digestion- a post will be pushed in a couple of days detailing the most interesting functionality published, Invoke-UserHunter and Invoke-StealthUserHunter. That’s where the real fun with Veil-PowerView begins ;)

Integrating the Veil-Framework Into Your Own Tools

With our movement towards making Veil a true framework, we’ve tried to make the code as modular and extensible as possible. We’ve also tried out best to make Veil-Evasion and Veil-Catapult scriptable with command line flags for almost every options. However, it’s also simple to integrate various aspects of Veil-Evasion into your own python projects at a code/library level. This is what Veil-Catapult effectively does for payload and shellcode generation, and we wanted to detail how you can do the same for your python code base.

First, you need to pull in Veil-Evasion’s installation location and other configuration information. The easiest way is with Veil’s common confirmation file at /etc/veil/settings.py:

import settings

The module tree should all be importable, including any of the payload modules from  ./modules/payloads/* as well as the common functions in ./modules/common/*.

To take advantage of Veil-Evasion’s shellcode generation, creating a modules.common.shellcode object and then calling the generate() method will drop users into the interactive shellcode-generation menu, spitting back out the resulting shellcode string after all options are set. You can also manually set the msfpayload and options:

from modules.common import shellcode
sc = shellcode.Shellcode()
if args.msfpayload:
    sc.SetPayload([args.msfpayload, args.msfoptions])
code = sc.generate()

If you want to invoke Veil-Evasion’s full menu structure and get the path of the compiled .exe back out, the controller object is what you want:

from modules.common import controller
con = controller.Controller()
exePath = con.MainMenu()

If you want the code from a particular module, that’s easy as well:

from modules.payloads.powershell.shellcode_inject import virtual
p = virtual.Payload()
code = p.generate()

If you’re interested in more detailed use, check out the code for Veil-Catapult, and let us know if you run into any problems, or have any ideas that you might think fit in with the project.


Veil-Evasion Cortana Integration

During our second Shmoocon demo, we briefly demonstrated the newly released Cortana script, veil_evasion.cna, included at Veil-Evasion/tools/cortana/veil_evasion.cna. We wanted to go over exactly what this script is and how it can be used effectively.

Cortana is an attack scripting language based on Sleep, both written by Raphael Mudge. Cortana allows for advanced manipulation of Armitage or Cobalt Strike, the free and paid versions of a gui-type environment (and more) for Metasploit. (Note: armitage is freely available in Kali with apt-get install armitage). With Cortana, you can trigger on specific events or user actions, interact with the full Metasploit backend, modify menus, and more. There are some great examples on Raffi’s github of what you can do with this powerful language at your fingertips.

We wanted to fully integrate Veil-Evasion’s capabilities into Armitage/Cobalt Strike utilizing Cortana. In order to get the menu structure desired, Armitage (bsd-licensed) backend code was stripped apart and custom menus were constructed using Raffi’s existing code examples. We were finally able to get our graphical menus to what we wanted. To load up the veil_evasion.cna script in Armitage, go to Armitage -> Scripts, select the Load button and navigate to the veil_evasion.cna script:


On first run, you will be prompted for your Veil-Evasion installation path:


After loading the Cortana script, a Veil-Evasion menu will be opened in the top menu bar. Clicking on it will allow you to Generate a payload, check the Current PSEXEC Payload, or Set Veil-Evasion Path to your current installation. Choosing Generate will present the main Veil-Evasion menu:


Double-clicking on Payload will fill a dynamically-generated list of all current Veil-Evasion payloads in your installation:


Double-clicking MSFPayload will present a set of selectable msfpayload options for shellcode_inject payloads:


Clicking Generate will run the appropriate Veil-Evasion command in the backend and generate the output path for your generated payload If you select Set as PSEXEC Payload, then all straight Metasploit psexec module executions will be hooked and your generated payload will be substituted in:


If you ever want to chance the hooked PSEXEC payload to something else, choose Veil-Evasion -> Current PSEXEC Payload and either enter a custom .EXE path or clear to eliminate the custom .EXE hooking. If you’re utilizing Cobalt Strike, selecting Use Listener will allow you to select one of your existing listeners and fill in all appropriate options for payload generation.

If you’re interested in Cortana, check out Raffi’s master github, his tutorial, and/or the Cortana script pack I’ll be maintaining here. And if you happen to be in Austin in mid-to-late March, check out my talk on Cortana scripting at @BSidesAustin, “Wielding a Cortana” where I’ll cover this particular Cortana effort and others in more detail. The slides are up on slideshare and the video is posted here.


Feb 15th V-Day Release

For our V-Day this month, we have created a new “type” of add-on to Veil-Evasion.  We are releasing two auxiliary modules this month based off of feedback we’ve heard from the community.  The modules are:

  • War file wrapper
  • Python “compiler”

To go into a little more detail, we’ve been asked multiple times if Veil is able to create a .war payload.  As of yesterday, this functionality was not in Veil-Evasion.  If users wanted to create a .war payload, they had to perform the process themselves manually.  However, with the inclusion of the War file wrapper, this doesn’t need to be done manually anymore.  You can simply invoke the war wrapper like you would any other Veil-Evasion payload.  However, the only option it needs is the path to an executable.  Once you “generate” your payload, you will now have a .war file of the executable file you provided.


The python “compiler” is something that resulted out of the large number of tests we run when trying to make a payload.  We would always have to look up the exact command to convert any python script we were currently working on into a Windows executable.  Well, we decided it would be easier to just automate this process too.  So the pyinstaller wrapper will take any python script as its required option, and “compile” it into an executable.

Pyinstaller wrapper

Thanks for using the Veil-Framework, please keep giving us a feedback, we do listen, and if you have any questions, just ask in our forums!

Server Donation – Our Thanks!

The Veil development team has been extremely fortunate to have a number of people reach out to ask how they can help us to continue our work on the Veil-Framework.  We’re pretty fortunate to be able to call Ahmed, the owner of Digitalfyre, our friend.

Ahmed has donated to the Veil development team a server to utilize as we see fit.  As of now, we will utilize the server to track our project goals and utilize the infrastructure to test future development work on.

Personally, our development team have also purchased virtual servers for use from Ahmed, and couldn’t speak highly enough of the stability and customer service we receive when working with Digitalfyre.  We obviously wanted to say thanks to Ahmed, and hope that if anyone has any hosting needs of any kind, that you look to Digitalfyre.

Bypassing On-disk Detection With Veil-Catapult

Say you’re on an internal pentest for a client, and the backdoor .exe you’ve been using has suddenly been snatched up by some antivirus solution. You’re short on time, you haven’t heard of Veil-Evasion, and you really need access. Are you toast, or is there some other option?

There still might be hope. One of the techniques released with Veil-Catapult at Shmoocon 2014 is the host-and-UNC-invoke approach. Choose the [h]ost method when prompted and enter your local IP (tab-completable) so the target machines know where to reach back to:


We use the Impacket library to throw up a temporary SMB server to host an .EXE, and then issue a pth-wmis or pth-winexe command that invokes a command with a \\UNC path back to our attacker box. This will load the payload executable into memory without touching disk, allowing otherwise disk-detectable executables to bypass detection:


One interesting note we discovered when working with this technique: you can use this to get some otherwise disk-detectable executables past some solutions, but not all. Microsoft Security Essentials will detect a stock-generated msfvenom executable executed-in-memory using host/execute but not other disk-detectable methods (like c/shellcode_inject/void):


More evidence that AV vendors are trying to block pentesting tools without actually doing the correct behavioral detection.

#avlol :)