Definition
Comparing the "text" or "code" memory segments to a source of truth.
How it works
A process code segment is an executable portion of computer memory allocated to a particular process. Process Code Segment Verification implements verification to compare a process code segment to some expected value.
Verification logic
Verification can occur during application startup, or continuously during execution. The logic which verifies the process code may be separate in a third-party process, embedded in the application itself at compile time, or dynamically linked at runtime.
System of record
Examples of systems of record:
- On-disk application binary files or checksums
- Remotely stored binary data or checksums
- Embedded binary data or checksums
Post Verification Actions
If the verification function determines a process code segment may have been altered, a capability may invoke Eviction techniques as **Process Termination** to end the current process, or **Executable Blacklisting** to prevent the executable from launching in the future.
Considerations
False positives
False positives commonly occur in the case that the layout of code in the process segment is legitimately modified:
- Operating system features or third-party security software may modify the layout of process code, for example in the defensive technique **Segment Address Offset Randomization**, or in the case that a module is rebased. In both of these cases, the alteration occurs before the code is fully loaded into memory, and it would be possible to avoid the false positive by securely feeding this constant offset and any relocation data into the verification logic.
- Process code segments may be written to modify themselves or other process code segments; however, this goes against widely-accepted current practices in software development.
False negatives
False negatives can occur via alteration of the verification logic or source of truth, or insufficient verification logic.
- Verification techniques which are executed only locally may be defeated by altering the local verification logic.
- Verification that is run only on a recurring basis could be evaded if the malicious alteration is completed before verification is run.
- Verification that requests an operation to be performed on a subset of the code segment could be evaded by performing that operation on a copy of the relevant bytes of the code segment.
- Verification based on a system of record that can be altered may fail if that system of record is modifiable by a malicious user.
Implementation perspective
Process Code Segment Verification should be treated as a technical defensive capability rather than a product checkbox. In practice, teams should define the protected scope, the conditions under which the technique acts, and the observable evidence that demonstrates the intended behavior. For this technique, likely engineering context includes Process Code Segment.
Use the technique to identify suspicious, unauthorized, or abnormal activity through observable evidence and repeatable analysis.
Questions to ask
- Which events, states, or artifacts must be observed for the analysis to work?
- What analytic logic, threshold, comparison, or signature turns observations into a finding?
- How are expected false positives, blind spots, and environmental variations documented?
- Who receives the result, and what action is expected when the technique produces a finding?
Evidence and validation
- Telemetry and data-source configuration records
- Analytic logic, thresholds, signatures, and version history
- Test cases demonstrating expected positive and negative results
- Alert, triage, escalation, and tuning records
Common failure patterns
- Required telemetry is missing, delayed, or transformed in a way that invalidates the analysis.
- The technique produces alerts without an accountable triage and response process.
- Detection coverage is claimed from product deployment without testing the relevant analytic behavior.
This implementation perspective is original Bare Metal Cyber educational content. It does not replace the official D3FEND definition or establish that a specific product implements the technique.
Technique hierarchy
Top-level family
Parent techniques
Direct child techniques
None listed at this level.
Artifacts and ontology entities
These relationships describe how D3FEND connects a defensive technique to artifacts or other ontology entities. They describe graph semantics, not a product certification.
Explicit technique relationships
Show inferred artifact relationship paths (1)
Offensive-technique relationships
These relationships are generated from D3FEND graph paths and are explicitly experimental. They should be treated as hypotheses for defensive analysis—not as proof that the technique prevents, detects, or removes an offensive behavior.
ATT&CK Enterprise (7)
ATT&CK for ICS (4)
Authoritative sources
- Open this technique on the official D3FEND website ↗
- Open the official ontology resources ↗
- Anti-tamper system with self-adjusting guards ↗ARXAN TECHNOLOGIES Inc · Kevin Dale Morgan · PatentReference
- Guards for application in software tamperproofing ↗Purdue Research Foundation · Hoi Chang; Mikhail J. Atallah; John R. Rice · PatentReference
- System and method for detecting malware injected into memory of a computing device ↗Endgame Inc · Joseph W. Desimone · PatentReference
- System and method for validating in-memory integrity of executable files to identify malicious activity ↗Endgame Inc · Joseph W. Desimone · PatentReference
- Tamper proof mutating software ↗ARXAN TECHNOLOGIES Inc · Kevin Dale Morgan · PatentReference
- Threat detection through the accumulated detection of threat characteristics ↗Sophos Ltd · Clifford Penton; Irene Michlin · PatentReference
Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by The MITRE Corporation. MITRE D3FEND™ and the D3FEND logo are trademarks of The MITRE Corporation. MITRE ATT&CK® and ATT&CK® are registered trademarks of The MITRE Corporation. Use of D3FEND source material is subject to the official Terms of Use.