Malware › Module 5 › Lesson 2
Rule Anatomy
YARA rule anatomy — rule, meta, strings, condition — write literacy rules from $MAL_LAB strings, not weapon evasion.
Visual · mal_rule_anatomy
YARA rule anatomy literacy. $MAL_LAB only. Original Cyberlium.
Opening
Every YARA rule has a name, metadata, strings, and a condition — clarity reduces SOC pain.
Basic structure: rule Name { meta: strings: $a = "text" condition: any of them }. Conditions combine string matches with filesize, uint16(0) magic bytes, and boolean logic. Good rules cite sample sha256 in meta and avoid overly broad strings like 'http'. Cyberlium teaches anatomy so you read and draft defender rules on $MAL_LAB — not minimal 'FUD' rules from offensive forums. Next: False Positives.
1. Rule block components
rule: identifier (no spaces). meta: description, author, date, reference_sample_hash. strings: text, hex, regex ($a, $b). condition: boolean expression selecting matches.
Example literacy: match unique ransom note string AND MZ header — not 'any file containing the'.
Command guide
Try these commands — Rule block components
═══ LINUX / macOS / WINDOWS (YARA Analysis) ═══
Create a sample detection rule for suspicious downloader artifacts
Command — copy this
cat << 'EOF' > detect_suspicious.yar
rule Suspicious_Downloader_Artifact {
meta:
description = "Detects PowerShell web download patterns and executable headers"
author = "Cyberlium SOC Analyst"
date = "2026"
strings:
$mz = { 4D 5A }
$s1 = "DownloadString" nocase
$s2 = "WebClient" nocase
$s3 = "powershell -enc" nocase
condition:
$mz at 0 and (any of ($s*))
}
EOFCompile and validate the YARA rule against a file or folder
Command — copy this
yara -w detect_suspicious.yar /path/to/sample.bin
Primary tools to practice this lesson: yara. Reference sites: YARA command line (https://yara.readthedocs.io/en/stable/commandline.html); EICAR (https://www.eicar.org/). Run every command in the box — install first, then the usage lines — only on YOUR lab / program scope.
2. String and hex patterns
Text strings from Module 4 strings output — escape quotes. Hex patterns for non-printable opcodes — use sparingly with context. Regex powerful but slower — test performance on $MAL_LAB corpus.
Document which string came from which sample sha256 in meta for reproducibility.
3. Conditions and specificity
Tight conditions reduce false positives: filesize limits, multiple string matches, PE module at entry. Loose conditions flood SOC — professional analysts iterate on $MAL_LAB benign set.
Ship: annotated rule skeleton with meta, two strings, one condition — no live offensive evasion. Next: False Positives.
4. What you ship: YARA rule skeleton template
Annotated skeleton: meta with hash, two strings, specific condition. $MAL_LAB test note. chmod 600.
5. What you record before the next lesson
Date. YARA skeleton. $MAL_LAB named. File t22-m05-l02-rule-anatomy.txt chmod 600.
6. Wrong vs right: live malware on daily driver vs sandbox
Worked failure — same MSF word, opposite target. Right never needs a café Wi-Fi or classmate laptop.
Wrong
condition: true on all files. Copy FUD evasion rule from forum.
Right
Write YARA rule skeleton template. Next: False Positives.
Mission: draft rule skeleton
1) Label meta, strings, condition sections. 2) Add reference_sample_hash meta field. 3) Write specific condition example. 4) chmod 600.
Stuck? Ask Cyberlium AI Mentor
Specific conditions beat clever but noisy broad rules.
Knowledge Check
APPLY: YARA rule anatomy includes:
Multiple choice
Knowledge Check
APPLY: True or False: meta should reference sample sha256 used for validation.
True or False
Knowledge Check
APPLY: Loose condition like 'any of them' on common string 'http' likely causes:
Multiple choice