return
Threat detection is the key step for organizations' cyber defenses, it is the way we clearly feed our protection and response systems. It is only by finding that active threat that we can act, isolate, eliminate, deceive or improve cyber threat models.
Exploring some examples based on the previous statement, we notice that there are many cases where it is possible to act in our favor without the need to have made any type of detection, by activating a firewall, deploying an antimalware solution, or using a complex password. However, this is not entirely true, as all the protective actions we apply (whether preventive or reactive) are based on an understanding of threats that have been previously modeled, as in the case of more comprehensive strategies such as the Principle of Least Privilege (PoLP), the old and beloved defense in depth, or the Zero Trust model.
With this in mind, we will now focus on the behavior of cyber attackers and how it is possible to distill usable detection rules ufrom a set of hypotheses. In this post we will analyze the logic behind behavior-based detection, some languages for the generation of exportable rules and a dynamic detection model known as “Detection as Code”.
From technique to detection
We will take some techniques commonly used within the cyber attack chain to analyze them, in this case we will use as a reference the MITRE ATT&CK matrix in the context of threat hunting (you can learn more about it in our previous post)
T1087.004 - Account Discovery: Cloud Account
Let's start by getting a little ahead in the stages of a cyberattack and take as a reference the "Account Discovery" enumeration technique in its "Cloud Accounts" variant. This technique, like most enumerationtechniques, is based on the premise that the cyber attacker might try to collect a list of additional items that allow him to expand his attack, for this particular technique, the data discovered can be users and roles within a cloud service (Azure AD, Google Workspace, IaaS, Office 365, SaaS).
Recognizing this behavior, we analyze the specific way in which a cyber attacker could carry it out in practice. To be specific with our example, we will focus on the Azure command interface (AZ CLI). MITRE ATT&CK proposes the command "az ad user list" as a sample. A possible output of this command with some parameters would deliver user specific data.
A hypothesis then to start with "our distillate by detection" could be:
From the point of view of "detection" we can see that the degree of accuracy of this assertion is low, since we can find several cases in which we find this behavior and it is not an attacker. For example in the implementation of some kind of solution by a cloud administrator, even some identity management software that performs queries through the same API. We should here refine our hypothesis to improve accuracy, for example:
This new definition increases the degree of accuracy, but on the other hand it limits the scope, as we can only detect this behavior if the originating terminal is unknown (and it is not always).
Accurate detection brings us closer to the bottom of the pyramid. Exhaustive detection brings us closer to the top. There are no right answers, we constantly combine both strategies (Signatures + Heuristics).
The right size will depend on our detection objectives and the risks associated with the asset we ultimately want to protect.
On the other hand, moving forward with the practical implementation of this detection and from the perspective of 'requirements' to carry it out, the triggering element could be continuous monitoring of commands executed through the 'Azure CLI' interface. This detection source is not trivial, like a pre-configured audit log, which is why we need to shape the detection from other observable elements according to the technologies we have. It is necessary to find alternatives, such as focusing on terminals that could execute commands in Azure CLI and monitoring the execution history in PowerShell, or other types of strategies to also cover executions from Azure Cloud Shell, for example.
T0878 - Alarm Suppression
Let's move now to a different environment and focus on tactics that are more related to some kind of impact on industrial environments. "Alarm suppression" is a technique that falls under the MITRE matrix specific "Response Function Inhibition" tactic for ICS or Industrial Control Systems (You can go deeper into ICS or OT in this post or stand on the attacker's side in this post).
This technique involves the inhibition of an alarm function aimed at alerting an operator of a critical situation in the system. This type of technique, contrary to the previous one, is focused on specific devices of industrial networks (e.g. PLC / Scada systems).
This technique is usually applied, for example, by modifying or suppressing a system of warnings and report messages, or even by altering the data displayed on an HMI type interface. There are several ways to approach this technique depending on the types of alarms and devices involved in the operation, but we can draw some hypothetical examples:
This hypothesis will require as "data sources" some kind of network traffic monitoring, or integrity monitoring of the programs involved in the devices, for example.
The translation of these hypotheses into an operable language in the form of logical rules will be our next step to then deploy different use cases on our infrastructure. Always considering the previous factors which will allow us to adjust the precision of each one.
About detection rules
Large-scale detection of malicious activity within the infrastructure then becomes complex if we want to take techniques one by one and define them for each of their particular variants. Consuming detection rules from the community, a vendor or other organizations has the difficulty that each of these have different detection solutions, log types and strategies to define their protection. Each SIEM even has its own query languages.
What are the SIGMA rules?
SIGMA rules are an open source signature format that allows to write detection rules considering any input record and in a standardized form. These have a syntax in yaml format and can then be converted (or translated I like to say) to the syntax of our preferred SIEM or the platform used in the organization.
We take as an example a sigma rule from a community repository found in a SigmaHQ project library (here), in this rule the behavior to detect is the connection of a possible attacker from an affected system to an external service for "Command and Control” (C&C TA0011) through the onion network (Multi-hop Proxy T1090.003). The particular technique makes use of the TOR browser to accomplish its mission, this is the detection rule:
We can interpret for this example that the detection is based in principle on the names and locations of the executed binaries, specifically for Windows environments. The careful reader will know that these rules should be refined to improve their accuracy.
A guide to understand the syntax of this type of rules for the creation of new rules can be here.
Next, in order to make use of this sigma rule, we can convert it to a format understandable to our preferred detection solution, a SIEM such as IBM's QRADAR, leaving us with a query in the following form:
This conversion can be done manually by understanding the syntax of both pseudo-languages or we can use available tools such as the undercoder.iotranslator.
Sigma rules are just one example of a format to perform screening decisions, which can also be found with different applications and scopes:
Detection as a Code
At the end of the day, security analysts already have a concrete detection rule, applicable to their security systems and based on well-known behaviorwithin a cyberattack. But engineering detection requires much more than the creation of a good rule, it requires driving a set of rules that will constantly be modified, refined, added to and deactivated.
What if we carry out this operation using some known framework that has that dynamism of continuous integration and delivery? This is how the concept of Detections as a Code is being improved as a means to sustain a dynamic and efficient detection using DevOps.
This approach allows us to count for example with some of these characteristics:
Here is an excellent diagram of the entire flow of creation and distribution of detection rules, prepared by Matt Bromiley in his paper "Detecting Malicious Activity in Large Enterprises":
Some conclusions
In the process of distilling behavior to obtain a way to detect malicious activity, we will be tempted to think that a logical control can close a door to the attacker. A very restrictive firewall rule that limits access to the Internet is an excellent measure, but it will not replace the need to detect C&C traffic within the network.
The "generic" detection that we can find in the mere fact of deploying a protection solution such as an EDR, a WAF, or an IPS has a lot of value, protection as a good practice should start from the most comprehensive measures to the most specific measures. There is no point in relying on hypotheses to detect "advanced" behavior if, on the other hand, we cannot see what privileges are assigned to users, for example.
The field of AI is providing us with a host of tools that are becoming more and more readily available, incorporating machine learning into "detection as code" is a practice that will further enhance the capabilities of SOC teams to operate more efficiently and effectively.
