This hypothesis targets adversaries deploying fake MSVCpp DLLs to hijack application execution flow, a technique often used for initial access or privilege escalation in Windows environments. Proactively hunting for these specific YARA signatures allows the SOC to identify low-and-slow persistence mechanisms or supply chain compromises that may evade standard behavioral detections in Azure Sentinel.
rule MSLRH_v032a_fake_MSVCpp_DLL_Method_4_emadicius_h: PEiD
{
strings:
$a = { 55 8B EC 56 57 BF 01 00 00 00 8B 75 0C 85 F6 5F 5E 5D EB 05 E8 EB 04 40 00 EB FA E8 0A 00 00 00 E8 EB 0C 00 00 E8 F6 FF FF FF E8 F2 FF FF FF 83 C4 08 74 04 75 02 EB 02 EB 01 81 50 E8 02 00 00 00 29 5A 58 6B C0 03 E8 02 00 00 00 29 5A 83 C4 04 58 74 04 75 02 EB 02 EB 01 81 0F 31 50 0F 31 E8 0A 00 00 00 E8 EB 0C 00 00 E8 F6 FF FF FF E8 F2 FF FF FF }
condition:
$a at pe.entry_point
}This YARA rule can be deployed in the following contexts:
This rule contains 1 string patterns in its detection logic.
msvcp140.dll or similar runtime DLLs in %TEMP% or project-specific build folders during compilation or testing. These files may be signed by Microsoft but reside in non-standard paths, triggering “fake” DLL heuristics.
%TEMP%, %LOCALAPPDATA%\Temp, or directories matching *build*, *obj*, *bin* if the parent process is MSBuild.exe, devenv.exe, or vbc.exe.C:\ProgramData\Adobe\... or C:\Users\<user>\AppData\Local\JetBrains\...) before moving them to the system directory. These staged DLLs may lack the exact expected path or digital signature context expected by the rule.
C:\ProgramData\Adobe\, C:\ProgramData\JetBrains\, or C:\Users\<user>\AppData\Local\Temp\ if the parent process is an installer executable (e.g., msiexec.exe, setup.exe, install.exe).