DET0300: Detection Strategy for Reflective Code Loading
DET0300 is MITRE’s detection strategy object for Reflective Code Loading, a behavior where code is executed from process memory rather than from a normal f...
Analyst context for executives and security teams
DET0300 is MITRE’s detection strategy object for Reflective Code Loading, a behavior where code is executed from process memory rather than from a normal file-backed execution path. The business significance is that this can reduce the usefulness of controls and investigations that depend mainly on files, command lines, or process creation events. Leaders should treat this as a validation point for whether endpoint monitoring and incident response can see suspicious in-memory execution patterns across the operating systems where the related ATT&CK technique applies: Linux, macOS, and Windows.
Executive priority
Prioritize this as an assurance question for SOC and IR readiness: can the organization detect and investigate memory-resident execution, or is coverage mostly limited to files written to disk? This matters for resilience, audit evidence, and control prioritization because reflective loading can make incidents harder to scope if telemetry does not capture memory allocation, module loading, process behavior, and endpoint security events. Since the ATT&CK detection strategy object itself has no official description or detection text, executives should ask for environment-specific evidence rather than assume coverage from the ATT&CK entry alone.
Technical view
Use the relationship to T1620 Reflective Code Loading as the operational anchor. Detection engineering should validate whether endpoint telemetry can distinguish normal process memory behavior from suspicious allocation-and-execution patterns, anonymous or memory-only payload activity, and execution that is not backed by an expected file path. Because the DET0300 object does not specify platforms, tactics, or detection logic, teams should map validation to the related technique’s stated platforms of Linux, macOS, and Windows only where those platforms exist in the environment. IR teams should confirm whether triage procedures preserve enough process, module, memory, and endpoint event context to explain code execution that lacks a conventional on-disk artifact.
Likely telemetry
- Endpoint detection and response alerts and raw endpoint events
- Process creation and process lineage records
- Module or shared library load telemetry where available
- Memory allocation and memory protection change telemetry where available
- Evidence of executable memory regions or anonymous in-memory payloads where tooling supports it
Detection direction
- Validate that detections are not limited to file hashes, files written to disk, or command-line indicators.
- Test whether monitoring can surface suspicious execution from memory regions that are not clearly backed by trusted files on disk.
- Tune detections against legitimate software that uses dynamic loading, just-in-time compilation, security tooling, scripting runtimes, or plugin frameworks to reduce false positives.
- Correlate memory/code-loading signals with process lineage, user context, network activity, and unusual module behavior rather than relying on a single event type.
- For Linux, macOS, and Windows environments, confirm platform-specific visibility exists before claiming coverage for the related technique.
Mitigation priorities
- Start with visibility: confirm endpoint telemetry and IR tooling can collect process, module, and memory-related evidence needed to investigate reflective loading-like behavior.
- Harden execution controls where appropriate so untrusted code, scripts, libraries, and unauthorized tools have fewer opportunities to run inside legitimate processes.
- Apply least privilege and application control principles to reduce the number of users and processes able to introduce or execute unapproved code.
- Ensure incident response playbooks include memory-aware triage and preservation steps, not only disk artifact collection.
- Use detection validation exercises to produce audit-ready evidence of what is monitored, what is not, and which platforms are covered.
Analyst notes and limits
The supplied ATT&CK object is a detection strategy record, DET0300, and its only substantive context is that it detects T1620 Reflective Code Loading. The official detection and description fields for DET0300 are not provided, so this take is intentionally framed as validation guidance rather than a claim that MITRE provides a specific analytic. The related technique supplies the key behavioral context: adversaries may allocate and execute payloads directly in process memory to conceal execution.
This assessment is constrained by sparse official fields: no DET0300 description, no official detection text, no specified platforms, and no specified tactics on the detection strategy object. Platform references are derived only from the related T1620 technique. Local telemetry, endpoint tooling, operating system configuration, and acceptable business use of dynamic code loading must be reviewed before determining actual detection coverage or risk.
Detection Strategy for Reflective Code Loading
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1620 | Reflective Code Loading | This object detects Reflective Code Loading. |
All related ATT&CK context
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 | b6d8629d376e… |
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 DET0300Open 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.