Developing YARA Rules
Introduction to YARA & Sigma
YARA and Sigma are two essential tools used by SOC analysts to enhance their threat detection and incident response capabilities. They empower analysts with improved threat detection capabilities, efficient log analysis, malware detection and classification, IOC identification, collaboration, customization, and integration with existing security tools.
Importance of YARA and Sigma rules for SOC Analysts
Let's explore the key reasons why YARA and Sigma are invaluable for SOC analysts:
Enhanced Threat Detection: YARA and Sigma rules allow SOC analysts to develop customized detection rules tailored to their unique environment and security needs. These rules empower analysts to discern patterns, behaviors, or indicators linked to security threats, thus enabling them to proactively detect and address potential incidents. Various Github repositories provide a wealth of examples of YARA and Sigma rules.
Efficient Log Analysis: Sigma rules are essential for log analysis in a SOC setting. Utilizing Sigma rules, analysts can filter and correlate log data from disparate sources, concentrating on events pertinent to security monitoring.
Collaboration and Standardization: YARA and Sigma offer standardized formats and rule structures, fostering collaboration among SOC analysts and tapping into the collective expertise of the broader cybersecurity community.
For instance, "The DFIR Report" shares YARA and Sigma rules derived from their investigations.
Integration with Security Tools: YARA and Sigma rules can be integrated seamlessly with a plethora of security tools, including SIEM platforms, log analysis systems, and incident response platforms. This integration enables automation, correlation, and enrichment of security events, allowing SOC analysts to incorporate the rules into their existing security infrastructure. As an example, Uncoder.io facilitates the conversion of Sigma rules into tailor-made, performance-optimized queries ready for deployment in the chosen SIEM and XDR systems.
Malware Detection and Classification: YARA rules are particularly useful for SOC analysts in pinpointing and classifying malware. Leveraging YARA rules, analysts can create specific patterns or signatures that correspond to known malware traits or behaviors.
Indicator of Compromise (IOC) Identification: Both YARA and Sigma rules empower SOC analysts to locate and identify IOCs, which are distinct artifacts or behaviors linked to security incidents or breaches. By embedding IOCs into their rules, analysts can swiftly detect and counter potential threats, thus mitigating the consequences of security incidents and curtailing the duration of attackers' presence within the network.
YARA and YARA Rules
YARA is a powerful pattern-matching tool and rule format used for identifying and classifying files based on specific patterns, characteristics, or content. SOC analysts commonly use YARA rules to detect and classify malware samples, suspicious files, or indicators of compromise (IOCs).
YARA Rule Structure
Let's dive into the structure of a YARA rule. YARA rules consist of several components that define the conditions and patterns to be matched within files. An example of a YARA rule is as follows:
Each rule in YARA starts with the keyword rule followed by a rule identifier. Rule identifiers are case sensitive where the first character cannot be a digit, and cannot exceed 128 characters.
The following keywords are reserved and cannot be used as an identifier:
Now, let's go over the YARA rule structure using a rule that identifies strings associated with the WannaCry ransomware as an example. The rule below instructs YARA to flag any file containing all three specified strings as Ransomware_WannaCry.
YARA Rule Breakdown:
Rule Header: The rule header provides metadata and identifies the rule. It typically includes:
Rule name: A descriptive name for the rule.Rule tags: Optional tags or labels to categorize the rule.Rule metadata: Additional information such as author, description, and creation date.
Rule Meta: The rule meta section allows for the definition of additional metadata for the rule. This metadata can include information about the rule's author, references, version, etc.
Rule Body: The rule body contains the patterns or indicators to be matched within the files. This is where the actual detection logic is defined.
Rule Conditions: Rule conditions define the context or characteristics of the files to be matched. Conditions can be based on file properties, strings, or other indicators. Conditions are specified within the condition section.
In this YARA rule, the condition section simply states all of them, which means that all the strings defined in the rule must be present for the rule to trigger a match.
Let us provide one more example of a condition which specifies that the file size of the analyzed file must be less than 100 kilobytes (KB).
This condition also specifies that the first 2 bytes of the file must be either 0x5A4D (ASCII MZ) or 0x4D5A (ASCII ZM), by using uint16(0)
uint16: This indicates the data type to be extracted, which is a 16-bit unsigned integer (2 bytes).
Developing YARA Rules
Let's dive into the world of YARA rules using a sample named svchost.exe residing in the /home/htb-student/Samples/YARASigma directory of this section's target as an illustration. We want to understand the process behind crafting a YARA rule, so let's get our hands dirty.
Initially, we need to conduct a string analysis on our malware sample.
From the first few strings, it becomes evident that the file is packed using the UPX (Ultimate Packer for eXecutables) packer. Given this discovery, we can incorporate UPX-related strings to formulate a basic YARA rule targeting samples packed via UPX.
Developing a YARA Rule Through yarGen
Once again, we need to conduct a string analysis on our malware sample.
After we execute the strings command on dharma_sample.exe, we spot C:\crysis\Release\PDB\payload.pdb, which is pretty unique.
yarGen is our go-to tool when we need an automatic YARA rule generator. What makes it a gem is its ability to churn out YARA rules based on strings found in malicious files while sidestepping strings common in benign software.
Let's place our sample in a temp directory and specify the path using the following command-line arguments.
The resulting YARA rules will be written to the htb_sample.yar file inside the /home/htb-student/yarGen-0.23.4 directory of this section's target. Let's see the content of the generated rule.
Now, for the moment of truth. We'll unleash YARA with our newly minted rule to see if it sniffs out any matches when run against a malware sample repository located at home/htb-student/Samples/YARASigma inside this section's target.
Manually Developing a YARA Rule
Example 1: ZoxPNG RAT Used by APT17
We want to develop a YARA rule to scan for a specific variation of the ZoxPNG RAT used by APT17 based on:
A sample named
legit.exeresiding in the/home/htb-student/Samples/YARASigmadirectory of this section's targetString analysis
Imphash
Common sample file size
Let's then use the hashes mentioned in Intezer's post to identify common sample sizes. It looks like there are no related samples whose size is bigger than 200KB. An example of an identified sample is the following. https://www.hybrid-analysis.com/sample/ee362a8161bd442073775363bf5fa1305abac2ce39b903d63df0d7121ba60550
Finally, the sample's Imphash can be calculated as follows, using the imphash_calc.py script that resides in the /home/htb-student directory of this section's target.
A good YARA rule to detect the aforementioned variation of ZoxPNG resides in the /home/htb-student/Rules/yara directory of this section's target, saved as apt_apt17_mal_sep17_2.yar.
YARA Rule Breakdown:
Rule Imports: Modules are extensions to YARA's core functionality.import "pe": By importing the PE module the YARA rule gains access to a set of specialized functions and structures that can inspect and analyze the details ofPEfiles. This makes the rule more precise when it comes to detecting characteristics in Windows executables.
Rule Meta:description: Tells us the main purpose of the rule, which is to detect APT17 malware.license: Points to the location and version of the license governing the use of this YARA rule.author: The rule was written by Florian Roth from Nextron Systems.reference: Provides a link that goes into more detail about the malware or context of this rule.date: The date the rule was either created or last updated, in this case, 3rd October 2017.hash1,hash2,hash3: Hash values, probably of samples related to APT17, which the author used as references or as foundational data to create the rule.
Rule Body: The rule contains a series of strings, which are potential indicators of the APT17 malware. These strings are split into two categories$x* strings$s* strings
Rule Condition: This is the heart of the rule, where the actual detection logic resides.uint16(0) == 0x5a4d: Checks if the first two bytes of the file areMZ, which is the magic number for Windows executables. So, we're focusing on detecting Windows binaries.filesize < 200KB: Limits the rule to scan only small files, specifically those smaller than200KB.pe.imphash() == "414bbd566b700ea021cfae3ad8f4d9b9": This checks the import hash (imphash) of the PE (Portable Executable) file. Imphashes are great for categorizing and clustering malware samples based on the libraries they import.1 of ($x*): At leastoneof the$x strings(from the strings section) must be present in the file.6 of them: Requires that at leastsixof the strings (from both $x and $s categories) be found within the scanned file.
Example 2: Neuron Used by Turla
We want to develop a YARA rule to scan for instances of Neuron Service used by Turla based on:
A sample named
Microsoft.Exchange.Service.exeresiding in the/home/htb-student/Samples/YARASigmadirectory of this section's target
Since the report mentions that both the Neuron client and Neuron service are written using the .NET framework we will perform .NET "reversing" instead of string analysis.
Note: A better reversing solution would be to load the .NET assembly (Microsoft.Exchange.Service.exe) into a .NET debugger and assembly editor like dnSpy.
A good YARA rule to identify instances of Neuron Service resides in the /home/htb-student/Rules/yara directory of this section's target, saved as neuron_1.yar.
YARA Rule Breakdown:
Strings Section:$class1 = "StorageUtils" asciito$class8 = "W3WPDIAG" ascii: These are eight ASCII strings corresponding to class names within the .NET assembly.$func1 = "AddConfigAsString" asciito$func7 = "FindSPath" ascii: These seven ASCII strings represent class or function names within the .NET assembly.$dotnetMagic = "BSJB" ascii: This signature is present in the CLI (Common Language Infrastructure) header of .NET binaries, and its presence can be used to indicate the file is a .NET assembly. Specifically, it's in the Signature field of the CLI header, which follows the PE header and additional tables.
Condition Section:uint16(0) == 0x5A4D: This checks if the first two bytes at the start of the file areMZ, a magic number indicating a Windows Portable Executable (PE) format.uint16(uint32(0x3c)) == 0x4550: A two-step check. First, it reads a 32-bit (4 bytes) value from offset0x3cof the file. In PE files, this offset typically contains a pointer to the PE header. It then checks whether the two bytes at that pointer arePE(0x4550), indicating a valid PE header. This ensures the file is a legitimate PE format and not a corrupted or obfuscated one.$dotnetMagic: Verifies the presence of theBSJBstring. This signature is present in the CLI (Common Language Infrastructure) header of .NET binaries, and its presence can be used to indicate the file is a .NET assembly.6 of them: This condition states that at least six of the previously defined strings (either classes or functions) must be found within the file. This ensures that even if a few signatures are absent or have been modified, the rule will still trigger if a substantial number remain.
Example 3: Stonedrill Used in Shamoon 2.0 Attacks
We want to develop a YARA rule to scan for instances of Stonedrill used in Shamoon 2.0 attacks based on:
A sample named
sham2.exeresiding in the/home/htb-student/Samples/YARASigmadirectory of this section's target
Encrypted/compressed/obfuscated in PE files usually means high entropy. We can use the entropy_pe_section.py script that resides in the /home/htb-student directory of this section's target to check if our sample's resource section contains anything encrypted/compressed as follows.
We notice that the resource section (.rsrc) has high entropy (8.0 is the maximum entropy value). We can take for granted that the resource section contains something suspicious.
A good YARA rule to identify instances of Stonedrill resides in the /home/htb-student/Rules/yara directory of this section's target, saved as stonedrill.yar.
YARA Rule Breakdown:
Rule Imports: Modules are extensions to YARA's core functionality.import "pe": By importing the PE module the YARA rule gains access to a set of specialized functions and structures that can inspect and analyze the details ofPEfiles. This makes the rule more precise when it comes to detecting characteristics in Windows executables.import "math": Imports the math module, providing mathematical functions like entropy calculations.
Rule Meta:copyright = "Kaspersky Lab": The rule was authored or copyrighted by Kaspersky Lab.description = "Generic detection for samples that enumerate files with encrypted resource called 101": The rule aims to detect samples that list files and have an encrypted resource with the identifier "101".reference = "https://securelist.com/from-shamoon-to-stonedrill/77725/": Provides an URL for additional context or information about the rule.hash: Two hashes are given, probably as examples of known malicious files that match this rule.version = "1.4": The version number of the YARA rule.
Strings Section:$mz = "This program cannot be run in DOS mode.": The ASCII string that typically appears in the DOS stub part of a PE file.$a1 = "FindFirstFile", $a2 = "FindNextFile": Strings for Windows API functions used to enumerate files. The usage ofFindFirstFileWandFindNextFileWAPI functions can be idenfitied through string analysis.$a3 = "FindResource", $a4 = "LoadResource": As already mentioned Stonedrill samples feature encrypted resources. These strings can be found through string analysis and they are related to Windows API functions used for handling resources within the executable.
Rule Condition:uint16(0) == 0x5A4D: Checks if the first two bytes of the file are "MZ," indicating a Windows PE file.all of them: All the strings $a1, $a2, $a3, $a4 must be present in the file.filesize < 700000: The file size must be less than700,000bytes.pe.number_of_sections > 4: The PE file must have more thanfoursections.pe.number_of_signatures == 0: The file must not be digitally signed.pe.number_of_resources > 1 and pe.number_of_resources < 15: The file must contain more than one but fewer than15resources.for any i in (0..pe.number_of_resources - 1): ( (math.entropy(pe.resources[i].offset, pe.resources[i].length) > 7.8) and pe.resources[i].id == 101 and pe.resources[i].length > 20000 and pe.resources[i].language == 0 and not ($mz in (pe.resources[i].offset..pe.resources[i].offset + pe.resources[i].length))): Go through each resource in the file and check if the entropy of the resource data is more than7.8and the resource identifier is101and the resource length is greater than20,000bytes and the language identifier of the resource is0and the DOS stub string is not present in the resource. It's not required for all resources to match the condition; only one resource meeting all the criteria is sufficient for the overall YARA rule to be a match.
YARA Rule Development Resources
As you can imagine, the best YARA rule development resource is the official documentation, which can be found at the following link.
The next best resource on effective YARA rule developement comes from Kaspersky.
Below are some blog posts that offer a more detailed explanation on how to use yarGen for YARA rule development:
yarGen is a great tool to develop some good yara rules by extracting unique patterns. Once the rule is developed with the help of yarGen, we definitely need to review and add/remove some more patterns to make it an effective rule.
Now let's start working on the lab.
1) Perform string analysis on the "DirectX.dll" sample that resides in the "/home/htb-student/Samples/YARASigma" directory of this section's target. Then, study the "apt_apt17_mal_sep17_1.yar" YARA rule that resides in the "/home/htb-student/Rules/yara" directory and replace "X.dll" with the correct DLL name to ensure the rule will identify "DirectX.dll". Enter the correct DLL name as your answer. Answer format: _.dll
The condition section specifies the criteria that must be met for the rule to trigger:
uint16(0) == 0x5a4d: Checks if the file starts with the bytes0x5a4d, which corresponds to the "MZ" header indicating a Windows executable file.filesize < 500KB: Ensures that the file size is less than 500 KB. This could be used to narrow down the scope to files that fit a certain profile.all of them: Indicates that all the strings defined in thestringssection must be found in the file.
We need to replace "X.dll" with the correct DLL name to ensure the rule will identify "DirectX.dll".
I conducted an online search using apt_apt17_mal_sep17_1.yar and found the corresponding rule on this GitHub link: https://github.com/Neo23x0/signature-base/blob/master/yara/apt_apt17_mal_sep17.yar.
I searched for the APT17_Malware_Oct17_1 rule in this file and discovered the missing DLL.
I utilized regular expressions to extract all .dll files from the DirectX.dll file.
Answer: TSMSISrv.dll
Last updated
