Select a result to preview

Yara

##cybersecurity/forensics/tools

YARA is a tool built to identify and classify malware by searching for unique patterns, the digital fingerprints left behind by attackers. Imagine it as a detective’s notebook for cyber defenders: instead of dusting for prints, YARA scans code, files, and memory for subtle traces that reveal a threat’s identity.

In what situations might defenders rely on this tool?

Values

YARA brings several key advantages:

Rules

A YARA rule is built from several key elements:

Here’s how it looks in practice:

rule TBFC_KingMalhare_Trace
{
    meta:
        author = "Defender of SOC-mas"
        description = "Detects traces of King Malhare’s malware"
        date = "2025-10-10"
    strings:
        $s1 = "rundll32.exe" fullword ascii
        $s2 = "msvcrt.dll" fullword wide
        $url1 = /http:\/\/.*malhare.*/ nocase
    condition:
        any of them
}

Strings
As mentioned earlier, strings are the clues that YARA searches for when scanning files, memory, or other data sources.
They represent the signatures of malicious activity in fragments of text, bytes, or patterns that can reveal the presence of King Malhare's code. In YARA, there are three main types of strings, each with its own purpose.

**Text strings
**Text strings are the simplest and most common type used in YARA rules. They represent words or short text fragments that might appear in a file, script, or memory. By default, YARA treats text strings as ASCII and case-sensitive, but you can modify how they behave using special modifiers - small keywords added after the string definition. The example below shows a simple rule that searches for the word Christmas inside a file:

rule TBFC_KingMalhare_Trace
{
    strings:
        $TBFC_string = "Christmas"

    condition:
        $TBFC_string 
}

Sometimes, attackers like King Malhare try to hide their code by changing how text looks inside a file - using encoding, case tricks, or even encryption. YARA helps defenders counter these obfuscation methods with a few powerful modifiers that extend the capabilities of text strings:

strings:
    $xmas = "Christmas" nocase

strings:
    $xmas = "Christmas" wide ascii

strings:
    $hidden = "Malhare" xor

strings:
    $b64 = "SOC-mas" base64

Each of these modifiers makes your rule smarter and more resilient, ensuring that even when King Malhare disguises his code, the defenders of TBFC can still uncover the truth.

**Hexadecimal strings
**Sometimes, King Malhare's code doesn't leave readable words behind; instead, it hides in raw bytes deep inside executables or memory. That's when hexadecimal strings come to the rescue. Hex strings allow YARA to search for specific byte patterns, written in hexadecimal notation. This is useful when defenders need to detect malware fragments like file headers, shellcode, or binary signatures that can't be represented as plain text.

rule TBFC_Malhare_HexDetect
{
    strings:
        $mz = { 4D 5A 90 00 }   // MZ header of a Windows executable
        $hex_string = { E3 41 ?? C8 G? VB }

    condition:
        $mz and $hex_string
}

**
Regular expression strings
**Not all traces of King Malhare's malware follow a fixed pattern. Sometimes, his code mutates, small changes in file names, URLs, or commands make it harder to detect using plain text or hex strings. That's where regular expressions come in. Regex allows defenders to write flexible search patterns that can match multiple variations of the same malicious string.
It's especially useful for spotting URLs, encoded commands, or filenames that share a structure but differ slightly each time.

rule TBFC_Malhare_RegexDetect
{
    strings:
        $url = /http:\/\/.*malhare.*/ nocase
        $cmd = /powershell.*-enc\s+[A-Za-z0-9+/=]+/ nocase

    condition:
        $url and $cmd
}

Regex strings are powerful but should be used carefully; they can match a wide range of data and may slow down scans if written too broadly.

Conditions

Now that the defenders of TBFC know how to describe what to look for using strings, it's time to learn when YARA should decide that a threat has been found. That logic lives inside the condition section, the heart of every YARA rule. The condition tells YARA when the rule should trigger based on the results of all the string checks. Think of it as the final decision point, the moment when the system confirms: "Yes, this looks like King Malhare's code." Let's look at a few basic examples defenders use in their daily missions.

Match a single string
The simplest condition, the rule triggers if one specific string is found. For example, the variable xmas.

condition:
    $xmas

**Match any string
**When multiple strings are defined, the rule can be configured to trigger as soon as any one of them is found:

condition:
    any of them

This approach is useful for detecting early signs of compromise; even a single matching clue can be enough to raise attention.

**Match all strings
**To make the rule stricter, you can require that all defined strings appear together:

condition:
    all of them

This approach reduces false positives; YARA will only flag a file if every indicator matches.

**Combine logic using: and, or, not
**Defenders often need more control over how rules behave. Logical operators let you combine multiple checks into one condition, just like building a small defensive strategy.

condition:
    ($s1 or $s2) and not $benign

This means the rule will trigger if either $s1 or $s2 is found, but not $benign. In other words: detect suspicious code, but ignore harmless system files.

**Use comparisons like: filesize, entrypoint, or hash
**YARA can also check file properties, not just contents. For example, you can detect files that are unusually small or large, a common trick used by King Malhare to disguise his payloads.

condition:
    any of them and (filesize < 700KB)

Here, the rule will trigger only when one of the strings matches and the file size is smaller than 700KB.
We've now reviewed the main examples of Conditions, and it's time to move on to the practical use cases where these rules come to life.