Introducing Synthetic Adversarial Log Objects (SALO)

The SURGe team at Splunk is always exploring new methods and tools to make our lives easier. Today we’d like to share some of that work with you. Before we dive into the what and how, I’d like to briefly explain the why.

Last year, when we were all still reeling from the impact of the SolarWinds compromise, we took a step back to identify areas where we as a team and community could improve. This resulted in research and a published white paper titled Detecting Supply Chain Attacks: Using Splunk and JA3/s hashes to detect malicious activity on critical servers. During the course of our  research, we found that we had a wealth of data such as syslog, netflow, and windows event logs. However, in many cases we didn’t have the exact data we needed to test and explore different hypotheses or detection methodologies. As a result, we had to build extensive infrastructure to replicate environments, logging, and malicious events. Thankfully, Splunk Threat Research Team (STRT) created Attack Range making simulated attacks much easier than in the days of yore, but the process can still prove challenging, time consuming, and costly. We knew there had to be a more efficient method to replicate log events in order to tackle this problem. 

A Better Way with Synthetic Adversarial Log Objects, or SALO

A better way you say? Let’s explore. Recently, I open sourced a new tool called Synthetic Adversarial Log Objects, or SALO. I know, it sounds nifty, but what is it really? To quote the project’s extensive documentation:

“Synthetic Adversarial Log Objects (SALO) is a framework for the generation of log events without the need for infrastructure or actions to initiate the event that causes a log event. The purpose of this framework is to allow security practitioners, data scientists, and researchers the ability to create log events in a simple, repeatable, and randomized way without the overhead of traditional required resources.”

Let’s look at a simple example of what SALO can do. We will start with a new yaml file that details our desired log output (in SALO parlance, this is a recipe). We will name this file dns.yaml and save the content below into it.

Viola! Once we run SALO, the tool generates a random log event in the exact schema of a default Zeek dns.log event.

We can customize the output to our heart’s content by making simple (or much more complex) changes to our recipe file. Want to replicate logs for a Cobalt Strike or Sunburst DNS query? Simply use a recipe and you’re set. There is a lot more to SALO. We’ve only covered a portion of the tip of the iceberg. For more examples of what SALO can do, check out  the project's documentation as well as some more complex scenarios in the code repository.

Oh, one last thing. Since this is a Splunk project and we want to make it as simple as possible, you can also send events straight from SALO directly into Splunk. 

Conclusion

Want to learn more about SALO? You’re in luck. SALO was presented at Carnegie Mellon University Software Engineering Institute’s annual conference, FloCon 2022. The presentation, Generating Known Unknowns Through Known Knowns, can be found on the FloCon 2022 website. The conference organizers were even kind enough to post a video of the presentation online. 

As with all of our projects, if you find SALO useful or have ideas on how to improve the project, we’d love to hear from you! The SURGe team here at Splunk will have many more fun projects to share in the future, so keep your eyes peeled for updates on our website.