reversinglabs/reversinglabs-yara-rules

YARA rules published by ReversingLabs, a commercial file-analysis vendor. Like any YARA ruleset these match against files and process memory rather than events, so they answer "what is this sample" and not "what happened".

The distinguishing property is intent: these are classification rules, not threat-hunting rules. Each one is built to identify a specific malware family and label it, backed by ReversingLabs' own sample collection. Where signature-base leans toward sweeping a suspect host for APT tooling, this ruleset leans toward answering "which family is this binary".

Rules are organized by category — backdoor, downloader, infostealer, ransomware, rootkit, trojan, pua, exploit, virus, certificate — one file per family, named Platform.Category.Family.yara.

rule Linux_Backdoor_PondRAT : tc_detection malicious
{
    meta:
        author              = "ReversingLabs"
        status              = "RELEASED"
        sharing             = "TLP:WHITE"
        category            = "MALWARE"
        malware             = "PONDRAT"
        tc_detection_type   = "Backdoor"
        tc_detection_name   = "PondRAT"
        tc_detection_factor = 5
    strings:
        $connect_proxy_p1 = { 41 55 41 54 55 53 48 81 EC ?? ?? ?? ?? E8 ?? ?? ?? ?? ... }
    ...
}

Two things stand out. The rule tags (: tc_detection malicious) and the tc_* meta fields tie into ReversingLabs' TitaniumCloud classification taxonomy — tc_detection_factor is their confidence weighting, not a severity in the sense this site uses.

More importantly, the strings are almost entirely hex opcode patterns with wildcards, not printable text. These are code-level signatures matching compiled instruction sequences, which makes them resistant to string obfuscation and packing-agnostic in ways that text-based rules are not — and also makes them essentially unreadable without disassembling the family yourself.

The rule body is shown verbatim.

Severity and ATT&CK read as absent, not as zero. YARA carries no field for either, and this ruleset adds no ATT&CK mapping of its own. The vendor's own tc_detection_factor is preserved in the rule body but is not mapped onto this site's severity scale, because it measures classification confidence rather than threat severity and conflating the two would be misleading.

• These rules identify families, so a match tells you what something is, not that an attack succeeded or even executed.
• tc_detection_factor looks like a severity score and is not one. Read it as ReversingLabs' confidence in the classification.
• Opcode-pattern rules are tightly coupled to specific compiled builds. A new build of the same family may not match, which is a different failure mode from a string-based rule going stale.