March V-Day

Hello All!

For this (late) March V-Day, we’re happy to add in a module that was developed and submitted to us from @byt3bl33d3r!  This is a python based beaconing payload.  The payload was based off of the original POC from @midnite_runr (available here).

If configured to beacon out for data, the payload will continuously call back to a system of the attacker’s choice every X seconds.  Once the beacon receives data (a web server 200 code) from the web server, it will attempt to inject the data into memory and execute it.

To use this payload, you will want to dump the raw shellcode to a file, vs. storing it in a \x1f\xbc… format.

Thanks to @midnite_runr for the original POC and thanks to @byt3bl33d3r for not only writing the module, but working with us to get it ready for release!

February V-Day – Binding Payload

Happy belated Valentine’s Day all!

For February 2015’s V-Day :) we have merged in and accept a payload submitted from m1m1x!  The payload added in through this pull request creates a python based payload that binds to a user-specified port on the machine (versus performing a reverse connection) and waits for the connection from your handler.

Additionally, m1m1x has added in code that will allow you to generate x64 python port-binding payloads.  In order to do this, you will need to have x64 wine with x64 python installed within wine.  As of now, this will have to be manually performed by the user.

If anyone has any questions, feel free to hit us up in #veil on freenode!

January 2015 V-Day!

Welcome to 2015!  For our January 2015 V-Day, we have a small addition to our Ruby shellcode injection payload.  Currently, the payloads are injection shellcode into memory using the VirtualAlloc API call routine, but this was the only method.  We’ve just added in the ability to inject shellcode into memory via HeapCreate and HeapAlloc.

Additionally, the Metasploit Project devs have updated Meterpreter to version 0.0.13.  We’ve just added support for the latest version of Meterpreter in Veil-Evasion.

If anyone has any questions, feel free to reach out to us!


December V-Day – Ruby Stagers!

Happy Holidays!

For our December V-Day we are releasing ruby http and https stagers!  These stagers are written purely in ruby and don’t utilize any shellcode.  Like most ruby payloads, these are fairly tiny once “compiled” (unlike python payloads).  Hope that everyone is able to use these for some fun pwning!

November V-Day – Self-Contained Ruby Payloads

So, last month was our first V-day that we missed. It’s unfortunate, but life happens. We’re sure everyone was quite capable of #avloling without last month’s V-Day, but we’re back this month!

For our November V-Day, we’re happy to release self-contained reverse_http & reverse_https payloads written in Ruby.  These payloads are similar to our self-contained python payloads.  The meterpreter dll is contained within the executable created by Veil-Evasion.  This means that your payload never needs to receive the meterpreter dll over the wire.  When the payload connects back to the handler, it is simply registered as an orphaned connection, and quickly establishes a connection with the handler for command and control.

If you have any questions on how these payloads work, feel free to hit us up on Freenode within #veil or on twitter!

Veil-Ordnance – Fast Stager Shellcode Generation

Generating shellcode is a task that nearly all pen testers have to do at some point, unless they write their own shellcode.  The typical way of generating shellcode consists of using msfvenom, or the combination of msfpayload and msfencode.  Both of these methods can easily generate shellcode for the payload of your choice, and you can invoke shellcode encoders, if necessary, to avoid bad characters.

Since its release, Veil-Evasion has always relied on msfvenom for generating the shellcode within Veil-Evasion payloads.  Leveraging another tool’s capabilities has allowed us to rely on the Metasploit Framework to handle the shellcode generation without requiring too much effort on our end.  However, this has also caused some issues.  On two separate instances, updates to msfvenom’s output has caused Veil-Evasion to “break” by creating invalid/non-working payloads.  This is because Veil-Evasion is parsing the msfvenom output.  In the event that the msfvenom output changes, then our ability to parse it typically breaks, and requires a patch on our end.  Will Schroeder (@harmj0y), Mike Wright (@themightyshiv), and myself (@ChrisTruncer) identified this issue fairly early on when developing Veil-Evasion, and we basically took the approach that we hoped there wouldn’t be changes to the output, or we would deal with it.  Well, we were obviously wrong.  After the first break in compatibility, we discussed the need for having our own shellcode generator independent of the Metasploit Framework.  Even through we agreed it was needed, our other commitments kept our attention.  That was, until we ran into the issue a second time.  At this point, we felt it was something we actually needed to look into.

