Reguli Sigma și YARA cu AI: de la draft la detecție testată

Scrierea regulilor de detecție e în mare parte muncă de traducere: intră o descriere a unui atac sau o grămadă de string-uri extrase și iese o regulă precisă. Un model de limbaj se descurcă bine la traducerea asta, cu condiția să nu refuze să discute comportamentul atacatorului pe care încerci să-l detectezi. Ghidul ăsta îți arată cum să folosești Odin v1 ca să scrii drafturi de reguli Sigma și YARA, să le reglezi, să le convertești în query-uri SIEM și să le testezi înainte de producție.

Unde te ajută un model și unde nu

Odin v1 grăbește părțile lente, dar nu grele: transformă un paragraf dintr-un raport de threat intelligence într-o primă regulă Sigma, alege string-uri candidate dintr-un dump lung de strings, sugerează filtre pentru alertele zgomotoase și explică de ce o regulă s-a declanșat sau nu.

Nu înlocuiește testarea. Un model n-a văzut niciodată mediul tău sau pipeline-ul tău de loguri. Tratează fiecare regulă generată ca pe un draft: validează sintaxa cu instrumente reale, rulează regula pe date benigne, apoi pe un sample malițios cunoscut, într-un laborator.

Reguli Sigma dintr-o descriere de atac

Pornește de la o descriere scurtă și concretă a comportamentului. Un input vag („detectează PowerShell malițios”) produce reguli vagi. Un prompt bun numește sursa de loguri, comportamentul și zgomotul pe care îl știi deja:

Scrie o regulă Sigma pentru logurile Windows de creare a proceselor (Sysmon Event ID 1 sau Security 4688 cu auditarea liniei de comandă activată). Detectează powershell.exe sau pwsh.exe pornit cu -EncodedCommand sau cu oricare dintre formele lui scurte (-e, -ec, -en, -enc). Potrivește pe Image și pe OriginalFileName, ca să prinzi și binarele redenumite. Clientul nostru SCCM (C:\Windows\CCM\CcmExec.exe) lansează legitim comenzi codate, așa că filtrează-l. Include tag-uri ATT&CK, false pozitive și un level.

Te poți aștepta la o regulă YAML completă plus note despre compromisuri: -e cu spații în jur evită potrivirea pe -ExecutionPolicy, PowerShell acceptă orice prefix neambiguu al unui parametru, iar un filtru bazat pe procesul părinte poate fi abuzat de un atacator care controlează acel părinte. După revizuire, regula arată așa:

title: PowerShell Started With an Encoded Commandid: 3f6b2a9e-5c1d-4e8a-9b27-0d4c8e1f7a63status: experimentaldescription: Detects powershell.exe or pwsh.exe launched with the -EncodedCommand parameter or one of its short forms, often used to hide script content.references:    - https://attack.mitre.org/techniques/T1059/001/author: InterOdin teamdate: 2026-10-20tags:    - attack.execution    - attack.t1059.001    - attack.t1027logsource:    category: process_creation    product: windowsdetection:    selection_img:        - Image|endswith:              - '\powershell.exe'              - '\pwsh.exe'        - OriginalFileName:              - 'PowerShell.EXE'              - 'pwsh.dll'    selection_cli:        CommandLine|contains:            - ' -e '            - ' -ec '            - ' -en '            - ' -enc '            - ' -enco'    filter_main_sccm:        ParentImage: 'C:\Windows\CCM\CcmExec.exe'    condition: all of selection_* and not 1 of filter_main_*falsepositives:    - Configuration management agents and admin scripts that pass encoded commandslevel: medium

Aceeași abordare funcționează și pentru binarele living-off-the-land (LOLBins). Descrie un singur tipar de abuz per regulă, de exemplu „certutil.exe cu urlcache sau verifyctl care descarcă un fișier prin HTTP”:

title: Certutil Used to Download a Remote Fileid: 8c41d0e7-2b6f-4a59-a3d8-61e9f2b07c14status: experimentaldescription: Detects certutil.exe called with urlcache or verifyctl and a URL on the command line, a common living-off-the-land download technique.references:    - https://attack.mitre.org/techniques/T1105/author: InterOdin teamdate: 2026-10-20tags:    - attack.command-and-control    - attack.t1105logsource:    category: process_creation    product: windowsdetection:    selection_img:        - Image|endswith: '\certutil.exe'        - OriginalFileName: 'CertUtil.exe'    selection_flags:        CommandLine|contains:            - 'urlcache'            - 'verifyctl'    selection_url:        CommandLine|contains:            - 'http://'            - 'https://'    condition: all of selection_*falsepositives:    - Rare administrative use to fetch certificates or revocation listslevel: high

