================================================================================
  YARA RULE WRITING CHALLENGES — CTF Blue Team Lesson 03
  Malware Detection & Classification
================================================================================
  SAFETY NOTE: This file contains simulated malware artifacts for training
  purposes only. No actual malicious code is included. All hex bytes, strings,
  and hashes are fabricated.
================================================================================


****************************************************************************
  CHALLENGE 1: Write a YARA Rule from Raw Artifacts
****************************************************************************

You have received a suspicious PE file from your SOC. Below are the raw
artifacts extracted during initial triage. Write a YARA rule to detect
this specific sample and close variants.

--- SAMPLE METADATA ---

Filename:       invoice_march2026.exe
SHA256:         aa11bb22cc33dd44ee55ff66aa11bb22cc33dd44ee55ff66aa11bb22cc33dd44
File Size:      294,912 bytes
File Type:      PE32 executable (GUI), Intel 80386
Compilation:    2026-03-28 03:14:22 UTC
Entropy:        7.18 (HIGH)
Packer:         UPX modified (non-standard stub)

--- EXTRACTED STRINGS ---

String 1:  "inv_loader_v2.4"
String 2:  "AppData\\Roaming\\Microsoft\\Office\\recent.dat"
String 3:  "http://dl.invoice-processor.example.com/stage2"
String 4:  "HKCU\\Software\\Microsoft\\Office\\16.0\\Common\\Startup"
String 5:  "Global\\InvoiceProcessorMtx"
String 6:  "Content-Type: multipart/form-data; boundary=----InvBoundary"

--- HEX BYTE PATTERNS ---

Pattern at offset 0x00001A40 (shellcode entry):
  { 55 8B EC 83 EC 20 C7 45 E0 68 74 74 70 C7 45 E4 3A 2F 2F 64 }

Pattern at offset 0x00002F10 (XOR decryption loop):
  { 8A 04 0E 34 5A 88 04 0E 41 3B C8 7C F4 }

Pattern at offset 0x00004200 (anti-debug check):
  { 64 A1 30 00 00 00 8B 40 02 0F B6 C0 85 C0 75 ?? }

--- YOUR TASK ---

Write a YARA rule named "Detect_InvoiceLoader" that:
  1. Checks for MZ header (PE file)
  2. Limits file size to under 500KB
  3. Includes at least 3 of the extracted strings
  4. Includes at least 1 hex pattern
  5. Uses appropriate string modifiers (ascii, wide, nocase)
  6. Has a reasonable condition that balances detection vs false positives
  7. Includes complete meta section (author, description, date, severity)

HINT: Think about which strings are most unique to this sample (unlikely
to appear in legitimate software) vs which are generic. Build your
condition around the unique indicators.


****************************************************************************
  CHALLENGE 2: Write a Behavioral Detection Rule
****************************************************************************

Your threat intelligence team has identified a new attack technique used
by the threat group "PHANTOM BEAR." They don't have a specific sample,
but they have documented the behavioral pattern from multiple incident
reports. Write a YARA rule to detect any malware exhibiting this behavior.

--- BEHAVIORAL PROFILE (from 7 incident reports) ---

Technique:  Fileless persistence via WMI Event Subscription

Observed Indicators (present in dropper scripts and loader binaries):
  - References to WMI event subscription classes:
    * "__EventFilter"
    * "CommandLineEventConsumer"  OR  "ActiveScriptEventConsumer"
    * "__FilterToConsumerBinding"
  - PowerShell WMI commands:
    * "Set-WmiInstance"
    * "Get-WmiObject"
    * "[wmiclass]"
  - Common namespace reference:
    * "root\\subscription"  OR  "root/subscription"
  - Execution triggers (at least one):
    * "__InstanceModificationEvent"
    * "Win32_LocalTime"
    * "Win32_ProcessStartTrace"
  - Typically contains one or more of these evasion strings:
    * "-WindowStyle Hidden"
    * "-ExecutionPolicy Bypass"
    * "-EncodedCommand"
    * "FromBase64String"
    * "Invoke-Expression"  OR  "IEX"

--- YOUR TASK ---

Write a YARA rule named "Detect_WMI_Persistence" that:
  1. Detects files (scripts, binaries, documents) containing WMI
     persistence indicators
  2. Requires the WMI subscription triad: EventFilter + Consumer + Binding
  3. Requires at least one execution trigger
  4. Optionally boosts confidence if evasion strings are present
  5. Works across file types (not just PE files — no MZ header check)
  6. Keeps false positive rate low (WMI terms appear in legitimate admin tools)

HINT: The key to reducing false positives is requiring the COMBINATION of
WMI subscription classes with PowerShell execution. Legitimate admin tools
reference WMI classes but rarely combine them with hidden execution and
base64 encoding in the same file.


****************************************************************************
  CHALLENGE 3: Write a Generic Family Detection Rule
****************************************************************************

Your malware zoo contains 3 samples from the same family (dubbed
"STEELCLAW" by your team). These samples were collected over 6 months
and show evolution, but share common DNA. Write ONE rule to detect all
three — and hopefully future variants.

