Built to Blend: Miraak’s Modular Post Exploitation Framework 

Key Takeaways 

• Blackpoint’s Adversary Pursuit Group (APG) identified a novel post exploitation framework, dubbed Miraak, through proactive threat hunting that surfaced an adversary operational security failure. 

• Miraak is a modular post exploitation framework, not a single backdoor, with multiple agent packaging and execution methods built around a common operator architecture. 

• Its control plane is PostgreSQL/Timescale, allowing tasking, check-ins, results, BOF storage, and job state to move through database operations instead of conventional web beacon endpoints. 

• Malicious hostfxr.dll variants abuse trusted .NET naming and load paths, either decoding an embedded Miraak agent to %TEMP%\msedgeupdate.exe or launching a configured agent from miraak.conf. 

• The Miraak agent supports shell execution, process control, screenshots, file transfer, discovery, sleep control, and asynchronous jobs, giving operators a mature post exploitation toolkit without requiring a second framework. 

• Miraak implements Cobalt Strike Beacon Object File compatibility, which allows operators to execute existing BOFs while retaining Miraak’s own C2 and tasking infrastructure. 

• An associated F# tunneling implant was also identified during the investigation, with the TLS certificate presented by its infrastructure labeled miraak-socks. This naming provides additional linkage to the Miraak ecosystem and supports the tunnel’s role as an associated reverse TCP pivoting capability. 

• Real-world impact: Miraak can turn one compromised endpoint into broader access, putting business operations, sensitive data, and customer environments at risk. 

Executive Summary 

Blackpoint’s Adversary Pursuit Group (APG) identified Miraak, a previously undocumented post exploitation framework, through proactive threat hunting that uncovered an adversary operational security failure. Multiple Miraak components and related tools had been left exposed in attacker controlled open directories, giving researchers visibility into how the framework is deployed, controlled, and used after an environment has already been compromised. 

Analysis showed that Miraak is designed to provide operators with persistent control of compromised systems while supporting command execution, file transfer, process management, screenshot collection, and extensible post exploitation activity. A defining aspect of the framework is its use of cloud hosted PostgreSQL and Timescale infrastructure for command and control. Rather than communicating through traditional web-based C2 endpoints, Miraak uses database connections to register infected systems, retrieve operator tasking, track jobs, and return results. This design allows core command and control activity to blend into encrypted database traffic directed toward legitimate cloud-hosted services, potentially reducing the visibility defenders gain from controls focused primarily on conventional HTTP-based malware communications. 

Further hunting also uncovered an associated tunneling capability that can extend access from a compromised endpoint into additional systems and services within a victim environment. The combination of flexible deployment, database-backed command and control, extensible post exploitation functionality, and network pivoting indicates that Miraak was built as a broader operator platform rather than a single purpose backdoor.  

Technical Analysis 

Hunting the Open Web: How Miraak Was Identified 

The APG identified Miraak through proactive threat hunting of publicly exposed web directories across the internet. The attacker’s infrastructure had multiple open directory listings that exposed binaries and supporting files on ports 18081, 18082, and 18083. These directories contained combinations of dotnet.exe, hostfxr.dll, git.exe, and supporting runtime components, providing the initial material that led to deeper analysis.  

Image 1: Open web directory exposing a Miraak deployment pair consisting of dotnet.exe and a collocated hostfxr.dll 

Image 2: Open web directory exposing multiple Miraak associated components including dotnet.exe, hostfxr.dll, git.exe, and supporting runtime files.  

Additional investigation uncovered a separate exposed directory containing docfx.exe, Microsoft.DocAsCode.Common.dll, and doccache.dll.  

Image 3: Open Web Directory exposing the DocFX-based tunneling components, including docfx.exe, Microsoft.DocAsCode.Common.dll, and doccache.dll 

Reverse engineering of the recovered files ultimately revealed the Miraak framework. The agent contained explicit internal identifiers including Miraak agent, miraak-test-agent, miraak_resolve_dnsquery, MIRAAK_AGENT_ID_ENC, and g_miraak_pe. Analysis also showed that multiple hostfxr.dll variants converged on the same Miraak agent architecture, while the exposed git.exe build implemented the same PostgreSQL-backed tasking, BOF execution, and job management functionality. 

