YARA: Upptäck Skadlig Kod i 12 Steg, 75 Min [2026]

Ransomware-grupper byter kod snabbare än signaturdatabaser hinner uppdateras, men mönstren i binärfilerna ändras sällan lika fort. Det är precis det gapet YARA fyller. Verktyget har funnits sedan 2008 och används fortfarande dagligen av analytiker på VirusTotal, incidenthanteringsteam och hotjägare världen över, för att hitta skadlig kod baserat på textsträngar, binärmönster och struktur i stället för att vänta på en signatur från en antivirusleverantör. I den här guiden bygger vi upp ett komplett skanningsverktyg från grunden: installation, din första regel, ett Python-skript som letar igenom hela filsystem, och ett sätt att automatisera hela processen så den körs varje natt utan att du behöver tänka på det.

Guiden passar dig som redan jobbar med säkerhet men aldrig skrivit en YARA-regel, eller som skrivit några enstaka men vill gå från engångsskript till ett verktyg som faktiskt körs i produktion. Vi går igenom både klassiska YARA 4.5.8 och efterträdaren YARA-X 1.20.0, som VirusTotal själva numera kör i skarp drift när de skannar miljarder filer mot tiotusentals regler. Svenska bolag som Electrolux och Aarsleff hörde till de 156 ransomware-offer som identifierades i Sverige under året, och Dustin-attacken läckte 6,2 terabyte data från en miljon konton. Snabb och träffsäker detektion är inte längre valfritt för den som ansvarar för säkerhet i en svensk organisation.

Till skillnad från många kommersiella detektionsplattformar kostar inget av det vi bygger här en krona i licensavgift. Du behöver ingen molntjänst, ingen prenumeration och ingen leverantörslåsning, bara öppen källkod, ett gäng textfiler med regler och ett Python-skript som binder ihop allt. Det gör upplägget lika användbart för ett enmansteam på ett mindre bolag som för en större säkerhetsavdelning som redan har ett SIEM-system men saknar ett snabbt sätt att leta efter specifika hotfamiljer.

Förutsättningar och verktyg du behöver

Innan du börjar, se till att du har följande på plats. Ingenting här är exotiskt, men versionerna spelar roll eftersom syntaxen mellan YARA och YARA-X skiljer sig något.

• YARA 4.5.8 (senaste stabila utgåvan av den klassiska C-motorn) eller YARA-X 1.20.0 (Rust-omskrivningen från VirusTotal)
• Python 3.11 eller senare, samt pip
• yara-python (Python-bindningar mot YARA-motorn)
• En Linux-, macOS- eller Windows-maskin med minst 2 GB ledigt minne för större skanningar
• Git, för att kunna hämta färdiga regelbibliotek senare i guiden
• Grundläggande kommandoradsvana och lite Python-kunskap (vi förklarar varje rad i skripten)
• Helst en testmapp med några ofarliga exempel-filer att skanna, så du inte kör dina första test mot produktionsdata

Räkna med ungefär 75 minuter för att gå igenom hela guiden och få ett fungerande skanningsverktyg igång, inklusive tid för att testa reglerna mot egna filer.

Vad YARA faktiskt gör, och varför det inte är ersatt av AI ännu

YARA (namnet är ett rekursivt skämt: “Yet Another Ridiculous Acronym”) låter dig beskriva egenskaper hos skadlig kod som textsträngar, hexmönster, filstorlek eller kombinationer av dessa, och sedan matcha filer eller processminne mot den beskrivningen. Skillnaden mot traditionella antivirussignaturer är att en YARA-regel kan beskriva en hel familj av skadlig kod snarare än en enskild fil. Skriver du regeln rätt fångar du varianter som ännu inte finns i någon databas.

Verktyget används i tre huvudsakliga scenarier. Det första är klassisk malware-analys, där en analytiker packar upp ett skadligt prov och skriver en regel för att identifiera samma familj i framtiden. Det andra är threat hunting, där man skannar hela nätverk eller filservrar efter tecken på att en känd hotaktör redan finns i miljön. Det tredje är kontinuerlig övervakning, där nya filer som laddas upp eller skapas automatiskt matchas mot ett regelbibliotek, ungefär som VirusTotals Livehunt-funktion gör mot deras dagliga inflöde av prover.

Fördelen jämfört med rena maskininlärningsmodeller är transparens. En YARA-regel går att läsa, granska och felsöka rad för rad. När en regel ger falska positiva vet du exakt vilken sträng eller vilket villkor som orsakade träffen, och kan justera. Det gör verktyget svårt att ersätta helt, även i en tid där AI-baserad detektion marknadsförs som lösningen på allt.

