Definition
Analyzing vendor specific branch call recording in order to detect ROP style attacks.
How it works
This technique is used to detect an attacker attempting to exploit and execute code on a target system's call stack using return-oriented programming (ROP). Modern processors that have the ability to maintain a list of the branching calls, e.g., Intel's Last Branch Recording (LBR), can be used to track and analyze indirect branching calls that are indicative of malicious activity.
In order to reduce the number of indirect branch calls to analyze to a manageable set it is assumed that malicious ROP activity will involve the use of system calls. The technique observes indirect branch calls that are part of paths that lead to system calls, all others are ignored. Branching calls chained together is often referred to as gadgets and gadgets are often used in ROP attacks. Indirect branch calls that involve a transfer from user-space to kernel-space are of interest for this technique.
Identification of potential ROP exploit execution includes:
- Inspecting the LBR when a system function call is made
- The LBR is configured to return only instruction of interest (ret, indirect jmp, indirect calls)
- Behavior is analyzed for
- Ret instructions that appear to target areas not preceded by the call sites
- Sequences of small code fragments that appear to be chained through the indirect branching calls (gadgets)
- Of interest are returns that appear to not render control back after calls
- Typical ret-call are paired
- gadgets will appear to have ret followed by instruction of next instruction of the following gadget
Considerations
- May be operating system dependent since specific system calls are used to scope branching behavior
- Processors need to support access to a Last Branch Recording list feature
- The size of the LBR stack can limit the expected size of the analyzed execution stack
- If processor does not support LBR then overhead costs for the analysis can be significant
Implementation perspective
Indirect Branch Call Analysis 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 the relevant system, activity, and evidence sources.
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.
Authoritative sources
- Open this technique on the official D3FEND website ↗
- Open the official ontology resources ↗
- Transparent ROP Exploit Mitigation using Indirect Branch Tracing ↗Columbia University · Vasilis Pappas, Michalis Polychronakis, Angelos D. Keromytis Columbia University · AcademicPaperReference
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.