It’s been about two months since the release of Empire 1.2. We took a quick breather after coming down from our sprint to BSidesLV and the two follow-up releases. Part of this lull was to work on massive rewrite of PowerView 2.0 which I spoke about a few weeks ago. Much of this Empire 1.3 release is centered around updating the framework’s PowerView modules with this new code, and coming up with a process to streamline integration between the two projects.
Previously, the source for each PowerView-based module (like situational_awareness/network/userhunter, which utilized Invoke-UserHunter) was broken out into hand-stripped files in the module_source/situational_awareness/network folder. This was done to reduce the total size of the scripts transported to an agent on each module run. For example, if you’re just enumerating the DCs for a domain (a small code snippet) you don’t need to have the entire PSReflect codebase transported along with it. The downside is that this makes updating the files a pain, complicated by the fact that many functions with PowerView are linked and dependent on other functionality in the script (to cut down on code reuse).
Empire 1.3 now uses a class of helper functions to take a function name and a raw script string (like powerview.ps1), and recursively trace through the function dependencies needed. A new trimmed script is dynamically generated based on only the required functions (with comments stripped), and if the helpers determine that PSReflect is needed by any functions in the final set, the declarations/overhead are inserted as well. The end result is a single source script dependency and a (hopefully!) more rapid turnaround for updating any of PowerView’s functionality in Empire.
With this revamped integration, we went ahead and added in 9 additional new modules from PowerView’s code base, renamed some more, and eliminated others. Also, the PowerView specific functions have been moved to situational_awareness/network/powerview/* to keep everything a bit more organized. Here are the new functions:
- get_forest_domain integrates Get-NetForestDomain, which will return information on all domains in the current (or specified) forest.
- get_group integrates PowerView 2.0’s Get-NetGroup while get_group_member integrates Get-NetGroupMember. These functions will pull information on group objects and group member objects, respectively. Our bad for forgetting to include these previously :)
- find_user_field and find_computer_field (Find-UserField and Find-ComputerField) allow you to easily search through the description (or other) fields of user and computer objects for specific terms. This is something that @obscuresec has written about before.
- get_ou and get_gpo (Get-NetOU and Get-NetGPO) will return OU and GPO object information, while get_object_acl can enumerate access control information for specific AD objects. If you’re interested, my next post will be on utilizing this ACL enumeration functionality to do some interesting stuff.
- find_gpo_location and find_gpo_computer_admin (Find-GPOLocation and Find-GPOComputerAdmin) do some fun cross-linking with GPO and OU/user/computer correlation. I should have a post out soon(ish) on this as well.
- process_hunter (Invoke-ProcessHunter) lets you hunt for processes owned by specific users on the domain, or (more useful) specific process names. Think putty.exe :)
- find_foreign_group and find_foreign_user (Find-ForeignUser and Find-ForeignGroup) round out the new additions by letting you enumerate users and groups in a domain not a part of the domain queried. If you’re not sure why this might be useful, check out some of the domain trust posts on this blog.
rvrsh3ll has also started working on a set of ./recon/* modules. The first one is recon/find_fruit (built on PowerSploit’s Get-HttpStatus), which will scan a given network range for potentially exploitable web services (Tomcat, JBoss, etc.). He’s working on some other cool modules, so be sure to keep an eye on ./recon/*.
pasv submitted a situational_awareness/host/paranoia module that will “Continuously check running processes for the presence of suspicious users, members of groups, process names, and for any processes running off of USB drives“. The module will run in the background and display output when any of the trigger conditions hit.
Other changes since the official 1.2 release include @xorrior‘s update to his situational_awareness/host/winenum module, a fix for a RCE in the Empire control server disclosed by @zeroSteiner (ya that was bad lol), and @jamcut‘s update to the Office Macro to enable ‘legacy’ support (1997-2003 documents).
As always, hit us up on Freenode in the #psempire, on Twitter, or on Github with any questions or issues.
Hi, nice job. Is it possible to automatically execute commands when we receive an agents connection?
Yep! Check http://www.harmj0y.net/blog/empire/empire-1-4/ . If you set a module’s options then do “set Agent autorun” and “execute”, it will set agents to automatically task that module code to autorun on agent checkin.