Category: V-Day

Welcome! For our June 15th V-Day, we have two different updates for Veil-Evasion.

First off, Josh Pitts (@midnite_runr) has pushed multiple updates to the Backdoor Factory last month. We’ve incorporated his updates into Veil-Evasion, and everything works great! By the way, he also released a new tool called the Backdoor Factory Proxy, check it out! It’s an awesome tool that can backdoor executables mid-download when performing a man-in-the-middle attack against your target.

The other addition we’ve made is adding the heap injection memory allocation technique to our C shellcode injection payloads. Originally, we had two shellcode injection payloads, virtual and void. Now, these have been combined into a single C payload (flat) which contains all three memory injection techniques.

We like to release these “base” methods for injecting shellcode so the community has an example to base their own obfuscation methods off of. Have an interesting method to bypass Antivirus in C, or any other language? Send us a pull request and we’ll get it added in!

This month’s V-Day has a few new C# payloads, and some nice new Python obfuscation. Veil-Evasion 2.8.0, just pushed to the master branch, now implements two new C# payloads, cs/meterpreter/rev_http and it’s SSL wrapped brother cs/meterpreter/rev_https. These are similar to the C stagers released a few months ago, as well as the Python reverse http[s] payloads released in January. The Python posting has some more detailed information. These payloads also have the MSF http checksum algorithm built in as well, so each run should request a shiny new resource URI for staging. Oh, and these work great against a beacon handler.

We also have some newly-developed Python obfuscation integrated. Last week, I released a project named Pwnstaller, which generates an obfuscated version of the Pyinstaller runw.exe loader used by Veil-Evasion Python payloads. A detailed blog post on its workings was released here. Pwnstaller has now been integrated into Veil-Evasion for all Python payloads, with “2 – Pwnstaller” now being an option on the Python compilation menu:

There is also a “–pwnstaller” cli flag added that can force Pwnstaller usage. A backup of the original Pyinstaller runw.exe loader is now located in ./tools/runw_orig.exe, and can be restored to /opt/pyinstaller-2.0/support/loader/Windows-32bit/ if desired. A presentation at BSidesBoston was given on Pwnstaller this past Saturday (5/10/14) and the slides are can be found here.

For the April 15th V-Day release, we have uploaded a single payload into the master branch of our github repo. This is a new payload “type” for Veil-Evasion. As of yet, all of Veil-Evasion’s payloads are started in their own process, create a thread, and execute their embedded shellcode.

The “pidinject” payload, takes the shellcode embedded inside it, and runs it inside of another process, essentially allowing you to migrate your shellcode into another running process (assuming you have the permissions to interact with said process). All you need to do is provide the process ID of the process you wish to have your shellcode run inside of, and then you’ll be set.

For our V-Day this month, we have created a new “type” of add-on to Veil-Evasion. We are releasing two auxiliary modules this month based off of feedback we’ve heard from the community. The modules are:

War file wrapper

Python “compiler”

To go into a little more detail, we’ve been asked multiple times if Veil is able to create a .war payload. As of yesterday, this functionality was not in Veil-Evasion. If users wanted to create a .war payload, they had to perform the process themselves manually. However, with the inclusion of the War file wrapper, this doesn’t need to be done manually anymore. You can simply invoke the war wrapper like you would any other Veil-Evasion payload. However, the only option it needs is the path to an executable. Once you “generate” your payload, you will now have a .war file of the executable file you provided.

The python “compiler” is something that resulted out of the large number of tests we run when trying to make a payload. We would always have to look up the exact command to convert any python script we were currently working on into a Windows executable. Well, we decided it would be easier to just automate this process too. So the pyinstaller wrapper will take any python script as its required option, and “compile” it into an executable.

Thanks for using the Veil-Framework, please keep giving us a feedback, we do listen, and if you have any questions, just ask in our forums!

For our January V-Day, we’re introducing two new payload modules, python/meterpreter/rev_http and python/meterpreter/rev_https. These stagers are shellcode-less, ‘pure’ Meterpreter stagers somewhat similar to traditional reverse_tcp stagers.

Meterpreter reverse_https[s] stagers are actually a bit simpler than reverse_tcp. The general idea is the same- the handler serves up a .dll file that the client then injects using the VirtualAlloc/etc. methodology. However, instead of having to patch the .dll ourselves with assembly instructions and the socket file descriptor, the Metasploit handler patches the user-agent, transport method (http/https), url and expiration/communication timeout dynamically as it serves the Meterpreter .dll:

Since http[s] stagers are packet-based instead of stream-based, the MSF devs put a system into the handlers that corrals ‘orphaned’ sessions. That is, if you close your reverse_http handler, then start it up later (within the specified reconnect window) the handler will pick the session back up and reregister it. We talked about this during our Building in the Meterpreter .dll post. Here, since we’re registering a session in the correct way, we stay with the ’92’ checksum value (which corresponds to URI_CHECKSUM_INITW).

With the checking algorithm implemented in the stagers, you’ll get a nice and different checksum value every time each stager is run, instead of having to rely on a single hardcoded value. Another nice little bonus with the rev_http is that it plays functions nicely as a native stager for Cobalt Strike’s beacon. We talked about using beacon with Veil previously and this gives a nice alternative to using straight shellcode 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”. ./Veil.py -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, “crypters.py” has been absorbed into “encryption.py” and “randomizer.py” has been absored into “helpers.py”. Check out ./modules/payloads/template.py 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.

allocate a (length-byte + 5) buffer, mark it as writable and executable

at buffer[0], write some assembly that stores the current socket ID of the connection in the EDI register

at buffer[1:4] store the int value of the current socket ID

read length bytes from the connection from the pipe into buffer[5…] (this is the meterpreter .dll)

invoke call the shellcode blob with the VirtualAlloc() pattern or void pointer casting

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.

Hello and welcome to our second V-Day! We’re happy to push the Veil-Evasion 2.1.0 release to our master branch. As standard with any of our releases, we’d like to document for you exactly what has changed:

New Payload – Joshua Pitts’ awesome tool The Backdoor Factory has been integrated into Veil. This tool has way more features to play around with than what we’re defaulted to- be sure to play around with it and check it out.

Self-Contained Payload Update – Our previous release of the self-contained payloads used an older version of the metserv.dll and would crash if you did not use the correct version. This has since been updated and the latest dlls are now being used within the self-contained payloads.

Re-added Update Functionality – Somewhere during our development project, we accidentally removed the capability to update Veil-Evasion directly within the tool. This functionality has been added back in (again). :)

Note: To utilize the update functionality built into Veil to work, you will need to have cloned Veil from github because it requires the git information stored within the Veil directory to update. If you installed via apt, you can always do an apt-get update to get the latest version within the repositories.

Validation to LHOST and LPORT – To help prevent any confusion on when to add the LHOST and LPORT value, we’ve expanded our validation checks to catch additional exceptions and provide feedback if entering either parameter at the wrong screen.

Default msfvenom options – Default options for msfvenom, such as PrependMigrate, can now be specified in /etc/veil/settings.py

Over the past 6 months the Veil team has built up a decent private repository of publicly-drawn and privately-developed AV-evasion research. This has resulted in 30+ private payload modules that span a variety of methods and languages. We realized that this code was doing no good just sitting around; we want these methods out! So after some debate, a schedule for the next year has been drafted to release these modules in the main Veil github repository.

The Veil-Evasion team is starting something we’re calling “V-Day”, for victory over antivirus. On the 15th of every month, for the next year, at least one new payload module will be released. We’d like to thank Microsoft with their Patch Tuesday as our inspiration :) With that being said, we’re happy to release the following updates to Veil-Evasion for our very first V-Day.

We’ve released the capability to include void pointer casting to all python payloads. We wanted to be able to provide some information to you about how they work and what it means for you.

Currently, Veil now has two methods of injecting shellcode into memory, Void Pointer Casting or VirtualAlloc (and a few additional calls). Both methods can work, but void pointer casting does require a specific target and/or configuration setting.

Void pointer casting works by storing our shellcode in an array, and passing a pointer to the array to a function which then executes the shellcode. The issue you may encounter with this method of injecting code is DEP (Data Execution Prevention). When injecting shellcode in this manner, we aren’t “marking” the location in memory where our shellcode is stored as being executable. Therefore, systems (typically Vista or newer) that use DEP will likely prevent your shellcode from being executed. You may receive an access violation message, or simply nothing at all. There is a chance that this method in injecting and executing shellcode will work, however, it does require that the enforcement “level” is set in an insecure manner, potentially such as “AlwaysOff”.

VirtualAlloc lets us bypass standard DEP enforcement. When we use VirtualAlloc to allocate memory, we specifically set the allocated memory as being “PAGE_EXECUTE_READWRITE“. This allows us to not only write to the allocated section of memory, but also execute the code stored inside of it as well. This is a valid call that can be used to bypass DEP. Therefore, for DEP protected systems, this is likely the injection method that will work to execute your payload.

If you have any questions about this, feel free to leave a comment, or just ask any of us on twitter.

Note: with this version of Veil, the ./config/veil.py settings file may have moved for some installations to /etc/veil/settings.py , and the ./output/ folder is being moved to ~/veil-output/ in an effort to move towards proper Debian compliance for Kali.