Jon Yates (@redbeardsec) made a significant contribution by diving into the Metasploit source code to understand how the base MSF shellcode is generated.  He helped catch me up to speed with everything he had learned, and really was a huge asset in writing Veil-Ordnance.  Armed with what I needed to know thanks to Jon, I started writing a small POC that would generate shellcode for a few different payloads.  I selected a few of the more “popular” payloads to support for the initial release, and added them into Ordnance.  However, the tool would require at least one encoder for use, and Justin Warner (@sixdub) graciously created a single byte xor encoder, and said I was free to add it in to Ordnace.  With six different payloads, a single encoder, and a good amount of QA time, I’m happy to push out the initial release of Veil-Ordnance.

Github Link:

CLI Options

NOTE: One MAJOR point to note here, is that Ordnance is a pure port of Metasploit’s stagers within the Metasploit Framework.  We did not write these stagers, they were ported from Ruby into Python, and added to Ordnance.  The Metasploit Framework developers are the guys who deserve full credit for creating these payloads.

Ordnance has multiple features that I find helpful:

  • Instant generation of the stager shellcode
    • reverse_tcp
    • bind_tcp
    • reverse_http
    • reverse_https
    • reverse_tcp_dns
    • reverse_tcp_all_ports
  • An encoder is available for removal of most bad characters
  • The default Ordnance output will always remain the same
    • By default, only the shellcode is returned to the console
    • With extra flags, the user can obtain the shellcode “metadata” (size, xor key, etc.)

Ordnance is used by passing parameters to it via the command line.  Ordnance’s command line parameters are:

  • -p – payload type (rev_tcp, bind_tcp, rev_http, rev_https, rev_tcp_dns, rev_tcp_all_ports)
  • –ip – IP address (or domain) to connect to for reverse payloads
  • –port – Port number to connect to, or listen on
  • -e – Encoder to use when encoding shellcode
  • -b – Bad character(s) to avoid within the shellcode (\x00\x0a)
  • –print-stats – Prints the extra “metadata” about the generated shellcode
  • –list-payloads – lists all currently available payloads
  • –list-encoders – lists all currently available encoders

To use Ordnance to generate reverse tcp stager shellcode, you could use the following command:

./ -p rev_tcp --ip --port 8675


This will output reverse tcp stager shellcode which can be copied and pasted for use.  If you wanted to use Ordnance to generate reverse https stager shellcode, avoid the use of “\x00” and “\x0a”, and see the length of the generated shellcode, you could use the following command:

./ -p rev_https --ip --port 443 -e xor -b \x00\x0a --print-stats

https stats

Assuming the encoder does not run into any character encoding issues, Ordnance would output the stats about the shellcode generated, and then the shellcode itself.

I would love to call upon to community to help add one or two more encoders into Ordnance.  The more encoders, the better to try to help ensure all bad characters could be avoided if necessary.

If anyone has any questions about how to use Veil-Ordnance, please feel free to get in touch with us on twitter (@veilframework), hop on IRC in #veil, or hit us up on Github!  If anyone finds any bugs, please let us know!  Opening an issue on Github lets us easily track problems!  Thanks, and we hope that this can help!

Honor Amongst Thieves – Building Trust in Veil-Evasion Payloads

Anytime that a professional pen tester, or red teamer, uses a tool on an assessment, your customer is trusting you to not introduce additional vulnerabilities into their network.  When you create a backdoor through Veil-Evasion, or any other payload generator, you need to be sure that the payload you are creating connects back to you and only you.  So how can you ensure that the payloads generated by Veil-Evasion only connects to where it is explicitly specified to connect to?  One way would be to perform a complete source code review of Veil-Evasion and perform an environmental analysis of the generated payload.  This method would provide the highest level of assurance.

There is also another way.  There are a number of scripts that can be used to extract the Python source code from a PyInstaller executable.  One such script is called PyInstaller Extractor and written by extremecoders.  This script will extract all files within the PyInstaller executable, including the Python source code.  We can then compare the extracted Python source code with the source code file that’s created alongside of the PyInstaller executable when using Veil-Evasion.  The two Python source code files will match up and prove that there is not any additional code added inside the “compiled” payload, thus the original source code output can be reviewed and trusted as being the actual source code in the resulting payload.  Ironically, as long as the original source code is reviewed and understood to be non-malicious, then you can trust Veil-Evasion payloads.  So, let’s get along with proving this!

Note: This article only discusses PyInstaller payloads.

First, download the PyInstaller Extractor script and place it in the same directory as your Python payload.  Call the PyInstaller Extractor script and pass the Veil-Evasion payload in as the script’s only option.  The script will now extract the files from the PyInstaller executable.  When you ls you should see the different files that were contained within the payload.

Extracted Payload

