Adversaries may execute malicious payloads via loading shared modules. Shared modules are executable files that are loaded into processes to provide access to reusable code, such as specific custom functions or invoking OS API functions (i.e., Native API).
Adversaries may use this functionality as a way to execute arbitrary payloads on a victim system. For example, adversaries can modularize functionality of their malware into shared objects that perform various functions such as managing C2 network communications or execution of specific actions on objective.
The Linux & macOS module loader can load and execute shared objects from arbitrary local paths. This functionality resides in
dlfcn.h in functions such as
dlsym. Although macOS can execute
.so files, common practice uses
The Windows module loader can be instructed to load DLLs from arbitrary local paths and arbitrary Universal Naming Convention (UNC) network paths. This functionality resides in
NTDLL.dll and is part of the Windows Native API which is called from functions like
LoadLibrary at run time.
Identify and block potentially malicious software executed through this technique by using application control tools capable of preventing unknown modules from being loaded.
Monitoring module loads may generate a significant amount of data and may not be directly useful for defense unless collected under specific circumstances, since benign use of shared modules load functions are common and may be difficult to distinguish from malicious behavior. Legitimate software will likely only need to load routine, bundled, or system modules such that deviation from known module loads may be suspicious
Limiting module loads to trusted directories, such as
|OS API Execution
Monitor for API calls that may execute malicious payloads via loading shared modules.