Veil-Evasion 2.3.0 – More Stagers

Time for our December V-Day. Veil-Evasion 2.3.0 has been pushed to the master branch and we’d like to let you know exactly what’s changed:

  • New Payloads – meterpreter/reverse_tcp stagers for C# and Python have been released under cs/meterpreter/rev_tcp and python/meterpreter/rev_tcp. These function similarly to the C stagers released on our last V-Day.
  • C# obfuscation –  People may have noticed that our C# payloads look surprisingly similar on each generation: this is because our first approach was a simple template that we substituted connection options into. All C# payloads now implement basic variable and method obfuscation in an attempt to generate slightly dissimilar payload “families”. More advanced obfuscation will be implemented in upcoming releases.
  • Python self-expiring payloads – Python payloads now have an expiration option; this will be covered in more detail in an upcoming post.
  • Payload hash record – the SHA-1 hash of every generated payload executable is now kept in ~/veil-output/hashes.txt. An upcoming post will show how to put this to use.
  • Payload reorganization – The way payloads are organized has been changed. The general structure is now [language]/[method]/[payload]. ‘Method’ at this point consists of “meterpreter” for Meterpreter stagers, and “shellcode_inject” for the various shellcode injection methods. List on the main menu will show you the structure, or you can browse it directly at ./modules/payloads/*
  • Command line options changed – Along with the payload reorganization, the “-l” command line option has been eliminated and “-p” now takes the entire payload name, i.e. “-p python/meterpreter/rev_tcp”. ./ -p will list all available payloads if a specific one isn’t specified. Also, new options have been introduced, “–overwrite”, which will overwrite existing source/compiled payload files if they exist, and “–clean” which will clean out payload folders.
  • Backend Changes –  the main class for the payload modules is now “Payload” instead of “Stager”. Additionally, “” has been absorbed into “” and “” has been absored into “”. Check out ./modules/payloads/ for proper usage. Our previous tutorials and posts have been updated to reflect the changes.

We shoot to preserve as much backwards compatibility as possible, but occasionally backend changes do need to be made in the framework. Our goal is to make these types of modifications as rarely as possible, and to give everyone a heads up for major interface and framework tweaks. With these consolidated changes, usability should hopefully stay uniform for at least the next year.


Veil-Evasion 2.2.0 – Native Stagers

Shellcode injection has been around for a long time and usually utilizes four standard windows API calls:

  1. VirtualAlloc() is used to allocation a RWX memory page to hold the shellcode
  2. RtlMoveMemory() (or some other low-level copy function) is used to copy the shellcode bytes into the region reserved by VirtualAlloc()
  3. CreateThread() is used to create a thread within the virtual address space of the calling process
  4. WaitForSingleObject() is used to wait until the thread exits

Since the Metasploit .dll is built to be reflectively injectable using Stephen Fewer’s awesome work, we can use the same process to inject the .dll into memory. If we make a few more tweaks, we can build a pure Metasploit stager without resorting to shellcode. Egypt did a great job describing how the Metasploit stager works :

  1. establish a socket connection to the Metasploit handler
  2. read a 4-byte length
  3. allocate a (length-byte + 5) buffer, mark it as writable and executable
  4. at buffer[0], write some assembly that stores the current socket ID of the connection in the EDI register
  5. at buffer[1:4] store the int value of the current socket ID
  6. read length bytes from the connection from the pipe into buffer[5…] (this is the meterpreter .dll)
  7. invoke call the shellcode blob with the VirtualAlloc() pattern or void pointer casting
  8. the meterpreter .dll now uses the already-established socket for communication, avoiding an additional connect back

Raphael Mudge did a great post a bit ago talking about building these types of loaders, and we stumbled upon his stager code a while back and adapted the code for Veil-evasion. For today’s V-Day, we’re releasing a traditional and psexec-able service versions of this c-stager in Veil-evasion v.2.2.0 under c/meter_rev_tcp and c/meter_rev_tcp_service. We’ve implemented some basic randomization and method obfuscation to decrease detection.

Have fun :)

How to Customize Backdoor Factory Payloads within Veil

We were lucky enough to be able to include The Backdoor Factory by Joshua Pitts in our October 2013 V-day.  It’s a great tool and we’re really happy to have been able to work with Josh to include the Backdoor Factory within Veil as an option.  As it is currently implemented, the Backdoor Factory payload will backdoor the psinfo.exe executable that comes with Veil.  So this leads to the question, how do you change the executable that is backdoored?  That’s what this tutorial is set out to show you.

First, the you’ll need to select the executable you want to backdoor.  In this instance, we chose the Microsoft tool Process Explorer.  One thing to note when choosing the executable to backdoor, ensure that it’s not UPX packed.  Also, in our current implementation of the Backdoor Factory payloads, we’re primarily focused on x32 binaries.  Full support for x64 binaries within Veil will come in a future update.

Now that we have our executable, you want to copy it into the “tools/backdoor” directory within the Veil folder structure as shown below.  Or, your other option will be to provide the full path to your executable for the orig_exe option (as shown in this video).


Now that our binary is in the correct location, we can start Veil.  When listing the available payloads, use the “native/BackdoorFactory” payload.  Now, we need to set our required option.  Go ahead and define the LHOST and LPORT options to correspond with your handler.  Now, we need change the “orig_exe” option.  In this case, change the exe and have set to the new executable, in this case, “procexp.exe” (if you didn’t place your executable in the tools/backdoor directory, provide the full path to the executable you want to backdoor).


We can always verify that our options are correctly set by typing the “info” command.


Now that we’ve confirmed we’re all set, go ahead and give Veil the “generate” command.  Veil will invoke the Backdoor Factory payload and use the process explorer executable.  Once the backdoored executable has been generated, you should see Veil’s familiar output screen.


Now, simply move the backdoored executable onto your victim’s machine and run it.  You will still see the executable run normally, except we now also receive a callback!


And that is how you change the program that is backdoored within Veil.  If you have any questions, just let us know!



Veil-Evasion 2.1.0 Release

Hello and welcome to our second V-Day!  We’re happy to push the Veil-Evasion 2.1.0 release to our master branch.  As standard with any of our releases, we’d like to document for you exactly what has changed:

  • New Payload – Joshua Pitts’ awesome tool The Backdoor Factory has been integrated into Veil. This tool has way more features to play around with than what we’re defaulted to- be sure to play around with it and check it out.
  • Self-Contained Payload Update – Our previous release of the self-contained payloads used an older version of the metserv.dll and would crash if you did not use the correct version.  This has since been updated and the latest dlls are now being used within the self-contained payloads. 
  • Re-added Update Functionality – Somewhere during our development project, we accidentally removed the capability to update Veil-Evasion directly within the tool.  This functionality has been added back in (again).  :)
    • Note: To utilize the update functionality built into Veil to work, you will need to have cloned Veil from github because it requires the git information stored within the Veil directory to update. If you installed via apt, you can always do an apt-get update to get the latest version within the repositories.
  • Validation to LHOST and LPORT – To help prevent any confusion on when to add the LHOST and LPORT value, we’ve expanded our validation checks to catch additional exceptions and provide feedback if entering either parameter at the wrong screen.
  • Default msfvenom options –  Default options for msfvenom, such as PrependMigrate, can now be specified in /etc/veil/

How to use Cobalt Strike’s Beacon with Veil

Raphael Mudge recently made a great post on how to deliver and execute Beacon on a targeted machine with the metasploit framework. What’s great is that the Veil-Evasion framework also supports the creation of an executable that will act as a stager for Beacon right out of the box! We figured it would be worthwhile to show how to do this with one of Veil’s payloads. You can follow this guide or use the post that Raffi made as it follows nearly identical steps.

To begin, we want to start up Cobalt Strike and set up a Beacon listener on any port, in this case, we’ll use a http Beacon on port 80.


With our handler setup, it’s important to look at the CobaltStrike console and note the location of the beacon dll that we will be using. You should see something like this:

Beacon Location

Once we have this info, let’s drop into Veil-Evasion. Basically we can choose any Veil payload type. In this instance, I’ll use python/FlatInjection. We don’t need to do anything special at this moment, just give Veil the “generate” command.

Flat Injection Selected

This next section is where we will point to our beacon listener. The payload we want to use is windows/dllinject/reverse_http. After that, provide Veil with the IP and port that your beacon listener is setup to use. One thing to note, is we will need to add in an “extra” option, which is the location of our dll (which we received earlier). Our console should look similar to the following:

Beacon Generated

After generating your shellcode, just provide a name for the executable, and you should be good to go. Simply take the executable and drop it onto your target/victim system by any means necessary. After getting it on the machine, and executing the payload, you should see your Beacon start checking in.

Received Beacon

If you have any questions on this, be sure to let us know, hit us up on twitter, leave a comment, or submit a github issue if needed. Otherwise, hope this helps and don’t get caught!

We’d Like to Introduce – V-Day

Over the past 6 months the Veil team has built up a decent private repository of publicly-drawn and privately-developed AV-evasion research. This has resulted in 30+ private payload modules that span a variety of methods and languages. We realized that this code was doing no good just sitting around; we want these methods out! So after some debate, a schedule for the next year has been drafted to release these modules in the main Veil github repository.

The Veil-Evasion team is starting something we’re calling “V-Day”, for victory over antivirus. On the 15th of every month, for the next year, at least one new payload module will be released. We’d like to thank Microsoft with their Patch Tuesday as our inspiration :) With that being said, we’re happy to release the following updates to Veil-Evasion for our very first V-Day.

We’ve released the capability to include void pointer casting to all python payloads. We wanted to be able to provide some information to you about how they work and what it means for you.

Currently, Veil now has two methods of injecting shellcode into memory, Void Pointer Casting or VirtualAlloc (and a few additional calls). Both methods can work, but void pointer casting does require a specific target and/or configuration setting.


Void pointer casting works by storing our shellcode in an array, and passing a pointer to the array to a function which then executes the shellcode. The issue you may encounter with this method of injecting code is DEP (Data Execution Prevention). When injecting shellcode in this manner, we aren’t “marking” the location in memory where our shellcode is stored as being executable. Therefore, systems (typically Vista or newer) that use DEP will likely prevent your shellcode from being executed. You may receive an access violation message, or simply nothing at all. There is a chance that this method in injecting and executing shellcode will work, however, it does require that the enforcement “level” is set in an insecure manner, potentially such as “AlwaysOff”.

VirtualAlloc lets us bypass standard DEP enforcement. When we use VirtualAlloc to allocate memory, we specifically set the allocated memory as being “PAGE_EXECUTE_READWRITE“. This allows us to not only write to the allocated section of memory, but also execute the code stored inside of it as well. This is a valid call that can be used to bypass DEP. Therefore, for DEP protected systems, this is likely the injection method that will work to execute your payload.


If you have any questions about this, feel free to leave a comment, or just ask any of us on twitter.

Note: with this version of Veil, the ./config/ settings file may have moved for some installations to /etc/veil/ , and the ./output/ folder is being moved to ~/veil-output/ in an effort to move towards proper Debian compliance for Kali.

Thanks, and don’t get caught!

Veil v2.0.4 Released!

The Veil team worked on adding a couple new features to over the weekend, and we’re happy to say that we were able to push them out into the tool.  The two main features that have been added to the tool are:

  • x64 compatibility – Veil originally was designed for x86 versions of linux (or Kali specifically).  Over the weekend, we’ve updated our setup script to make Veil compatible with both x86 and x64 versions, so now you shouldn’t have issues running it on any version of linux!
  • Update Feature – Originally, in order to update Veil, you had to be in the same directory as Veil itself, and then perform a “git pull”.  We’ve now added an update function within Veil that will allow you to update Veil from either the command line or menu.  It can be run from any directory, and will ensure that your version of Veil is up to date!

Note: The way that packages are installed in Kali, the update functionality built into Veil will not work.  In this case, the Veil team will be consistently working with the great people on the Offensive Security team to ensure that Kali is regularly updated within its repos.

If anyone has any questions, feel free to ask, otherwise don’t get caught!

Building in the Meterpreter .dll

Today we are releasing a few new modules that take a slightly different approach to payload delivery.  Please welcome the shellcode-less python/MeterHTTPContained and python/MeterHTTPSContained modules, which encapsulate the meterpreter .dll within a python payload.

These payloads read in the meterpreter metsrv.dll from the Metasploit install path, binary patch in some header information, an agent string, communication/expiration timeouts, ssl information, and finally the address/port of the metasploit handler. The binary data of the .dll is then compressed using zlib and transformed into a base64 string, and a launcher is built that decompresses the .dll and injects it into memory. Since the meterpreter .dll is built for reflective injection, it will take over execution from there.


One detail that was glossed over: meterpreter’s checkin for reverse_http and reverse_https aren’t quite a simple as “connect and read”. Various URI’s with varying checksums are sent depending on communication state. Normally, a stager checks in with a handler, receives the meterpreter .dll as a response, and starts comms. So how do we ‘trick’ the handler into not sending the full .dll? We use the already-established comms checksum value, which will register the stager as an ‘orphaned session’ and reattach it to the particular handler.


For anyone interested in the technical details, the metasploit reverse_http/https handler is located at /usr/share/metasploit-framework/lib/msf/core/handler/reverse_http.rb . URI_CHECKSUM_CONN is the checksum value for established comms that we use to generate our initial URI, and generate_uri_checksum(sum) is the short checksum algorithm that the handler uses. The checksum was ported over to python so we can generate unique checkins instead of hardcoding values.


Powershell Payloads? Yes please!

With Veil’s 2.0 release, several powershell payloads were released which we wanted to detail a bit more here.

powershell/VirtualAlloc uses the VirtualAlloc() pattern to inject shellcode into memory. The concept was adapted from Matthew Graeber’s excellent article concerning powershell shellcode injection. The powershell string is then compressed and a .bat launcher is built, which will invoke the powershell binary with a command that decompresses and runs the original powershell file. The .bat launcher does basic x86/x64 architecture detection to attempt to work on multiple platforms.

powershell/DownloadVirtualAlloc takes adapts the technique from ObscureSecurity’s writeup to download a secondary powershell payload from a separate sever, which it then runs. A small encrypted command is output which will download a larger secondary powershell stage from a specified webserver and launch it in memory.

powershell/PsexecVirtualAlloc is similar to the VirtualAlloc module, but it builds a metasploit .rc resource file that’s compatible with metasploit’s psexec_command module. When you run the produced resource file in metasploit, the psexec_command module is selected and the COMMAND parameter is properly set to the powershell VirtualAlloc launcher. You can then set the RHOSTS, SMBUser and SMBPass and then psexec away, utilizing pure powershell for AV-evading goodness.

Also of note, Veil now has a development branch on its GitHub page. New bug fixes and features will be pushed here first, but with no guarantees to stability. If you have any questions, or if something breaks, please get in touch with us in #veil on freenode!

Tutorial – Payload Development

A big part of our effort with Veil is to provide a framework for the community to integrate their own AV-evasion methods, public or private. With that said, we wanted to provide a tutorial on the general payload development process for Veil.

We’ve provided a payload template at ./modules/payloads/ :


The top of each module contains a comment string detailing the workings of the module, any references/prior work the module uses or was based on, and the author who wrote the module.

Imports of common Veil modules are up next using the form from modules.common import MODULE syntax, where MODULE is any of the python files contained in ./modules/common/*. These methods are then called with module.method() syntax. The following is a breakdown of some of the common modules/methods payloads can take advantage of:

  • common.helpers : various string/variable randomization methods, display helpers, etc.
  • common.encryption : encryption related methods (AES, letter substitution, etc.) and language-specific crypters/obfuscators (currently just Pyherion)
  • common.shellcode : the most commonly used module, allows for modularized shellcode generation: call shellcode.generate() to utilize built in menus and return the raw shellcode selected
  • settings : Veil’s configuration file, options referenced with syntax of  settings.CONFIG_SETTING. Check out /etc/veil/ for all available options.

Under __init__(), a few options are required:

  • self.description : a 1-2 sentence description of the payload
  • self.language : the language to group the payload under (currently python/cs/powershell/c#/native)
  • self.extension : the extension to write the payload file out to

Other options can used as needed:

  • self.shellcode = shellcode.Shellcode() : instantiated if shellcode generation is needed
  • self.notes : additional notes (i.e. manual compilation instructions) to display to the user on generation
  • self.required_options : payload options that require a value, of the format {option_name : [“default_value”, “description”], … } . A commonly used instance of this is the “compile_to_exe” option to instruct Veil to automatically compile the payload. Note: if no default value is supplied, Veil will automatically require a user to input a value before payload generation.

The generate() method is “where the magic happens”. Shellcode can be generated by Veil’s internal functionality be calling the internal shellcode object with the syntax Shellcode = self.shellcode.generate() like on line 42. Line 48 shows how to use a method in helpers to get a randomized string. Lines 51 and 52 demonstrate how to take advantage of appropriate source code encrypters. Finally, the resulting source code is returned so it can be processed by Veil.

Once you write your own payload module, drop it into the appropriate location in the ./modules/payloads/* folder and it will automatically load into the Veil framework. The general structure is [language]/[method]/[payload]. ‘Method’ at this point consists of “meterpreter” for Meterpreter stagers, and “shellcode_inject” for the various shellcode injection methods.

If you have any questions, feel free to get in touch with in #veil on freenode or checkout our forums at .