Predictive Defense: How to build Early Warning System with examples
Introduction
Predictive approach aims to organise cyber defense based on scenarios with probability to materialize in the future, unlike the traditional approach that relies on what has already happened. It utilizes predictive analysis methods and a red team perspective.
As a result of these efforts, two types of predictions are obtained: forecasts (long-term) and early warnings (short-term). Forecasts provide information about conditions that may occur in the long term (1+ year) and assist in shaping security strategy. Early warnings, on the other hand, provide us with information about impending attacks (ranging from a few weeks to one month in advance) and enable us to initiate preparatory activities early.
In this article, we will focus on the second type of prediction, which is early warning.
Research Methods for Early Warning System
In previous articles, we discussed that there are various approaches that can be used to create an early warning system. However, we can categorise all of these approaches into two groups:
Profile-driven research methods
Correlation-guided research methods
Profile-driven Research
The actor-centric method can be primarily defined as tracking the digital footprints of actors of interest. This can involve monitoring the patterned behaviours of actors in attack preparation or observing their activities on forums or similar platforms. This method requires an analyst to closely follow an actor or a series of cyber campaigns. While it demands more resources, it produces more reliable and actionable signals. This method is particularly useful when dealing with persistent actors targeting your organization.
Here is an example:
Leery Turtle — Tracking the Actor’s Attack Preparation Stages
When these attacks were investigated, some characteristics were discovered in the C2 servers used in the attack. The following signs were defined for the observed characteristics.
Purchase of a new domain with the same pattern as Leery Turtle, containing at least two of the words google, drive, cloud, share, upload. (Sign 1: potential Leery Turtle domain)
Having ports 80 and 8080 open at the same time on the server directed by the domain name. (Sign 2: potential Leery Turtle host)
A domain/server was tagged as “Leery Turtle” when both of the conditions we defined met simultaneously.
Full report: Leery Turtle Threat Report
Correlation-guided Research
The second method is based on investigating correlations among various internal and external signals. If these correlations can be found, they can be used as probabilistic indicators of a cyber attack. This method can be implemented with lower costs but produces signals with lower reliability and are not generalisable.
Now, let’s take a brief look at an example of this correlation-based approach, which I discussed in the article “Early Warning Intelligence — How to predict cyber attacks?”
Collecting data
Disclaimer: The example I will discuss below is fictional and does not reflect the data of any real organization.
In the first step, data was collected from various internal and external sources related to various events and visualised on a time series. These events were randomly selected, and in the next step, it will be examined to see whether there is a correlation among them. The events that were selected was:
Darkweb mentions (source: intel vendor)
Exposed credential through infostealer (source: intel vendor)
Phishing/spam emails (source: user reports)
Coupon code sales (source: intel vendor)
DDoS attacks (source: WAF)
Web exploitation attempts (source: WAF)
Azure risky sign-ins (source: Azure)
Investigating for correlations
The second step was to filter out data sets with low variation among them. For example, an event that occurs almost every day renders any correlation with itself meaningless. Afterward, the binary combinations of these events were compared using the correlation function. This process was repeated by shifting one of the compared data sets forward in time. In other words, we’re attempting to find an answer to the question, ‘Is there a correlation between the event A from one week ago and the event B today?’
Then, something interesting surfaced. When the data was shifted by two weeks, a moderate inverse correlation between Infostealer and DDoS events was observed. What this data was telling us is that some of the DDoS attacks were happening in the midst of two Infostealer-related credential leakage events. Despite not giving a strong signal, lets investigate this intriguing occurrence further.
Going down the rabbit hole
Between the seemingly unrelated events of Infostealer infection and DDoS attack, two things needed to be investigated to uncover the connection:
What information was present in the Infostealer logs where credential leaks were detected, and what was the content of other logs published around the same time?
What were the scale, type, and impact of the DDoS attacks?
Upon examining the first case, everything seemed to be normal. The logs we identified were typical Infostealer logs containing passwords, some belonging to the customers and others to the employees. Actions had been taken for all the leaks, and there were no signs of exploitation for the leaked accounts.
However, upon a closer look to the DDoS incidents, something interesting came up. Some of the events classified as DDoS attacks were actually credential stuffing attacks! The attack’s execution involved making repeated requests to the system, and the WAF was categorising them as DDoS attacks. That’s when it hit me.
Constructing the hypothesis
Using threat intelligence sources, I conducted research on credential stuffing attacks. I learned that attackers commonly create custom username/password lists tailored to the platforms they target, using various sources, including data breaches and Infostealer logs. These public sources were easy pickings for the attackers!
The correlation we observed here was likely related to this. Attackers were using publicly shared Infostealer logs to generate new combolists and launching attacks a few days later. With this newfound information, I was able to formulate the following hypothesis:
If accounts belonging to our organization or our customers have been leaked in publicly shared Infostealer logs (and data breaches), there is a 40% probability that a DDoS/credential stuffing attack will occur within two weeks.
Building the Early Warning System
At this point, the system we are going to establish is very straightforward:
Identify and monitor sources where Infostealer logs and data breaches are publicly shared.
Detect compromised accounts belonging to our organization and customers.
Generate alerts if the number of these compromised accounts exceeds a certain threshold.
This series of actions, which can be easily automated, will essentially become our early warning system!
Ok.. so what?
This system, being based on correlation rather than intelligence, cannot produce alerts with absolute certainty. You may rightfully ask, ‘What can I do with information about an attack that may never happen?’ This situation actually highlights how static our current defense approach is. A defense structure that only acts on facts and consistently produces the same type of actions will never go beyond being reactive. That’s why I believe we need to shift our perspectives about cyber defense. While facts are undoubtedly important, we should also incorporate predictions into our defense planning. With more flexible and creative action plans, we can fully harness the benefits of predictions and truly achieve proactive defense.
At this point, I want to introduce a concept that I call temporary countermeasures. These are security controls that we cannot permanently implement for various reasons but could be temporarily useful in situations where the threat level is elevated.
Let’s take an example of an alert generated by the system we designed above. You are expecting a credential stuffing attack with a 40% probability within the next two weeks. In this case, temporarily implementing the following controls can help reduce its impact when the credential stuffing attack occurs.
Adjusting rate limits, bot scores etc. to be more restrictive
Configure k8s pods to use increased resources
Disable certain features temporarily to mitigate impact
If you noticed, these controls are not feasible to implement permanently, mainly due to their cost or the friction they might create for users. However, in high-risk and high-threat environments, the cost of temporarily implementing these controls can become tolerable. A striking example of this is a cryptocurrency exchange that, during an attack, temporarily subjects normally automated withdrawal processes to manual verification, preventing the theft of customer funds.
I hope you enjoyed my post. See you in the next one!