Some time ago, I came across a SANS white paper authored by Ricardo Dias titled “Intelligence Driven Incident Response With Yara”, you can find the paper on the SANS reading room here.
If you are a practitioner within the InfoSec space, either in a IR or SOC environment, I recommend taking a few moments to have a read of Ricardo’s paper.
Protecting The Network, And The Budget…
What’s special about Ricardo’s approach is that there are already an abundance of end point solutions which have the capability to leverage IOC rules developed in-house by a SOC however for the most part, almost without exception, these solutions come at a premium. The solutions on the market with these capabilities are fantastic when used correctly during Incident Response or for proactive monitoring however for 90% of organisations, they simple are not within the average CTO/CISO’s budget. Ricardo’s method takes the power of Yara and makes it accessible to all organisation, allowing for them to inspect endpoints for IOC’s at a fraction of the cost.
Yara is a powerful pattern matching solution which uses boolean logic to classify and in this case, detect suspicious files. You can learn more about Yara here
I wanted to add some additional depth and use-cases to Ricardo’s approach and so here is the short version of his design.
Using the code provided in the aforementioned SANS paper, we are able to compile an executable file to be used by the clients, and a REST server which hosts our .Yar rules. The example below is the same code as demonstrated in Ricardo’s paper.
At run time, the .Exe accepts arguments such as the directory in which to scan, and the name of the .Yar file which should be used. The .Exe then makes a GET request to the REST server to collect the named .Yar file and completes the scan on the endpoint in the specified directory. If a positive match is found, the .Exe then makes a PUT request and posts the Hostname, Location/Filename and Rulename back to the REST server. This allows Incident Response & Security Analysts to sweep an environment for a particular indicator. This is not dissimilar to Mandiants MIA solution although uses Yara instead of OpenIOC.
Distributing the .Exe to endpoints is also briefly covered in the paper however any of the usual software distribution methods should be able to push this to selected hosts without too much pain.
The logic behind these GET/Yara/PUT request is shown in the figure below:
Once a scan is completed, the PUT request appends positive detection into a file called “Results.txt” on the REST server, in the format Rule Name/File Name/ Host Name.
YARA REST Challenges
While this approach is great for cost saving and handling host IOC’s, it does come with challenges.
The applications of Ricardo’s Yara Rest allow for InfoSec teams so sweep a network/domain for IOC’s and collect those results in a central location. The REST server collecting the PUT requests will quietly sit inside/outside your network (SSL/TLS is recommended particularly for external usage) and collect those positive results in the Results.txt file.
For Incident Response, this is great. The team can swiftly deploy an agent with a signature and simply monitor the Results.txt file for hits however this can become a problem if the following are considered:
- Requires regular or constant manual monitoring of the Results.txt file.
- Ties up an IR resource.
- Alerts can easily be missed or cause delays.
I’ve tried a few solutions to this problem over time and discovered the best solution is to integrate with your SIEM/Log collecting solution of choice.
Most recently I have had success integrating the logs generated on the REST server with LogRhythm and have also spoken with Ricardo recently who has experienced positive results with HP ArcSight, however any SIEM/Log aggregation tool that allows you to create your owning parsing logic should work just as well.
The objective is to collect the logs in real time from the Results.txt file and parse them as they come into the SIEM solution which allows Security Analysts to triage that alert and escalate to Incident Response teams as soon as the alert is triggered. Linking your alerts up with an SMTP server will also allow direct alerts to be emailed to the relevant teams if needed.
In order to collect the logs into LogRhythm you can use the System Monitor Agent provided by the vendor and install this on the REST server. Configure the agent to monitor the Results.txt file which, once complete, will feed each line change into LogRhythm in real time.
As the results enter LogRhythm, you will need some logic to parse the logs into something more structured. The following regular expression works well within LogRhythm.
Now that you have the logs from Results.txt being collected by the System Monitor Agent and ingested into the SIEM solution correctly using the logic provided, you simply need to create some type of alert or alarm which notifies a user/team of a new detection. In this case you can see an Alarm triggered with LogRhythm below. Drilling down into this event will reveal the hostname, rule that was triggered and the location of the suspected malware.
A handful of simple use cases can quickly be introduced once SIEM integration has been completed…
- On demand domain sweep…. During Incident Response, quickly create your .Yar rules and publish to the REST server followed by a emergency deployment of the .Exe agent to perform the scan. Monitor your SIEM solution for positive results and respond to hosts identified accordingly.
- Continuous IOC monitoring… Collect a library of .Yar rules based on IOC’s collected over time. Then integrate .Exe with your corporate gold build and create scheduled tasks/edit registry keys to run regularly sweeping the endpoint for specified .Yar rules. Any suspicious files introduced to the environment that match an IOC will be detected and the Security Team will receive an alert from the SIEM.
Of course, the downside of this method is the same as any other home made solution and that there is no support. The team using this will of course require a certain skill set to capture, analyse and collect IOC’s from malware which are used to create signatures and then of course require reliable infrastructure where rules can be hosted. You may find a little investment is needed here in order to build the right infrastructure.
Weighing up the benefits Vs cost of these solutions vs premium products will ultimately shape the direction your team may choose however it never hurts to have a fall back which is entirely controlled by your own organisation and is not reliant on 3rd party vendors.
Thank you for reading, please subscribe and comment with any questions or suggestions below.