PowerSploit is a series of Microsoft PowerShell scripts that can be used in post-exploitation scenarios during authorized penetration tests. PowerSploit is comprised of the following scripts:

--------------
Root Directory
--------------

Inject-Dll:

   Inject-Dll injects a Dll into the process ID of your choosing.

Inject-Shellcode:

   Inject-Shellcode injects shellcode into the process ID of your choosing or within PowerShell locally.

Encrypt-Script:

   Encrypt-Script will encrypt a script (or any text file for that matter) and output the results to a minimally obfuscated script - evil.ps1.

Get-GPPPassword:

   Get-GPPPassword retrieves the plaintext password for accounts pushed through Group Policy in groups.xml.

   Used with permission from @obscuresec (www.obscuresecurity.blogspot.com).

Invoke-ReverseDnsLookup:

   Invoke-ReverseDnsLookup scans an IP address range for DNS PTR records. This script is useful for performing DNS reconnaissance prior to conducting an authorized penetration test.

----------
.\PETools
----------

A PowerShell module used to parse/manipulate Windows portable executables

Get-PEHeader:

   Get-PEHeader is an in-memory and on-disk PE parsing utility.

Get-PEArchitecture:

   Get-PEArchitecture returns the architecture for which an executable was compiled.

Get-DllLoadPath:

   Get-DllLoadPath returns the path from which Windows will load a Dll for the given executable.

----------
.\RE_Tools
----------

Tools to aid in reverse engineering

Get-ILDisassembly:

   disassembles a raw MSIL byte array passed in from a MethodInfo object in a manner similar to that of Ildasm.

-------
License
-------

The PowerSploit project and all individual scripts are under the BSD 3-Clause license.

-----
Usage
-----

The scripts in PowerSploit are not scripts in the traditional sense in that you just execute them at the command line and go. Rather, each script defines a function that can consequently be called at the command line. This method, in my opinion, provides more flexibility with PowerShell. If executing these scripts as traditional scripts ("dot source") becomes necessary, you can always append the command you want to execute after the function definition.

Refer to the comment-based help in each individual script for detailed usage information.


------------------
Script Style Guide
------------------

For all contributors and future contributors to PowerSploit, I ask that you follow this style guide when writing your scripts.

* Avoid Write-Host at all costs. You should output custom objects instead. For more information on creating custom objects, read these articles:
   * http://blogs.technet.com/b/heyscriptingguy/archive/2011/05/19/create-custom-objects-in-your-powershell-script.aspx
   * http://technet.microsoft.com/en-us/library/ff730946.aspx

* If you want to display relevant debugging information to the screen, use Write-Verbose. The user can always just tack on '-Verbose'.

* Always provide descriptive, comment-based help for every script. Also, be sure to include your name and a BSD 3-Clause license.

* Make sure all functions follow the proper PowerShell verb-noun agreement. Use Get-Verb to list the default verbs used by PowerShell.

* I prefer that variable names be capitalized and be as descriptive as possible.

* Provide logical spacing in between your code. Indent your code to make it more readable.

* If you find yourself repeating code, write a function.

* Catch all anticipated errors and provide meaningful output. I prefer 'Write-Warning; return' to Write-Error. Use your discretion as to what you think works best for your script though.

* If you are writing a script that interfaces with the Win32 API, do not compile C# code. It is imperative that nothing aside from the script touches the disk.

* Do not use hardcoded paths. A script should be useable right out of the box. No one should have to modify the code unless they want to.

* I don't want any v3 dependencies right now.

* Make your overall script a function so that Get-Help can be used properly.

* Use positional parameters and make parameters mandatory when it makes sense to do so. For example, I'm looking for something like the following:
   * [Parameter(Position = 0, Mandatory = $True)]

* Don't use any aliases. They make code more difficult to read for people who are unfamiliar with a particular alias.

* Don't let commands run on for too long. For example, a pipeline is a natural place for a line break.

* Don't go overboard with inline comments. Only use them when certain aspects of the code might be confusing to a reader.

* Use Out-Null to suppress unwanted/irrelevant output.

* Only use .NET code when absolutely necessary.

* use the return keyword when returning an object from a function. I know it's not necessary but it makes the code more readable.

* Use default values for your parameters when it makes sense. Ideally, you want a script that will work without requiring any parameters.