This YARA rule targets specific memory patterns associated with the RLPackV119DllaPlib043ap0x artifact, indicating the presence of a low-severity packed or obfuscated component often used in initial access or persistence stages. Proactively hunting for this signature in Azure Sentinel allows the SOC to identify dormant or stealthy malware implants that may evade standard behavioral detections, ensuring early visibility into potential supply chain or low-and-slow attacks.
rule RLPackV119DllaPlib043ap0x
{
meta:
author="malware-lu"
strings:
$a0 = { 80 7C 24 08 01 0F 85 89 01 00 00 60 E8 00 00 00 00 8B 2C 24 83 C4 04 83 7C 24 28 01 75 0C 8B 44 24 24 89 85 3C 04 00 00 EB 0C 8B 85 38 04 00 00 89 85 3C 04 00 00 8D B5 60 04 00 00 8D 9D EB 02 00 00 33 FF E8 52 01 00 00 EB 1B 8B 85 3C 04 00 00 FF 74 37 04 01 04 24 FF 34 37 01 04 24 FF D3 83 C4 08 83 C7 08 83 3C 37 00 75 DF 83 BD 48 04 00 00 00 74 0E 83 BD 4C 04 00 00 00 74 05 E8 B8 01 00 00 8D 74 37 04 53 6A 40 68 00 10 00 00 68 [4] 6A 00 FF 95 D1 03 00 00 89 85 5C 04 00 00 5B FF B5 5C 04 00 00 56 FF D3 83 C4 08 8B B5 5C 04 00 00 8B C6 EB 01 40 80 38 01 75 FA 40 8B 38 03 BD 3C 04 00 00 83 C0 04 89 85 58 04 00 00 E9 94 00 00 00 56 FF 95 C9 03 00 00 85 C0 0F 84 B4 00 00 00 89 85 54 04 00 00 8B C6 EB 5B 8B 85 58 04 00 00 8B 00 A9 00 00 00 80 74 14 35 00 00 00 80 50 8B 85 58 04 00 00 C7 00 20 20 20 00 EB 06 FF B5 58 04 00 00 FF B5 54 04 00 00 FF 95 CD 03 00 00 85 C0 74 71 89 07 83 C7 04 8B 85 58 04 00 00 EB 01 40 80 38 00 75 FA 40 89 85 58 04 00 00 66 81 78 02 00 80 74 A5 80 38 00 75 A0 EB 01 46 80 3E 00 75 FA 46 40 8B 38 03 BD 3C 04 00 00 83 C0 04 89 85 58 04 00 00 80 3E 01 0F 85 63 FF FF FF 68 00 40 00 00 68 [4] FF B5 5C 04 00 00 FF 95 D5 03 00 00 E8 3D 00 00 00 E8 24 01 00 00 61 E9 [4] 61 C3 }
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.
Scenario: A developer or DevOps engineer runs a static analysis tool (e.g., Ghidra, IDA Pro, or Binary Ninja) on a legacy C++ application to reverse-engineer a specific DLL for performance tuning or bug hunting. The YARA rule’s byte patterns match the specific packing structure or header signature of the analyzed binary in memory or on disk.
C:\Projects\, C:\Dev\, C:\Users\<user>\AppData\Local\Temp\ghidra\) or exclude processes originating from known IDE/reverse-engineering executables (e.g., ghidra.exe, idaw.exe, bnd.exe).Scenario: An automated build pipeline (e.g., Jenkins, Azure DevOps, or GitHub Actions) compiles a C/C++ project that uses a specific third-party library (e.g., a proprietary math or compression library) which happens to share the same binary packing characteristics as the target malware. The rule triggers on the newly generated .dll or .exe artifact during the build agent’s workspace.
jenkins_svc, azure_devops_agent) or located in standard build workspace paths (e.g., C:\Jenkins\workspace\, C:\AzureDevOps\agent\_work\). Additionally, correlate with the parent process being a build agent executable.Scenario: A system administrator performs a manual integrity check on a critical application using a hash verification tool (e.g., HashCheck, CertUtil, or a custom PowerShell script) that loads the DLL into memory to compute its SHA-256. The YARA rule scans the loaded module and matches the signature due to