Continued analysis of the exposed tooling also identified an associated F# tunneling capability. The implant and its DocFX-based execution components were recovered from one of the open directories, while the supporting infrastructure presented a TLS certificate labeled miraak-socks. The shared infrastructure, exposed tooling, and certificate naming provide additional operational linkage between the tunneling capability and the broader Miraak ecosystem. 

Miraak’s discovery reflects the value of looking beyond known malware signatures and confirmed intrusions. The APG uncovered the framework by hunting exposed infrastructure across the open internet, where an adversary OPSEC failure left portions of the framework, its loaders, and supporting tooling publicly accessible. 

Trust as an Execution Primitive 

The analyzed Miraak components consistently hide malicious functionality behind filenames and runtime components that would normally appear legitimate. dotnet.exe was consistent with a genuine Microsoft .NET host, while several malicious DLLs adopted the expected hostfxr.dll name used during normal .NET startup. The DLLs also preserved familiar hostfxr_* exports, including hostfxr_main, hostfxr_main_startupinfo, and hostfxr_set_error_writer, helping the files maintain the appearance of legitimate runtime components. 

Image 4: Malicious hostfxr.dll preserving expected .NET hosting exports to maintain the appearance of a legitimate runtime component 

A closer look at the same binaries exposed their actual purpose. Internal symbols such as MIRAAK_AGENT_ID_ENC, MIRAAK_AGENT_IDLE_MS_ENC, and MIRAAK_DATABASE_URL_ENC revealed Miraak-specific configuration embedded directly within the malicious hostfxr.dll builds. This approach gives operators a less conspicuous path to execution by placing malicious logic behind software names and dependency relationships that defenders may already trust 

Image 5: Miraak specific configuration symbols embedded within the malicious hostfrxr.dll tied to agent identity, sleep interval, and database C2 configuration 

 

Wrapped in the Runtime 

The two larger hostfxr.dll samples function as embedded payload launchers, combining a legitimate looking .NET runtime interface with Miraak specific configuration and staging logic. Reverse engineering identified a routine named miraak_decode that walks an input buffer byte by byte and XORs each value with 0x42 (Figure X). Cross references to that routine show it being used to decode MIRAAK_AGENT_ID_ENC, MIRAAK_DATABASE_URL_ENC, and MIRAAK_AGENT_IDLE_MS_ENC, confirming that key runtime configuration is stored in an encoded form and recovered immediately before use. 

Image 6: Decompilation of miraak_decode showing Miraak’s byte-wise XOR 0x42 routine used to recover encoded runtime configuration 

Decoding the embedded database configuration further exposed Miraak’s command and control design. Applying the recovered XOR key revealed a PostgreSQL connection string pointing to a cloud hosted Tiger Data/Timescale endpoint over TCP/39014 with SSL explicitly required. Credentials have been redacted, but the recovered configuration confirms that the loader carries the information necessary for the Miraak agent to connect directly to its database backed control plane. 

Image 7: Decoded Miraak Database Configuration revealing a PostgreSQL connection to a cloud hosted Tiger Data infrastructure 

The loader also contains an embedded Miraak PE that is protected separately using XOR 0x5A. Once decoded, the payload is written to %TEMP%\msedgeupdate.exe, launched with CreateProcessA, and deleted shortly afterward.  

Image 9: Recovering the Miraak PE with XOR 0x5A 

Both larger loader samples ultimately decode the same Miraak executable, indicating that they are alternate deployment wrappers around a common agent build rather than separate payload families. Their primary differences lie in configuration, including the database infrastructure supplied to the agent at runtime. 

The temporary staging sequence further limits how long the unpacked agent remains present as a standalone executable. The loader writes the decoded PE using the Microsoft Edge themed filename msedgeupdate.exe, starts it, waits briefly, and removes the staged copy.  

A smaller hostfxr.dll variant takes a more configurable approach. Instead of carrying the complete Miraak agent internally, it reads miraak.conf, resolves AGENT_EXE or AGENT_PATH, converts additional configuration entries into environment variables, and launches the selected agent executable. Its hostfxr_* exports provide only minimal compatibility with the expected runtime interface, while the actual launcher behavior begins during DLL initialization. 

Image 10: Miraak load_config() parsing miraak.conf and resolving AGENT_EXE and AGENT_PATH within the smaller hostfxr.dll 

 

The Database Is the Beacon 

