Hello! I'm working on a YARA-L detection project and need some guidance. I'm trying to create a rule to detect if the same user connects to the same domain at regular intervals. Here's what I have so far:
I want to track the times of each connection (for example, if a user accesses Spotify 4 times within 10 minutes) and calculate the time differences between each connection. My goal is to determine if the connections happen at consistent intervals (e.g., every 2 minutes), which could indicate beaconing behavior. If the intervals aren't consistent, I want to ignore them.
After researching, I found that YARA-L doesn't support complex functions for this kind of stuff. What do you recommend as an alternative to functions? Any ideas would be greatly appreciated!
However, the following rule logic should work, and identifies two events where the timestamp between both are equal to 120 seconds (2 minutes) matching via the host and domain over a 10 minute period.
This can be extended to capture for example 4 events, all occurring 120 seconds within each other, matching on the host and domain over a 10-minute period. The logic for this would be as follows and can be extended. However it is worth noting utilising this sort of logic will likely impact the detection engine's capabilities and could result in a rule body error, or an increase in time to generate an alert. Unfortunately within the instance, this testing is taking place, no events match the criteria to generate an alert, but should work like the above example 🙂
However, the following rule logic should work, and identifies two events where the timestamp between both are equal to 120 seconds (2 minutes) matching via the host and domain over a 10 minute period.
This can be extended to capture for example 4 events, all occurring 120 seconds within each other, matching on the host and domain over a 10-minute period. The logic for this would be as follows and can be extended. However it is worth noting utilising this sort of logic will likely impact the detection engine's capabilities and could result in a rule body error, or an increase in time to generate an alert. Unfortunately within the instance, this testing is taking place, no events match the criteria to generate an alert, but should work like the above example 🙂
