YARA Hands on Labs

Choose a lab

Choose the Interactive Lab for a short, guided browser exercise. Try the Full Lab after reviewing the tool guide and preparing an isolated, authorised environment.

How to use these labs

Start with the browser based route to practise the workflow and evidence decisions without touching a real system. Use the Full Lab only in an isolated, authorised environment, and compare its outcome with the corresponding tool guide.

Interactive Lab

Browser based

YARA Interactive Lab

Expand labOpen in new tab

✓ No installation

Practise a guided YARA workflow in a safe browser simulation with immediate feedback.

Y

Case SUSA-014: suspicious activityWrite or apply a focused rule to identify a known known training sample.

Task 1 of 4

Safe simulationThese illustrative records practise decisions relevant to YARA. The layout and output are not a replica of the product. No tool runs and no evidence is changed.

1. 1Source
2. 2Configure
3. 3Review
4. 4Explain

YARA · Static analysis workspaceSUSA training case / read only simulation

Task 01 · Select evidence

Choose the authorised, traceable source

Select the source that matches the case and has a recorded origin.

training-sample.bin · inert · SHA-256 recordedUnknown executable opened on SUSASample renamed with no original hash

Select a source to continue.

Full Lab

Self hosted

YARA Full Lab

Windows training VM required

Objective

Test a content rule before trusting a match

Case SUSA-YARA-01: which of two training files contains both IEX and DownloadString, regardless of letter case? Use YARA, a tool that tests file content against rules, to answer this question. Save a rule, two scan records and a short finding that explains what a match can and cannot prove.

1. 01Prepare two samplesCreate harmless text and a rule.Prepare ›
2. 02Test the ruleCompare a match with a control.Test ›
3. 03Explain your findingSave evidence and close the lab.Report ›

Prepare your resources

Environment

An authorised Windows training VM, PowerShell, a text editor and permission to create C:\SUSA-YARA-01. A VM is a virtual computer; a snapshot is its saved recovery point. Take a snapshot before starting. Administrator access is not needed to scan these readable files.

Tool and evidence

Download the Windows build matching your VM from the official YARA releases. Extract it to C:\Tools\YARA. Use classic YARA for this exercise. Keep a case folder outside the VM's snapshot storage for the final evidence copy.

Before you act: use only the text samples below. Do not execute sample content or download a payload. Finish tool downloads before disconnecting the VM's network. The existing illustrated guide retains the download/extraction screenshots and original example; this lab uses inert .txt files instead of running a script.

The positive sample contains both strings (pieces of text). The negative control deliberately contains only one; it tests whether the rule requires both. Neither file is malware. This is static analysis: examining content without running it.

Mission 01: Prepare

Prepare the environment

Your win: two known inputs and one readable rule, with recorded file fingerprints.

1. Record your context. Note the VM name, snapshot, Windows version, date/time and time zone. Record the download URL and archive filename; verify published integrity information if supplied.
2. Check the executable. In PowerShell run & 'C:\Tools\YARA\yara64.exe' --version. If your extracted executable has a different name or location, use its actual path in all commands below. Save the version output in your case notes.
3. Create the controlled inputs. Open the procedure below. It stops if the case folder already exists, so previous evidence is not overwritten.

01Create the samples and rulePowerShell in the VM

Run this block once. The quoted sample text is written to files; it is not executed. ASCII encoding keeps the sample bytes predictable.

$labPath = 'C:\SUSA-YARA-01'
if (Test-Path -LiteralPath $labPath) { throw 'Case folder exists. Preserve it before starting a fresh run.' }
New-Item -ItemType Directory -Path $labPath | Out-Null
Set-Location -LiteralPath $labPath
Set-Content -LiteralPath '.\positive.txt' -Encoding ascii -Value 'Training text only: IEX and DownloadString'
Set-Content -LiteralPath '.\negative.txt' -Encoding ascii -Value 'Training text only: IEX'
@'
rule Suspicious_PowerShell_Download
{
    strings:
        $iex = "IEX" nocase
        $download = "DownloadString" nocase
    condition:
        all of them
}
'@ | Set-Content -LiteralPath '.\powershell.yar' -Encoding ascii
Get-FileHash -LiteralPath '.\positive.txt', '.\negative.txt', '.\powershell.yar' -Algorithm SHA256 |
    Export-Csv -LiteralPath '.\input-hashes.csv' -NoTypeInformation