Projektet underhålls i dag av VirusTotal (som köptes av Google 2012) och den officiella dokumentationen finns tillgänglig på virustotal.github.io/yara. Där hittar du hela språkspecifikationen, inklusive moduler för att läsa PE-headers, ELF-binärer och kryptografiska hashvärden direkt i en regel. Just kombinationen av ett enkelt textformat och djup insyn i filstrukturen är anledningen till att YARA fortfarande används av i stort sett alla stora malware-labb, snarare än att ha ersatts av rena AI-klassificerare som är svårare att förklara och granska efter en incident.

Steg 1: Installera YARA och YARA-X

Börja med att installera den klassiska motorn. På de flesta Linux-distributioner finns YARA i standardförråden, men versionen där kan ligga efter. Vill du ha den senaste 4.5.8 är det enklast att bygga från källkod eller använda ett paketverktyg som Homebrew på macOS.

# macOS med Homebrew
brew install yara

# Ubuntu/Debian (kan ge en äldre version)
sudo apt update && sudo apt install -y yara

# Verifiera installerad version
yara --version

# Installera YARA-X (Rust-baserad efterträdare) via cargo
cargo install yara-x-cli

# Verifiera YARA-X
yr --version

Har du inte Rust och cargo installerat sedan tidigare behöver du hämta det från rustup.rs först. På Windows fungerar samma cargo-kommando i en PowerShell-terminal, förutsatt att Visual Studio Build Tools är installerat. Kör du i en container eller CI-pipeline rekommenderar vi att bygga en egen image med båda verktygen förinstallerade, så slipper du installationstid vid varje körning.

Steg 2: Installera yara-python och sätt upp projektet

För att styra YARA från Python, vilket vi gör i resten av guiden, behöver du yara-python. Skapa en virtuell miljö först så att beroenden inte krockar med andra projekt på maskinen.

mkdir yara-scanner && cd yara-scanner
python3 -m venv venv
source venv/bin/activate   # Windows: venv\Scripts\activate

pip install yara-python

# Skapa mappstruktur för projektet
mkdir regler loggar testfiler
touch regler/forsta_regeln.yar

Notera att paketet heter yara-python på PyPI, inte bara yara, eftersom det namnet redan är upptaget av ett annat bibliotek. Det är ett av de vanligaste nybörjarfelen (mer om det i pitfalls-avsnittet längre ner). När installationen är klar har du en mappstruktur med tre kataloger: en för dina regler, en för loggfiler och en för testfiler du kan skanna utan risk.

Kontrollera alltid att versionen av yara-python matchar din installerade YARA-motor innan du går vidare. Skillnader i major-version mellan C-biblioteket och Python-bindningen är en vanlig källa till kryptiska felmeddelanden längre fram, särskilt i CI-miljöer där paketen installeras separat från olika cachelager.

Steg 3: Förstå anatomin i en YARA-regel

Varje YARA-regel har tre delar: ett namn, en strings-sektion som listar vad du letar efter, och en condition-sektion som beskriver logiken för när regeln ska räknas som en träff. Så här ser den enklaste möjliga strukturen ut:

rule Exempel_Regel
{
    meta:
        author = "Ditt namn"
        description = "Kort beskrivning av vad regeln letar efter"
        date = "2026-09-24"

    strings:
        $text1 = "skadlig_sträng"
        $hex1 = { E2 34 A1 C8 23 FB }

    condition:
        $text1 or $hex1
}

meta-sektionen är valfri men bör alltid fyllas i, den kostar inget vid körning men sparar timmar när du om sex månader försöker minnas varför en regel finns. strings kan innehålla textsträngar, hexmönster eller reguljära uttryck, och du kan blanda flera typer i samma regel. condition är där logiken bor, du kan kombinera flera strängar med and/or, räkna förekomster med #$text1 > 3, eller kontrollera filstorlek och filtyp.

Varje sträng kan också få modifierare som styr exakt hur matchningen sker. nocase ignorerar skiftläge, wide letar efter UTF-16-kodad text (vanligt i Windows-binärer), ascii tvingar fram vanlig enbytes-text, och fullword kräver att strängen inte är en del av ett längre ord, vilket minskar falska positiva rejält när du letar efter korta strängar som lätt förekommer av misstag i legitim kod. En sträng kan dessutom kombinera flera modifierare samtidigt, till exempel $s1 = "cmd.exe" nocase wide ascii, vilket gör att samma regel matchar oavsett kodning eller skiftläge.

Steg 4: Skriv din första regel för att upptäcka skadlig kod

