Guides

Private YARA rules

Threatray allows you to upload and use your own private YARA rules, which are run against both the submitted file and all memory regions on every analysis type.

Newly created rules are applied only to new submissions. Private YARA rules remain within your private instance, where all users from your organization have access to view and edit them. These rules are not shared outside of your private Threatray instance.

YARA ruleset overview

Private YARA rules are organized into rulesets, which are files containing one to many YARA rules. To manage your rulesets, navigate to the YARA rulesets menu (1).

In this view, you will find a list of your organizations YARA rulesets (1). By default, Threatray provides several community rulesets that are automatically updated and cannot be modified or deleted (2).

Creating a YARA ruleset

To create a new ruleset, click the Add Ruleset button. You can then either enter the YARA rule(s) directly into the text field or upload a file containing the rules. After that, provide a name for the ruleset and click "Save" once you are done.

Threatray supports the default YARA syntax, metadata fields and all standard YARA modules. If a ruleset contains syntactically invalid rules, an error will appear when attempting to save the ruleset.


Detection rules

In Threatray, a verdict on an analysis—or parts of it (e.g., process, memory region, or submitted file)—is influenced by various detection technologies. This is explained in more detail here. The verdict consists of two components: detection (malicious, suspicious) and identification (malware family label). Both of these components can be influenced using private YARA rules by adding specific metadata fields to the rule.

The following metadata fields can be added to the meta section of a YARA rule:

  • threatray_family = <label> (Optional): Influences the identification component of the verdict by assigning a malware family label. When this field is set, the detection verdict is automatically set to "malicious." However, this default behavior can be overridden with the threatray_verdict field.
  • threatray_verdict = <suspicious|malicious> (Optional): Influences the detection part of the verdict, with allowed values being "suspicious" or "malicious."

These fields can be used independently of each other (see the example section). If neither field is specified, the rule is considered an intelligence rule and will not influence the verdict.

For instance, the following rule will produce a verdict with a malicious detection and an identification with the malware family label "CobaltStrike":

rule CobaltStrike_Resources_Artifact32_and_Resources_Dropper_v1_49_to_v3_14
{
  meta:
    description = "Cobalt Strike's resources/artifact32{.exe,.dll,big.exe,big.dll} and resources/dropper.exe signature for versions 1.49 to 3.14"
    hash =  "40fc605a8b95bbd79a3bd7d9af73fbeebe3fada577c99e7a111f6168f6a0d37a"
    author = "[email protected]"
    reference = "https://cloud.google.com/blog/products/identity-security/making-cobalt-strike-harder-for-threat-actors-to-abuse"
    date = "2022-11-18"
    threatray_family = "CobaltStrike"

  strings:
    // Decoder function for the embedded payload
    $payloadDecoder = { 8B [2] 89 ?? 03 [2] 8B [2] 03 [2] 0F B6 18 8B [2] 89 ?? C1 ?? 1F C1 ?? 1E 01 ?? 83 ?? 03 29 ?? 03 [2] 0F B6 00 31 ?? 88 ?? 8B [2] 89 ?? 03 [2] 8B [2] 03 [2] 0F B6 12 }

  condition:
    any of them
}

In the resulting analysis, the YARA rule name will appear in the verdict details section (1), while the malware family label will be used for the identification part in the verdict (2).

Note that the threatray_family and threatray_verdict fields can be added to individual rules only, not to entire rulesets.

Intelligence rules

If both the threatray_family and threatray_verdict fields are omitted, the YARA rule is treated as an intelligence rule and does not influence the verdict. Instead, these rules appear in the Intelligence section of an analysis or parts of it (process, memory region, submitted file) (1).

For example, the following rule does not include either field, making it an intelligence rule:

rule HKTL_NET_NAME_RunasCs {
    meta:
        description = "Detects .NET red/black-team tools via name"
        reference = "https://github.com/antonioCoco/RunasCs"
        license = "Detection Rule License 1.1 https://github.com/Neo23x0/signature-base/blob/master/LICENSE"
        author = "Arnim Rupp"
        date = "2021-01-22"
        id = "c5fc5b01-1d30-5af5-be99-e629cb23295b"
    strings:
        $name = "RunasCs" ascii wide
        $compile = "AssemblyTitle" ascii wide
    condition:
        (uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550) and all of them
}

In the resulting analysis, the matching YARA rule name will appear in the intelligence section (1).

Note that all included community rules are intelligence rules.

Examples

Here are a few examples demonstrating how to use the threatray_family and threatray_verdict fields in YARA rules:

