Detecting Dohdoor Backdoor DLL sideloading on Windows systems

DLL sideloading remains one of the most reliable ways for attackers to hide in plain sight on Windows: they run a trusted, signed Microsoft (or vendor) binary and trick it into loading a malicious DLL from a location the attacker controls. In campaigns associated with the Dohdoor backdoor, defenders should pay special attention to suspicious DLL loads by trusted binaries such as mblctr.exe and ScreenClippingHost.exe, plus stealth tactics like hash-based API resolution and anti-forensic cleanup (for example, clearing Run history and wiping clipboard content).

This article breaks down practical detection ideas you can deploy today in Microsoft Sentinel (and beyond), and includes starter ClamAV and Snort signatures you can adapt to your environment.

What makes Dohdoor-style activity stand out

Dohdoor-like intrusion patterns are often not one “smoking gun,” but a cluster of behaviours that become high-confidence when correlated:

• Trusted process execution followed by unusual DLL load paths (classic sideloading)
• API resolution without clear imports (hash-based or obfuscated lookup patterns)
• Anti-forensic actions that reduce analyst visibility (Run dialogue history clearing, clipboard wiping)
• DoH (DNS over HTTPS) queries to attacker infrastructure over TCP/443, blending into normal HTTPS traffic

Your best results come from combining endpoint telemetry (process + module loads), Windows artifacts (registry + clipboard-related events), and network signals (DoH endpoints, SNI, JA3/JA4, proxy logs).

Detection strategy 1: catch suspicious DLL loads by trusted binaries

Why mblctr.exe and ScreenClippingHost.exe matter

Attackers commonly pick binaries that are:

1. Present by default on many machines
2. Signed and trusted
3. Likely to be allowed by application control policies
4. Able to load DLLs from their working directory or a nearby path

ScreenClippingHost.exe is especially attractive because it can exist on many systems and doesn’t always raise eyebrows during casual triage.

What to monitor

At a minimum, alert on module loads where:

• The loading process is a trusted binary (for example, ScreenClippingHost.exe, mblctr.exe)
• The loaded DLL is in a suspicious directory such as:
  • User-writable locations: Downloads, Desktop, AppData\Local, AppData\Roaming, Temp
  • Unexpected application folders: newly created directories, oddly named vendor folders
  • The same folder as a recently dropped executable or archive extraction path
• The DLL name mimics legitimate modules (typosquatting) or matches known lure naming patterns in your environment

Fast triage checklist (what your analyst should answer)

1. Is the DLL signed? If yes, by whom, and does it match the expected vendor?
2. Was the DLL created shortly before the process started?
3. Does the host show evidence of archive extraction or email attachment execution near the same time?
4. Are there follow-on behaviours: new persistence, unusual outbound 443 connections, anti-forensic actions?

Many sideloading cases become obvious when you align three timestamps: DLL file creation time, process start time, and first outbound connection time.

Detection strategy 2: identify hash-based API resolution and suspicious memory behaviour

What “hash-based API resolution” looks like in practice

Malware that wants to frustrate static analysis often avoids importing Windows APIs in the usual way. Instead, it:

• Loads modules (like kernel32.dll, ntdll.dll)
• Computes hashes for function names
• Resolves function pointers dynamically

This can reduce the number of clean “import table” indicators and shift your detection toward behavioural signals.

Recommended telemetry sources

Depending on your stack, prioritise:

• EDR “suspicious API” analytics and memory protection changes (RX/RWX transitions)
• Process behaviours like:
  • Unbacked or unsigned modules in memory
  • Dynamic code execution patterns (reflective loading, abnormal thread creation)
  • High-entropy payloads written to memory

Even if you can’t reliably detect “hashing,” you can still detect the surrounding behaviours: suspicious parent/child chains, unsigned modules, and unusual network egress.

Detection strategy 3: watch for anti-forensic actions (Run history clearing and clipboard wipes)

Why these are valuable detections

Attackers don’t clear artifacts unless they believe those artifacts could expose them. That makes anti-forensics a strong “intent” signal.

Run dialog history clearing (common artifact)

The Run dialogue history commonly lives under a user hive path similar to:

• HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU

Signals to alert on:

• Deletion of values under RunMRU
• Sudden “reset” of the key (values disappear) shortly after suspicious execution
• A suspicious process modifying Explorer-related keys without an admin tool context

Clipboard wiping

Clipboard wiping is harder to see natively without specific telemetry, but you can still catch proxies:

• A suspicious process repeatedly calling clipboard APIs
• User-reported symptoms: “my copied text keeps disappearing”
• Correlation with other events (sideloading + outbound DoH + cleanup)

If your environment supports enhanced auditing, consider enabling clipboard-related telemetry where feasible (balanced with privacy and policy constraints).

Detection strategy 4: detect DoH to attacker domains over TCP/443

Why DoH is effective for attackers

DoH traffic:

• Runs over HTTPS (TCP/443)
• Often blends into normal web traffic
• Can bypass some legacy DNS-based detections if you only monitor port 53

Practical ways to detect malicious DoH usage

Focus on what you can reliably measure in your network stack:

• Known DoH endpoints allowlist: If you do not officially support third-party DoH, any connection to public DoH resolvers can be suspicious.
• Proxy categories / URL paths (when visible): Some DoH providers use recognisable endpoints (for example, /dns-query).
• SNI / certificate / destination reputation: Unexpected DoH hosts from endpoints that don’t need them.
• Endpoint-to-domain mismatch: A workstation that normally only talks to Microsoft 365 suddenly starts talking to niche DoH infrastructure.