The most distinctive element of Miraak is its database-backed C2 model. The agent imports libpq routines such as PQconnectdb, PQexec, PQexecParams, PQresultStatus, PQgetvalue, PQunescapeBytea, and PQfinish, then uses PostgreSQL tables as the operational queue between agent and controller. 

Image 11: Miraak importing PostgreSQL libq routines used to communicate directly with its databasebacked C2 infrastructure 

This structure turns database state into the command protocol. The agent identifies itself with an agent ID, hostname, username, operating system, architecture, and metadata, then polls a task table for the next unclaimed command.  

Image 12: db_checkin() showing how Miraak using PostgreSQL records for agent registration and task result submission 

Once a task is selected, Miraak marks it as claimed so competing sessions do not consume the same work. Results are inserted into a separate table, while long running activity is tracked in a jobs table. 

Image 12: db_poll_task() querying the task table for an unclaimed command and marking the selected task as calaimed 

From a defender’s perspective, this design moves the problem away from recognizable URI paths and beacon JSON. The network session can look like encrypted PostgreSQL traffic to a cloud database provider. That makes egress policy, process-to-destination correlation, DNS visibility, and anomaly detection more important than signatures built around conventional C2 web patterns. 

The analyzed configurations used telemetry like table names such as metrics_ingest, events_log, and sessions. Naming the control plane after ordinary application data does not change the behavior, but it can make backend artifacts less obvious during a cursory review of cloud resources or database audit logs. 

Operator Capability Without a Second Framework 

The Miraak agent exposes a broad native tasking set that gives an operator substantial post exploitation capability without immediately relying on a second stage framework. Recovered function names, task strings, and API usage show support for shell execution, host and user discovery, process enumeration and termination, working directory management, screenshot capture, file transfer, configurable sleep behavior, agent termination, BOF execution, and asynchronous job control. 

Task	Capability
shell	Executes commands via cmd.exe /c <command>
whoami	Retrieves the user and host context
pwd	Returns the current working directory
kill	Terminates a specified PID or matching process
screenshot	Captures the desktop using native Windows GDI APIs
download	Reads a local file and returns it Base64 encoded
upload	Base64-decodes the supplied data and writes it to disk
sleep	Changes the agent polling interval
bof	Retrieves and execute a Beacon Object File (BOF)
jobs	Manages asynchronous agent tasks

This command set is significant because Miraak does not need to immediately hand execution off to another post exploitation platform to perform routine operator actions. Discovery, command execution, file movement, process control, screenshots, and BOF execution are already built into the agent. 

The asynchronous job model further differentiates Miraak from a minimal polling beacon. Longer running operations can be registered, tracked, completed, and terminated independently of the main task loop, allowing the agent to continue polling while background work executes. Combined with its BOF loader and database backed task queue, this makes Miraak better characterized as a modular operator framework than a simple command and control implant. 

Borrowing the BOF Ecosystem 

Miraak implements a compatibility layer for Cobalt Strike Beacon Object Files (BOFs) by exposing many of the APIs BOFs expect at runtime. These include BeaconData*, BeaconFormat*, BeaconPrintf, BeaconOutput, BeaconUseToken, BeaconRevertToken, and BeaconIsAdmin. Their presence does not indicate that Miraak is a Cobalt Strike Beacon; instead, the framework recreates enough of the Beacon API surface to load and execute existing BOF modules within the Miraak agent itself. 

Image 13: Miraak’s bof_run() routine invoking its internal coff_run() loader to execute BOF/COFF modules within the agent 

This is operationally important because BOFs give operators access to a large ecosystem of compact, task specific post exploitation modules without requiring them to deploy Cobalt Strike as a separate payload. Miraak can reuse those modules while retaining its own PostgreSQL-backed tasking, job tracking, and execution model.  

A Second Path: Pivoting Through DocFX 

A separate component in the analyzed set provides an F#-based reverse TCP tunneling capability that is launched through a trojanized Microsoft.DocAsCode.Common.dll. Rather than relying on classic native DLL sideloading, the modified managed assembly introduces a direct dependency on doccache.dll and invokes doccache.CacheService.Initialize() from its module initializer. After initialization, the thread is placed into Thread.Sleep(-1), keeping the implant resident for the lifetime of the hosting process. 