Get-Content -LiteralPath '.\positive.txt', '.\negative.txt', '.\powershell.yar'

nocase ignores letter case; all of them requires both defined strings. SHA-256 is a fingerprint of file bytes; keep these hashes to identify the exact samples and rule used.

Expected resultThe folder contains positive.txt, negative.txt, powershell.yar and input-hashes.csv. The displayed rule requires both strings. Predict a match only for positive.txt.

Executable or file creation failed?

• Executable not found: inspect the extracted folder and use the full path to the executable, not the ZIP archive. PowerShell's & runs a quoted executable path.
• Access denied: use an authorised writable training location and update the paths consistently; do not disable security controls to continue.
• Case folder exists: retain it as an earlier run. Use a new case folder or restore the clean snapshot after exporting that run's evidence.

Do not continue until the version command works and all three input files can be read.

Save before continuing I saved the VM/snapshot, time context, download source and YARA version. I saved both samples, the rule, input hashes and my prediction.

Stopping point: save the case folder and notes outside snapshot storage, then shut down the VM. Resume here by checking the files and tool version.

Continue to Mission 2 ›

Mission 02: Test

Complete the focused task

Your win: one explained match and one checked non match. Scan only these two files; keep rules and logs out of the scan targets.

01Run and record both scansPowerShell in the VM

1. Return to your case folder. Run the commands below, using your recorded executable path. -s asks YARA to print the matching strings. Redirection saves normal output and errors separately.

   Set-Location -LiteralPath 'C:\SUSA-YARA-01'
   $yaraExe = 'C:\Tools\YARA\yara64.exe'
   Get-Date -Format o | Set-Content -LiteralPath '.\scan-times.txt'
   & $yaraExe -s '.\powershell.yar' '.\positive.txt' 1> '.\positive-output.txt' 2> '.\positive-errors.txt'
   $positiveExit = $LASTEXITCODE
   & $yaraExe -s '.\powershell.yar' '.\negative.txt' 1> '.\negative-output.txt' 2> '.\negative-errors.txt'
   $negativeExit = $LASTEXITCODE
   Get-Date -Format o | Add-Content -LiteralPath '.\scan-times.txt'
   "positive exit: $positiveExit", "negative exit: $negativeExit" |
       Set-Content -LiteralPath '.\scan-status.txt'
   Get-Content -LiteralPath '.\positive-output.txt', '.\positive-errors.txt', '.\negative-output.txt', '.\negative-errors.txt', '.\scan-status.txt'
   

2. Compare with your prediction. The positive output should identify Suspicious_PowerShell_Download, the target and both strings. String output includes byte offsets (positions within the file). The negative output should contain no matching rule line. Do not assume that silence means a successful scan: review both error files, saved status and the exact paths.

3. Keep the run intact. Save the commands in your notes and keep every output/error file, even empty ones. Resolve errors before treating the negative result as a control. For a retry, preserve the earlier logs first so the same output names do not overwrite them.

Expected result, not a supplied test resultThe positive sample satisfies the two string rule. The negative sample does not. Your own saved logs must establish what actually happened in your VM.

Missing match, extra match or an error?

Symptom	Check before retrying
Rule syntax error	Compare braces, quotes, dollar signs and condition with the saved rule. Check the file did not become powershell.yar.txt.
Positive sample does not match	Read its content, check the target path and preserve errors. Recreate ASCII input only in a fresh run; UTF-16 text has different bytes.
Negative sample matches	Check it contains only IEX, and that the rule still says all of them. Confirm you did not scan a folder containing the rule itself.
Cannot open file	Check current directory, quoted paths and read permissions. An unreadable file is not a valid negative result.

