LinkedIn
Twitter
In our previous post, we covered using event operators and modifiers that demonstrate the flexibility in building detection rules with YARA-L basics.
In this post, we’ll focus on building a single event rule in Chronicle SIEM using a regular expression, which will serve as a foundation for future rule building concepts.
Follow along in the video below.
Chronicle uses Google’s re2 software library for regular expressions. It’s similar to other regular expression libraries in terms of syntax, which lowers the learning curve for use with Chronicle. It can be used in a few different ways in YARA-L.
While there is a function for regular expression matching today, we’re going to use the forward slash notation, which can also be used in UDM search.
Any field that a user can input values into is a good candidate for a regular expression.
In our example, we’re going to look at using regex with values from a command line, where there can be a tremendous amount of variability.
To illustrate this, below are a series of Windows admin shares that connect to c$, admin$, and ipc$ from one system to another.
The net use command could use mixed case, have additional spaces, map to any drive letter, map to any of these three shares, or contain a prepended path to the net use command.
All of these permutations make string matching extremely difficult, however this can easily be solved with a regular expression.
Example of a regular expression
Follow along in the video starting at 1:53 to see the example in action.
We’re going to build a rule that detects when Windows administrative shares are launched using the net use command.
The use of these shares aligns with the MITRE ATT&CK technique, Remote Services, and the subtechnique, SMB/Windows Admin Shares, which is part of the tactic, Lateral Movement. We’re going to include these descriptors in the meta section of our rule so other users can better understand what our rule is detecting and providing coverage for.
As we build our regular expression in our rule, we need to think about the key values that we can use in our criteria versus the values that might have more variability.
Start by clicking the “New” create rule button in the rule editor in the top left corner of the screen. Chronicle will present us with a rule template.
Let’s start by naming our rule, t1021_002_admin_shares since t1021.002 is the attack technique ID. Because we want our rule to be easily understood by others, I’m going to paste the metadata into the meta section of the rule.
In the events section, we’ll start by adding the enumerated value for metadata.event_type of process launch to focus our rule on a subset of our events.
From there, I’m going to inspect the target.process.command_line field for values that would indicate the creation of Windows admin shares.
Based on what we discussed previously, some common values when creating a Windows admin share would include the net command, the use option, as well as the share names, c$, admin$, and ipc$.
The path, the drive letter, and the server values are all variable, so including them in the regex statement would not be ideal, unless we were focused on a very specific subset of systems.
Regex statements can use the forward slash to start their match, which is where we’ll start. Because net may or may not be the first character of the command line, we’ll just start with n e t. If we wanted to force n e t to be the first characters in the field, we would start our expression with a caret (^). By just starting our expression with net, re2 will find that pattern anywhere within our field and match from there.
Now let’s talk about wild cards for a moment. Because net use could contain net.exe use or net use and still be valid, we can enter .* between the words net and use to basically say, find the pattern, net, and then find anything until we get to use.
We can also use parentheses () and pipes || to separate values and compare each one with an or statement between them. So when we see (c|admin|ipc), this means c or admin or ipc.
The $ after the parentheses would be appended to the values in the or statement, so we end up looking for c$ or admin$ or ipc$.
Don’t forget that some characters, like the dollar sign, have special meaning in regex, which is why we would prepend an escape character of backslash to the dollar sign. Because we have the backslash dollar sign, it would then be treated as an actual dollar sign and not the end of an input. Then we add a forward slash to close the regex expression.
And of course, we want to add the nocase modifier to the end of our criteria. We could force case using re2, but the nocase modifier is so easy to use, why not use it?
The last section we need is the condition section. In this example, we just need to include the event variable, which we defined earlier, $process.
With that, let’s test our rule and see if we get the detections we expected. Notice that we’ve detected target.process.command_line with different drive letters and different shares. With our regex statement, this is much easier to do.
Once we’re happy with our logic, you can go ahead and save the rule.
Remember that when it comes to using regular expressions and rules, that the re2 syntax can be leveraged to streamline your detection. The rule criteria can be set to use regex by wrapping your values in forward slashes. And don't forget to use the nocase modifier.
Finally, any field that leverages user inputs is a great place to consider using regex. This isn’t an absolute by any stretch, but is definitely a good place to start.