Låt oss skriva en regel som letar efter ett par vanliga tecken på att ett skript försöker ladda ner och köra ytterligare kod, ett beteende som är gemensamt för många droppers och första stadiet av ransomware-kedjor.

rule Misstankt_Nedladdning_Och_Korning
{
    meta:
        author = "Säkerhetsteamet"
        description = "Flaggar skript som laddar ner och kör kod i minnet"
        date = "2026-09-24"
        severity = "medium"

    strings:
        $ps1 = "IEX (New-Object Net.WebClient).DownloadString" nocase
        $ps2 = "Invoke-Expression" nocase
        $enc = "-EncodedCommand" nocase
        $bypass = "-ExecutionPolicy Bypass" nocase

    condition:
        2 of ($ps1, $ps2, $enc, $bypass)
}

Lägg märke till 2 of (...) i villkoret. Det betyder att minst två av de fyra strängarna måste finnas i filen för att den ska räknas som en träff, vilket minskar risken för falska positiva jämfört med att bara leta efter en enda vanlig sträng som Invoke-Expression, vilket förekommer i massor av legitima administrationsskript.

Steg 5: Testa och validera regeln med YARA CLI

Spara regeln som regler/forsta_regeln.yar och kör den mot en mapp med testfiler direkt från kommandoraden innan du bygger något i Python. Det är snabbast sätt att fånga syntaxfel.

yara -r regler/forsta_regeln.yar testfiler/

# Exempel på utdata vid en träff:
# Misstankt_Nedladdning_Och_Korning testfiler/skript_exempel.ps1

# Kör med -s för att se vilka strängar som matchade
yara -s -r regler/forsta_regeln.yar testfiler/
# Misstankt_Nedladdning_Och_Korning testfiler/skript_exempel.ps1
# 0x42:$ps2: Invoke-Expression
# 0x91:$bypass: -ExecutionPolicy Bypass

Får du inget utskrivet alls betyder det att ingen fil matchade, vilket kan bero på att testfilen faktiskt är ren, eller att regeln har ett fel i villkoret. Lägg alltid till minst en fil som du vet borde matcha (till exempel genom att skriva en av strängarna i en tom textfil) så att du kan verifiera att regeln fungerar innan du litar på den.

Steg 6: Bygg en Python-baserad filskanner

Kommandoradsverktyget räcker för enstaka tester, men för att köra kontinuerlig övervakning behöver du ett skript som kan hantera flera regler, logga resultat och köras schemalagt. Här är grunden.

import yara
import os
import json
from datetime import datetime, timezone

REGELMAPP = "regler"
LOGGFIL = "loggar/traffar.jsonl"

def kompilera_regler(regelmapp):
    filer = {}
    for namn in os.listdir(regelmapp):
        if namn.endswith(".yar") or namn.endswith(".yara"):
            filer[namn] = os.path.join(regelmapp, namn)
    return yara.compile(filepaths=filer)

def skanna_fil(regler, filväg):
    try:
        träffar = regler.match(filväg, timeout=30)
        return träffar
    except yara.Error as fel:
        print(f"Kunde inte skanna {filväg}: {fel}")
        return []

def logga_traff(filväg, regel_namn, strängar):
    post = {
        "tidpunkt": datetime.now(timezone.utc).isoformat(),
        "fil": filväg,
        "regel": regel_namn,
        "matchade_strängar": [s.identifier for s in strängar],
    }
    with open(LOGGFIL, "a") as f:
        f.write(json.dumps(post, ensure_ascii=False) + "\n")

if __name__ == "__main__":
    regler = kompilera_regler(REGELMAPP)
    for rot, _, filer in os.walk("testfiler"):
        for namn in filer:
            sökväg = os.path.join(rot, namn)
            träffar = skanna_fil(regler, sökväg)
            for träff in träffar:
                logga_traff(sökväg, träff.rule, träff.strings)
                print(f"TRÄFF: {träff.rule} i {sökväg}")

Skriptet kompilerar alla regler i regelmappen en gång, vilket är betydligt snabbare än att kompilera om vid varje fil, och sparar sedan varje träff som en JSON-rad i loggfilen. Formatet gör det enkelt att senare läsa in loggen i ett SIEM-system eller bara greppa igenom den med jq.

Steg 7: Lägg till ransomware-specifika indikatorer

Generiska nedladdningsregler fångar en bred kategori hot, men ransomware har egna kännetecken värda att leta efter specifikt: lösensedeltexter, filändelser som krypteringsverktyget lägger till, och referenser till Tor-domäner i betalningsinstruktioner.

