Veil-Evasion 2.3.0 – More Stagers

Time for our December V-Day. Veil-Evasion 2.3.0 has been pushed to the master branch and we’d like to let you know exactly what’s changed:

  • New Payloads – meterpreter/reverse_tcp stagers for C# and Python have been released under cs/meterpreter/rev_tcp and python/meterpreter/rev_tcp. These function similarly to the C stagers released on our last V-Day.
  • C# obfuscation –  People may have noticed that our C# payloads look surprisingly similar on each generation: this is because our first approach was a simple template that we substituted connection options into. All C# payloads now implement basic variable and method obfuscation in an attempt to generate slightly dissimilar payload “families”. More advanced obfuscation will be implemented in upcoming releases.
  • Python self-expiring payloads – Python payloads now have an expiration option; this will be covered in more detail in an upcoming post.
  • Payload hash record – the SHA-1 hash of every generated payload executable is now kept in ~/veil-output/hashes.txt. An upcoming post will show how to put this to use.
  • Payload reorganization – The way payloads are organized has been changed. The general structure is now [language]/[method]/[payload]. ‘Method’ at this point consists of “meterpreter” for Meterpreter stagers, and “shellcode_inject” for the various shellcode injection methods. List on the main menu will show you the structure, or you can browse it directly at ./modules/payloads/*
  • Command line options changed – Along with the payload reorganization, the “-l” command line option has been eliminated and “-p” now takes the entire payload name, i.e. “-p python/meterpreter/rev_tcp”. ./ -p will list all available payloads if a specific one isn’t specified. Also, new options have been introduced, “–overwrite”, which will overwrite existing source/compiled payload files if they exist, and “–clean” which will clean out payload folders.
  • Backend Changes –  the main class for the payload modules is now “Payload” instead of “Stager”. Additionally, “” has been absorbed into “” and “” has been absored into “”. Check out ./modules/payloads/ for proper usage. Our previous tutorials and posts have been updated to reflect the changes.

We shoot to preserve as much backwards compatibility as possible, but occasionally backend changes do need to be made in the framework. Our goal is to make these types of modifications as rarely as possible, and to give everyone a heads up for major interface and framework tweaks. With these consolidated changes, usability should hopefully stay uniform for at least the next year.


Veil-Evasion 2.2.0 – Native Stagers

Shellcode injection has been around for a long time and usually utilizes four standard windows API calls:

  1. VirtualAlloc() is used to allocation a RWX memory page to hold the shellcode
  2. RtlMoveMemory() (or some other low-level copy function) is used to copy the shellcode bytes into the region reserved by VirtualAlloc()
  3. CreateThread() is used to create a thread within the virtual address space of the calling process
  4. WaitForSingleObject() is used to wait until the thread exits

Since the Metasploit .dll is built to be reflectively injectable using Stephen Fewer’s awesome work, we can use the same process to inject the .dll into memory. If we make a few more tweaks, we can build a pure Metasploit stager without resorting to shellcode. Egypt did a great job describing how the Metasploit stager works :

  1. establish a socket connection to the Metasploit handler
  2. read a 4-byte length
  3. allocate a (length-byte + 5) buffer, mark it as writable and executable
  4. at buffer[0], write some assembly that stores the current socket ID of the connection in the EDI register
  5. at buffer[1:4] store the int value of the current socket ID
  6. read length bytes from the connection from the pipe into buffer[5…] (this is the meterpreter .dll)
  7. invoke call the shellcode blob with the VirtualAlloc() pattern or void pointer casting
  8. the meterpreter .dll now uses the already-established socket for communication, avoiding an additional connect back

Raphael Mudge did a great post a bit ago talking about building these types of loaders, and we stumbled upon his stager code a while back and adapted the code for Veil-evasion. For today’s V-Day, we’re releasing a traditional and psexec-able service versions of this c-stager in Veil-evasion v.2.2.0 under c/meter_rev_tcp and c/meter_rev_tcp_service. We’ve implemented some basic randomization and method obfuscation to decrease detection.

Have fun :)