reversing stories….

Oyster Loader/Backdoor – Analysis

November 16, 2025

Introduction

In this article, I will provide an in-depth analysis of the Oyster backdoor, also known as the Broomstick loader. This C++-based malware was first identified in 2023. It is primarily distributed via malvertising campaigns that deceive users into downloading trojanized installers for legitimate software, such as PuTTY, KeePass, WinSCP, Google Chrome, or Microsoft Teams. These counterfeit downloads frequently appear in SEO-poisoned search results or on lookalike domains.

The Oyster backdoor employs a shellcode-based reflective loader to inject the DLL directly into memory for execution, ensuring that the malicious DLL never touches the file system. This technique enables it to effectively evade antivirus software and other security tools.

Additionally, the malware incorporates anti-debugging measures to detect the presence of a debugger.

Attack Flow

The Oyster backdoor is distributed through fake  installers. In this scenario, when a victim downloads and runs a fake Microsoft Teams setup executable, the first-stage DLL is loaded directly into memory. This DLL establishes a connection to the attacker’s command-and-control (C2) server to retrieve the second-stage payload.

The second-stage payload is also a DLL, which subsequently loads the final third-stage DLL into memory. For persistence, the second-stage DLL creates a scheduled task that periodically executes the second-stage payload.

This final DLL establishes a persistent backdoor, enabling the attacker to perform reconnaissance on the victim’s machine. Once initial access is secured, the attacker can deploy additional malicious payloads for further exploitation, including ransomware.

In certain variants, the second-stage DLL drops an executable on disk. This executable is then launched, and the final third-stage DLL is injected into its memory.

Introduction: ShellCode Reflective DLL Injection

There are numerous methods for injecting a DLL into a process, but Reflective DLL Injection stands out as the most stealthy.

In this technique, the target process executes shellcode that contains a Reflective Loader—a custom, position-independent PE loader responsible for mapping the DLL directly into memory without touching the disk.

The Windows OS relies on its native loader to parse the Portable Executable (PE) structure and load EXE/DLL files into memory. Similarly, the reflective loader mimics this behavior using custom LoadLibrary-like functions and tailored section mapping—but entirely in-memory.

Key Advantages:

No disk artifacts: The DLL never persists on the file system, evading antivirus scans and forensic detection.

Non-dumpable without the loader: The DLL is written to memory in a non-standard way, making it impossible to extract and reload without the original reflective loader.

Execution Flow:

1. Shellcode is loaded into the target process (local or remote).

2. The shellcode invokes the reflective loader function.

3. The loader:

   – Calculates the current image base address.

   – Parses and loads kernel32.dll and ntdll.dll to resolve required exports.

   – Maps all sections and rebuilds the import table.

   – Processes relocations.

   – Calls the DLL entry point (`DllMain`).

For a deeper technical dive, refer to Steven Fewer’s original blog on reflective DLL injection.

Fake SetUp file – MSTeamsSetup.exe

The fake installer (masquerading as legitimate software) contains a sequence of functions that embed shellcode. The initial function allocates memory and writes the shellcode into this region.

Once the shellcode is fully staged in memory, the loader resolves essential Windows API functions—including LoadLibraryA, GetProcAddress, VirtualProtect, and InternetOpen—via dynamic resolution.

Execution then transfers control to the shellcode, which implements a Shellcode Reflective DLL Injection technique. This shellcode serves as a minimal reflective loader, using only a small set of Windows APIs to map the first-stage DLL directly into memory without writing it to disk.

After successful injection, the first-stage DLL establishes a connection to the attacker’s C2 server and downloads the second-stage DLL. This second-stage payload is subsequently loaded using rundll32.exe (via exported function execution) and establishes persistence by creating a scheduled task that periodically re-executes the payload.

IOC’s

C2: nickbush24.com:443, lucidamiproductions.com:443
Scheduled Task:
schtasks.exe /Create /SC MINUTE /MO 13 /TN "COPYING3" /TR "C:\Windows\System32\rundll32.exe" C:\Users\ttt\Downloads\oyster\Copying3.dll,DllRegisterServer
Other Commands:
cmd.exe /C ping 1.1.1.1 -n 1 -w 3000 > Nul & Del /f /q "%s"

Request Headers:
Content-Type: application/json
x-amz-cf-id:
Content-Encoding:
GET /login
User Agent: WordPressAgent,FingerPrint

Second Stage DLL – Copying3.DLL

