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/settings.py

PrependMigrate with Veil

We want to start this tutorial off with stating ScriptJunkie wrote a great article on PrependMigrate and how it works.  In a nutshell, PrepentMigrate allows you to “start the shellcode in a new process”.  This great feature works very well in instances where you receive your callback, and it dies nearly immediately.  There could be multiple reason for this happening, and Metasploit’s PrependMigrate will help “save your shell”.

Now, by default, Veil payloads do not have this enabled.  In order to do utilize this feature, we will need to set this when we are creating our payload within Veil.  To begin, go ahead and start Veil, select your payload, and provide your LHOST and LPORT values.  In this instance, we’re using python/FlatInjection, however, this should work for all payload options.  When Veil asks if you have any additional msfvenom options, be sure to enter:

PrependMigrate=true

PrependMigrate

Once this has been entered, allow Veil to generate your shellcode, and then wrap it into a windows executable.

Now, simply set up your handler, drop your payload on your target machine, and execute it.  If you’re viewing the running processes on the target machine, you will see your original payload running, but also rundll32.exe.  Your meterpreter session (assuming that is your payload of choice) is now running within the rundll32.exe process and hopefully you have kept your session!

Hope this helps, feel free to ask any questions, and don’t get caught!

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.

BeaconListener

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.

Voidcast

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.

Virtualalloc

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/veil.py settings file may have moved for some installations to /etc/veil/settings.py , 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!

Veil is Available in Kali Linux

The Veil development team is happy to announce that as of today, Veil has been added to Kali’s repositories!  Veil will always be available via github, but now we can also simply use apt to install Veil within Kali.

In order to install Veil with apt, simply run the following two commands:

apt-get update
apt-get install veil

You should see something similar to the following:Veilkaliinstall

After installing Veil, navigate to the setup directory (as shown above it is as /usr/share/veil/setup) and run the setup script like you normally would. The script just ensures that all Veil specific dependencies are installed and sets up up a few variables that Veil uses during normal use.

After this, simply typing veil will start Veil for your use within Kali!  We’re really happy and humbled to have Veil added into Kali, and hope to continue ensuring Veil not only helps us, but can help the security industry.

As usual, if you have any questions, bugs, requests, comments, etc. please don’t hesitate to get in contact with us on Twitter, Github, or via e-mail.

Thanks, and don’t get caught!

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/template.py :

payload_template

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/settings.py 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 https://www.veil-framework.com/forums/ .

Pyherion

A recently implemented feature in Veil is the pyherion ‘crypter’ for all python payloads. This came about from thinking, “how far can we go with python obfuscation?”. AES/DES/etc. encryption of shellcode is great, but the decrypter stubs more or less remain the same. How can we randomize the file as much as possible?

Taking a cue from from the excellent Hyperion PE-crypter from the folks over at http://nullsecurity.net, let’s trying AES’ing the entire code string of the payload with a random key. Since this is python and not C, we’ll use pycrypto’s AES capability to encrypt the entire payload string with a randomized key. Using python’s exec() function, we can then execute the entire file after it’s decrypted dynamically. So we go from this:

pyherion_unencrypted

To this:

pyherion_encrypted1

That still has some standard patterns, so let’s base64 encode it and wrap it in another exec wrapper. This code will function fine as a straight python file, but what if we want to compile it to an exe using pyinstaller or py2exe? When building the binary, pyinstaller/py2exe needs to know what libraries to package with the python interpreter beforehand, so any imports need to be extracted out. Let’s shuffle those and import pycryto/base64 specifically as random names. We’re left with a series of randomized imports, and a single exec() statement that invokes a base64 encoded, then AES (with a random key) encoded string of our original payload file. This code changes every time its generated, even for the same start file:

pyherion_encrypted2

This code is implemented in ./modules/common/crypters.py for all Veil python payloads. To use, set the “use_pyherion” to “Y” in the payload menu before generating your payload. A standalone version is in ./tools/pyherion.py , which will take (almost) any python file and produce a crypted version.

Check out our tutorial and writeup on new Veil 2.0 features.

 

Veil v2.0 : Towards a True Framework

Repo Location: https://github.com/Veil-Framework/Veil-Evasion

Team Veil is proud to announce the release of Veil v2.0.  This drastically reworked version of the Veil AV-evasion framework incorporates a new structure, a slew of new features, and a variety of new payloads:

New Structure

  • Veil has moved from a single flat file towards a truly modular framework:
    • Payload modules dropped into ./modules/payloads/[language] are loaded into the framework automatically
    • Common reusable functions are stored in various files in ./modules/common/*
    • Source/compiled files are output by default to ./output/source/ and ./output/compiled/
    • ./config/update.py is executed automatically on first run, producing a common configuration file at ./config/veil.py, which can be edited manually
    • External tools used by payloads are stored in ./tools/
    • ./doc/* contains pydoc generated documentation for the framework
  • A tutorial describing how to develop payload modules is forthcoming.

New features

  • Veil’s menus and interface have been redesigned for increased usability.
  • One of the common requests for Veil was the inclusion of additional msfvenom shellcode payloads. To incorporate this, we built in automatic crawling of the metasploit /windows/* payload tree and the extraction of necessary payload parameters. The payloads should tab complete within the shellcode selection menu, in msfvenom windows/PAYLOAD format.
  • Tab completion has also been added in a variety of places around the framework, including most menus, LHOST for IP completion, and LPORT for 4444 completion. Try it out!
  • A new python ‘crypter’ named ‘pyherion’ (inspired by Null Security’s Hyperion) has been introduced, which encapsulates python payload files in an AES/base64 encoded wrapper that dynamically decodes/decrypts the python code in memory and executes it. A standalone version has also been introduced in ./tools/pyherion.py . A short post explaining its implementation details will be forthcoming.
  • Command line switches have been implemented for almost all options. Type ./Veil.py -h for details.

New payloads

  • C payloads – Using both a void pointer reference and direct injection into memory with VirrtualAlloc calls
  • Powershell – VirtualAlloc injection, MSF-psexec formatted resource file generation, and download/execution of a secondary payload.
  • C# payloads – VirtualAlloc and base64 obfuscated payloads have been introduced, along with C# .exe compilation.
  • Native payloads – hyperion and pescrambler