How T1620 reflective code loading hides in normal process activity
A SOC lead opens an alert showing that a legitimate process is doing something it does not normally do, yet there is no new file on disk to examine. That gap is what T1620 Reflective code loading creates. In this technique, code is loaded and run in a process's memory without being written out as a file, so the usual file-based trail is missing. The Stealth tactic (TA0005) covers actions adversaries take to hide and appear as normal behavior, and this technique fits that goal because the code runs inside software the organization already trusts. Detection therefore depends on observing what the process does.
Adversaries typically use this technique after gaining an initial foothold, when they want to run additional capability inside an existing process on Linux, macOS or Windows. Because the code never lands as a file, hash-based allowlists, file reputation checks and file creation monitoring see little or nothing of it. Those controls remain useful, but they cover an earlier or different stage of the intrusion. Defender visibility has to come from process-level telemetry: which modules a process loads, which other processes it accesses, and whether its child activity or network behavior changes. The ATT&CK data components referenced most often for Stealth techniques, including Process Creation, Module Load and Process Access, are the starting points for the detection logic in this topic.
This page targets ATT&CK Enterprise version 20.0, which MITRE released on October 13, 2026, according to the attack-stix-data index. Stealth is the Enterprise tactic name from version 19 onward, when MITRE split Defense Evasion into Stealth, which keeps ID TA0005, and Defense Impairment, a new tactic with ID TA0112. Releases can rename, deprecate or revoke techniques, so each detection mapping should name the version it targets. Before writing rules, confirm the current detection strategies and data components for T1620 on the ATT&CK updates page, and record the ATT&CK version in every rule's metadata so later reviews can see what the rule was built against.
Which telemetry reveals reflective code loading on each platform
This table maps the data components most often referenced for Stealth techniques (Module Load, Process Access and Process Creation) to Linux, macOS and Windows, with the signal to look for and an open-source collector for each. Read each row as a starting point: confirm per-platform coverage in your own environment before relying on any single source, because reflective loading leaves different traces on each operating system.
| Platform | Telemetry and signal to look for | Open-source collector | Coverage to confirm |
|---|---|---|---|
| Windows, Module Load (DC0016) | Unbacked or unexpected image and DLL loads into a process, especially loads with no matching file on disk | Sysmon-style endpoint logging forwarded to Wazuh | Whether image load events are captured for all target processes and are not filtered out |
| Windows, Process Access (DC0035) | Access to another process's memory with write or execute rights from an unexpected parent or tool | Sysmon-style endpoint logging, Velociraptor for hunting | Whether access events are logged at the rights level you need, and volume is manageable |
| Windows, Process Creation (DC0032) | Unusual parent-child relationships and command lines around the process that later loads code | Sysmon-style endpoint logging, Wazuh agent | Whether command line capture is enabled and retained long enough for investigation |
| Linux, Module Load | Unexpected shared object loads and executable memory mappings in long-running processes | Auditd rules for relevant syscalls, Wazuh agent, Velociraptor for memory-related artifacts | Whether your kernel and audit rules cover the events you need, and the performance impact is acceptable |
| Linux, Process Creation | Processes started from memory-backed or deleted file paths, or interpreters started with unusual arguments | Auditd execve records, Wazuh agent | Whether execution records include full arguments and whether they reach the manager |
| macOS, Module Load and Process Creation | Dynamic library loads and process launches that do not match expected signed software | Endpoint logging via unified logs forwarded to Wazuh, Velociraptor for hunting | Which unified log predicates your fleet collects and how much native detail you retain |
| macOS, Process Access | Cross-process access or debugging attach events on hosts that should not run them | Endpoint logging via unified logs, Velociraptor for hunting | Whether process access events are visible at all on your macOS versions and management setup |
Detection logic that catches reflective loading without a file write
Reflective code loading avoids writing a payload to disk, so file-based controls see little. The detections below shift attention to what the process does in memory: which modules it maps, which other processes it touches, how it was started and where its executable code lives. Each idea needs a baseline from your own estate before it is trusted.
Unexpected module loads into long-lived processes
Watch for modules mapped into processes that rarely load new code, such as a web server worker, a scheduled service host or a database process. Alert when a module loads from a path outside the normal install directories, has no signature, or appears in a process that never loaded it during the baseline window. Tuning starts with a count of distinct new modules per process per day, and the threshold should sit well above the normal rate of your patch and plugin cycles. Expect false positives from JIT runtimes, which generate code at run time, and from security agents and EDR self-protection, which inject their own components. Allowlist those by publisher and path, not by process name alone.
Cross-process memory access by non-debugging tools
Process Access telemetry records when one process opens another with memory read or write rights. Reflective loading often needs a write into a foreign process, so flag access requests that combine write and thread-creation rights from a source that is not a debugger, backup agent or endpoint product. Set the threshold per source binary: a single hit from an unknown parent is a lead, while repeated access to several targets within a short window is a higher-priority case. Common false positives include crash reporters, performance monitors and EDR sensors, which read memory legitimately. Keep an allowlist of those vendors and review it after every agent upgrade.
Parent-child anomalies in process creation
Process Creation events show who started a process and with which arguments. Reflective loaders often run inside a legitimate host, so the signal is an unusual parent for a known binary, such as an office application or a browser starting a shell, or a service host spawning an interpreter it never used before. Build the baseline as a list of parent and child pairs seen over a fixed period, then alert on pairs that are new for that host group. Tune by frequency: a pair seen once across the fleet is more suspicious than one seen on many hosts. Expect false positives from software installers, management tools and build agents, so route those through change records.
Execution from anonymous or unbacked memory
Executable memory that does not map to a file on disk is a strong signal, because legitimate code normally runs from a mapped image. Where your EDR or memory scanner reports regions as private executable memory with no backing module, alert when such a region belongs to a process outside the JIT and runtime allowlist. Set the threshold on the region size and on whether the thread start address points into the region. Expect false positives from browsers, Java and .NET runtimes, and some game or virtualization software. Confirm during the cyber range exercise what your tooling can see on each operating system before you rely on this card.
How to baseline legitimate in-memory loading before you alert
Before any T1620 Reflective code loading alert reaches an analyst, build a baseline of the legitimate processes that map or execute code from memory as a normal part of their work. On Windows, that list usually includes .NET runtimes and their just-in-time compilers, PowerShell hosts, browser renderer and script engines, and endpoint security agents that inspect memory. On Linux and macOS, it includes interpreters and language runtimes such as JVM-based services, Node.js and Python packages that load native extensions, and browser processes. Collect this inventory from a representative set of hosts over a period that covers patch cycles, browser updates and routine business jobs, then record for each entry the process name, the signed publisher, the install path, the modules it typically loads and the parent process. Confirm the exact telemetry fields your Wazuh, Security Onion or Velociraptor deployment actually captures before you rely on them.
Turn the baseline into allow-list entries that match on more than the process name. Anchor each entry to a signed publisher and an exact install path, and record the owner, the business reason and an expiry date for every exception so that it is reviewed on a schedule rather than kept indefinitely. Tie expiry to change events such as a runtime upgrade or a security agent version change, so a stale rule is retired when the software it covers is replaced. Keep the allow-list in version control with the Sigma or detection rules that reference it, so changes are reviewed the same way code is.
The main risk of an allow-list is that it becomes a blind spot. A rule that trusts a publisher and path will also trust any process that can write to that path or that has been replaced by a look-alike binary, so review whether standard users or service accounts can modify those directories. Ask your security team to confirm that every exception is still justified each review cycle, and that alerts suppressed by the list are still sampled and logged. Test the baseline in your private cyber range by introducing a benign, out-of-baseline loader on a host that matches an allowed publisher, and confirm that the detection still fires.
How to validate a T1620 detection in a lab before it goes live
This sequence proves that a reflective code loading detection fires on the intended activity, stays quiet on normal software, and is documented well enough to repeat after every rule change. It produces a detection test log that a reviewer can trace from test to rule to result.
Define scope and success criteria
The detection owner and the platform lead agree in writing which operating systems (Linux, macOS and Windows), which host roles and which log sources are in scope, and which rule or analytic is under test. They also set the pass criteria before any test runs: the expected signal (for example, a Process Creation, Module Load or Process Access event tied to the test process), the expected alert severity and the acceptable false positive behavior. The step is done when the criteria are signed off and stored with the rule. Confirm the ATT&CK version this test targets (for example, the version recorded in your rule metadata) so later reviewers know which technique and data component mappings applied.
Select a benign test from an approved library
The test team chooses a reflective loading test from an emulation library approved by the security governance group, and documents its name, source, version and the ATT&CK technique it maps to. Tests must be benign: they should load a harmless module into a test process and not perform any follow-on action. Because emulation libraries change, record the exact revision used so the test can be repeated. The step is done when the test is approved in the change record and the expected telemetry is listed next to it. Ask your vendor or library maintainer to confirm which platforms each test supports before selecting it.
Prepare a representative host in the range
The platform team builds a cyber range host that matches production as closely as practical: the same operating system build, the same endpoint agent and logging configuration, and the same audit policies and forwarding path to the SIEM. Isolate the range from production networks and confirm that logs reach the analytics platform, such as Wazuh or Security Onion, before any test is run. Take a snapshot so the host can be reset between runs. The step is done when a harmless baseline event sent from the host is visible in the SIEM with the expected fields.
Run the test and confirm which signals fired
An operator runs the approved benign test on the prepared host while a second person watches the SIEM and the endpoint console. The operator records the start and end time of the run. The analyst then checks which telemetry appeared (Process Creation, Module Load, Process Access or the equivalent on each platform) and whether the rule fired. Missing signals are logged as gaps and are not explained away. The step is done when each expected signal is either confirmed or marked as a gap with a reason.
Record timestamps and the matched rule
For each alert, the analyst records the event timestamps from the source host, the timestamp of ingestion into the SIEM, the rule identifier and version, the matched fields and the alert time. Comparing these values shows how much latency the pipeline adds and whether the alert would have arrived in time for the responder. Any clock skew between the host and the platform is noted. The step is done when the timeline for the test run can be read from start to alert without gaps.
Measure false positives during a soak period
The rule runs in a non-blocking mode against production-like benign activity for an agreed soak period, which the change owner sets in writing. Analysts review every alert and classify it as a true positive, a benign match or an unexplained event. The team tunes the rule only through a documented change and re-tests after each change. The step is done when the false positive rate for the period is calculated, the benign sources are listed, and the change owner accepts the result. Confirm with your analytics platform how it reports alert volume so the calculation is repeatable.
Write the detection test log and approve release
The detection engineer writes a single detection test log entry per rule with the rule identifier and version, the ATT&CK technique and version, the test name and revision, the host configuration, the expected and observed signals, the timestamps, the false positive results and the reviewer's sign-off. The log is stored with the rule in version control and is linked to the change record. The rule is released to production only when the log is complete. The step is done when the log is approved and the rule is promoted.
Preventive controls that reduce reflective loading exposure
Reflective code loading is hard to block outright because it relies on legitimate operating system loading interfaces. The controls below reduce how often a loader can run unchecked, how much it can do once running, and how well the team can see it. Each card names what the mitigation limits, what it cannot stop, and what to confirm with the endpoint vendor before relying on it.
Behavior prevention on endpoint
Behavior Prevention on Endpoint (M1040) asks the endpoint product to act on suspicious sequences of activity, such as a process allocating executable memory and then running code that was never loaded from disk. This is the control most likely to interrupt in-memory loading, because it watches behavior rather than file signatures. It cannot stop loading that looks like normal runtime activity, such as legitimate .NET, Java or browser JIT compilation. Confirm which memory and injection behaviors the product blocks by default, which only alert, and how exclusions are approved and reviewed.
Execution prevention controls
Execution Prevention (M1038) covers controls that stop unapproved code from running, including application allowlisting and restrictions on which binaries may load modules. On Windows and macOS, these controls can limit which signed components may load into a process. Their limit is that a permitted, trusted binary can still be abused to load attacker-supplied content, so allowlists must be scoped to the loading paths the business needs. Ask the vendor how allowlist rules apply to memory-only loads and whether policy can be enforced in audit or enforce modes.
Audit configuration for loading events
Audit (M1047) means turning on the logging the detections depend on, such as process creation with command line, image load and process access events on Windows, and equivalent auditing on Linux and macOS. Without these settings, loader activity leaves little trace beyond a parent process. Audit is not a prevention control and does not block anything. Confirm that log volume, retention and forwarding to the SIEM are sized for the chosen events, and that the team tests the events with a known benign load before trusting a detection built on them.
Privileged account management
Privileged Account Management (M1026) limits which accounts can debug, inspect or write into other processes. Reflective loading into a process owned by another user or service generally requires elevated rights or a suitable process access right, so restricting who holds those rights narrows the attack surface. It cannot stop loading inside a process the attacker already controls under an ordinary account. Review which service accounts and administrators can open other processes with full access, and confirm whether the endpoint platform exposes a way to remove debugging privileges from standard users.
What the SOC does in the first hour after a reflective loading alert
The first hour after a reflective code loading alert has one goal: decide whether the event is a benign software behavior or an intrusion that needs containment, and do it with evidence the team can later defend. Start by confirming the host, the process and the account involved in the alert, then check whether the process is one the organization expects to load code this way. Analysts should compare the loaded module against the signed baseline for that application or image, confirming the publisher, the file hash and the expected path. A module that is unsigned, signed by an unexpected publisher, or running from a user-writable location moves the alert up the queue. Record what was checked and what was not, because the decision to escalate depends on those gaps as much as on the findings. Next, pull context from the SIEM. For Windows hosts, that means the Process Creation events for the parent and child processes, the Module Load events around the alert time, and any Process Access events showing another process touching the suspect process. For Linux and macOS, use the equivalent process lineage and file-activity telemetry your Wazuh or Security Onion deployment already collects. Look at the process tree for unusual parents, and check network connection records from the same process for destinations that do not match the application's normal profile. Confirm the time window with the host's own clock, since a skewed timestamp can make correlated events look unrelated.
Before any containment action, preserve volatile evidence. A collector such as Velociraptor, or a similar agent your team already operates, can capture process memory and loaded module state from the affected host, which is the evidence most likely to disappear after a reboot or a process exit. Confirm that the collection is authorized under your incident response procedure and that chain-of-custody notes are started at the moment of collection. Isolation is a decision, not a reflex: isolate the host when the module cannot be explained by the baseline, when the same process shows up on other endpoints, or when the process has access to privileged credentials. If the process is a known business application with a verified signature, the better action may be to monitor closely and open a change or vendor query. Document the scope in an incident record that names affected hosts, accounts, time windows and each decision taken, and state which items remain unconfirmed.
Rehearsing T1620 detection and response in a private cyber range
The range should mirror the telemetry path of the production estate closely enough that a detection that works in the range has a fair chance of working in production. For T1620 that means at least one Linux host, one macOS host and one Windows host, each forwarding the telemetry the detection depends on to a Wazuh or Security Onion stack. The network stays isolated from corporate and internet routes, and all test binaries and tooling live only inside the range.
- Host coverage: Include Linux, macOS and Windows endpoints with agents configured the way production agents are, not with debug settings that the production estate does not use.
- Telemetry path: Confirm that process creation, module load and process access events reach the SIEM with their original fields intact, and document any parsing or filtering between the endpoint and the index.
- Isolation: Enforce egress controls so that range hosts cannot reach production or external networks, and record the rules that enforce this.
- Time synchronization: Align clocks across hosts and the SIEM so that timelines in the triage record can be reconstructed.
- Snapshots: Snapshot each host before the exercise so that the range can be reset between runs.
Before the first run, ask your team to confirm which telemetry source names, agent versions and log retention settings the range shares with production, since results only transfer where those match.
Injects are the scenarios the purple team plays out in the range. Each one describes an adversary objective and the observable outcome the defenders should be able to see, without spelling out the exact steps that produce it. Scenarios should vary the platform, the loading context and the level of noise so that the team learns where detection is brittle rather than only where it is absent.
- Scenario on Windows: An in-memory code loading event occurs in a process that normally loads only signed modules, and the team checks whether module load and process access telemetry raise an alert.
- Scenario on Linux: Code is loaded into a process by a non-standard mechanism, and the team checks whether process creation and file activity provide enough context for an analyst to triage it.
- Scenario on macOS: A benign administrative tool behaves in an unexpected way, testing whether the team separates true positives from common false positives.
- Scenario with noise: Run the same activity during a routine patch window or backup job to measure whether alert volume hides the signal.
- Scenario with evasion pressure: Include a variant that changes process names or parent relationships, so the team can see whether detections rely on fragile fields.
For each inject, record the expected telemetry in advance, so the debrief can compare what should have appeared with what did.
Good detection for T1620 is measured by more than whether an alert fired. The team should judge the time from activity to alert, whether the alert names the affected host and process, and whether the triage record lets a second analyst reach the same conclusion. Response is judged by whether containment and evidence collection happened in the order the runbook sets out. Set these criteria before the exercise so the results are not interpreted after the fact.
- Time to alert: Measure from the first event in the inject to the first alert in the console, and agree in advance what threshold the organization considers acceptable for each platform.
- Alert quality: Check that the alert carries the process, parent, module and user context needed to triage it without pivoting through several tools.
- Triage record: Require a written record with the timeline, the evidence reviewed, the decision taken and the reason for it, so that auditors and reviewers can follow the reasoning.
- Containment: Confirm that the response steps in the runbook were executed, and note any steps that depended on one person's knowledge.
- Gap register: Log every missed detection, slow alert or incomplete record as a tracked item with an owner.
Before relying on any threshold, confirm with your own SOC leads and your environment's telemetry what time to alert is realistic for your estate, because results depend on the client's environment and must be confirmed during the exercise.
Questions SOC leads and detection engineers ask about T1620
Is module load telemetry enough to detect reflective code loading on Linux?
Module load telemetry is a useful signal on Linux, but it is rarely enough on its own. Reflective loading often places code in memory without a file ever touching disk, so a pure file-based view misses it. Pair module or shared object load events with process creation records, memory-related audit events where your platform exposes them, and network connection data for the same process. Confirm in your own environment which of these your Linux agents actually collect, at what verbosity, and whether kernel audit rules are maintained by your team or by a hardening baseline. Test the gaps with an approved simulation in your cyber range before you rely on any single source.
How do we stop JIT runtimes from flooding the SOC with alerts?
Just-in-time runtimes such as browsers, Java virtual machines and .NET hosts load code dynamically as part of normal work, so a naive rule fires constantly. Reduce noise by scoping rules to parent-child relationships that are unusual for a given host role, by baselining which runtimes and modules load on each asset group, and by suppressing known-good signed components through explicit allowlists that are reviewed on a schedule. Keep suppressions narrow and documented so that an allowlist entry cannot quietly hide a new technique. Ask your detection team to show the false positive rate per rule over a representative period before and after tuning.
How do we map Sigma and Wazuh rules to ATT&CK v20.0 and handle renames?
Record the ATT&CK version in every rule's metadata, for example v20.0, and reference the technique ID, the detection strategy and the data components your analytic depends on. Enterprise ATT&CK 20.0 was released by MITRE on 2026-10-13 according to the attack-stix-data repository index, and releases can rename, deprecate or revoke techniques. Store the mapping as data and compare it against each new STIX bundle, so a change to a technique or sub-technique surfaces as a review task rather than a silent gap. Confirm with your detection engineers how mapping updates are approved and who signs off on coverage changes. The attack-stix-data repository is the natural starting point for this comparison.
What should we do when Process Access events are not being logged?
Start by confirming whether Process Access is a collected data source in your environment at all, since many default configurations do not capture it. If it is missing, do not treat that as an acceptance decision. Document the gap, then rely more heavily on Process Creation and Module Load coverage, and check whether endpoint detection tooling offers equivalent memory or process interaction telemetry that you are licensed and configured to use. Enabling broad access auditing can create large volumes, so scope it to sensitive processes and critical servers first. Confirm the logging capability, the storage cost of the volume it creates and the retention period with your platform and security vendors before changing collection.
How can we test T1620 detections without running live malware?
Use controlled, benign simulations that produce the same telemetry shape as the behavior described in the ATT&CK technique, such as loading a test module through a sanctioned harness in an isolated range. Keep the range private, separate from production networks, and approved in writing by the asset owner. Define the expected alerts before each exercise, record what fired, what was missed and why, and feed the results back into rule tuning. Confirm with your range provider what isolation controls, data handling and reset procedures are in place. DeployOpen runs private cyber ranges and security testing, and the scope of any exercise is agreed in writing before work begins.
How do we confirm T1620 coverage still works after a platform upgrade?
Treat every platform upgrade as a detection change. Keep a regression set of benign test cases tied to each rule, rerun it in a staging copy of the SIEM and endpoint stack, and compare alert output against the pre-upgrade baseline. Check that field names, data component mappings and agent collection settings have not changed, because a schema change can break a rule without raising an error. Confirm the upgrade calendar, the rollback steps and who approves a coverage sign-off with your platform owner. For ongoing verification, retainers for continuous testing and upgrade support are available, with scope agreed in writing.
How DeployOpen builds T1620 detections and range scenarios
DeployOpen works on T1620 Reflective code loading as a fixed-scope engagement inside the client's own environment, covering Linux, macOS and Windows telemetry. The work moves from written scope to tested detections, cyber range rehearsal and documented handover, with ongoing support available as a retainer.
How we scope
- Agree in writing which platforms, telemetry sources and log pipelines are covered for T1620.
- Confirm which ATT&CK version the detection mappings will target before any rule is written.
- Record which Process Creation, Module Load and Process Access sources are in place and which must be enabled.
How we build
- Translate the ATT&CK detection strategies for T1620 into open-source rules for the client's SIEM and EDR stack.
- Tune Sigma-based logic against the client's benign software inventory to limit false positives from legitimate loaders.
- Map each detection to the ATT&CK mitigations Audit and Behavior Prevention on Endpoint where the client's tooling supports them.
How we hand over
- Deliver rule logic in plain language, with data source requirements, known blind spots and tuning notes.
- Run scripted range scenarios on Linux, macOS and Windows so the client's analysts can replay the detection themselves.
- Provide a runbook covering triage, containment steps and evidence capture for alerts raised on T1620.
How we support
- Review detection coverage after each ATT&CK release, since technique and data component changes can affect mappings.
- Re-run range scenarios after platform upgrades or telemetry changes to confirm the detection still fires.
- Offer ongoing support and continuous testing as a retainer, with scope agreed in writing.
