Category: Uncategorized

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.

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:

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.

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 :)

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:

The module will create a web page containing a fake wordpress login.

The fake page will be md5ed, and the hash will be used to encrypt the shellcode stored inside the executable.

Once the executable has been placed on a machine and run, it will beacon to the URL specified looking for the web page.

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.

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.

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.

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!

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.

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!

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!

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.

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.

–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:

./Veil-Ordnance.py -p rev_tcp --ip 192.168.63.149 --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:

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!

Time for a followup on the remaining functionality of Veil-PowerView. Today I’ll cover the two most interesting features released, Invoke-UserHunter and Invoke-StealthUserHunter.

As detailed previously, Veil-PowerView started as a pure powershell replacement for various net domain enumeration commands used to gain situational awareness on a Windows network. It expanded into some metafunctions such as Invoke-Netview (a port of Rob Fuller’s netview.exe), Invoke-ShareFinder to find interesting network shares, and Invoke-FindLocalAdminAccess (a port of local_admin_search_enum.rb). These functions are interesting and useful, but we soon realized that we could do a few more really interesting tricks utilizing all this existing powershell AD functionality and Windows API calls.

Invoke-UserHunter chains together particular aspects of Invoke-Netview to find where specific users are logged in on the current network. It can utilize a delay/jitter between host enumerations and works as follows:

The current user and domain are pulled with Get-NetCurrentUser and Get-NetDomain, respectively

Machines on the domain are queried (and the resulting list shuffled) using Get-NetServers, or by reading in a host list

A specific group is queried for users using Get-NetGroup (which defaults to ‘domain admins’), or a specific username is specified, or a user list is given

For each machine in the target list, Get-NetSessions and Get-NetLoggedon are used to see what users are logged in and/or have current sessions (and from where). The script will sleep for a delay between each host enumeration, if specified

The results are compared against the target user list, and matches are displayed

Found machines can optionally be checked for local admin access with Invoke-CheckLocalAdminAccess

Invoke-StealthUserHunter takes a more subtle, ‘red-teamy’ approach to hunting down user locations. It will issue one group query to build a target user list with Get-NetGroup, and one query to find all users (and detailed user information) in the domain with Get-NetUsers. It will then extract all servers found from user HomeDirectory entries, and run one Get-NetSessions call against each found file server (after the delay/jitter if specified) to get current user sessions on those targets. The results of the sessions calls are compared against the target user list, and matches are highlighted. While not as accurate as Invoke-UserHunter as only the file servers in a domain are touched, Invoke-StealthUserHunter is significantly stealthier as only as a handful of queries are made.

The end result? As a normal domain user, running these functions can tell you exactly where domain administrators (or other target users) are logged into, and can optionally tell whether you have local admin access to those boxes. One some domains this can help you point -> click -> get DA :)

Quick sidenote- I received some great feedback from Carlos Perez concerning how to make PowerView standards compliant. I’ll be integrating his suggestions over the next week or so, but a side effect is that many of the method names are likely going to change. This post and last weeks will be updated appropriately with the updated usage. Also, I’m going to be helping @obscuresec and @mattifestation get some of PowerView’s functionality into PowerSploit soon, so keep your ears open for updates.