New to CAPEC? Start Here
Home > CAPEC List > CAPEC-471: Search Order Hijacking (Version 3.9)  

CAPEC-471: Search Order Hijacking

Attack Pattern ID: 471
Abstraction: Detailed
View customized information:
+ Description
An adversary exploits a weakness in an application's specification of external libraries to exploit the functionality of the loader where the process loading the library searches first in the same directory in which the process binary resides and then in other directories. Exploitation of this preferential search order can allow an attacker to make the loading process load the adversary's rogue library rather than the legitimate library. This attack can be leveraged with many different libraries and with many different loading processes. No forensic trails are left in the system's registry or file system that an incorrect library had been loaded.
+ Typical Severity

Medium

+ Relationships
Section HelpThis table shows the other attack patterns and high level categories that are related to this attack pattern. These relationships are defined as ChildOf and ParentOf, and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as CanFollow, PeerOf, and CanAlsoBe are defined to show similar attack patterns that the user may want to explore.
NatureTypeIDName
ChildOfStandard Attack PatternStandard Attack Pattern - A standard level attack pattern in CAPEC is focused on a specific methodology or technique used in an attack. It is often seen as a singular piece of a fully executed attack. A standard attack pattern is meant to provide sufficient details to understand the specific technique and how it attempts to accomplish a desired goal. A standard level attack pattern is a specific type of a more abstract meta level attack pattern.159Redirect Access to Libraries
Section HelpThis table shows the views that this attack pattern belongs to and top level categories within that view.
+ Execution Flow
Explore
  1. Identify target general susceptibility: An attacker uses an automated tool or manually finds whether the target application uses dynamically linked libraries and the configuration file or look up table (such as Procedure Linkage Table) which contains the entries for dynamically linked libraries.

    Techniques
    The attacker uses a tool such as the OSX "otool" utility or manually probes whether the target application uses dynamically linked libraries.
    The attacker finds the configuration files containing the entries to the dynamically linked libraries and modifies the entries to point to the malicious libraries the attacker crafted.
Experiment
  1. Craft malicious libraries: The attacker uses knowledge gained in the Explore phase to craft malicious libraries that they will redirect the target to leverage. These malicious libraries could have the same APIs as the legitimate library and additional malicious code.

    Techniques
    The attacker monitors the file operations performed by the target application using a tool like dtrace or FileMon. And the attacker can delay the operations by using "sleep(2)" and "usleep()" to prepare the appropriate conditions for the attack, or make the application perform expansive tasks (large files parsing, etc.) depending on the purpose of the application.
Exploit
  1. Redirect the access to libraries to the malicious libraries: The attacker redirects the target to the malicious libraries they crafted in the Experiment phase. The attacker will be able to force the targeted application to execute arbitrary code when the application attempts to access the legitimate libraries.

    Techniques
    The attacker modifies the entries in the configuration files pointing to the malicious libraries they crafted.
    The attacker leverages symlink/timing issues to redirect the target to access the malicious libraries they crafted. See also: CAPEC-132.
    The attacker leverages file search path order issues to redirect the target to access the malicious libraries they crafted. See also: CAPEC-38.
+ Prerequisites
Attacker has a mechanism to place its malicious libraries in the needed location on the file system.
+ Skills Required
[Level: Medium]
Ability to create a malicious library.
+ Mitigations
Design: Fix the Windows loading process to eliminate the preferential search order by looking for DLLs in the precise location where they are expected
Design: Sign system DLLs so that unauthorized DLLs can be detected.
+ Example Instances
For instance, an attacker with access to the file system may place a malicious ntshrui.dll in the C:\Windows directory. This DLL normally resides in the System32 folder. Process explorer.exe which also resides in C:\Windows, upon trying to load the ntshrui.dll from the System32 folder will actually load the DLL supplied by the attacker simply because of the preferential search order. Since the attacker has placed its malicious ntshrui.dll in the same directory as the loading explorer.exe process, the DLL supplied by the attacker will be found first and thus loaded in lieu of the legitimate DLL. Since explorer.exe is loaded during the boot cycle, the attackers' malware is guaranteed to execute.
macOS and OS X use a common method to look for required dynamic libraries (dylib) to load into a program based on search paths. Adversaries can take advantage of ambiguous paths to plant dylibs to gain privilege escalation or persistence. A common method is to see what dylibs an application uses, then plant a malicious version with the same name higher up in the search path. This typically results in the dylib being in the same folder as the application itself. If the program is configured to run at a higher privilege level than the current user, then when the dylib is loaded into the application, the dylib will also run at that elevated level.
+ Taxonomy Mappings
Section HelpCAPEC mappings to ATT&CK techniques leverage an inheritance model to streamline and minimize direct CAPEC/ATT&CK mappings. Inheritance of a mapping is indicated by text stating that the parent CAPEC has relevant ATT&CK mappings. Note that the ATT&CK Enterprise Framework does not use an inheritance model as part of the mapping to CAPEC.
Relevant to the ATT&CK taxonomy mapping (also see parent)
Entry IDEntry Name
1574.001Hijack Execution Flow:DLL search order hijacking
1574.004Hijack Execution Flow: Dylib Hijacking
1574.008Hijack Execution Flow: Path Interception by Search Order Hijacking
+ References
[REF-409] "M Trends Report". Mandiant. 2011. <https://www.mandiant.com>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2014-06-23
(Version 2.6)
CAPEC Content TeamThe MITRE Corporation
Modifications
Modification DateModifierOrganization
2015-11-09
(Version 2.7)
CAPEC Content TeamThe MITRE Corporation
Updated References
2018-07-31
(Version 2.12)
CAPEC Content TeamThe MITRE Corporation
Updated Attack_Phases, Attack_Prerequisites, Attacker_Skills_or_Knowledge_Required, Description, Description Summary, Examples-Instances, References, Related_Weaknesses
2019-04-04
(Version 3.1)
CAPEC Content TeamThe MITRE Corporation
Updated Taxonomy_Mappings
2020-07-30
(Version 3.3)
CAPEC Content TeamThe MITRE Corporation
Updated Execution_Flow, Taxonomy_Mappings
2020-12-17
(Version 3.4)
CAPEC Content TeamThe MITRE Corporation
Updated Mitigations
2021-06-24
(Version 3.5)
CAPEC Content TeamThe MITRE Corporation
Updated Taxonomy_Mappings
2022-09-29
(Version 3.8)
CAPEC Content TeamThe MITRE Corporation
Updated Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2018-07-31
(Version 2.12)
DLL Search Order Hijacking
More information is available — Please select a different filter.
Page Last Updated or Reviewed: July 31, 2018