DLL injection via registry

Threat snapshot

The AppCertDlls registry key is one of Windows' least-known persistence mechanisms and one of the most effective. Any DLL listed under this key is automatically loaded into every process that calls the CreateProcess, CreateProcessAsUser, CreateProcessWithLoginW, CreateProcessWithTokenW, or WinExec API functions. On a standard Windows system, that covers almost every application that launches another process, which is to say nearly all of them. An attacker who places a malicious DLL path into the AppCertDlls key does not need to modify a specific application, hook a scheduled task, or write a service. They simply wait for any process on the system to spawn a child, and their DLL is loaded automatically into that child's memory space.

This technique is particularly dangerous because it operates below the visibility of most endpoint monitoring tools, survives reboots without any additional persistence mechanism, and runs inside the address space of legitimate processes rather than as a standalone executable. Log360 detects it through the New DLL Added to AppCertDlls Registry Key rule, which fires whenever a new value is written to this key. Any addition to AppCertDlls that cannot be attributed to a documented, authorised software installation is a high-confidence indicator of attacker-placed persistence.

At a glance

How this attack works

The AppCertDlls key lives at:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCertDlls

Each value under this key specifies the full path to a DLL. When any process calls one of the five affected Win32 API functions, Windows reads every value under AppCertDlls and loads each listed DLL into the new process before it begins executing. The DLL's DllMain function runs with the same privileges as the calling process. If a high-privilege process such as a Windows service or a user running as administrator spawns a child, the injected DLL inherits that privilege level automatically.

The attack sequence is straightforward. The attacker, having already gained sufficient access to write to HKLM (which requires local administrator rights), drops a malicious DLL to a path on disk and adds a registry value under AppCertDlls pointing to that path. From that point forward, the DLL is loaded into every new process created on the system without any further attacker interaction. The malicious DLL can perform any action available to the host process: injecting further code, communicating with a C2 server, harvesting credentials from process memory, or establishing additional persistence mechanisms inside the memory space of trusted applications.

This technique is favoured by sophisticated threat actors because it combines persistence, privilege inheritance, and defense evasion in a single registry modification. The malicious code runs inside a trusted process, making network connections, file operations, and memory access appear to originate from that trusted process rather than from a standalone attacker binary.

Why this technique is difficult to detect without dedicated monitoring
The AppCertDlls key has a legitimate purpose: software vendors can use it to install DLL-based certification or monitoring hooks that apply globally to all process creation. This legitimate use case means the key is not blocked or restricted by default Windows security controls. Because the injected DLL runs inside a host process rather than as a standalone executable, file-based AV and process-execution monitoring tools see only the legitimate host process. The malicious DLL's activity is attributed to that process in most logging systems. Without a rule specifically monitoring for writes to the AppCertDlls key, the persistence mechanism is invisible until the DLL itself performs an action that triggers a separate detection.

Attack chain

The table below maps each stage of a DLL injection via AppCertDlls attack to the corresponding MITRE ATT&CK technique.

Real-world scenario

A software development company runs a Windows-based build environment with several developers who have local administrator rights on their workstations. A threat actor who compromised a developer's account via a credential stuffing attack against the company's VPN has been operating inside the network for four days using the developer's credentials.

Using the developer's local admin rights, the attacker drops a DLL named wmidll.dll into the C:\Windows\System32 directory, chosen because the name resembles legitimate WMI-related system files. They then add a registry value named WMIExtension under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCertDlls, pointing to the DLL path. The entire operation takes under ten seconds and requires no reboot to take effect.

From that point forward, every process the developer launches, including their IDE, the build tools, the corporate chat application, and the browser, loads wmidll.dll into its address space. The DLL opens a reverse shell from within the context of whichever process was most recently created, making the C2 connection appear to originate from the developer's IDE or browser. The developer's workstation is subsequently rebooted during a patch cycle. The DLL loads again automatically. The persistence mechanism survives the patch, the reboot, and a subsequent antivirus scan that checks the System32 directory but does not evaluate the AppCertDlls registry key values against the files they reference.