rule Mojlig_Ransomware_Losensedel
{
    meta:
        description = "Letar efter typiska fraser i ransomware-lösensedlar"
        severity = "high"

    strings:
        $note1 = "your files have been encrypted" nocase
        $note2 = "restore your files" nocase
        $note3 = ".onion" nocase
        $note4 = "bitcoin" nocase
        $ext1 = ".locked"
        $ext2 = ".encrypted"

    condition:
        (2 of ($note1, $note2, $note3, $note4))
        or ($ext1 in (0..filesize) and $ext2 in (0..filesize))
}

Villkoret 0..filesize gör att YARA söker i hela filen oavsett storlek, vilket är viktigt för större dokument eller binärer. Kombinerar du den här regeln med filsystemsövervakning (till exempel genom att köra skannern varje gång ett nytt eller ändrat dokument dyker upp) kan du fånga en pågående krypteringsattack medan den fortfarande sprider sig, inte bara i efterhand.

Steg 8: Skanna hela kataloger rekursivt och logga resultat

Skriptet från steg 6 skannar redan rekursivt via os.walk, men i en verklig miljö vill du sannolikt begränsa vilka filtyper som kontrolleras och hoppa över extremt stora filer för att spara tid. Lägg till dessa förbättringar:

MAX_STORLEK_MB = 200
GILTIGA_ANDELSER = {".exe", ".dll", ".ps1", ".js", ".vbs", ".doc", ".docx", ".pdf", ".zip"}

def ska_skannas(sökväg):
    if os.path.getsize(sökväg) > MAX_STORLEK_MB * 1024 * 1024:
        return False
    _, andelse = os.path.splitext(sökväg)
    return andelse.lower() in GILTIGA_ANDELSER

Lägg in ett anrop till ska_skannas(sökväg) före du skickar filen till skanna_fil() i huvudloopen. På en filserver med hundratusentals filer är det här filtret skillnaden mellan en skanning som tar tio minuter och en som tar hela natten.

Skannar ni nätverksdiskar eller molnbaserade filresurser i stället för lokal disk, tänk på att varje filläsning då går över nätverket, vilket gör I/O snarare än själva YARA-matchningen till den faktiska flaskhalsen. I den situationen ger det ofta större effekt att köra fler parallella skanningsprocesser (se avsnittet om prestanda längre ner) än att försöka optimera reglerna ytterligare, eftersom väntetiden på nätverket ändå dominerar den totala körtiden.

Steg 9: Minska falska positiva och trimma regler

Den vanligaste anledningen till att säkerhetsteam slutar lita på ett detektionsverktyg är att det skriker varg för ofta. Kör dina regler mot en stor mängd kända rena filer (till exempel ett helt Windows-installationsmedia eller din organisations standardarbetsstation) innan du sätter dem i produktion, och räkna träffarna.

# Kör mot ett rent referensbibliotek och räkna träffar per regel
yara -r regler/*.yar /sokvag/till/ren/referens/ | sort | uniq -c | sort -rn

Ger en regel fler än ett fåtal träffar mot kända rena filer behöver den strama åt villkoret, till exempel genom att kräva fler samtidiga strängar, lägga till ett filstorlekvillkor, eller byta ut en generisk sträng mot ett mer unikt hexmönster hämtat direkt ur det skadliga provet. Många analytiker sparar sina regler i en git-branch och kör automatiska tester mot referensbiblioteket vid varje ändring, ungefär som man kör enhetstester för vanlig kod.

Steg 10: Automatisera skanningar med cron

När regelbiblioteket känns stabilt är nästa steg att låta skannern köra automatiskt, till exempel varje natt eller var fjärde timme på kritiska filservrar.

# Redigera crontab
crontab -e

# Kör skannern varje natt klockan 02:30
30 2 * * * cd /home/analytiker/yara-scanner && venv/bin/python skanner.py >> loggar/korning.log 2>&1

# Alternativ: kör var fjärde timme
0 */4 * * * cd /home/analytiker/yara-scanner && venv/bin/python skanner.py >> loggar/korning.log 2>&1

Skicka gärna larm vidare till Slack, e-post eller ett SIEM-system när en träff loggas, i stället för att förlita dig på att någon manuellt läser loggfilen varje morgon. Ett enkelt sätt är att låta skriptet anropa en webhook varje gång logga_traff() körs, så flödar larmen in i samma kanal som ni redan bevakar för annan säkerhetsinformation.

Steg 11: Koppla ihop med VirusTotal Livehunt och hotunderrättelser

Har ni en betald VirusTotal-prenumeration kan ni gå ett steg längre och köra samma regler mot Livehunt, en tjänst som notifierar er så fort en fil som matchar era regler laddas upp av någon annanstans i världen. Det ger tidig varning innan skadlig kod ens når er egen miljö, eftersom VirusTotal enligt egen uppgift kör motorn i skarp drift mot miljarder filer och tiotusentals regler dagligen.