If your organisation already allows DoH for privacy or performance reasons, shift from “block all DoH” to “alert on unusual DoH for that user/device,” and correlate it with endpoint execution and DLL sideloading signals.

Suggested Microsoft Sentinel detections (high-level logic)

Even if you don’t want your SOC to live in KQL, you still want clear, repeatable detection logic you can operationalise as analytics rules.

Here are detection ideas expressed as portable logic you can implement in Sentinel, your EDR, or a SIEM pipeline:

Rule 1: trusted binary + user-writable DLL load

Trigger when:

• Process name is ScreenClippingHost.exe or mblctr.exe
• A DLL is loaded from \Users\*\Downloads\, \Users\*\AppData\, or \Windows\Temp\
• DLL is unsigned OR recently created OR has low prevalence in your fleet

Rule 2: sideloading chain + suspicious outbound 443

Trigger when:

• Rule 1 matches
• The same process (or its child) makes outbound connections on TCP/443 to:
  • Newly registered domains (if you have that intel)
  • Low-reputation hosts
  • Non-corporate DoH endpoints
• AND the host shows anti-forensic registry modifications (RunMRU) within a short time window

Rule 3: anti-forensic registry changes without admin context

Trigger when:

• A non-admin tool process modifies RunMRU
• The modification happens shortly after execution from user-writable paths
• The device also shows unusual module loads or network egress anomalies

Starter signatures: ClamAV and Snort (adapt before production)

These examples are intentionally conservative and meant as a starting point. You should test in a lab, tune to your environment, and ensure you don’t introduce noisy false positives.

ClamAV: YARA-based approach (recommended when possible)

ClamAV can leverage YARA rules in many workflows. A practical approach is to look for combinations commonly seen in loaders/backdoors (strings + behaviours), rather than a single fragile string.

Example YARA rule concept (starter)

rule WIN_Dohdoor_Sideloading_Helper_Stub
{
meta:
description = "Starter heuristic for Dohdoor-like loader/backdoor components (tune before use)"
author = "Defender guidance"
date = "2026-02-27"

strings:
$s1 = "dns-query" ascii
$s2 = "RunMRU" ascii wide
$s3 = "ScreenClippingHost.exe" ascii wide
$s4 = "CryptAcquireContext" ascii
$s5 = "VirtualProtect" ascii
$s6 = "GetProcAddress" ascii

condition:
2 of ($s*) and filesize < 5MB
}

How to use it effectively:

• Scope scanning to suspicious directories (Downloads/AppData/Temp) and newly created DLLs
• Combine with allowlists for known internal tools that legitimately touch clipboard or registry

Snort: detect potential DoH endpoints / dns-query over HTTP semantics

Snort can help when you have visibility into HTTP(S) metadata (for example, via TLS interception, proxy logs feeding IDS, or plaintext HTTP in a subset of traffic). If you cannot see inside TLS, focus on destination allowlists and SNI-based detections in your network stack.

Example Snort rule concept (HTTP /dns-query)

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (
msg:"Potential DoH usage - dns-query endpoint";
flow:to_server,established;
content:"/dns-query"; http_uri;
classtype:policy-violation;
sid:9001001; rev:1;
)

If you can reliably capture SNI, consider rule logic in your proxy/NDR tools for:

• Unexpected DoH provider SNI values
• Rare destinations contacted by only one or two endpoints (low prevalence)

A practical investigation playbook (what to do when you alert)

When an alert fires, your SOC needs fast, repeatable steps:

1. Confirm the DLL load
   
   • Which DLL was loaded?
   • From what directory?
   • Was it signed, and is that signature expected?

• Trace execution and persistence
  
  • Parent process and command line
  • Any new scheduled tasks, services, Run keys, WMI persistence
• Check anti-forensics
  
  • Run history changes (RunMRU)
  • Evidence of artifact wiping (where visible)
• Pivot to network
  
  • Outbound 443 destinations
  • Any DoH-like destinations or patterns
  • Time correlation with the first suspicious process start
• Contain and remediate
  
  • Isolate host if confidence is high
  • Remove malicious DLL + initial dropper
  • Rotate credentials if there’s any sign of token/credential access

How SecQube helps you operationalise these detections in Sentinel

Microsoft Sentinel is powerful, but day-to-day SOC work often gets stuck on two bottlenecks: KQL dependency and alert-to-incident workflow friction. SecQube is designed to remove both.

With SecQube’s AI-powered, multi-tenant platform for Microsoft Sentinel, your team can:

• Use Harvey, the conversational AI assistant, to guide investigation steps and summarise what matters without requiring deep KQL expertise
• Run consistent incident triage workflows across customers/business units in a multi-tenant security portal
• Standardise response with built-in ticketing and change management, so remediation doesn’t live in scattered emails and chats
• Enrich alerts with real-time threat intelligence and automated severity context, especially useful for DoH/443 “blended” traffic
• Support MSSPs through white-label SOC operations, while still maintaining governance and repeatability

If you want to turn the Dohdoor sideloading + DoH detection ideas above into a clean, scalable SOC workflow inside Sentinel, explore SecQube here: SecQube

Quick reference: behaviours to watch

Start by implementing a “thin slice” detection: ScreenClippingHost.exe (or mblctr.exe) + suspicious DLL load path, then add correlation with outbound 443 anomalies and RunMRU modifications. That progression typically yields fast wins without overwhelming your SOC with noise.

If you share what telemetry you have available (Microsoft Defender for Endpoint module load visibility, Sysmon config, proxy/SNI logs, and whether DoH is officially allowed), I can suggest a tuned detection plan and clean alert logic aligned to your environment.