Why this happens

The AppCertDlls key is rarely included in registry monitoring baselines because it is not a commonly known persistence vector compared to Run keys or scheduled tasks. Most AV and EDR products focus their registry monitoring on well-documented persistence locations. An attacker who knows that AppCertDlls is unmonitored in a target environment can use it confidently, knowing the DLL will load into every new process indefinitely without generating a standalone process creation event that would trigger a process-based detection rule.

Business impact: What can go wrong

A malicious DLL successfully placed in the AppCertDlls key creates a persistent, privileged, and stealthy foothold with broad downstream consequences:

• Persistent code execution in every process: the injected DLL runs in the address space of every new process on the system, giving the attacker execution capability that survives process termination, application restarts, and system reboots without any additional persistence mechanism.
• Privilege inheritance: if the DLL is loaded into a high-privilege process such as a Windows service, a UAC-elevated application, or a process running as SYSTEM, the DLL code executes with the same privilege level, enabling actions that the original attacker foothold may not have permitted.
• Trusted process attribution: all activity performed by the injected DLL is attributed to the host process in network logs, file system logs, and process monitoring. Credential harvesting appears to come from the browser. C2 connections appear to come from the IDE. Data exfiltration appears to come from a build tool. This attribution confusion significantly complicates incident scope determination.
• Long-term undetected access: because the persistence mechanism is a single registry value and a file on disk that does not execute independently, automated persistence scanning tools that check scheduled tasks, services, and Run keys will not detect it. The attacker can maintain access for extended periods with minimal operational activity.
• Credential exposure across all sessions: a DLL loaded into a browser process can harvest saved passwords and session tokens. Loaded into an office application, it can capture document contents and keystrokes. The breadth of processes it enters means the attacker has access to essentially all user activity on the system.
• Compliance and audit trail contamination: because malicious activity is attributed to legitimate processes, audit logs and compliance records will show authorised applications performing unauthorised actions. Determining the true scope of the breach for compliance reporting becomes significantly more complex.

Indicators of compromise and detection signals

Prerequisites for detection using Log360

Before the New DLL Added to AppCertDlls Registry Key rule can fire reliably, ensure the following are in place:

• Sysmon is deployed on all monitored endpoints with a configuration capturing Event ID 13 (Registry Value Set) for the AppCertDlls key path. This is the primary telemetry source for the rule. The Sysmon configuration must explicitly include the full AppCertDlls registry path: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCertDlls.
• Sysmon Event ID 7 (Image Loaded) is enabled in the Sysmon configuration. This event records DLL load events and provides the secondary confirmation signal: seeing the new DLL loaded into multiple processes after the registry modification confirms the persistence mechanism is active.
• Windows Object Access auditing for the registry is enabled to generate Event ID 4657 as a supplementary record. While Sysmon Event ID 13 is the primary detection path, Event ID 4657 provides an independent audit record that is generated by the Windows kernel rather than the Sysmon driver, making it harder for an attacker to suppress by disabling the Sysmon service.
• Windows Process Creation auditing with command-line logging is enabled, generating Event ID 4688. This allows Log360 to identify the process responsible for writing the registry value, which is essential for distinguishing attacker-initiated modifications from legitimate software installation.
• Endpoint agents or Windows Event Forwarding are configured to forward Security and Sysmon logs from all monitored endpoints to Log360. Because AppCertDlls persistence affects individual endpoints rather than centralised infrastructure, coverage must include workstations, not only servers.

Note
Sysmon Event ID 7 (Image Loaded) can generate a high volume of events if not filtered carefully. Configure the Sysmon Image Load rule to exclude known, signed system DLLs and focus on DLL loads from user-writable paths, unsigned DLLs, or paths outside the standard Windows and Program Files directories. Without this filtering, Event ID 7 will create significant log volume without improving detection quality.

Detecting DLL injection via registry using Log360

Once log collection is configured, follow these steps to enable and tune detection in Log360:

Step 1: Enable the detection rule

