Built to Blend: Miraak's Modular Post-Exploitation Framework

What it is

Miraak, a modular post-exploitation framework documented by Blackpoint's APG. The summary covers the framework's shape; what it omits are the concrete network artifacts, ports, and detection surfaces an engineer needs to hunt for it.

Preconditions / detection surfaces the summary omits

Open-directory footprint. The exposed attacker infrastructure served binaries over ports 18081, 18082, and 18083 (dotnet.exe, hostfxr.dll, git.exe, runtime files). A separate directory held the DocFX tunnel components (docfx.exe, Microsoft.DocAsCode.Common.dll, doccache.dll).

Database C2 endpoint. The decoded PostgreSQL connection string points to a cloud-hosted Tiger Data/Timescale endpoint over TCP/39014 with SSL required. The agent uses libpq (PQconnectdb, PQexec, PQexecParams, PQunescapeBytea, etc.) and disguises its control-plane tables with ordinary-looking names: metrics_ingest, events_log, sessions, plus a task table and a jobs table. This is the key detection pivot — egress to an uncommon database port toward a cloud DB provider, from a host that shouldn't be making direct PostgreSQL connections.

F# tunnel C2. The reverse-TCP implant connects to 45.61.182[.]62:9443, attempts TLS accepting any certificate, and falls back to raw TCP if negotiation fails. It identifies the host as win-<MachineName>. Execution runs through the managed dependency chain (module initializer → doccache.CacheService.Initialize() → Thread.Sleep(-1)), so no PowerShell, rundll32, regsvr32, or reflective loader is involved.

Infrastructure pivot. The self-signed miraak-socks cert (subject and issuer both CN=miraak-socks) was exposed on TCP/8443 — distinct from the 9443 tunnel listener. Certificate-metadata hunting surfaced three IPs:

• 144.172.98[.]250
• 167.88.164[.]117
• 45.61.182[.]62

Loader staging string. The larger loaders decode the embedded PE to %TEMP%\msedgeupdate.exe, launch via CreateProcessA, then delete it. The smaller variant reads miraak.conf and resolves AGENT_EXE / AGENT_PATH instead.

Binary strings for detection. Internal identifiers: Miraak agent, miraak-test-agent, miraak_resolve_dnsquery, MIRAAK_AGENT_ID_ENC, MIRAAK_DATABASE_URL_ENC, MIRAAK_AGENT_IDLE_MS_ENC, g_miraak_pe. Malicious hostfxr.dll builds preserve the real exports (hostfxr_main, hostfxr_main_startupinfo, hostfxr_set_error_writer) to pass as legitimate.

What to do

Blackpoint's stated mitigations, in priority order for this framework:

• Restrict outbound PostgreSQL from endpoints and general-purpose servers to approved destinations — this is what breaks the DB-as-C2 model, since signature/URI-based web-C2 detection sees nothing.
• Baseline outbound behavior for developer/documentation tooling (docfx.exe, dotnet.exe) and flag connections to uncommon external ports (39014, 9443, 8443).
• Apply application control and integrity monitoring so trojanized DLLs can't ride legitimate filenames and .NET dependency load paths.

Caveats

The IOC tables (File Indicators, Network Indicators) referenced on the page did not render in the fetched text — only the inline IPs and ports above are captured here; consult the source for hashes. The tunnel is described as an associated component, not a native Miraak module; linkage rests on shared infrastructure and the miraak-socks certificate naming. APG explicitly notes it did not bypass authentication to view the C2 panel.