One of our core features at LimaCharlie is building an extensible platform that security teams can use to build a robust detection and response platform. One way we accomplish this is native integration with multiple types of detection engines and languages. In this post, we’ll look at the integration of LimaCharlie with YARA, the “pattern matching swiss knife for malware researchers.” YARA rules were originally designed by Victor Alvarez of VirusTotal, who was looking for a common syntax to identify and classify malware for research and detection purposes.
What is YARA?
YARA, which stands for either “Yet Another Recursive Acronym” or “Yet Another Ridiculous Acronym”, became the default way to classify malware based on commonly observed text or binary strings, patterns, metadata, and other attributes of a wide range of executable files. YARA’s power also extends from the ability to scan files on disk and in-memory, giving defenders an option to quickly share signatures and detect running or dormant malware on their systems.
Let’s look at a sample YARA rule to detect an SSH backdoor based on python and paramiko, taken from this GitHub repository:
The above rule includes multiple points of metadata, however the key detection(s) are located in the “strings” section of the rule. In the strings section, the rule defines three ascii strings (denoted by the ascii at the end of the line) that can be found in the file(s). The “condition” field specifies that we must match on 2 of 3 strings to yield a true positive. This is a relatively straightforward rule, however YARA can be expanded to include unicode or hex values, look at file types, PE and binary offsets, etc.
YARA scanning capabilities have been integrated in the LimaCharlie platform since 2019. This allows security teams to easily enable a private or public repository of YARA rules and begin real-time or on-demand scanning of systems, all within a matter of seconds. This is a huge force multiplier for incident response teams, who can deploy LimaCharlie and begin scanning with their custom repository of YARA rules in a matter of minutes.
Let’s examine the two types of YARA scanning, from a LimaCharlie perspective:
Continuous, or real-time, YARA scanning is done automatically, in the background, with little to no user impact (maximum 1% CPU usage). Note that continuous or automated scanning will look at all files loaded in memory.
On-demand YARA scanning is initiated by an analyst and will scan both files in memory and on disk. However, on-demand scanning will spike up system resource utilization and impact performance on the system.
Determining “which” YARA scan to use within LimaCharlie will often come down to timing, incident/investigative needs, and/or system resource availability. We recommend enabling in-memory YARA scanning on a continuous basis, whereas systems under active investigation and/or an active incident may require manual scanning.type: embedded-entry-inline id: 5FMNLqtGlnLkz00OHNG1g4
One option to enable and customize YARA scanning within LimaCharlie is using the GUI. Within your dashboard, go to ‘Add-ons’, ‘Services’, and subscribe to yara. Once enabled, within the ‘Develop’ options YARA Scanners will appear.
Once YARA scanning has been enabled, the next step is to import YARA rules and create either continuous or manual scans. We’ll look at these steps next.
Within the YARA configuration page, our first step will be to ‘Add Source’. This allows us to link to either a private or public GitHub repository and import YARA rules within that repository. Adding a source is fairly trivial, we only need a few key pieces of information.
If you’re unsure where to pull YARA rules from, there’s a curated list of various sources available here, in this meta GitHub repository. While we don’t recommend importing every single rule you can find, some “master” repositories have a solid collection of rules for malware and/or malicious activity detection and should provide enough coverage for even basic uses.
With at least one YARA rule source configured, we can now configure continuous or on-demand scanning.
Continuous Scanning
Continuous scanning is enabled by adding a scanner. There are a few options available within this menu:
The two most important considerations for configuring a continuous scanner are the YARA source(s) to enable and the application platform(s). This gives an IR or SOC team amazing flexibility - they can create OS- or project-based repositories and configure continuous scanning at the platform level. Finally, notice that in the event that a YARA rule is matched, a “YARA_DETECTION” event will be emitted, which we can write detection and response rule(s) for. We’ll look at this more in Part 2.
On-Demand Scanning
In the event that a team wants to run an ad-hoc or on-demand scan, the ‘Run Manual Scan’ option is available. Remember from earlier that on-demand scans will hit files on disk and in memory, however will consume more resources and take longer. An on-demand scan requires only the sensor to run against and the YARA source(s) for the scan.
And that’s it! At this point, you should have imported at least one YARA rule source repository and configured either continuous or an on-demand scan (or both!). Remember, YARA rules extend the LimaCharlie platform by allowing for total rule customization and integration, meaning a security team is in control of what they are detecting, with ultimate visibility.
In Part 2, we’ll look at extending YARA rules even further, analyzing YARA detection events, and other YARA tricks within the LimaCharlie platform.
Top comments (0)