bishopfox/asminject
Heavily-modified fork of David Buchanan's dlinject project. Injects arbitrary assembly (or precompiled binary) payloads directly into x86-64, x86, and ARM32 Linux processes without the use of ptrace by accessing /proc/<pid>/mem. Useful for certain post-exploitation scenarios, recovering content from process memory, etc..
asminject.py is a heavily-modified fork of David Buchanan's dlinject project. Injects arbitrary assembly (or precompiled binary) payloads directly into x86-64, x86, and ARM32 Linux processes by accessing /proc/<pid>/mem instead of attaching via ptrace. Useful for tampering with trusted processes, certain post-exploitation scenarios, recovering content from process memory, and bypassing some security controls. Can inject into containerized processes from outside of the container, as long as you have root access on the host.
You can also read more about asminject.py and its origins on its Bishop Fox tool page, including a detailed writeup of the work that inspired the tool.
In this document:
Separate, more detailed documentation:
asminject.py is like dlinject, except it lets you inject any payload you want instead of just loading a library, and it works on multiple architectures."asminject.py is vaguely like Frida, except that it doesn't attach via the ptrace interface, so processes can't block it by ptracing themselves."asminject.py was written for two primary scenarios in penetration testing within Linux environments:
For example, consider a penetration test in which the tester has obtained root access to a server that hosts many containers. One of the containers processes bank transfers, and has a very robust endpoint security product installed within it. When the pen tester tries to modify the bank transfer data from within the container, the endpoint security software detects and blocks the attempt. asminject.py allows the pen tester to inject arbitrary code directly into the banking software's process memory or even the endpoint security product from outside of the container. Like a victim of Descartes' "evil demon", the security software within the container is helpless, because it exists in an environment entirely under the control of the attacker.
The original dlinject.py was designed specifically to load Linux shared libraries into an existing process. asminject.py does everything the original did and much more. It executes arbitrary assembly code, and includes templates for a variety of attacks. It has also been redesigned to help avoid detection by security mechanisms that key off of potentially suspicious activity like library-loading events.
The practice directory of this repository includes basic looping code that outputs a timestamp and loop iteration to the console, so you can practice injecting various types of code in a controlled environment. These practice loops are referred to in the remaining examples.
The basic syntax for calling asminject.py is:
# python3 ./asminject.py <target_process_id> <payload> \
--arch [x86-64|x86|arm32] --relative-offsets-from-binaries --stop-method "slow" \
--var <payload_variable_1_name> <payload_variable_1_value> \
# ... \
--var <payload_variable_n_name> <payload_variable_n_value>
In most cases, any of the payloads used in the examples will run on any of the supported architectures.
Most Linux distributions include a kernel security module named Yama that controls access to use the ptrace capability against other processes. While asminject.py doesn't attach to the debugger interface, it still requires permission to use the ptrace capability. If you are receiving errors about this capability, check the content of /proc/sys/kernel/yama/ptrace_scope. If it's set to 2, then run the following command as root:
echo 1 > /proc/sys/kernel/yama/ptrace_scope
Values of 3 or higher cannot be unset without a reboot. However, if you are an authorized administrator of a Linux system where someone has accidentally set /proc/sys/kernel/yama/ptrace_scope to 3, or are conducting an authorized penetration test of an environment where that value has been set, see the ptrace_scope_kernel_module directory for a potential workaround that does not require a reboot.