Navigate to Security > Manage Rules > Rule Library in the Log360 console. Install and enable the rule: New DLL Added to AppCertDlls Registry Key. Configure an alert profile for the same. Set the alert severity to Critical.

Step 2: Read the alert

When the rule fires, the alert will display the hostname, the account that wrote the registry value, the full registry path including the value name, the DLL path written as the value data, and the process responsible for the write. Review the DLL path first. A path in a system directory with a name that mimics a legitimate system file is a strong attacker indicator. Then review the writing process: reg.exe or PowerShell writing to AppCertDlls from a user session context is high confidence. A signed vendor installer writing to this key during a documented software deployment is the primary false positive scenario.

Investigating an alert

When the New DLL Added to AppCertDlls Registry Key rule fires, an L2 analyst should work through the following steps:

• Examine the DLL path in the registry value data. Determine the full path of the DLL that was registered. Check whether the file exists at that path. If the file does not exist, the registry value was written but the DLL has not yet been placed, which may indicate the attacker is in the process of staging the attack. If the file exists, check its digital signature and compare it against known, legitimate software in your environment.
• Check the file's digital signature and hash. Verify whether the DLL is signed by a known, trusted vendor. If it is unsigned or signed by an unrecognised certificate, treat this as high-confidence malicious. Submit the file hash to a threat intelligence source or sandbox for analysis. Do not execute the file on the affected host.
• Identify the process that wrote the registry value. Open the Incident Workbench and find the process responsible for the AppCertDlls modification. Determine whether it was an interactive session, a remote session, a scheduled task, or a service. Trace the process back to its parent to identify the original compromise vector.
• Check for DLL load activity after the registration. Query Log360 for Sysmon Event ID 7 on the same host after the time of the registry modification. Look for the registered DLL path appearing in image load events across multiple processes. If the DLL is already loading into processes, the persistence mechanism is active and the host should be isolated immediately.
• Check for the DLL file being written to disk. Query Log360 for Sysmon Event ID 11 (File Create) on the same host in the period before the registry modification. Identify when the DLL file was first created on disk, by which process, and from what parent. This establishes the full sequence: file drop, then registry registration.
• Verify against documented software installations. Check the change management system and your software deployment logs for any authorised software installation on this host around the time of the alert. If no installation is documented, check with the host owner to confirm whether they installed any new software. If neither explains the registry modification, treat it as confirmed malicious.

Escalation trigger
Escalate immediately to L3 if the registered DLL is unsigned or signed by an unrecognised certificate; if Sysmon Event ID 7 shows the DLL already loading into multiple processes; if the registry modification was made by a non-administrative account or via a remote session from an unrecognised source IP; or if the DLL file creation and the registry modification cannot be attributed to any documented software installation. Isolate the host before attempting further investigation if the DLL is confirmed to be loading into active processes.

Responding and remediating

Immediate containment

• Remove the malicious registry value from the AppCertDlls key immediately. Use reg delete or PowerShell Remove-ItemProperty to delete the specific value. Do not delete the AppCertDlls key itself, as this may affect legitimate DLLs registered by authorised software. Delete only the specific value added by the attacker.
• Isolate the affected host from the network if the DLL has already been confirmed as loading into active processes. Use EDR host isolation to prevent the injected DLL from communicating with C2 infrastructure while forensic preservation is completed.
• Do not delete the DLL file from disk until a copy has been preserved for forensic analysis. The DLL is evidence. Hash it, copy it to a secure forensic location, and then remove it from the production path.
• Identify and disable the account used to write the registry value if it was a named user account. If it was SYSTEM or a service account, identify the process that ran as that account and disable or quarantine it.

Forensic preservation

• Preserve a copy of the malicious DLL before removal. Hash the file using SHA-256 and document the hash, the file path, the file creation timestamp, and the file size. Submit the hash to a threat intelligence platform and the file to a sandbox for full behavioural analysis.
• Export the Sysmon operational log and Windows Security event log from the affected host covering the full period from the DLL file creation to the time of containment. These logs provide the complete sequence of events including the file drop, the registry modification, and all DLL load events.
• Capture a memory image of the affected host if the DLL has been actively loading into processes. The DLL's in-memory state and any data it has accumulated (harvested credentials, staged exfiltration data) may be recoverable from the memory image.

