YARA explained
YARA (aka "Yet Another Recursive Acronym") is a tool designed for file analysis, in particular, identification and classification of malware based on textual and binary patterns. Its tongue-in-cheek name notwithstanding, YARA has been an important part of cybersecurity toolkits since the researcher Victor Alvarez launched it on GitHub in 2013. It is open source, which means that a broad community of security experts and organizations contribute to YARA rule sets while simultaneously using it in the field to test suspicious code and confirm malware types found in digital environments.
Similarly to tools such as Suricata®, YARA analyzes and matches binary patterns, textual patterns, and other characteristics using its own rule language. Analysts can use the results to classify and alert on malware families— which can assist in the analysis and detection of malware.
What are YARA rules?
YARA rules are detailed descriptions that can help classify and identify malware types using the open-source YARA file analysis tool. Whether you want access to high-quality rules or are ready to write your own, using the tool can improve SOC efficiency and overall security. YARA rules are essentially sets of instructions or conditions that must be met for a software sample to be classified as malicious. The rule will define a set of variables or conditions that, when met, indicate a match with known malware strains or families or just match a specific condition that is important to classify but not malicious.
Security professionals often publish YARA rules they have created in public forums and repositories such as GitHub. Agencies such as CISA will often include them in public announcements about recently discovered vulnerabilities and indicators of compromise. While security teams can create YARA rules tailored to the systems they protect, they can also tap into the broader cyber community to make their YARA deployment more extensive and effective.
Why is malware analysis still important?
Malware has been a persistent threat since the advent of digital networks and remains one of the top concerns of security researchers. One study found evidence of over 6 billion malware attacks in 2023, an 11% YoY increase and the highest raw total in several years. (1)
Additionally, there is significant concern over the impact of generative AI on malware creation. AI models can create reproductions of known malware strains that are highly accurate and can assist sophisticated bad actors in the creation of variants.
Malware analysis and detection engines are harnessing many of the same capabilities. However, advances in generative AI and the continued evolution of malware mean that security teams must work with a wide range of analytic tools to keep pace with the current threat environment.
Components of YARA rules
YARA rules vary widely in terms of complexity and specificity, but most will contain a syntax that includes these key components:
- Rule name (or identifier). Every YARA rule must have a unique identifier and conform to a few conditions (e.g., no spaces in the name; names cannot be standalone numbers).
- Metadata. This part of the rule simply provides context about the rule's origin, often the name of the creator, date of creation, version numbers, what malware it is designed to identify, and other descriptors that tell the story about the origin of the rule and what it does.
- Strings. Strings are text sequences embedded in files that can be extracted for analysis. A YARA rule will identify specific strings, or malware signatures that it searches for within files or network traffic; a rule may incorporate a single or multiple strings. Strings can be created in text, regular expressions or hexadecimal sequences to represent binary code, and can include modifiers that link them to certain conditions.
- Conditions. The conditions contain Boolean logic expressions and operators (such as "AND," "OR" or "NOT") to specify when the YARA rule will match elements of the file being analyzed. They may also contain certain properties, such as file size.
The YARA rule example below focuses on a binary named pskt. It looks for a single string [md] as ASCII text, checks the first 16 bytes (uint16(0)) for the value 0x457f, specifies the file should not exceed 15,000 KB in size and that the entropy of the binary should exceed 6.2:
Guidelines for writing strong YARA rules
Creating YARA rules that match against malware signatures without generating a high number of false positives requires experience, research, and practice. What's more, security teams can extensively use the open source community and YARA repositories to find and deploy rules suitable for their particular organizations and the threats they face.
However, analysts who have the time and incentive to write new YARA rules can build effective malware detection by observing some general principles and guidelines:
- Select multiple, malware-specific strings. Effective YARA rules depend on specificity. Strings in YARA rules should be unique to malware and should not include strings that may well appear in benign files and lead to false positives. Using strings in some combination of regular expressions, text, and hexadecimal forms can also reduce false positive risk. Malware-specific strings might include rarely used user agents, registry keys, a mutex or configuration strings.
- String keywords. While keywords are optional, they are recommended for all string types.
- Avoid generalized or overly fuzzy conditions. Striking a balance on the level of detail in conditions is a key to writing effective YARA rules. There are no hard and fast rules, but rule writers should be cautious about deploying characters like wildcards that can help detect files that are similar to a string but not exact matches. Overly broad matching is also a sure way to introduce performance problems.
- Test and tune. YARA rules should be tested on many types of files before they are released. Writers can gauge how well the rules execute and make adjustments to optimize performance with various datasets. Overly complex rules may be simplified by removing strings or being split into modules.
- Make use of rule-building tools. Even experienced rule writers can deploy tools that either make rule creation faster and simpler or generate the foundation of a rule by reviewing a specified malware file. One example is yarGen, which can pull distinct strings from malware files and also delete less-specific strings that may appear in normal files while creating a framework for the rule. Mandiant's FLOSS expedites detecting and extracting malicious strings that have been obscured or packed within the file.
How SOCs can import YARA rules
There is no lack of environments in which security teams can deploy YARA rules. Platforms that monitor endpoints, such as endpoint detection and response (EDR), data aggregation solutions such as security information and event management (SIEM), network detection and response (NDR), cloud security solutions, and malware analysis systems are all platforms where imported or team-created YARA rules can assist in the detection and elimination of malware.
However, the SOC should also consider what visibility these platforms provide, and whether the YARA rules can be applied to a sufficient number of data streams and environments. As one example, most leading EDR platforms enable the import and use of YARA rules and other file analysis tools. While this capability provides in-depth visibility into files, it is limited in its view of networks, OT environments, legacy operating systems, and endpoints that cannot support EDR, such as many IoT devices. Moreover, some malware types are designed to bypass EDR detections (e.g., DLL, sideloading, command line obfuscation and code signing). EDR may also not detect advanced attacks like modular remote access trojans (RATs) that only download required features from command and control servers.
These limitations are not an argument against using YARA rules within EDR. Rather, they emphasize the need to deploy malware analysis tools across the security stack. Accessing YARA rules in each of the pillars of the SOC Visibility Triad — EDR, NDR and SIEM — can help the SOC maximize the value inherent to each platform.
Using YARA rules with an NDR platform
NDR platforms give security teams visibility into traffic on all types of networks (e.g., on-premises, cloud, hybrid), provide continuous, real-time monitoring capabilities, and enable tool consolidation by supporting multiple functions, including file analysis. Most incorporate intrusion detection system (IDS) capabilities and a combination of signature-based and behavioral based analysis to investigate traffic patterns and generate alerts. Whether a SOC writes its own YARA rules or imports them, the NDR platform can provide a streamlined and effective environment for file analysis at scale.
NDR can also assist in malware detection by enabling file extraction and providing SOCs with a platform to quickly scan files against a YARA rule repository. By providing visibility and contextualization of network traffic, NDR can enable identification of malicious files that match YARA rule conditions and decrease the number of false positives. In turn, static file analysis complements NDR in several ways:
- Aids in detection of known malware. YARA rules can augment IDS functionality in NDR platforms and help SOCs detect malicious strings and patterns that suggest the presence of malware.
- Improve incident investigation and response times. The combination of preemptive technologies such as advanced NDR and YARA rules can expedite the identification of malicious files and enable faster remediation.
- Pivoting to threat hunting. Static file analysis can help security teams identify IOCs related to potential threats before they execute and enable analysts to test hypotheses.
