Hijack Execution Flow

Change which code a trusted action selects

Execution-flow hijacking redirects how an operating system or application chooses code to run. Search order, library resolution, executable paths, or related configuration can cause a legitimate program to load unintended content. The visible initiating application may remain familiar while the selected code changes.

This is different from assuming every newly loaded library is malicious. Applications legitimately use modules and dependencies. The investigation needs the intended resolution path, actual selected artifact, permissions, provenance, and execution evidence.

An approved service loads an unexpected component

In a fictional environment, a trusted service loads a library from a location unrelated to its approved installation. The analyst reviews module-load records where available, service configuration, file metadata, search or resolution settings, and recent changes.

A legitimate plugin or product update could explain the location. The team checks the service owner's documentation and deployment history. A signed parent application does not automatically establish trust in every artifact it loads.

Determine whether a less-trusted identity could write to the selected path or change the relevant configuration. That relationship may explain how the actor redirected execution without replacing the main executable.

Verify selection and execution separately

A suspicious file in a searched directory shows an opportunity. Evidence that the application actually selected or loaded it supports a stronger conclusion. Additional process or behavior records may show the resulting effects.

Preserve paths, identifiers, relevant configuration, and artifacts before cleanup where practical. Later restoration may remove the conditions that explain why a particular component was chosen.

Shared Modules describes reusable code loading. File and Directory Permissions Modification can explain an enabling access change, while Compromise Host Software Binary concerns modification of existing software itself. These mechanisms should be distinguished using the observed sequence.

Restore the selection boundary

Remove unauthorized artifacts or settings through an approved process and correct the writable paths or configuration that enabled redirection. Replacing one library without fixing the resolution weakness may allow the same path to be reused.

Coordinate with the application owner because dependency and path changes can break legitimate components. Verify the approved program loads the expected code and continues to perform required functions.

For practice, compare an approved plugin load with a fictional service selecting a same-named library from an unexpected writable directory. Identify the load, path, permission, provenance, and change evidence needed for a decision. Explain what cannot be established from the library's presence alone. Incident response and Incident reporting and handover connect code-selection findings to a defensible remediation plan.

Related concepts

• MITRE ATT&CK
• Logs and telemetry