YARA Style Guide: Comprehensive Best Practices for Naming, Structuring and Maintaining Detection Rules
Florian Roth’s YARA Style Guide has been translated and adapted by security specialist Maxim Motikov of the Russian company Garda to help teams maintain large, consistent collections of detection rules. The guide addresses the common problem that YARA lacks a strict naming or formatting standard, causing rulebases to become disorganized over time.
Rule Naming Conventions
Rule names should combine threat category, context, target platform and creation date so that analysts can understand the purpose of a rule without opening the file. Recommended category prefixes include MAL for malware, HKTL for hacktools, WEBSHELL, EXPL for exploits, VULN for vulnerabilities, SUSP for suspicious patterns and PUA for potentially unwanted applications.
Context tags such as APT, CRIME, RANSOM and ANOMALY can be added, followed by malware type indicators like RAT, Implant, Stealer, Loader or Crypter. Platform and technology suffixes cover operating systems (WIN, LNX, MacOS), architectures (X64, X86, ARM) and file formats or languages (PE, ELF, PS1, VBS, JS, NET, Go, Rust, PHP and others).
Packers such as UPX, Themida and NSIS should be noted when relevant, and specific threat actor or family names (Lazarus, CozyBear, CobaltStrike, PlugX, QakBot) are written in full. Unique suffixes such as May23 or _1 help prevent naming collisions.
Rule Structure and Metadata
Every rule follows a consistent layout with meta, strings and condition sections. Mandatory metadata fields are description (starting with “Detects …”), author, reference and date in YYYY-MM-DD format. Optional but recommended fields include score (0–100), hash (preferably SHA256), modified date and license.
The score helps prioritize alerts: values above 85 indicate high-confidence detections, while lower scores flag generic or low-severity indicators. Additional tags can be stored in a dedicated meta field when they are not central enough for the rule name.
String Organization and Readability
Strings are categorized into three groups: high-specificity strings prefixed with $x*, group strings prefixed with $s* and preliminary filter strings prefixed with $a*. False-positive indicators receive the $fp* prefix so that matches on legitimate patterns can suppress alerts.
Hexadecimal byte sequences should be accompanied by ASCII comments when possible, and long values may be split into 16-byte segments. Simple text strings must never be written as hex unless they contain control characters.
Condition Formatting
Conditions should follow a logical order: header checks, file-size limitations, other constraints, string combinations and finally false-positive filters. Each “and” clause is placed on a new line, and “or” groups are indented for clarity.
By adopting these conventions, teams can create self-documenting rules that remain understandable months or years after creation and reduce the time required to triage large numbers of alerts.
Related articles
Reflective DLL Injection: How Malware Executes DLLs Directly in Memory Without Disk Files
Reflective DLL Injection allows malicious code to load and execute a DLL entirely in memory, bypassing traditional file-based loading mechanisms on Windows. The technique uses a custom loader inside the DLL itself to handle PE format parsing, relocations, imports, TLS, and exception handling without calling LoadLibrary. Unlike standard loading, the resulting module often resides in MEM_PRIVATE regions and does not appear in conventional module lists, complicating forensic analysis. Tools such as Meterpreter and Cobalt Strike have historically employed reflective loaders, though Beacon Object Files represent a different COFF-based approach. Investigators must examine memory regions, thread start addresses, and Sysmon events 7, 8, and 10 rather than relying solely on file artifacts. The method does not bypass DEP, Arbitrary Code Guard, or access-control restrictions and leaves detectable traces when combined with behavioral indicators. Proper detection requires correlating private executable memory with process behavior and avoiding over-reliance on simplified signatures.
Leaked DarkSword iOS Exploit Chain 'P7' Now Steals Crypto Wallet Seeds and Keystores
A third build of the P7 variant of the leaked DarkSword iOS exploit chain has been identified, featuring a new lure site themed around Chinese online casinos and a fresh command server. The chain exploits six vulnerabilities, including three zero-days, to deploy an implant that decrypts the keychain directly on the device and extracts seed phrases from wallets such as imToken, Trust Wallet, and Phantom. Unlike the original GHOSTBLADE, P7 rewrites the C2 agent to focus exclusively on wallet data while retaining the core TaskRop and MIG-filter bypass modules. Passive analysis of public sources also uncovered the long-running 'qqtime' delivery cluster that pairs DarkSword with the older Coruna chain for broader iOS coverage. The operator uses channel codes to support multiple affiliate distributors and employs an AppleKeyStore oracle to decrypt keychain items locally before exfiltration.
Censys Exposes DarkSword iOS Exploit Platform and Coruna Crypto Wallet Stealer
Censys has disclosed the inner workings of DarkSword, a commercial platform that sells remote access to iOS devices, along with its associated malware Coruna that targets cryptocurrency wallet recovery keys. The infrastructure was exposed between September 15 and 17, allowing researchers to analyze the full attack chain starting from a WebKit and JavaScriptCore exploit delivered through the browser. After escaping the Safari sandbox and reaching the kernel, the platform deploys three layers including a flag, controller, and main implant. Coruna then scans the device for BIP39-compliant seed phrases stored in photos and Apple Notes across 19 targeted wallet applications such as MetaMask, Phantom, Trust Wallet, Coinbase, Exodus, imToken, Bitpie, and BitKeep. The exposed server contained 11 victim recovery keys, 179 directories of extracted data, and 75 operator accounts, indicating a structured commercial operation with agent accounts, commissions, and device quotas. Confirmed infections affect devices running iOS 16.1 and 16.3.1, while Apple has extended patches to additional iOS 18 devices. Maintaining updated iOS versions remains the primary defense against this threat.
How Malware Evades Sandboxes: Detection Techniques and Defense Strategies
Sandboxes have become a standard tool for analyzing suspicious files delivered via email, websites, messengers, and cloud storage. Modern malware often avoids detection by identifying virtual environments rather than directly attacking the sandbox. Techniques include checking for virtualization artifacts, system parameters, hardware signatures, network indicators, user activity, and timing delays. Reports such as Picus Red Report 2026 show technique T1497 returning to the top five most common MITRE ATT&CK methods. Examples like Blitz, GootLoader, and LummaC2 demonstrate environment checks and behavioral evasion. Effective defense requires combining multiple analysis methods, realistic sandbox profiles, pre-delivery inspection, and integration with other security controls.