MSVCpp DLL v8 typical OEP recognized h

Hunt Hypothesis

This hypothesis targets the presence of Microsoft Visual C++ runtime DLLs (v8) exhibiting a typical Original Entry Point (OEP) signature, which may indicate the use of legacy or potentially repacked native binaries in the environment. Proactively hunting for these artifacts helps identify outdated or suspicious native code execution that could serve as a foothold for low-level persistence or privilege escalation, ensuring the SOC team can validate the integrity of critical system components within Azure Sentinel.

YARA Rule

rule MSVCpp_DLL_v8_typical_OEP_recognized_h: PEiD
{
    strings:
        $a = { 8B FF 55 8B EC 53 8B 5D 08 56 8B 75 0C 85 F6 57 8B 7D 10 75 09 83 3D ?? ?? ?? ?? 00 EB 26 83 FE 01 74 05 83 FE 02 75 22 A1 ?? ?? ?? ?? 85 C0 74 09 57 56 53 FF D0 85 C0 74 0C 57 56 53 E8 ?? ?? ?? FF 85 C0 75 04 33 C0 EB 4E 57 56 53 E8 ?? ?? ?? FF 83 FE 01 89 45 0C 75 0C 85 C0 75 37 57 50 53 E8 ?? ?? ?? FF 85 F6 74 05 83 FE 03 75 26 57 56 53 E8 ?? ?? ?? FF 85 C0 75 03 21 45 0C 83 7D 0C 00 74 11 A1 ?? ?? ?? ?? 85 C0 74 08 57 56 53 FF D0 89 45 0C 8B 45 0C 5F 5E 5B 5D C2 0C 00 }
    condition:
        $a at pe.entry_point

}

Deployment Notes

This YARA rule can be deployed in the following contexts:

• Microsoft Defender for Endpoint — Custom indicators / advanced hunting
• Email Gateway — Attachment scanning
• File Share Monitoring — Periodic scanning of shared drives
• YARA CLI — Manual threat hunting on endpoints

This rule contains 1 string patterns in its detection logic.

• Source Rule

False Positive Guidance

• Legacy .NET Framework 2.0/3.5 Application Deployment: Many older enterprise line-of-business (LOB) applications built on the .NET Framework 2.0 or 3.5 rely on msvcp80.dll (Visual C++ 2005 runtime) for standard library functions. When these applications are deployed via Group Policy Preferences or SCCM to endpoints that already have the runtime installed, the DLL may be copied to the application’s local bin directory or C:\Windows\SysWOW64, triggering the OEP recognition.
  • Filter/Exclusion: Exclude paths where the DLL resides in application-specific directories (e.g., C:\Program Files\*\bin\, C:\Program Files (x86)\*\bin\) or where the parent process is a known deployment agent like ccmexec.exe (SCCM) or gpupdate.exe.
• Visual Studio Build Tools and Compiler Execution: Developers and CI/CD build agents frequently invoke the Microsoft Visual C++ compiler (cl.exe) or linker (link.exe) to compile C++ projects. These tools often load msvcp80.dll or similar v8-era runtime DLLs during the compilation or linking phase, especially if the project targets an older SDK or if the compiler itself is built against the 2005 runtime.
  • Filter/Exclusion: Exclude processes with names like cl.exe, link.exe, msbuild.exe, or vbc.exe (Visual Basic Compiler), and exclude paths under C:\Program Files (x86)\Microsoft Visual Studio\ or C:\Program Files\Microsoft Visual Studio\.
• Legacy Java/JNI Bridge Loading: Some legacy Java applications that use Java Native Interface (JNI) to call C++ native libraries may dynamically load `msvcp80.dll