Retrohunt fungerar tvärtom: du laddar upp en ny regel och söker den mot VirusTotals historiska arkiv för att se om samma hotfamilj redan förekommit tidigare, vilket är ovärderligt när ni utreder hur länge en attack pågått innan den upptäcktes. Kombinera gärna era egna interna regler med öppna community-bibliotek, som Florian Roths samling signature-base, för bredare täckning utan att behöva skriva allt från grunden.

Steg 12: Skala upp med regelbibliotek och versionshantering

Ett enda regelfilsbibliotek räcker inte länge när teamet växer. Lägg regelmappen i ett git-repo, dela upp filerna per hotkategori (ransomware, droppers, webbskal, och så vidare), och kör en enkel valideringsscript vid varje commit så att trasiga regler aldrig når produktion.

git init regler
cd regler
git add .
git commit -m "Initiala regler för ransomware-detektion"

# Hämta community-regler som komplement
git clone https://github.com/Neo23x0/signature-base.git externa-regler

# Validera alla regler innan commit (kör i pre-commit-hook)
for fil in *.yar; do
    yara -w "$fil" testfiler/tom.txt || echo "FEL i $fil"
done

Flaggan -w visar varningar (till exempel om ett villkor aldrig kan bli sant), vilket är minst lika viktigt som direkta fel. En regel som kompilerar utan varningar men aldrig matchar något är i praktiken lika värdelös som en trasig regel, bara svårare att upptäcka.

Så undviker ransomware-grupper detektion, och hur du ligger steget före

Innan du litar för mycket på en enda regel är det värt att förstå vad du faktiskt tävlar mot. Ransomware-operatörer packar och krypterar sina egna binärer, byter ut lösensedelstexter mellan varje kampanj, och delar upp körningen i flera steg där varje del för sig ser harmlös ut. En dropper laddar bara ner en fil, ett skript kör bara ett kommando, och krypteringsrutinen aktiveras först timmar senare på en helt annan maskin i nätverket. Ingen enskild YARA-regel fångar hela den kedjan.

Det är därför lager på lager fungerar bättre än ett enda skarpt verktyg. Skriv regler för varje steg i kedjan separat: en regel för misstänkta PowerShell-mönster (som vi gjorde i steg 4), en för själva lösensedeln (steg 7), och en för ovanliga binärer utan digital signatur (avsnittet om avancerade tips). Träffar du på flera av dessa regler i samma tidsfönster, även om ingen enskild träff är alarmerande på egen hand, är sannolikheten betydligt högre att något faktiskt pågår. Många team bygger en enkel korrelationsregel ovanpå loggfilen från steg 6: om samma katalog eller samma användarkonto genererar träffar från tre olika YARA-regler inom loppet av en timme, eskalera automatiskt till en incident i stället för att vänta på att någon läser loggen manuellt.

Ett annat vanligt undvikandeknep är att gömma skadlig kod i minnet och aldrig skriva den till disk, vilket gör att en ren filskanner som vår aldrig ser något att matcha mot. Här kompletterar minnesskanning (som vi nämner i FAQ-avsnittet) filbaserad YARA väl, eftersom samma regelspråk fungerar mot ett dumpat processminne precis som mot en fil på disk. Har ni redan ett EDR-system installerat är chansen god att det stödjer att skicka minnesdumpar till en YARA-motor för matchning, vilket ger er täckning mot precis den typen av fileless-attacker.

Prestanda och skalbarhet i stora miljöer

Skriptet vi byggt i steg 6-8 skannar filer sekventiellt, en i taget, vilket räcker gott på en enskild arbetsstation men blir en flaskhals mot en filserver med miljontals objekt. Lösningen är att dela upp arbetet över flera processorkärnor med Pythons inbyggda multiprocessing-modul i stället för att skriva om hela skannern i ett annat språk.

from multiprocessing import Pool

def skanna_parallellt(regler, filvägar, antal_processer=4):
    with Pool(antal_processer) as pool:
        resultat = pool.starmap(skanna_fil, [(regler, f) for f in filvägar])
    return resultat

En annan faktor som påverkar hastigheten mer än de flesta tror är hur regeln är skriven. Ett villkor som $s1 or $s2 or $s3 tvingar motorn att leta efter alla tre strängarna i varje fil, medan ett smalare villkor med filstorleksfilter eller magic bytes-kontroll (till exempel uint16(0) == 0x5A4D för att bara matcha Windows-körfiler) gör att YARA kan hoppa över uppenbart irrelevanta filer direkt. Skriv därför de billigaste villkoren, som filtyp och storlek, före de dyrare strängsökningarna i din condition-sektion när det går. Vill du pressa prestandan ytterligare är YARA-X på GitHub värt att testa, eftersom Rust-implementationen enligt VirusTotals egna uppgifter redan hanterar deras produktionsvolym av miljarder filer per dag.