Eradication and recovery

• Scan all other endpoints in the environment for the same DLL hash, the same file name, and the same AppCertDlls registry value. A targeted threat hunt across all managed endpoints for the IOCs identified on the affected host is essential to determine whether the persistence mechanism was deployed broadly.
• Review all persistence mechanisms on the affected host in addition to the AppCertDlls entry: scheduled tasks, services, Run keys, startup folder entries, and WMI subscriptions. An attacker who used AppCertDlls for persistence may have also established secondary persistence mechanisms.
• Rotate credentials for all accounts that had active sessions on the affected host during the period when the DLL was loading into processes. This includes the affected user account, any service accounts that ran processes on the host, and any administrator accounts that logged in during the incident window.

False positive guidance

The AppCertDlls key has limited legitimate uses. False positives are uncommon but do occur in the following scenarios:

• Enterprise security and DLP products: some Data Loss Prevention agents, endpoint protection platforms, and enterprise monitoring products legitimately register DLLs under AppCertDlls to intercept process creation events for inspection. These DLLs will be signed by the vendor and the registration will occur during a documented software installation. Verify the DLL path matches the product's documented installation directory, the DLL is signed by the expected vendor certificate, and the installation aligns with a change ticket.
• Software development tools: certain development environment tools and code analysis products use AppCertDlls to inject monitoring hooks for performance analysis or debugging. These will be present on developer workstations and the DLLs will be attributable to a specific development product. Verify the tool is in the approved software list and the DLL is signed by the vendor.
• Legacy application compatibility shims: some older enterprise applications use AppCertDlls as part of a compatibility shim layer to inject compatibility code into specific processes. These are typically set up during initial application deployment and will not generate new alerts unless the key is modified after initial installation. If an alert fires on a host with a long-standing AppCertDlls entry that suddenly has a new value added, the new value is the suspicious element.

Key differentiator

Legitimate DLLs in AppCertDlls are always signed by a known vendor, always attributable to a documented software product installed via a change-managed process, and always located in the product's documented installation directory. A DLL that is unsigned, located in a Temp or AppData directory, named to mimic a system file, or registered by a process other than a vendor installer is malicious with very high confidence. The AppCertDlls key is rarely modified in normal enterprise operations. Any new entry should be treated as suspicious until it is positively attributed to a documented software installation.

Hardening and prevention

The following controls reduce the risk of DLL injection via AppCertDlls in your environment:

• Apply a registry ACL to the AppCertDlls key that restricts write access to SYSTEM and documented software deployment service accounts only. Remove write access for interactive administrator sessions where operationally feasible. This prevents an attacker with local admin rights from modifying the key interactively, requiring them to first obtain SYSTEM-level access.
• Deploy Sysmon with explicit monitoring of the AppCertDlls registry path and Image Load events for DLLs loaded from non-standard paths. Without Sysmon coverage of this specific key, the persistence mechanism is invisible to Log360 and to most SIEM platforms.
• Include the AppCertDlls key in your configuration management baseline. Any value present under this key should be documented and audited. A monthly automated scan checking the key contents against the documented baseline provides a detection control independent of real-time monitoring.
• Enforce application allowlisting via AppLocker or Windows Defender Application Control to prevent unsigned DLLs from loading. This is the most effective prevention control: if unsigned DLLs cannot be loaded into processes, a malicious AppCertDlls entry will fail to execute even if the registry modification goes undetected.
• Enable Windows Defender Credential Guard to prevent credential material from being accessible to injected DLLs running in usermode processes. Even if a DLL is successfully loaded via AppCertDlls, Credential Guard prevents it from accessing LSASS-protected credentials.
• Apply the principle of least privilege to limit the number of accounts with local administrator rights on endpoints. The AppCertDlls key requires HKLM write access, which requires local admin. Reducing the number of accounts that can write to HKLM reduces the number of attacker footholds from which this technique is executable.