Image 14: Trojanized Microsoft.DocAsCode.Common.dll invoking the CacheService.Initialize function from its module initializer and then sleeping indefinitely to keep the tunneling implant resident 

This behavior is better characterized as trojanized managed dependency loading than traditional native DLL sideloading. The CLR loads an expected DocFX dependency, but the dependency itself has been modified to reference and invoke the malicious doccache.dll. Because execution occurs directly through the managed dependency chain, the operator does not need PowerShell, rundll32, regsvr32, or a separate reflective assembly loader to start the implant. 

Image 15: F# tunnel initialization decoding C2 configuration and identifying the hoast as win-<MachineName> before entering the connection loop 

Once active, the F# component hides its console, creates a persistent non-background worker thread, decodes its embedded configuration, and identifies the victim using a host identifier in the form win-<MachineName>. It then connects to 45[.]61[.]182[.]62:9443, initially attempting TLS while accepting any presented certificate. If the TLS negotiation fails, the implant can fall back to a raw TCP session. After authentication, it processes tunneling instructions that allow the remote operator to establish arbitrary outbound TCP connections through the compromised host. 

Image 16: F# implant startup data containing XOR-obfuscated C2 and authentication configuration. The 12 byte field1 value decodes to the C2 IP address of 45.61.182[.]62 

The operational value of this component is network reach. Miraak provides direct post exploitation control of the endpoint, while the associated tunneling implant can convert that same system into a pivot point for otherwise inaccessible internal services. The available evidence supports a close operational association with Miraak, but it is more accurate to describe the tunnel as an associated component rather than a native Miraak module. 

Following the SOCKS Trail 

The discovery of the F# tunneling implant created another infrastructure pivot for the APG. Analysis of the service supporting the tunnel revealed a TLS certificate labeled miraak-socks, providing a distinctive identifier that could be used to trace infrastructure associated with the reverse proxy capability. Rather than treating the tunnel as an isolated artifact, APG used the certificate as a hunting lead to identify the VPS supporting that portion of the operator infrastructure. 

Image 17: Self-Signed TLS certificate on the reverse proxy infrastructure using the operator selected miraak-socks identifer 

The miraak-socks certificate provides a clear operational link between the reverse proxy infrastructure and the broader Miraak ecosystem. The certificate is self-signed, with both the subject and issuer set to CN=miraak-socks, reflecting terminology embedded directly into the service configuration rather than a label introduced during analysis. 

Notably, the certificate bearing service was exposed over TCP/8443, while the analyzed F# tunneling implant was configured to connect to its controller over TCP/9443. This distinction shows that the infrastructure supported multiple network facing services rather than a single tunnel listener, with the miraak-socks identity exposed on a separate TLS enabled port. 

The reverse proxy capability complements Miraak’s endpoint control functionality by giving operators a way to route traffic through compromised systems and reach additional internal services. The miraak-socks certificate also provided a valuable infrastructure pivot beyond the individual VPS. Because the TLS service used a distinctive, self-signed certificate identity, APG was able to search for matching certificate metadata and identify the following additional infrastructure associated with the broader exploitation framework: 

• 144.172.98[.]250 

• 167.88.164[.]117 

• 45.61.182[.]62 

A Look Behind the Operator Panel 

Further investigation of the Miraak command and control infrastructure exposed another operational security weakness. An authentication-gating and user interface design flaw in the C2 authentication flow allowed portions of the operator facing interface to be rendered before access controls were fully enforced. Although the panel remained authentication protected, elements of the interface could still be observed without obtaining authenticated access. 

The exposure provided APG with a limited view into how Miraak appears from the operator side. Even a partial view of a C2 interface can be valuable during threat research because it helps validate conclusions drawn from binary analysis and provides context around how the framework’s capabilities are organized for the person controlling it. In this case, the exposed interface offered a glimpse into the operational layer sitting behind the agents, database backed tasking, and supporting infrastructure identified during the broader hunt. 

Image 18: Partial view of the Miraak C2 panel exposed through an authentication-gating and user-interface design flaw. 

Importantly, the finding did not require bypassing authentication or interacting with the panel as an authorized operator. The weakness was rooted in how the application handled unauthenticated presentation of the interface, allowing a portion of the UI to become visible before the authentication boundary fully restricted access. 