Skydda regelbiblioteket: granskning och CI/CD

Ett regelbibliotek är kod, och bör behandlas som kod. Det innebär kodgranskning innan en ny regel merge:as till huvudgrenen, automatiska tester mot referensbiblioteket från steg 9, och en tydlig ägare för varje regelfil. Utan den disciplinen är risken stor att en illa skriven regel med breda villkor smyger sig in och börjar generera hundratals falska larm per natt, vilket i sin tur gör att teamet slutar lita på hela systemet.

Om ni hämtar externa regler, till exempel från community-repon, bör ni alltid granska diffen innan ni drar in en uppdatering, precis som med vilket annat tredjepartsberoende som helst. Samma resonemang som gäller för sårbarheter i öppna paket på PyPI och npm gäller här: ett bibliotek du inte skrivit själv kan innehålla fel, föråldrad logik eller i värsta fall en medvetet vilseledande regel. Lägg regelgranskning i samma pull request-flöde som resten av er kodbas, i stället för att behandla den som ett sidoprojekt utanför den vanliga utvecklingsprocessen.

En enkel CI-pipeline för regelbiblioteket behöver inte vara komplicerad. Låt varje pull request automatiskt köra yara -w mot samtliga ändrade filer för att fånga syntaxfel och varningar, kör därefter samma regler mot referensbiblioteket med rena filer från steg 9 och blockera merge om träffantalet överstiger ett bestämt tak. Lägg till detta som ett obligatoriskt kontrollsteg i GitHub Actions, GitLab CI eller vilket verktyg ni redan använder för resten av kodbasen, så slipper ni att en trasig eller för bred regel någonsin når produktion utan att en människa aktivt godkänt undantaget.

YARA vs YARA-X: vilken ska du välja?

VirusTotal beskriver själva YARA-X som moget och stabilt, och säger att de kört det i produktion under lång tid för att skanna miljarder filer mot tiotusentals regler. Projektets uttalade mål är att bli standardverktyget för malware-analytiker på sikt, medan den klassiska C-motorn fortsätter få buggfixar men inte ny större utveckling. Så här skiljer de sig konkret i september 2026:

Egenskap	YARA (klassisk)	YARA-X
Senaste version	4.5.8 (28 juli 2026)	1.20.0 (24 augusti 2026)
Implementationsspråk	C	Rust
Utvecklingsstatus	Underhåll och mindre funktioner	Aktiv huvudutveckling
Produktionsanvändning hos VirusTotal	Historisk standard	Körs i skarp drift enligt VirusTotal
Kompatibilitet med äldre regler	Fullt kompatibel (referensimplementation)	Hög, men vissa edge-fall skiljer sig
Python-bindningar	yara-python (moget)	Under utveckling, kolla aktuell status innan produktionsbruk
Rekommenderat för nya projekt	Ja, som stabilt förstahandsval idag	Ja, för den som vill följa den strategiska riktningen

Vårt råd i september 2026: bygg mot klassisk YARA för produktionsmiljöer där du behöver mogna Python-bindningar och stabilitet, men håll ett öga på YARA-X och testa dina viktigaste regler mot båda motorerna. Skiftet kommer sannolikt att ske gradvis snarare än som ett abrupt byte, och att ha regler som fungerar i båda ger dig flexibilitet oavsett vart projektet tar vägen.

Ett praktiskt sätt att förbereda sig är att köra klassisk YARA som primär motor i produktion medan ni parallellt testar YARA-X i en separat testmiljö mot samma regelfiler och samma referensbibliotek. Skillnader i resultat mellan de två motorerna dyker då upp innan de blir ett problem i skarp drift, och ni bygger samtidigt upp erfarenhet av det nyare verktyget i egen takt snarare än under tidspress när underhållet av den klassiska motorn en dag trappas ner ytterligare.

Vanliga nybörjarmisstag

De flesta problem med YARA-regler kommer inte från komplicerad syntax utan från ett fåtal återkommande fällor. Här är de vi ser oftast hos team som precis kommit igång, och de flesta går att undvika helt genom att följa ordningen i den här guiden: testa lokalt innan produktion, validera mot ett referensbibliotek, och fyll alltid i meta-fälten.

