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!

Happy belated Valentine’s Day all!

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!

Happy Holidays!

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.

Github Link: https://github.com/Veil-Framework/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.

Ordnance has multiple features that I find helpful:

• Instant generation of the stager shellcode
  • reverse_tcp
  • bind_tcp
  • reverse_http
  • reverse_https
  • reverse_tcp_dns
  • reverse_tcp_all_ports
• An encoder is available for removal of most bad characters
• The default Ordnance output will always remain the same
  • By default, only the shellcode is returned to the console
  • With extra flags, the user can obtain the shellcode “metadata” (size, xor key, etc.)

Ordnance is used by passing parameters to it via the command line.  Ordnance’s command line parameters are:

• -p – payload type (rev_tcp, bind_tcp, rev_http, rev_https, rev_tcp_dns, rev_tcp_all_ports)
• –ip – IP address (or domain) to connect to for reverse payloads
• –port – Port number to connect to, or listen on
• -e – Encoder to use when encoding shellcode
• -b – Bad character(s) to avoid within the shellcode (\x00\x0a)
• –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:

./Veil-Ordnance.py -p rev_https --ip 192.168.63.149 --port 443 -e xor -b \x00\x0a --print-stats

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!