Example blog

Splunk: Introducing Synthetic Antagonist Log Objects (SALOs)

Splunk’s SURGe team is constantly exploring new ways and tools to make our lives easier. Today we would like to share some of this work with you. Before we dive into the what and the how, I would like to briefly explain the why.

Last year, while 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 publication of a white paper titled Detecting Supply Chain Attacks: Using Splunk and JA3/s hashes to detect malware activity on critical servers. During our research, we found that we have a wealth of data such as syslog, netflow and windows event logs. However, in many cases, we did not 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 malicious environments, logging, and events. Fortunately, Splunk’s Threat Research Team (STRT) created Attack Range, which makes simulated attacks much easier than before, but the process can still be difficult, time-consuming, and expensive. We knew there had to be a more efficient way to replicate log events to solve this problem.

A better way with Synthetic Antagonist Journal Objects, or SALO

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

“Synthetic Adversarial Log Objects (SALO) is a framework for generating 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 enable security practitioners, data scientists, and researchers the ability to create log events in a simple, repeatable, and random way without the overhead of traditional resources required.”

Let’s look at a simple example of what SALO can do. We’ll 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 contents below in it.

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

We can customize the output to our liking by making simple (or much more complex) changes to our recipe file. Do you want to replicate the logs for a Cobalt Strike or Sunburst DNS query? Just use a recipe and you’re set. There is much more to SALO. We’ve only covered part of the tip of the iceberg. For more examples of what SALO can do, see the project 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 directly from SALO directly into Splunk.


Want to know more about SALO? You’re lucky. SALO was presented at the Carnegie Mellon University Software Engineering Institute’s annual conference, FloCon 2022. The presentation, Generating Known Unknowns Through Known Knowns, is available on the FloCon 2022 website. The conference organizers were even kind enough to publish 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 an eye out for updates on our website.

Source link