The rundll32.exe utility is used to execute the second-stage DLL (e.g., via rundll32.exe Copying3.dll,EntryPoint). Upon loading, the DLL entry point (DllMain) is invoked, initiating a complex sequence of functions.

Memory Allocation via Native API

A critical function loads ntdll.dll and resolves NtAllocateVirtualMemory to allocate a memory buffer for the next-stage payload.

  • The base address of this region is stored in a global variable: cs:qword_180047010
  • This pointer is reused across functions to write shellcode chunks into the correct memory location.
Obfuscated Shellcode Staging

Each function within DllMain contains embedded shellcode fragments. As functions execute in a predetermined order, these fragments are progressively copied into a allocated memory region.

  • Sequence tracking: Unique variable names (semierectness24, urlar234, carbonator, peasouper4, ballastic4, acidophilous3 etc) are used to maintain execution order and verify correct shellcode reassembly.
  • This staged reconstruction ensures the reflective loader shellcode is fully built in memory before activation.

After multiple function calls, the allocated region now contains a complete reflective loader shellcode.

API Resolution Before Loader Activation

Before invoking the reflective loader, the second-stage DLL dynamically resolves the following Windows API functions:

  • RegCloseKey
  • GetProcAddress
  • LoadLibraryA
  • VirtualProtect
  • InternetOpenW

These are loaded into memory for use by both the current stage and the upcoming reflective loader.

Reflective Loader Execution

The reflective loader shellcode is then executed.

  • The third stage DLL is written to the same memory region where the current shellcode resides.
  • Bypasses standard Microsoft PE loading by manually parsing and mapping only necessary structures:
    • NT Headers
    • Section Headers
  • Maps sections to non-standard, randomized memory locations — deliberately avoiding the expected PE layout.
  • Omits the DOS header and loads only required sections.

Anti-analysis effect: This custom mapping makes memory dumping and static analysis of the third-stage DLL nearly impossible without the exact loader.

Post-Mapping API Reuse & Control Transfer

After section mapping:

  • The loader reuses previously resolved APIs:
    • LoadLibraryA
    • GetProcAddress
    • VirtualProtect
  • Performs relocations and fixes imports.
  • Executes a long jump to the third-stage DLL’s DllMain (entry point).

Upon completion, control returns to the second-stage DLL (Copying3.dll).

Persistence of Control: DLLRegisterServer Chain

The second-stage DLL then calls its own DLLRegisterServer export.

  • This function contains a hardcoded offset pointing to the third-stage DLL’s DLLRegisterServer.
  • Using this offset, it invokes the third-stage DLLRegisterServer.

At this point, full control resides in the third-stage DLL’s DLLRegisterServer function.

We will continue analyzing the malware’s behavior in-memory, focusing on the third-stage payload’s reconnaissance and persistence mechanisms.

Third Stage DLL

The third-stage DLL is loaded directly into memory under the filename rpp_dl.dll.

It immediately creates a mutex with the name: 7GhJ-2KlM-8NpQ-7RsT-9UvW-0XyZ-LmNo-PqKs to prevent multiple instances and signal successful execution.

Control then transfers to the C2 communication module.

Initial Check-in (GET Request)

The malware sends an HTTP GET request to the endpoint: /api/kcehc using the following User-Agent:

Mozilla/6.0 (Windows NT 10.0; Win64; x64) AppleWebKit/547.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36

This request is rotated across multiple attacker-controlled domains:

  • funkyfirmware.com
  • datadrivendreamers.com
  • daringdatadaredevils.com
  • cyberneticodyssey.com
  • 85.239.53.66
  • 51.222.96.108
  • 135.125.241.45
C2 Communication APIs

The malware leverages the following WinINet APIs for network operations:

  • HttpOpenRequestW
  • HttpSendRequestA
  • HttpQueryInfoW
  • InternetReadFile
Command Retrieval (POST Request)

It then sends a POST request to: /api/jgfnsfnuefcnegfnehjbfncejfh with JSON-formatted data to register the victim and receive commands.

At this point, the Oyster backdoor is fully operational, granting the attacker persistent remote access for further exploitation.

Conclusion

The Oyster backdoor (aka Broomstick loader) is a highly stealthy, fileless malware that consistently evades antivirus and EDR solutions through in-memory execution, reflective DLL injection, and impersonation of trusted tools.

Recommendations:

  • Establish and enforce baselines for development tools and installer behavior.
  • Restrict software downloads to verified, official sources only.
  • Conduct regular user awareness training on phishing, malvertising, and fake installers.

Vigilant policy enforcement and educated users remain the strongest defense against this threat.