The panel exposure adds another dimension to the broader Miraak picture. Open directories exposed the framework’s binaries and deployment components, the miraak-socks certificate provided a path into its reverse proxy infrastructure, and the C2 interface revealed part of the operator facing control layer. These findings point to a framework with capable post exploitation functionality but uneven operational and development discipline. Publicly exposed tooling, reusable infrastructure artifacts, and an authentication gating flaw in the panel are all consistent with the kind of rapid, convenience first development increasingly associated with vibe coding. While the available evidence does not prove how Miraak was developed, the contrast between its technical capability and its implementation weaknesses becomes an important part of the framework’s broader story. 

Conclusion 

The central lesson from Miraak is that technical capability does not always arrive with operational maturity. APG’s research uncovered a capable post exploitation framework through a series of adversary OPSEC failures, beginning with publicly exposed web directories that revealed Miraak’s loaders, agents, and supporting components. Analysis showed a framework built around multiple deployment paths, PostgreSQL/Timescale-backed command and control, BOF extensibility, and associated reverse proxy tooling capable of extending access deeper into victim networks. Additional infrastructure pivots, including the self-signed miraak-socks certificate and limited exposure of the operator facing C2 panel, provided further visibility into how the ecosystem was assembled and operated. 

That contrast is what makes Miraak particularly notable. Its underlying design demonstrates deliberate engineering choices intended to blend execution into trusted software paths and move command and control activity into encrypted cloud hosted database traffic, yet several surrounding implementation decisions exposed substantial weaknesses. Open directories, reusable certificate identifiers, and an authentication-gating flaw in the C2 interface suggest a convenience first development approach that is increasingly associated with vibe coding, where functional capability can outpace secure implementation and operational discipline. The available evidence does not establish how Miraak was developed, but it illustrates an emerging reality for defenders: rapidly assembled offensive tooling can still deliver meaningful post exploitation capability, while the shortcuts taken during development and deployment may create equally valuable opportunities to uncover the infrastructure behind it. 

Recommendations 

• Restrict unnecessary outbound database access: Limit direct PostgreSQL connections from user endpoints and general purpose servers to approved destinations to reduce exposure to database-backed command and control channels. 

• Strengthen application and dependency controls: Use application control, trusted software inventories, and integrity monitoring to reduce opportunities for malicious components to execute behind legitimate filenames or runtime dependencies. 

•  Baseline unusual outbound communications: Establish expected network behavior for developer, administrative, and documentation tools, and flag unexpected connections to uncommon external ports or infrastructure. 

•  Continuously hunt for emerging infrastructure and tooling: Supplement signature-based detection with proactive threat hunting focused on newly exposed infrastructure, unusual certificates, open directories, and other adversary OPSEC weaknesses that can reveal threats before widespread deployment. 

Indicators of Compromise 

File Indicators 

Indicator	FileName	SHA-256
Embedded-payload Miraak loader	hostfxr.dll	395f7c49df28c1c82398ba4d972687d0de327fc3537d02d691f54b069c8d5594
Embedded-payload Miraak loader, alternate backend	hostfxr.dll	1a7243e70c6477f355cf35603d49d1d4869044219ac9e5114cb884bcd2ec2586
Configurable Miraak launcher	hostfxr.dll	4368eb07ca605ad1920a8e49f23a0f9021dad65355372a939850093183666673
Standalone Miraak agent	git.exe	1880dabecc965d4adac397b286ee73b0c61999be2c69843a60efd7ecf8b896e1
Legitimate .NET host observed in chain	dotnet.exe	11058e8c2cd05f30dcf1775644bf19d2913c9a6d674c12f91d1896d95d9cc5c2
Decoded Miraak agent payload	msedgeupdate.exe / Miraak PE	c81dfcc3b54e0af491d28610d413e3fe587aa5f8b776ad9a9038d293f575b437

Network Indicators 

Type	Indicator
PostgreSQL/Timescale C2	s4f5g9agty[.]xtwipkvcwv[.]db[.]az[.]tigerdata[.]com:39014
PostgreSQL/Timescale C2	a1uas8t3d1[.]srpzp1bwt9[.]tsdb[.]cloud[.]timescale[.]com:38155
F# tunneling C2	45[.]61[.]182[.]62:9443
Miraak-socks VPS	167.88.164[.]117
Miraak-socks VPS	144.172.98[.]250
Miraak C2 + C2 Panel	144.172.96[.]13