--- SAMPLE A (earliest, collected 2025-10-15) ---

SHA256:     aa00aa00bb11bb11cc22cc22dd33dd33ee44ee44ff55ff55aa66aa66bb77bb77
Size:       389,120 bytes
Type:       PE32 executable

Unique strings:
  "STEELCLAW_v1.0_release"
  "http://steelclaw-c2-primary.example.com/api/v1/register"
  "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1)"
  "%TEMP%\\scw_payload_1.dll"

Shared strings (also in B and C):
  "SCW_MUTEX_"
  "\\AppData\\Local\\Microsoft\\CLR_v4.0\\"
  "Content-Type: application/octet-stream"
  "/api/heartbeat"
  "AES-256-CBC"
  "X-Request-ID: SCW-"
  "ProgramData\\Microsoft\\Crypto\\RSA\\"

--- SAMPLE B (collected 2026-01-22) ---

SHA256:     bb00bb00cc11cc11dd22dd22ee33ee33ff44ff44aa55aa55bb66bb66cc77cc77
Size:       412,672 bytes
Type:       PE32+ executable (x86-64)

Unique strings:
  "STEELCLAW_v2.1_hotfix"
  "http://cdn-update-service.example.com/api/v2/register"
  "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
  "%TEMP%\\scw_stage2.dll"

Shared strings (also in A and C):
  "SCW_MUTEX_"
  "\\AppData\\Local\\Microsoft\\CLR_v4.0\\"
  "Content-Type: application/octet-stream"
  "/api/heartbeat"
  "AES-256-CBC"
  "X-Request-ID: SCW-"
  "ProgramData\\Microsoft\\Crypto\\RSA\\"

--- SAMPLE C (most recent, collected 2026-04-03) ---

SHA256:     cc00cc00dd11dd11ee22ee22ff33ff33aa44aa44bb55bb55cc66cc66dd77dd77
Size:       528,384 bytes
Type:       PE32+ executable (x86-64)

Unique strings:
  "STEELCLAW_v3.0_major"
  "http://fast-telemetry-hub.example.com/api/v3/register"
  "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101"
  "%TEMP%\\scw_implant.dll"

Shared strings (also in A and B):
  "SCW_MUTEX_"
  "\\AppData\\Local\\Microsoft\\CLR_v4.0\\"
  "Content-Type: application/octet-stream"
  "/api/heartbeat"
  "AES-256-CBC"
  "X-Request-ID: SCW-"
  "ProgramData\\Microsoft\\Crypto\\RSA\\"

--- COMMON HEX PATTERN (present in all 3 samples) ---

  XOR decryption routine (at varying offsets):
  { 8B 55 ?? 8B 4D ?? 0F B6 04 0A 33 45 ?? 88 04 0A 42 3B 55 ?? 72 F0 }

  Configuration header magic bytes (always at offset 0x00 of encrypted config):
  { 53 43 57 2D 43 46 47 2D }
  NOTE: This is "SCW-CFG-" in ASCII

--- YOUR TASK ---

Write a YARA rule named "Detect_STEELCLAW_Family" that:
  1. Detects all 3 known samples (A, B, and C)
  2. Has a reasonable chance of detecting future STEELCLAW variants
  3. Uses the SHARED strings (not version-specific strings)
  4. Includes the common hex patterns
  5. Uses wildcard/regex where the family shows variation
     (e.g., version strings like "STEELCLAW_v?.?_*")
  6. Checks for PE file format
  7. Has well-documented meta section with references to all 3 sample hashes

HINT: The strongest family indicators are:
  - The "SCW-CFG-" magic bytes (unique to this family)
  - The "SCW_MUTEX_" prefix
  - The "X-Request-ID: SCW-" custom HTTP header
  - The XOR decryption loop hex pattern
  Build your condition so that matching the config magic bytes + mutex is
  sufficient, OR matching 4+ of the shared strings is sufficient. This
  catches both exact matches and variants that may change some strings.


================================================================================
  SCORING RUBRIC (for self-assessment)
================================================================================

For each challenge, check your rule against these criteria:

  [ ] Rule compiles without errors (test with: yara -C your_rule.yar)
  [ ] meta section is complete (author, description, date, severity/threat_level)
  [ ] Strings use appropriate modifiers (ascii, wide, nocase, fullword)
  [ ] Condition logic is sound (not too broad, not too narrow)
  [ ] Rule would not match common legitimate software (low false positive rate)
  [ ] Rule accounts for minor variations in the malware (resilient to change)
  [ ] Hex patterns use wildcards (??) where byte values may vary between samples
  [ ] Comments explain the reasoning behind key condition choices

BONUS: For Challenge 3, test your rule's resilience by imagining a
hypothetical STEELCLAW v4.0 that changes its C2 domain, user-agent, and
temp file names — but keeps the same encryption routine and config format.
Would your rule still detect it?

================================================================================