LinkedIn
Twitter
In our previous post, we covered an introduction to Chronicle SIEM with a focus on using variables in YARA-L to build detection rules.
In this post, we’ll focus on using event operators and modifiers that demonstrate the flexibility in building detection rules with YARA-L basics.
Follow along in the video below.
When it comes to YARA-L rule building, we need a way to build event criteria for our detections. Operators and modifiers provide some of the essential tools in our toolkit to make this happen.
When working with repeated fields, we also have any and all, which help us work with those fields as well.
Let’s start by taking a look at modifiers and operators in action.
Examples using modifiers and operators
Follow along in the video starting at 0:35 to see examples in action.
Our first example is going to be working with an unusual location link file rule. and, or, not can be used within the events section to build out search criteria. and is assumed in the absence of other operators.
Our rule has four different event type values and we’re using parentheses and the or operator to logically group this portion of our criteria.
The second part of our criteria is looking for strings within the target.file.full_path field.
The operators between the end of the parentheses and the other fields are all optional because they’re outside the parentheses. If they were inside the parentheses, you would need to have the and operator or you would get a syntax error.
The not prepended to the second file.full_path field indicates that we’re looking for link files in folders other than Desktop, Documents, and the Start Menu.
If we wanted to look in those specific places, we could just remove the not.
nocase is used by appending it to the end of a field and value and gives us a lot of flexibility when matching against command lines and other fields that contain user input. With nocase, I don’t need to worry if a folder, command, user, etc., is mixed case, uppercase, or lowercase - it just takes the guesswork out of it.
However it’s important to note that for enumerated fields like event type, nocase will throw a syntax error. That’s because all enumerated fields are always uppercase only. If you’re wondering which fields are enumerated, the UDM field list covers this. It’s a great reference to have handy.
Our other rule is really simplistic, but it highlights how the any and all modifiers can work with repeated fields.
Repeated fields handle items like multiple IP addresses associated with a system. In our example, we’re looking for a user login from a system that has a specific set of IP addresses.
Because IPs are repeated fields, specifying principal.ip = “X” and principal.ip = “Y” would fail because a field cannot be two values at the same time.
However, by prepending the word any to both pieces of IP address criteria, it allows us to look through all of the repeated values for that IP address and say, basically if any of the IP addresses that match this first string and any of the IP addresses match the second string, we meet our criteria.
The term all works nicely if you’re saying all IP addresses do not equal a value.
Generally, a good rule of thumb is to use the any and all terms whenever you’re working with a repeated field.
You’ll see more rules that build on these concepts, but for now, remember that and, or, and not are used to link different event criteria together with the help of parentheses.
nocase takes the guesswork out of fields that could have different values in mixed uppercase or lowercase.
any and all help with repeated fields to give more flexibility to find the values we care about most.
