This rule targets the execution of the ExeJoiner utility, a tool frequently used by adversaries to bundle multiple executables into a single file to evade detection or facilitate lateral movement. Proactively hunting for this behavior allows the SOC team to identify potential staging or deployment activities that may precede more complex post-exploitation actions within the Azure environment.
rule EXEJoinerv10
{
meta:
author="malware-lu"
strings:
$a0 = { 68 00 10 40 00 68 04 01 00 00 E8 39 03 00 00 05 00 10 40 C6 00 5C 68 [4] 68 [4] 6A 00 E8 }
condition:
$a0 at pe.entry_point
}
This YARA rule can be deployed in the following contexts:
This rule contains 1 string patterns in its detection logic.
MsMpEng.exe) or its companion processes often perform in-memory patching or module loading that can mimic the structural patterns of EXEJoinerv10 (likely targeting specific PE header anomalies or section characteristics associated with joiner/patcher tools).
MsMpEng.exe or MsMpEng.exe is the image, specifically if the command line contains arguments like /update or /patch.MSBuild.exe or vbc.exe may load temporary executable modules or perform in-memory linking that results in a binary structure matching the YARA signature, particularly during incremental builds or when using specific linker optimizations.
MSBuild.exe, vbc.exe, or csc.exe, and the file path resides under standard build directories like C:\Program Files (x86)\Microsoft Visual Studio\ or C:\Users\<user>\AppData\Local\Temp\.java.exe or jre.exe) often load native .dll or .so files that are mapped into memory. If the YARA rule scans memory or loaded modules, legitimate native libraries bundled with enterprise Java apps (like Oracle WebLogic, Tomcat, or custom internal tools) may exhibit section alignments or entropy values that trigger the rule.
java.exe or jre.exe, and the loaded module path contains jre\bin or jvm.dll.