Misstag	Konsekvens	Lösning
Installerar paketet “yara” i stället för “yara-python”	ImportError eller fel funktionalitet i Python	Kör alltid pip install yara-python, aldrig bara yara
För generiska strängar utan nocase-hantering	Missar varianter med annan skiftlägeskombination	Lägg till nocase där skiftläge inte är relevant
Villkor med bara “or” mellan svaga strängar	Massor av falska positiva	Använd N of (...) för att kräva flera samtidiga träffar
Ingen filstorleksgräns i skanningsskriptet	Skanningen tar orimligt lång tid mot stora arkiv	Filtrera bort filer över en rimlig gräns, till exempel 200 MB
Aldrig testat regeln mot ett känt rent bibliotek	Upptäcker falska positiva först i produktion	Kör alltid mot ett referensbibliotek innan driftsättning
Sparar inte meta-fält som datum och beskrivning	Ingen vet varför regeln finns sex månader senare	Fyll alltid i meta-sektionen, det kostar ingen prestanda

Felsökning: vanliga problem och lösningar

Stöter du på fel längs vägen är chansen stor att det redan finns i listan nedan. Vi har samlat de problem som dyker upp oftast när team sätter upp YARA för första gången.

• “yara: command not found” efter installation. Kontrollera att installationsmappen finns i din PATH-variabel, eller kör om Homebrew/apt-installationen och starta om terminalen.
• ModuleNotFoundError: No module named ‘yara’ i Python trots installation. Du har troligen aktiverat fel virtuell miljö, eller installerat i en annan Python-version än den du kör skriptet med. Kör which python3 och pip show yara-python för att jämföra.
• Syntaxfel vid kompilering av regel. Kör yara -w regel.yar testfil separat för att isolera vilken fil som orsakar felet, i stället för att kompilera hela mappen på en gång.
• Skanningen hänger sig på en enskild fil. Sätt alltid en timeout-parameter i match()-anropet (vi använde 30 sekunder i exemplet), annars kan en enda korrupt eller extremt stor fil blockera hela körningen.
• Regeln matchar inte alls trots att strängen “borde” finnas. Kontrollera teckenkodning. Text i binärfiler ligger ofta som UTF-16, inte ASCII, så lägg till wide som modifierare på strängen: $s1 = "text" wide.
• För många falska positiva efter driftsättning. Gå tillbaka till steg 9 och kör regeln mot ett större referensbibliotek av rena filer innan du stramar åt villkoret ytterligare.
• Skanningen är för långsam mot stora filservrar. Dela upp jobbet i flera parallella processer med Pythons multiprocessing, eller begränsa filtyper enligt steg 8.
• Git-repot med regler växer okontrollerat. Separera egna regler från externt hämtade bibliotek som signature-base i olika undermappar, så blir det tydligt vad som är eget underhåll och vad som uppdateras via git pull.
• Cron-jobbet körs inte som förväntat. Cron använder ofta en annan miljö än din interaktiva terminal. Ange alltid absoluta sökvägar i crontab-raden, som vi gjorde i steg 10, i stället för att lita på relativa sökvägar.
• YARA-X ger annat resultat än klassisk YARA på samma regel. Det förekommer i enstaka edge-fall kring reguljära uttryck. Kör båda motorerna parallellt under en testperiod innan du litar fullt ut på den ena.

Avancerade tips för erfarna analytiker

När grunderna sitter finns det några tekniker som gör verktyget betydligt kraftfullare. Först: kombinera YARA med importerade moduler som pe för att inspektera PE-headers i Windows-binärer, till exempel för att kräva att en fil har en ovanlig sektion eller saknar digital signatur innan den räknas som misstänkt. Det minskar falska positiva drastiskt jämfört med att bara leta strängar.

import "pe"

rule Osignerad_Korfil_Med_Ovanlig_Sektion
{
    condition:
        pe.number_of_signatures == 0
        and pe.number_of_sections > 8
        and filesize < 5MB
}

För det andra: bygg regler kring MITRE ATT&CK-tekniker i stället för enskilda skadliga prover. En regel som fångar processinjektionsmönster generellt (kopplat till tekniker som beskrivs på MITRE ATT&CK) överlever betydligt längre än en regel skräddarsydd för ett specifikt prov, eftersom hotaktörer byter ut enskilda verktyg oftare än de byter grundläggande angreppstekniker.

För det tredje: komplettera YARA med fuzzy hashing (till exempel ssdeep eller TLSH) för att hitta filer som liknar ett känt prov även när ingen exakt sträng eller hexmönster matchar. De två teknikerna täcker olika svagheter, YARA är precis men kräver att du känner till mönstret i förväg, medan fuzzy hashing hittar likhet men ger fler falska positiva. Kör dem tillsammans i samma pipeline för bäst täckning.

