Login
A make an LKM rootkit visible again.
It involves getting the memory address of a rootkit's "show_module" function, for example, and using that to call it, adding it back to lsmod, making it possible to remove an LKM rootkit.
We can obtain the function address in very simple kernels using /sys/kernel/tracing/available_filter_functions_addrs, however, it is only available from kernel 6.5x onwards.
An alternative to this is to scan the kernel memory, and later add it to lsmod again, so it can be removed.
So in summary, this LKM abuses the function of lkm rootkits that have the functionality to become visible again.
OBS: There is another trick of removing/defusing a LKM rootkit, but it will be in the research that will be launched.
ModTracer Finds Hidden Linux Kernel Rootkits and then make visible again.
Another way to make an LKM visible is using the imperius trick: https://github.com/MatheuZSecurity/Imperius
PoCs for Kernelmode rootkit techniques research or education. Currently focusing on Windows OS. All modules support 64bit OS only.
NOTE
Some modules use
ExAllocatePool2API to allocate kernel pool memory.ExAllocatePool2API is not supported in OSes older than Windows 10 Version 2004. If you want to test the modules in old OSes, replaceExAllocatePool2API withExAllocatePoolWithTagAPI.
All modules are tested in Windows 11 x64. To test drivers, following options can be used for the testing machine:
debugging-in-windbg--cdb--or-ntsd">Setting Up Kernel-Mode Debugging
Each options require to disable secure boot.
Detailed information is given in README.md in each project's directories. All modules are tested in Windows 11.
| Module Name | Description |
|---|---|
| BlockImageLoad | PoCs to block driver loading with Load Image Notify Callback method. |
| BlockNewProc | PoCs to block new process with Process Notify Callback method. |
| CreateToken | PoCs to get full privileged SYSTEM token with ZwCreateToken() API. |
| DropProcAccess | PoCs to drop process handle access with Object Notify Callback. |
| GetFullPrivs | PoCs to get full privileges with DKOM method. |
| GetProcHandle | PoCs to get full access process handle from kernelmode. |
| InjectLibrary | PoCs to perform DLL injection with Kernel APC Injection method. |
| ModHide | PoCs to hide loaded kernel drivers with DKOM method. |
| ProcHide | PoCs to hide process with DKOM method. |
| ProcProtect | PoCs to manipulate Protected Process. |
| QueryModule | PoCs to perform retrieving kernel driver loaded address information. |
| StealToken | PoCs to perform token stealing from kernelmode. |
More PoCs especially about following things will be added later:
Pavel Yosifovich, Windows Kernel Programming, 2nd Edition (Independently published, 2023)
Reversing-<a href=" https:="" title="Obfuscation">Obfuscation/dp/1502489309">Bruce Dang, Alexandre Gazet, Elias Bachaalany, and Sébastien Josse, Practical Reverse Engineering: x86, x64, ARM, Windows Kernel, Reversing Tools, and Obfuscation (Wiley Publishing, 2014)
Evasion-Corners/dp/144962636X">Bill Blunden, The Rootkit Arsenal: Escape and Evasion in the Dark Corners of the System, 2nd Edition (Jones & Bartlett Learning, 2012)
Demonized Shell is an Advanced Tool for persistence in linux.
FreshRSS 
git clone https://github.com/MatheuZSecurity/D3m0n1z3dShell.git
cd D3m0n1z3dShell
chmod +x demonizedshell.sh
sudo ./demonizedshell.sh
Download D3m0n1z3dShell with all files:
curl -L https://github.com/MatheuZSecurity/D3m0n1z3dShell/archive/main.tar.gz | tar xz && cd D3m0n1z3dShell-main && sudo ./demonizedshell.sh
Load D3m0n1z3dShell statically (without the static-binaries directory):
sudo curl -s https://raw.githubusercontent.com/MatheuZSecurity/D3m0n1z3dShell/main/static/demonizedshell_static.sh -o /tmp/demonizedshell_static.sh && sudo bash /tmp/demonizedshell_static.sh
And other types of features that will come in the future.
If you want to contribute and help with the tool, please contact me on twitter: @MatheuzSecurity
We are not responsible for any damage caused by this tool, use the tool intelligently and for educational purposes only.
VED (Vault Exploit Defense)-eBPF leverages eBPF (extended Berkeley Packet Filter) to implement runtime kernel security monitoring and exploit detection for Linux systems.
eBPF is an in-kernel virtual machine that allows code execution in the kernel without modifying the kernel source itself. eBPF programs can be attached to tracepoints, kprobes, and other kernel events to efficiently analyze execution and collect data.
VED-eBPF uses eBPF to trace security-sensitive kernel behaviors and detect anomalies that could indicate an exploit or rootkit. It provides two main detections:
wCFI (Control Flow Integrity) traces the kernel call stack to detect control flow hijacking attacks. It works by generating a bitmap of valid call sites and validating each return address matches a known callsite.
PSD (Privilege Escalation Detection) traces changes to credential structures in the kernel to detect unauthorized privilege escalations.
VED-eBPF attaches eBPF programs to kernel functions to trace execution flows and extract security events. The eBPF programs submit these events via perf buffers to userspace for analysis.
wCFI traces the call stack by attaching to functions specified on the command line. On each call, it dumps the stack, assigns a stack ID, and validates the return addresses against a precomputed bitmap of valid call sites generated from objdump and /proc/kallsyms.
If an invalid return address is detected, indicating a corrupted stack, it generates a wcfi_stack_event containing:
* Stack trace
* Stack ID
* Invalid return address
This security event is submitted via perf buffers to userspace.
The wCFI eBPF program also tracks changes to the stack pointer and kernel text region to keep validation up-to-date.
PSD traces credential structure modifications by attaching to functions like commit_creds and prepare_kernel_cred. On each call, it extracts information like:
* Current process credentials
* Hashes of credentials and user namespace
* Call stack
It compares credentials before and after the call to detect unauthorized changes. If an illegal privilege escalation is detected, it generates a psd_event containing the credential fields and submits it via perf buffers.
VED-eBPF requires:
VED-eBPF is currently a proof-of-concept demonstrating the potential for eBPF-based kernel exploit and rootkit detection. Ongoing work includes:
VED-eBPF shows the promise of eBPF for building efficient, low-overhead kernel security monitoring without kernel modification. By leveraging eBPF tracing and perf buffers, critical security events can be extracted in real-time and analyzed to identify emerging kernel threats for cloud native envionrment.
A Linux persistence tool!
A powerful and versatile Linux persistence script designed for various security assessment and testing scenarios. This script provides a collection of features that demonstrate different methods of achieving persistence on a Linux system.
SSH Key Generation: Automatically generates SSH keys for covert access.
Cronjob Persistence: Sets up cronjobs for scheduled persistence.
Custom User with Root: Creates a custom user with root privileges.
RCE Persistence: Achieves persistence through remote code execution.
LKM/Rootkit: Demonstrates Linux Kernel Module (LKM) based rootkit persistence.
Bashrc Persistence: Modifies user-specific shell initialization files for persistence.
Systemd Service for Root: Sets up a systemd service for achieving root persistence.
LD_PRELOAD Privilege Escalation Config: Configures LD_PRELOAD for privilege escalation.
Backdooring Message of the Day / Header: Backdoors system message display for covert access.
Modify an Existing Systemd Service: Manipulates an existing systemd service for persistence.
Clone this repository to your local machine:
git clone https://github.com/Trevohack/DynastyPersist.git
One linear
curl -sSL https://raw.githubusercontent.com/Trevohack/DynastyPersist/main/src/dynasty.sh | bash
For support, email spaceshuttle.io.all@gmail.com or join our Discord server.
https://discord.gg/WYzu65Hp
Thank You!
Hidden has been developed like a solution for reverse engineering and researching tasks. This is a windows driver with a usermode interface which is used for hiding specific environment on your windows machine, like installed RCE programs (ex. procmon, wireshark), vm infrastructure (ex. vmware tools) and etc.
and so on
Windows Vista and above, x86 and x64
Following guide explains how to make a release win32 build
Important: Keep in mind that the driver bitness have to be the same to an OS bitness
A command line tool hiddencli is used for managing a driver. You are able to use it for hiding and unhiding objects, changing a driver state and so on.
To hide a file try the command
hiddencli /hide file c:\Windows\System32\calc.exe
Want to hide a directory? No problems
hiddencli /hide dir "c:\Program Files\VMWare"
Registry key?
hiddencli /hide regkey "HKCU\Software\VMware, Inc."
Maybe a process?
hiddencli /hide pid 2340
By a process image name?
hiddencli /hide image apply:forall c:\Windows\Explorer.EXE
To get a full help just type
hiddencli /help
Nidhogg is a multi-functional rootkit for red teams. The goal of Nidhogg is to provide an all-in-one and easy-to-use rootkit with multiple helpful functionalities for red team engagements that can be integrated with your C2 framework via a single header file with simple usage, you can see an example here.
Nidhogg can work on any version of x64 Windows 10 and Windows 11.
This repository contains a kernel driver with a C++ header to communicate with it.
Since version v0.3, Nidhogg can be reflectively loaded with kdmapper but because PatchGuard will be automatically triggered if the driver registers callbacks, Nidhogg will not register any callback. Meaning, that if you are loading the driver reflectively these features will be disabled by default:
These are the features known to me that will trigger PatchGuard, you can still use them at your own risk.
It has a very simple usage, just include the header and get started!
#include "Nidhogg.hpp"
int main() {
HANDLE hNidhogg = CreateFile(DRIVER_NAME, GENERIC_WRITE | GENERIC_READ, 0, nullptr, OPEN_EXISTING, 0, nullptr);
// ...
DWORD result = Nidhogg::ProcessUtils::NidhoggProcessProtect(pids);
// ...
}To compile the client, you will need to install CMake and Visual Studio 2022 installed and then just run:
cd <NIDHOGG PROJECT DIRECTORY>\Example
mkdir build
cd build
cmake ..
cmake --build .To compile the project, you will need the following tools:
Clone the repository and build the driver.
To test it in your testing environment run those commands with elevated cmd:
bcdedit /set testsigning onAfter rebooting, create a service and run the driver:
sc create nidhogg type= kernel binPath= C:\Path\To\Driver\Nidhogg.sys
sc start nidhoggTo debug the driver in your testing environment run this command with elevated cmd and reboot your computer:
bcdedit /debug onAfter the reboot, you can see the debugging messages in tools such as DebugView.
Thanks a lot to those people that contributed to this project:
bootlicker is a legacy, extensible UEFI firmware rootkit targeting vmware hypervisor virtual machines. It is designed to achieve initial code execution within the context of the windows kernel, regardless of security settings configured.
bootlicker takes its design from the legacy CosmicStrain, MoonBounce, and ESPECTRE rootkits to achive arbitrary code excution without triggering patchguard or other related security mechanisms.
After initial insertion into a UEFI driver firmware using the the injection utility, the shellcodes EfiMain achieves execution as the host starts up, and inserts a hook into the UEFI firmware's ExitBootServices routine. The ExitBootServices routine will then, on execution, find the source caller of the function, and if it matches WinLoad.EFI, attempts to find the unexported winload.efi!OslArchTransferToKernel routine, which will allow us to att ack the booting kernel before it achieves its initial execution.
Once OslArchTransferToKernel executes, it will search for the ACPI.SYS driver, find the .rsrc PE section, and inject a small stager shellcode entrypoint called DrvMain to copy over a larger payload that will act as our kernel implant.
Entirely based upon d_olex / cr4sh's DmaBackdoorBoot
This code is apart of a larger project I've been working on that on / off in between burnout, like most of the concepts I've produced over the years under various aliases, will never see the light of day. Some of the code comments I've been to lazy to strip out that refer to unrelated functiaonlity, despite it being previously present. Do not expect this to work out of the box, some slight modifications are certainly necessary.
