RLPack v118 Basic DLL LZMA

Hunt Hypothesis

This hypothesis targets the presence of RLPack v118 packed DLLs utilizing LZMA compression, a technique frequently employed by adversaries to obfuscate malicious payloads and evade static analysis during initial access or lateral movement. Proactively hunting for this specific packing signature in Azure Sentinel allows the SOC to identify potentially compromised endpoints or staged malware artifacts before they are executed, reducing the mean time to detection for low-severity but high-impact threats.

YARA Rule

rule RLPack_v118_Basic_DLL_LZMA: PEiD
{
    strings:
        $a = { 80 7C 24 08 01 0F 85 ?? ?? ?? ?? 60 E8 00 00 00 00 8B 2C 24 83 C4 04 8D B5 21 0B 00 00 8D 9D FF 02 00 00 33 FF E8 9F 01 00 00 6A 40 68 00 10 00 00 68 00 20 0C 00 6A 00 FF 95 AA 0A 00 00 89 85 F9 0A 00 00 EB 14 60 FF B5 F9 0A }
    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

• Scenario: A developer or DevOps engineer uses a custom build script that invokes the RLPack command-line utility to compress and protect a small native C/C++ DLL (e.g., libcrypto_helper.dll) before deploying it to a staging server. The YARA rule triggers on the in-memory or disk-resident file because it matches the specific LZMA compression signature and version header of RLPack v118.

  • Filter/Exclusion: Exclude files located in specific development or build artifact directories (e.g., C:\Builds\, D:\Artifacts\, or C:\Users\<dev_user>\Projects\) and exclude files with a .dll extension if the parent directory is known to be a build workspace. Additionally, consider excluding processes initiated by common build tools like MSBuild.exe, dotnet.exe, or cmake.exe.

• Scenario: An enterprise application (e.g., a legacy Java-based middleware or a specific vendor’s agent) bundles a self-extracting DLL that uses RLPack v118 for its internal component loading mechanism. When the application starts, the DLL is loaded into memory, and the YARA rule detects the LZMA-compressed section. This is a legitimate part of the application’s runtime, not a malicious packer.

  • Filter/Exclusion: Create a whitelist for known vendor applications. For example, if the DLL is loaded by VendorApp.exe or resides in C:\Program Files\<VendorName>\, exclude the DLL path. You can also exclude based on the parent process name if it is a trusted, signed executable from a known vendor.

• Scenario: A scheduled maintenance job runs a custom PowerShell or batch script that uses a helper DLL (packed with RLPack v118) to perform log rotation or database cleanup tasks. The DLL is temporarily extracted to a