AN1095: Analytic 1095
Detects DLL injection through correlation of memory allocation and writing to remote process memory (e.g., VirtualAllocEx, WriteProcessMemory), followed by remote thread creation (e.g., CreateRemoteThread) that loads a suspicious or unsigned DLL using LoadLibrary or reflective loading.
Analyst context for executives and security teams
AN1095 is a Windows detection analytic for a high-risk process manipulation pattern: one process allocates and writes memory into another process, then creates a remote thread to load a suspicious or unsigned DLL. For leaders, the value is not just “DLL injection detection”; it is a check on whether the organization can see behaviors commonly associated with stealthy code execution inside trusted processes, which can affect incident containment, endpoint visibility, and confidence in SOC coverage.
Executive priority
Prioritize this analytic where Windows endpoint compromise would create material business disruption or where incident responders rely on endpoint telemetry to make containment decisions. Executives should ask whether security teams can prove collection of the required process, memory, module-load, and code-signing evidence, and whether alert triage procedures distinguish legitimate administrative or security tooling from suspicious remote process manipulation. Because no ATT&CK relationships or tactic mapping were supplied, treat this as a coverage validation item for Windows behavioral detection rather than as evidence of a specific threat campaign or outcome.
Technical view
For SOC and detection engineering teams, validate correlation across the sequence described in the official analytic: remote process memory allocation or writing, such as VirtualAllocEx or WriteProcessMemory, followed by remote thread creation, such as CreateRemoteThread, that results in DLL loading through LoadLibrary or reflective loading. The practical test is whether telemetry preserves source process, target process, call or event sequence, loaded DLL path or image metadata, and signing status closely enough to correlate the behavior. Since ATT&CK provides no separate official detection text and no relationship context for this object, local tuning should be based on known-good software that performs remote injection-like behavior, including enterprise management, EDR, accessibility, and developer tools where applicable.
Likely telemetry
- Windows endpoint process creation and process relationship events
- Remote process access, memory allocation, and memory write telemetry
- Remote thread creation telemetry
- DLL or image/module load events
- File path, hash, and code-signing metadata for loaded DLLs
Detection direction
- Confirm that Windows telemetry can correlate memory allocation or writing in a remote process with subsequent remote thread creation and DLL load activity, not just observe each event independently.
- Tune for suspicious or unsigned DLL loads while preserving visibility into signed-but-unusual binaries, because signing status alone should not be the only decision point.
- Baseline legitimate remote injection-like activity from approved security, administration, accessibility, and software deployment tools to reduce false positives.
- Prioritize alerts where the source process is unusual for the user or host, the target process is sensitive or commonly trusted, the DLL path is uncommon, or the DLL is unsigned or otherwise suspicious.
- Document telemetry gaps explicitly: if memory operation, remote thread, module load, or signing data is missing, the analytic may produce weak or incomplete coverage.
Mitigation priorities
- First, ensure endpoint visibility is sufficient on Windows systems to collect the event classes needed by the analytic.
- Next, harden operational allowlists and software governance so approved tools that use remote process techniques are known and can be separated from unexpected behavior.
- Then, use application control, code-signing policy review, and least-privilege practices where appropriate to reduce opportunities for untrusted DLL loading.
- Finally, incorporate this analytic into incident response playbooks so analysts know how to collect process, module, file, and user context before containment decisions.
Analyst notes and limits
This object is a detection analytic, not a technique, and the supplied fields include no tactics, no relationships, no aliases, and no external references beyond MITRE. The strongest supported interpretation is a Windows behavioral detection pattern for DLL injection involving remote memory operations, remote thread creation, and suspicious or unsigned DLL loading.
The official detection field is not provided, and no relationship context was supplied. This take therefore cannot assert associated ATT&CK techniques, threat actors, campaigns, impact, prevalence, or guaranteed detection coverage. Local endpoint logging, EDR capabilities, and tuning data are required to determine practical effectiveness.
Analytic 1095
Detects DLL injection through correlation of memory allocation and writing to remote process memory (e.g., VirtualAllocEx, WriteProcessMemory), followed by remote thread creation (e.g., CreateRemoteThread) that loads a suspicious or unsigned DLL using LoadLibrary or reflective loading.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 3d60b23d419a… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1095Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.