In this case, since the payload we are looking at was named veilpayload.exe, the extracted file we are looking for is therefore veilpayload.  The veilpayload file contains the Python code that is carried out when running the original executable.  Now, lets perform a comparison of the source code output from Veil-Evasion, and the extracted source code.

Original Source Code

 Original Source Code Output from Veil-Evasion

Extracted Python Code

Extracted Source Code from Veil-Evasion Payload

Performing a quick visual check against the two scripts shows that they are virtually identical outside of small formatting differences and the additional null byte at the end of the extracted source code.  Performing a diff of the two files also verifies this information.

Scripts diffed

In retrospect, this probably should have been among the first few published posts since Veil-Evasion’s initial release.  However, hindsight is always 20/20, so we’re happy we’re able to provide some level of assurance that your Veil-Evasion payloads aren’t backdoored in any way.  Please feel free to follow the steps outlined in this blog post to verify for yourself.  If you have any additional questions, feel free to hit us up on Twitter, Github, E-mail, or on Freenode in #veil!

June 15th V-Day

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

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

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

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


The State of the Veil-Framework

Today, 1 year ago, Veil was publicly released, and it’s humbling to look at how far we’ve come since then.

When we initially released Veil, it was a single flat 538-line file that only contained 7 different payloads. Thanks to the hard work of @harmj0y and @themightyshiv, Veil was expanded into a fully functional framework with significantly expanded capabilities, and the AV-evasion component was renamed Veil-Evasion. With the release of Veil-Catapult and Veil-PowerView, we’ve started looking beyond just the problem of antivirus towards other offensive areas. Our continuing goal with the Veil-Framework is to maintain an open-source toolkit that spans particular gap areas we’ve encountered.

Veil-Evasion originally supported only three different payload shellcode-injection options, Meterpreter’s reverse_tcp, reverse_http, and reverse_https payloads. As of Veil-Evasion 2.0, all Windows payloads from the Metasploit tree are now loaded and available for use within any */shellcode_inject/* payload. Our payload releases then moved beyond just shellcode injectors with the release of native Meterpreter tcp and http[s] stagers, and we soon started a continual payload release cycle name VDay. We’ve debated disclosure, introduced some auxiliary modules, released a Python obfuscator named Pyherion, and recently integrated a generator for obfuscated Pyinstaller loaders named Pwnstaller. We showed you how to easily check if your payloads have been submitted to Virustotal, integrated Veil-Evasion with Cortana, and got a proper logo. Along the way we’ve had the honor of presenting at Shmooon, CarolinaCon, and soon Defcon. Oh, and we just got our own McAfee signature :)


The framework structure now allows anyone to expand or modify the existing codebase. New payload generation modules (public or private) can be dropped into an appropriate language folder and will be automatically loaded up by the framework. We have a lot of existing functionality you can draw on for development of private payload modules, a template located in the tree at ./modules/payloads/, and a tutorial on payload development posted here.

So, we’re a year in now, but where do we go from here? We have a couple of goals we hope to achieve:

  • Port msfvenom to Python – We use MSF’s msfvenom for shellcode generation in the shellcode_inject modules when code isn’t supplied by the user. Being dependent on a third party tool can cause occasional issues, e.g. when the output of msfvenom was modified and a variety of our payloads would crash on execution. Porting msfvenom to Python will allow us to have complete control of the output, and any changes to the tool would be controlled by the Veil Development team, allowing us to account for the changes within the framework.
  • Research – We have a reasonable chunk of private research that’s been feeding our VDay releases. We currently have enough to continue VDay into next year, with some cool stuff hitting in the next few months. We’re keeping on our research efforts and hope to be releasing for a while :)
  • New tool development – We keep building tools to span whatever gap areas we see. The newest tool in development by @harmj0y is a post-exploitation framework named Veil-Pillage, and will be presented on at Defcon.

All that’s really left to say is thanks. We started off creating this project for our own use, but we soon realized we should try to give something back to the industry by making Veil publicly available. The community uptake and use of Veil has been nothing but humbling for all of us. Never did we expect so many people to hear of and use Veil, let alone have it be added to Kali Linux. There have been blog posts, how-to videos, and more developed by the community which showcase the framework and talk about how it’s been successfully used. For all the kind words and support, we thank you.

As always, if anyone ever has any questions on framework modifications, ideas for techniques or modules, or just wants to bounce offensive ideas off of someone, please feel free to get in touch with us. These tools are something we’re genuinely passionate about, and we love talking about new techniques, ways to get better, or simply helping others. We’re just a quick forum post, e-mail, tweet, or IRC message away (#veil on Freenode!).

Thanks for a great first year, and we hope to have many more. Don’t get caught!



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!