Preserve unexpected results and explain the correction; do not tick completion just to match the prediction.

Think before moving on: why would scanning powershell.yar itself be misleading? It contains the same strings you are looking for; a content match alone says nothing about intent.

Save before continuing I saved both scan commands, outputs, errors, times and status records. I compared both results with my prediction and resolved or documented any failure.

Stopping point: copy the complete run and notes outside the VM. On return, review the saved logs; you do not need to rerun a successful scan.

Continue to Mission 3 ›

Mission 03: Report

Review and report

Your win: another analyst can identify your inputs, reproduce the comparison and understand its limits.

Interpret the evidenceWhat does the positive match support?

Both rule strings occur in the scanned fileThe file ran and downloaded malware

Choose the conclusion supported by your evidence.

1. Write the finding. Answer the case question using your actual outputs. Explain why the negative control mattered. A non match means this rule was not satisfied in that scanned input; it does not certify that a file is safe.
2. Name a next source. To investigate execution, you could examine available process creation or PowerShell logs from the relevant host and time. Explain what you would seek and whether those logs were collected; do not claim they exist in this exercise.
3. Package the evidence. Save the note below, tool version, source files, hashes and all run records together outside snapshot storage. Recalculate SHA-256 for the copied samples and rule and compare them with input-hashes.csv.

Case note template

Case: SUSA-YARA-01
Question: Which training file contains both rule strings?
VM, snapshot, Windows/YARA versions, download source:
Times and time zone; executable and case-folder paths:
Sample and rule SHA-256 values:
Exact commands and saved output/error/status paths:
Prediction; positive result; negative control result:
Unexpected results, retries and unresolved limitations:
Finding and what it does not prove:
Next evidence source and why:
Evidence copy location and hash comparison:
Cleanup and recovery checks:

Clean up

1. Verify the evidence copy first. Open the copied note and logs outside the VM; confirm the input hashes agree. Do not roll back until the evidence copy is readable.
2. Restore the baseline. Shut down the disposable VM and restore the snapshot recorded in Mission 1. This removes the training changes; it can also erase any work kept only inside that VM.
3. Check recovery. Start the VM, confirm it is at the expected baseline, then shut it down if finished. Retain the external case folder. No network service or background scan was started by this lab.

Evidence copy missing or hashes differ?

Stop before restoring the snapshot. Check which files were copied and whether any input or rule was edited after hashing. Keep both versions and explain the difference. Recover a readable evidence copy before marking cleanup complete.

Expected resultA reviewable case folder supports your content based finding, and your disposable VM is back at its recorded baseline.

Confirm your case record I saved a bounded finding, the control comparison, limitations and a proposed next evidence source. I verified the external evidence copy and hashes, restored the baseline and recorded recovery checks.

Final stopping point: retain the external evidence folder. Your saved checkpoints record your confirmation, not an independent test of the files.

Full Lab evidence checklist

Your finish line: a tested rule and a reviewable finding.

Core completion covers six self reported checkpoints: context, inputs, scans, control, finding and cleanup. Keep the two samples, rule, hashes, scan records and case note. Answering the interpretation question does not complete the real lab.

Optional extension: test a rule limitation

After saving the core evidence, start a separate run in the disposable VM. Copy the positive sample and change only the letter case of the two strings. Predict whether nocase will still match, scan the new file and preserve its hash and output. Then consider a file using different wording: a two string rule cannot detect every script with similar behaviour. Keep this extension separate from core completion and restore the baseline again afterward.

Commands and rule semantics follow the official YARA command line reference and rule writing guide, checked 27 September 2026. Use the installed version's help if options differ. The illustrated overview remains available for the original commands and screenshots.