Generează singur un UUID nou pentru fiecare regulă; nu refolosi niciodată un id dintr-un exemplu.

Reguli YARA din string-uri extrase

La YARA, input-ul este rezultatul analizei statice: output de la strings sau FLOSS, metadate PE, secvențe de bytes notabile dintr-un disassembler. Odin v1 acceptă doar text, așa că le lipești ca text. Fereastra de context de 1.000.000 de tokeni îți permite să incluzi deodată string-uri din mai mulți membri ai aceleiași familii, exact ce îți trebuie: o regulă bună de familie se construiește din string-uri comune mai multor sample-uri și rare în software-ul curat.

Mai jos sunt dump-uri de string-uri FLOSS din patru sample-uri ale aceleiași familii de loader, colectate în laboratorul nostru de malware. Alege string-uri care apar în cel puțin trei sample-uri și care sunt puțin probabile în software benign. Evită numele de API-uri, artefactele de compilator și string-urile comune din biblioteci. Scrie o regulă YARA pentru fișiere PE sub 2 MB și explică de ce ai ales fiecare string.

Te poți aștepta la o regulă, la motivul pentru fiecare string ales și la string-urile respinse (cum ar fi kernel32.dll sau un user agent standard de browser). Pentru familia fictivă din ghidul nostru de triaj malware, rezultatul arată așa:

rule SyncHost_Loader_Strings{    meta:        description = "Fictional loader family used as an example on the InterOdin blog"        author = "InterOdin team"        date = "2026-10-20"        reference = "Synthetic strings, not a real malware family"
    strings:        $pdb   = "C:\\build\\synchost\\Release\\loader.pdb" ascii        $mutex = "Global\\SyncHostUpdateMtx" ascii wide        $ua    = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) SyncHost/2.1" ascii        $task  = "OneDrive Sync Helper" ascii wide        $path  = "/a/upd.dat" ascii        $cfg   = { 53 48 43 46 47 01 00 ?? ?? 00 00 }
    condition:        uint16(0) == 0x5A4D and        filesize < 2MB and        ( $pdb or $cfg or 3 of ($mutex, $ua, $task, $path) )}

Un singur string de încredere ridicată (calea PDB sau header-ul de config) ajunge de unul singur, în timp ce string-urile mai slabe trebuie să apară împreună. Cere modelului să justifice fiecare string; dacă nu poate, renunță la el.

Reducerea false pozitivelor

O regulă care se declanșează de 400 de ori pe zi ajunge dezactivată. La tuning economisește modelul cel mai mult timp: munca înseamnă să citești multe alerte zgomotoase și să observi tipare. Exportă alertele agregate după imaginea procesului părinte, utilizator și linia de comandă, scoate hostname-urile și numele de utilizator de care nu ai nevoie și întreabă:

Acestea sunt alertele din ultimele 7 zile pentru regula de PowerShell codat, grupate după ParentImage și prefixul CommandLine. Care grupuri arată a software legitim? Propune filtre Sigma cât mai înguste și spune-mi ce ar trebui să controleze un atacator ca să abuzeze fiecare filtru.

Obiceiuri bune de tuning, de impus în prompt și la revizuire:

• Filtrează pe căi complete plus procesul părinte, nu pe un substring din linia de comandă pe care un atacator îl poate copia.
• Folosește convenția Sigma filter_main_* pentru filtrele valabile peste tot și filter_optional_* pentru cele specifice mediului.
• Coboară level-ul în loc să adaugi un filtru atunci când nu poți face filtrul suficient de îngust.
• Pentru YARA, scanează un set mare de goodware (o instalare curată de Windows, repository-ul tău de software) și elimină orice string care se potrivește acolo.

Conversia Sigma într-un query SIEM

Regulile Sigma se convertesc cu sigma-cli, care folosește backend-uri și pipeline-uri de procesare pySigma ca să mapeze câmpurile generice pe schema ta de loguri:

pip install sigma-clisigma plugin install splunksigma plugin install sysmonsigma check rules/sigma convert -t splunk -p sysmon rules/powershell_encoded_command.yml

Pentru regula de PowerShell codat, output-ul pentru Splunk este:

EventID=1 Image IN ("*\\powershell.exe", "*\\pwsh.exe") OR OriginalFileName IN ("PowerShell.EXE", "pwsh.dll") CommandLine IN ("* -e *", "* -ec *", "* -en *", "* -enc *", "* -enco*") NOT ParentImage="C:\\Windows\\CCM\\CcmExec.exe"

Pentru Elastic, instalează plugin-ul elasticsearch și folosește -t lucene -p ecs_windows. Preferă instrumentul în locul conversiei manuale cerute modelului: backend-urile tratează consecvent escaping-ul și maparea câmpurilor.

Testarea pe loguri benigne și pe sample-uri de laborator

Fiecare regulă are nevoie de două teste înainte de deployment.

Un test negativ. Rulează regula pe un baseline despre care știi că e curat, de exemplu o săptămână de loguri de creare a proceselor de pe mașinile din laborator și de pe câteva stații de lucru reprezentative. Instrumente precum Chainsaw și Zircolite rulează reguli Sigma direct pe exporturi EVTX, sau poți rula query-ul convertit în SIEM pe o fereastră de timp liniștită. Orice potrivire e un fals pozitiv pe care trebuie să-l explici sau să-l filtrezi.

Un test pozitiv. Declanșează comportamentul într-un VM de laborator izolat și confirmă că regula se declanșează. Pentru regula de PowerShell codat ajunge o comandă inofensivă:

$cmd = [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes("Write-Output 'sigma test'"))powershell.exe -NoProfile -EncodedCommand $cmd

Pentru YARA, echivalentul este:

yara -s -r synchost.yar ./family_samples/   # should match every known family memberyara -r synchost.yar ./goodware/            # should print nothing

Ține sample-urile reale în VM-ul de analiză, niciodată pe o stație de lucru.

Automatizarea buclei de draft și verificare

Scriptul de mai jos trimite o descriere de comportament către Odin v1, extrage YAML-ul, îl parsează cu pySigma (care aruncă o eroare la regulile invalide) și afișează query-ul Splunk. Instalează dependențele cu pip install openai sigma-cli pysigma-backend-splunk pysigma-pipeline-sysmon.

import osimport reimport sys
from openai import OpenAIfrom sigma.backends.splunk import SplunkBackendfrom sigma.collection import SigmaCollectionfrom sigma.pipelines.sysmon import sysmon_pipeline
client = OpenAI(base_url="https://api.interodin.com/v1", api_key=os.environ["INTERODIN_API_KEY"])
SYSTEM = (    "You are a detection engineer. Write exactly one Sigma rule in YAML for the behavior "    "described. Use logsource category process_creation and product windows, use Sigma "    "modifiers, list realistic false positives, and return only the YAML.")

def draft_rule(description: str) -> str:    resp = client.chat.completions.create(        model="odin-v1",        messages=[{"role": "system", "content": SYSTEM}, {"role": "user", "content": description}],    )    text = resp.choices[0].message.content    fenced = re.search(r"`{3}(?:ya?ml)?\n(.*?)`{3}", text, re.DOTALL)    return fenced.group(1) if fenced else text

def to_splunk(rule_yaml: str) -> str:    rules = SigmaCollection.from_yaml(rule_yaml)    return SplunkBackend(sysmon_pipeline()).convert(rules)[0]

if __name__ == "__main__":    rule = draft_rule(sys.stdin.read())    print(rule)    print("--- Splunk ---")    print(to_splunk(rule))

Rulează-l cu python draft_sigma.py < behavior.txt. Dacă parsarea eșuează, lipește eroarea înapoi la model și cere o corectură. Pentru un harness care rulează reguli YARA pe folderele de sample-uri și de goodware, vezi tooling de securitate construit cu Claude Code pe Odin. Ghidul pentru OpenAI SDK explică configurarea clientului.

Primii pași

Creează o cheie API în consolă, urmează quickstart-ul și rulează scriptul de mai sus pe un comportament din cel mai recent raport de threat intelligence. Ține manipularea sample-urilor în laboratorul tău și munca în limitele Politicii de utilizare acceptabile.