Hunting for Domain Users With the Veil-Framework

Time for a followup on the remaining functionality of Veil-PowerView. Today I’ll cover the two most interesting features released, Invoke-UserHunter and Invoke-StealthUserHunter.

As detailed previously, Veil-PowerView started as a pure powershell replacement for various net domain enumeration commands used to gain situational awareness on a Windows network. It expanded into some metafunctions such as Invoke-Netview (a port of Rob Fuller’s netview.exe), Invoke-ShareFinder to find interesting network shares, and Invoke-FindLocalAdminAccess (a port of local_admin_search_enum.rb). These functions are interesting and useful, but we soon realized that we could do a few more really interesting tricks utilizing all this existing powershell AD functionality and Windows API calls.

Invoke-UserHunter chains together particular aspects of Invoke-Netview to find where specific users are logged in on the current network. It can utilize a delay/jitter between host enumerations and works as follows:

  1. The current user and domain are pulled with Get-NetCurrentUser and Get-NetDomain, respectively
  2. Machines on the domain are queried (and the resulting list shuffled) using Get-NetServers, or by reading in a host list
  3. A specific group is queried for users using Get-NetGroup (which defaults to ‘domain admins’), or a specific username is specified, or a user list is given
  4. For each machine in the target list, Get-NetSessions and Get-NetLoggedon are used to see what users are logged in and/or have current sessions (and from where). The script will sleep for a delay between each host enumeration, if specified
  5. The results are compared against the target user list, and matches are displayed
  6. Found machines can optionally be checked for local admin access with Invoke-CheckLocalAdminAccess

Invoke-StealthUserHunter takes a more subtle, ‘red-teamy’ approach to hunting down user locations. It will issue one group query to build a target user list with Get-NetGroup, and one query to find all users (and detailed user information) in the domain with Get-NetUsers. It will then extract all servers found from user HomeDirectory entries, and run one Get-NetSessions call against each found file server (after the delay/jitter if specified) to get current user sessions on those targets. The results of the sessions calls are compared against the target user list, and matches are highlighted. While not as accurate as Invoke-UserHunter as only the file servers in a domain are touched, Invoke-StealthUserHunter is significantly stealthier as only as a handful of queries are made.

The end result? As a normal domain user, running these functions can tell you exactly where domain administrators (or other target users) are logged into, and  can optionally tell whether you have local admin access to those boxes. One some domains this can help you point -> click -> get DA :)

Quick sidenote- I received some great feedback from Carlos Perez concerning how to make PowerView standards compliant. I’ll be integrating his suggestions over the next week or so, but a side effect is that many of the method names are likely going to change. This post and last weeks will be updated appropriately with the updated usage. Also, I’m going to be helping @obscuresec and @mattifestation get some of PowerView’s functionality into PowerSploit soon, so keep your ears open for updates.

2 thoughts on “Hunting for Domain Users With the Veil-Framework

  1. Hi,

    First of all thanks a lot for Powerview !

    In Powershell ISE, i did an “Import-Module .\powerview.ps1” and i’m able to launch “Net-Users” command -> OK.
    But when i try with “Net-Groups” i’ve got several error messages (excuse it’s not English it’s traduction…) :
    Impossible to find type [System.DirectoryServices.AccountManagement.ContextType] : Verify that assembly where it’s present, is loaded line 568 Character : 67

    + $ct = [System.DirectoryServices.AccountManagement.ContextType] <<<< ::Domain
    + CategoryInfo : InvalidOperation: (System.Director…ent.ContextType:String) [], RuntimeException
    + FullyQualifiedErrorId : TypeNotFound

    Any clue please ?

Leave a Reply