The AT&T Cybersecurity Alien Labs team is in charge of writing correlation rules and releasing threat intelligence updates on a day-to-day basis. When researchers in the team find new malware families or threats, we always try to find the best approach to keep our customers protected. In this blog, we will look into some of the differences between signatures and correlation rules.
Signatures are the values (sequence of bytes, string patterns, etc.) that security products use to detect known malicious behavior. For example: Snort/Suricata rules, antivirus signatures and YARA rules.
On the other hand, correlation is the processing of the event stream in order to identify important events or patterns of events within large volumes of data. The logic to identify these events is defined in a correlation rule.
Benefits of correlation rules:
- Correlation rules are based on behavior and not on specific indicators, this makes them resilient for long-term detection, identifying malicious behavior even when they have mutated over time.
- They can be used to map events from different data sources, no matter if the events are coming from network, endpoint agents or other security products. This cross-platform functionality makes it possible to use events from different sources to perform more complete and resilient detections.
- The ability to use event flows allows a context to be added to the detections that can be used both to improve the information reflected in the alarm and to aid in an incident response phase.
To clearly see the advantages of using these correlation rules and how they usually complement traditional rules, we will look at some examples like Baldr stealer, Ursnif banking Trojan and ALPC 0-day vulnerability and how we find the best approach.
Example 1: Malware versioning
In this first example, we will cover how a malware family can evolve with time and how the behavior and configuration can change between versions. In those cases, signatures can lose their detection criteria and stop triggering alerts. A great example of this is the Baldr malware that has been present since January 2019 and has presented major modifications through different versions.
Sophos has written a great report called Baldr vs The World where you can find a lot of information about this malware and also compare the differences of version 2.x with version 3. If we analyze some of the samples to see the network connections performed to command and control server, we can easily observe the differences introduced in every version release.
Baldr version 1.x.x
The first discovered version of Baldr was using a simple HTTP POST request with victim’s information contained in the URI. As you can see, it makes so easy to write a NIDS signature to detect the pattern within the network packets.
Baldr version 2.x
In the second version, or at least in version 2.2 and above, they changed the previous request and now the communication with command and control is encrypted with a XOR key. Here we can see the initial beacon where XOR key is always sent to the victim along with the version separated by “;” delimiter, more difficult to detect with signatures but still possible.
Baldr version 3.x
Finally in the third version, the communication method is pretty similar to the one used in the second version and they are still using a XOR key. However, they changed the delimiter by “~;~” and now they are also sending some configuration settings. These changes force us to create a new signature.
Knowing that, it is clear that network signatures written for version 1.x.x won’t work with versions 2.x and 3.x, the same thing happens with signatures for 2.x and 3.x. This scenario makes us think that if there were a new version, it would not be detected with the existing signatures and we will need to keep researching and creating new signatures whenever a new version of the malware is released.
Instead of that, we could try to observe all the actions performed by malware from the initial attack vector to the final command and control communication and correlate the events to create a detection. Based on the research made into the malware family, attackers used two different methods to distribute and infect victims: crafted ACE files, which exploit the WinRAR CVE-2018-20250 vulnerability and also RTF documents targeting Microsoft Office products with CVE-2018-0802 vulnerability.
Correlation rules could have helped us detect those attacks from the initial access phase and from the actions performed in victim’s systems. Here is a list of possible pseudo-correlation rules:
- Multiple emails received from outside company with same sender, subject or attachment name to multiple different recipients and file extension for attached files should be in a list of interesting file types to monitor.
- A file being dropped and executed by WinRAR executable, especially if the file is dropped in a user writable folder or if the compressed file comes from an email or from a browser download.
- A file being dropped and executed by a Microsoft Office product, especially if the file is dropped in a user writable folder or if the document comes from an email or from a browser download.
Example 2: Malware with many indicators
Sometimes a malware family is difficult to detect because it doesn’t use HTTP for beaconing, the communication is hidden or any other circumstances. A common approach when you can’t detect the communication is to keep track of all the malicious infrastructure to keep updating the indicators, making it very time consuming and inefficient. This is the case of Ursnif malware, a banking Trojan that tries to steal user information such as account credentials. If we take a look at the existing signatures for this malware, we will find a large amount of NIDS signatures and YARA rules that tries to detect some of the indicators of compromise present in the samples.
On the other hand, correlation rules can be used to detect malicious patterns in the behavior and benefit from the advantages discussed above. The following correlation rules could detect the Ursnif malware without the need to update or create new signatures whenever new indicators are present.
- Multiple emails received from outside company with same sender, subject or attachment name to multiple different recipients and file extension for attached files should be in a list of interesting file types to monitor. (same as first example)
- Suspicious chain of processes created by a Microsoft Office application.
- A legitimate system’s process name (explorer.exe) being created by wrong process parent.
- Registry key with auto start functionality added.
- Dropped file with suspicious double extension.
Example 3: New malware or attack with no existing signatures
Another interesting scenario to demonstrate the advantages of correlation rules is when a new malware or attack begins to appear and there is no signature present to detect it. In those cases, an existing correlation rule, looking for suspicious behaviors that normally don’t happen in a system, could detect it.
To explain this example we will talk about the ALPC 0-day vulnerability affecting Microsoft Windows systems. This vulnerability was publicly released without any patch and many systems were vulnerable to it. Since it was a local privilege escalation (LPE) and only a proof of concept (PoC) was available, network and endpoint signatures were nonexistent and not enough to detect a possible exploitation. By doing quick research about the method used to perform the privilege escalation, the list of correlation rules that detects the threat is:
- A file being dropped and executed as SYSTEM user from a user writable folder.
- A hard link being created to a file into Task directory and then a permission changed for the same file.
- A creation of new suspicious scheduled task.
Important things to keep in mind
We have talked about the benefits and advantages that correlation rules provide when we want to create detection methods. However, there are also some important things to take into consideration: there are no silver bullets in security, and it is better to be conservative and complement different methods and technologies to improve your detection capabilities. Use regular signatures and IOCs whenever you can, as they are fast to write and deploy, and have very high confidence.
Some of the cons of using Correlations Rules are:
- Correlation rules are more likely to have false positives if not designed properly, so your team will need time and expertise to triage them in a timely manner.
- They take more time to research and develop than signatures.
- It’s not enough to have the sample-- you need to understand how they are used in a compromise. You need to understand the behavior and look into a large number of events from different sources.