Family with suspicious verdict

The rule

import "pe"

rule SUSP_OBF_NET_Reactor_Native_Stub_Jan24 {
    meta:
        description = "Detects native packer stub for version 4.5-4.7 of .NET Reactor. A pirated copy of version 4.5 of this commercial obfuscation solution is used by various malware families like BlackBit, RedLine, AgentTesla etc."
        author = "Jonathan Peters"
        date = "2024-01-05"
        reference = "https://notes.netbytesec.com/2023/08/understand-ransomware-ttps-blackbit.html"
        hash = "6e8a7adf680bede7b8429a18815c232004057607fdfbf0f4b0fb1deba71c5df7"
        score = 70
        threatray_family = ".NET Reactor"
        threatray_verdict = "suspicious"
    strings:
        $op = {C6 44 24 18 E0 C6 44 24 19 3B C6 44 24 1A 8D C6 44 24 1B 2A C6 44 24 1C A2 C6 44 24 1D 2A C6 44 24 1E 2A C6 44 24 1F 41 C6 44 24 20 D3 C6 44 24 21 20 C6 44 24 22 64 C6 44 24 23 06 C6 44 24 24 8A C6 44 24 25 F7 C6 44 24 26 3D C6 44 24 27 9D C6 44 24 28 D9 C6 44 24 29 EE C6 44 24 2A 15 C6 44 24 2B 68 C6 44 24 2C F4 C6 44 24 2D 76 C6 44 24 2E B9 C6 44 24 2F 34 C6 44 24 30 BF C6 44 24 31 1E C6 44 24 32 E7 C6 44 24 33 78 C6 44 24 34 98 C6 44 24 35 E9 C6 44 24 36 6F C6 44 24 37 B4}
    condition:
        for any i in (0..pe.number_of_resources-1) : (pe.resources[i].name_string == "_\x00_\x00") and $op
}

The resulting analysis


Malicious verdict only

The rule

rule Themida
{
    meta:
        author = "kevoreilly"
        description = "Themida detonation shim"
        cape_options = "unhook-apis=NtSetInformationThread,force-sleepskip=0"
        packed = "6337ff4cf413f56cc6c9a8e67f24b8d7f94f620eae06ac9f0b113b5ba82ea176"
        threatray_verdict = "malicious"
    strings:
        $code = {FC 31 C9 49 89 CA 31 C0 31 DB AC 30 C8 88 E9 88 D5 88 F2 B6 08 66 D1 EB 66 D1 D8 73 09}
    condition:
        uint16(0) == 0x5A4D and all of them
}

The resulting analysis

Suspicious verdict only

The rule

rule Maldoc_RTF {
    meta:
        description = "Detects RTF documents with non-standard version and embeding one of the object mostly observed in exploit documents."
        author = "ditekSHen"
        threatray_verdict = "suspicious"
  strings:
        // Embedded Objects
        $obj1 = "\\objhtml" ascii
        $obj2 = "\\objdata" ascii
        $obj3 = "\\objupdate" ascii
        $obj4 = "\\objemb" ascii
        $obj5 = "\\objautlink" ascii
        $obj6 = "\\objlink" ascii
    condition:
        uint32(0) == 0x74725c7b and ((not uint8(4) == 0x66 or not uint8(5) == 0x31 or not uint8(6) == 0x5c) and 1 of ($obj*))
}

The resulting analysis

Intelligence only

The rule

rule HKTL_NET_NAME_RunasCs {
    meta:
        description = "Detects .NET red/black-team tools via name"
        reference = "https://github.com/antonioCoco/RunasCs"
        license = "Detection Rule License 1.1 https://github.com/Neo23x0/signature-base/blob/master/LICENSE"
        author = "Arnim Rupp"
        date = "2021-01-22"
        id = "c5fc5b01-1d30-5af5-be99-e629cb23295b"
    strings:
        $name = "RunasCs" ascii wide
        $compile = "AssemblyTitle" ascii wide
    condition:
        (uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550) and all of them
}

The resulting analysis

Editing a YARA ruleset

Once a ruleset is created, it can be edited by clicking on its name in the ruleset list view (1).

Both the ruleset content and its name can be modified. However, any changes to the ruleset content will only apply to new submissions—analyses performed with a previous version of the ruleset will not be updated retroactively.

Deleting a YARA ruleset

To delete a ruleset, simply click the delete button in the ruleset list view.

When a ruleset is deleted, any matches from that ruleset will also be removed from past analyses.

Updated 1 day ago