This rule identifies potential development or testing artifacts, such as specific code patterns or binary strings, that may indicate an adversary has deployed custom tools or is conducting preparatory activities within the environment. Proactively hunting for these indicators allows the SOC team to detect low-fidelity staging or initial access attempts before they escalate into more complex post-exploitation actions.
rule DevCv5
{
meta:
author="malware-lu"
strings:
$a0 = { 55 89 E5 83 EC 14 6A ?? FF 15 [3] 00 [14] 00 00 00 00 }
condition:
$a0
}This YARA rule can be deployed in the following contexts:
This rule contains 1 string patterns in its detection logic.
DevCv5 YARA rule likely targets specific byte patterns associated with development environments or specific compiler outputs. In a legitimate enterprise, the code.exe process or its child processes (like node.exe running extension hosts) may load shared libraries or temporary files that match the rule’s signature during active coding sessions or automated builds.
code.exe or Code.exe and the working directory resides within standard user profile paths (e.g., C:\Users\<User>\AppData\Local\Programs\Microsoft VS Code\).gcc, clang, msbuild) that generate intermediate object files or temporary executables. These artifacts can contain binary patterns that trigger the DevCv5 rule, especially if the rule targets specific debug symbols or development-specific headers.
jenkins, gitlab-runner, or ci-agent in the directory structure, or where the parent process is a known build orchestration tool like java.exe (for Jenkins) or python.exe (for GitLab runners).buildkitd daemon or dockerd process executes build steps in isolated namespaces. Temporary files created during RUN commands (e.g., compiling C/C++ code) may match the YARA signature.
dockerd, containerd-shim, or buildkitd, or where the file path contains /var/lib/docker/ or `/tmp