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:



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

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 ./ –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/

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.


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

Barebones Python Injection

We love powershell. It’s awesome for payload delivery for a myriad of reasons; trusted execution, AV-bypassing abilities, reputation filter bypass, full .NET capabilities, etc. However, on assessments we still sometimes encounter machines without powershell installed or enabled. Wouldn’t it be nice to still have a method to invoke payloads without powershell that still granted trusted execution and the other nice features we get with that approach?

The Barebones Python injector released with Veil-Catapult addresses this problem. If you don’t have powershell access on a system for some reason, don’t really like dropping malicious EXEs to disk, or nasty AV white listing/reputation filers are causing you pain, this method provides you an alternative option for owning boxes with a trusted execution model.

To execute, a zipped ‘barebones’ Python environment is first uploaded to the victim machine’s temp directory using Impacket, along with a stand alone 7zip binary. This environment was stripped by hand to only include the bare minimum libraries needed in order to invoke shellcode utilizing Python cytpes. A pth-wmis or pth-winexe command is used to unzip the environment, and a second command will invoke the extracted Python binary with the “-c” option. The passed string comprises a minimum Python program that will base64 decode a shellcode string and invoke it in memory:

python.exe -c "from ctypes import *; a=’u/Fp...’.decode(‘base_64’);cast(create_string_buffer(a,len(a)),CFUNCTYPE(c_void_p))()"

The end result? The only files that touch disk are known/trusted Python libraries and interpreter, and your Veil-Evasion generated shellcode is invoked without a malicious executable potentially being snarfed up by AV.