Det färdiga projektet: komplett skanningsverktyg

När du följt alla steg ovan har du en mappstruktur och ett antal filer som tillsammans bildar ett fungerande, om än enkelt, detektionsverktyg. Så här ser slutresultatet ut:

yara-scanner/
├── venv/                       # Virtuell Python-miljö
├── regler/
│   ├── forsta_regeln.yar
│   ├── ransomware_losensedel.yar
│   ├── osignerad_korfil.yar
│   └── externa-regler/         # Klonat från signature-base
├── loggar/
│   ├── traffar.jsonl           # En JSON-rad per träff
│   └── korning.log             # Cron-utdata
├── testfiler/                  # Egna testexempel, aldrig produktionsdata
└── skanner.py                  # Huvudskriptet från steg 6-8

Verktyget kör automatiskt varje natt via cron, loggar varje träff strukturerat, och kan enkelt utökas med fler regler utan att du behöver ändra i Python-koden. Nästa naturliga steg, om du vill fortsätta bygga vidare, är att koppla larmen till ert befintliga incidenthanteringsflöde snarare än att bara logga till fil, så att en YARA-träff automatiskt öppnar ett ärende för teamet att utreda.

Andra naturliga utbyggnader när grunden väl står stadigt: lägg till ett webhook-anrop i logga_traff() som postar till Slack eller Teams direkt vid en träff, koppla på multiprocessing från prestandaavsnittet om ni skannar mer än några tiotusentals filer per körning, och separera regelmappen i undermappar per allvarlighetsgrad så att kritiska träffar kan trigga en annan larmväg än lågprioriterade. Ingen av dessa utbyggnader kräver att ni skriver om grundarkitekturen, de bygger vidare på samma kompilerings- och loggningsmönster som resten av guiden.

Vanliga frågor

Är YARA gratis att använda?
Ja, både klassisk YARA och YARA-X är öppen källkod och kostnadsfria att ladda ner, kompilera och köra i egen miljö, inklusive kommersiellt bruk.

Behöver jag YARA-X eller räcker klassisk YARA?
För de flesta team räcker klassisk YARA 4.5.8 gott och väl i dag, särskilt om ni redan har Python-integrationer via yara-python. YARA-X är värt att följa eftersom det är den strategiska riktningen, men det är inget krav för att komma igång.

Kan YARA ersätta ett traditionellt antivirusprogram?
Nej. YARA är ett kompletterande detektionsverktyg för analytiker och threat hunting-team, inte en fristående slutpunktsskyddsprodukt med realtidsblockering, sandboxing och all annan funktionalitet ett fullständigt EDR-system erbjuder.

Hur ofta bör jag uppdatera mina YARA-regler?
Egna regler bör granskas varje gång ni analyserar ett nytt skadligt prov. Externa bibliotek som signature-base uppdateras löpande av communityn, så ett schemalagt git pull en gång i veckan håller er i fas utan manuellt arbete.

Fungerar YARA mot krypterad eller paketerad skadlig kod?
Bara delvis. Är filen packad med en kompressor eller krypterare döljs de flesta strängmönster tills filen packas upp i minnet. Kombinera därför filbaserad YARA-skanning med minnesskanning under körning för bättre täckning mot den typen av hot.

Kan jag köra YARA mot processminne, inte bara filer?
Ja, både yara-python och YARA CLI stödjer att skanna ett processID direkt i minnet på Linux och Windows, vilket är särskilt användbart för att fånga skadlig kod som aldrig skriver sig till disk.

Var hittar jag färdiga YARA-regler att komma igång med?
Florian Roths signature-base-repo på GitHub är ett av de mest använda öppna biblioteken och ett bra ställe att börja studera hur erfarna analytiker strukturerar sina regler.

Skalar det här upplägget till en hel organisation, eller bara enstaka maskiner?
Grundprincipen skalar bra, men i en större organisation bör ni köra skanningen distribuerat närmare datat (till exempel på varje filserver) snarare än att dra all data till en central skanner, samt centralisera bara loggarna för analys.

Vad kostar det att komma igång jämfört med en kommersiell detektionsplattform?
Själva mjukvaran i den här guiden, YARA, YARA-X, Python och yara-python, är helt gratis och öppen källkod. Den enda kostnaden är analytikertid för att skriva och underhålla regler, samt eventuell serverkapacitet för skanningarna. Vill ni komplettera med VirusTotals Livehunt och Retrohunt tillkommer en prenumerationskostnad för det, men grundverktyget kräver ingen licens alls.