The goal of a Threat Hunter is to find an attacker in the middle of an attack before they can cause damage. This entails hunting through thousands of requests trying to pick out the malicious telemetry emanating from thousands of endpoints that looks like hundreds of different users. The task becomes exponentially more difficult as the volumes increase. As an example, one of our customers was a recent target of an attack that reached 50,000 requests per minute. If we assume that 10% of the traffic is attack-related, the Threat Hunter has to perform the near-impossible task of analyzing 5,000 requests per minute. In this scenario, the term “hunting” is apt as it implies the potential for going home empty-handed.
Why Manual Threat Hunting Doesn’t Scale
The only way that a threat hunting team can keep pace with automated attacks is to either add more resources (people), or use automation, much like the attackers do. Automated threat hunting (analytics) tools detect when the traffic is valid and when it isn’t by analyzing hundreds of signals within the application requests such as:
- Which users are compromised or otherwise problematic
- IP addresses the attacker may be using from a proxy network
- Whether or not the user agent or browser is valid
- Attack behavioral factors such as rotating users, IP addresses, user agents, cookies, headers, and anything else that an attacker will use to make the traffic seem legitimate
Using automation to sort through 50,000 requests per minute will only go so far, perhaps surfacing users coming from too many IPs originating from Bulletproof Proxy Networks or an individual user with 55 different browsers. But remember we have to find 5,000 per minute.
Automation alone hits a ceiling here. Correlating IP reputation, user-agent anomalies, and behavioral drift across tens of thousands of requests a minute isn’t something an analyst can do by hand, and stacking more detection rules onto a signals-based system just produces more alerts to triage. A team drowning in alerts spends more time ruling out false positives than finding the 5,000 requests that actually matter.
From Hunting to Catching
Enter the concepts of Machine Learning and Artificial Intelligence, the foundational elements of our analytics engine, which enables Threat Hunters to move from hunting to catching. Our standard onboarding process is to configure Cequence to receive and analyze traffic from the applications a customer needs to protect.
No custom code or development efforts are required; Cequence needs to see and analyze either all or some of the traffic. The next step is to begin “training” the ML models with interesting elements inside the traffic. We can point to login flows and identify good and bad login behaviors. We can point to standard requests to train the models to understand where there should be uniqueness and where there won’t be. As Cequence analyzes the traffic, the attacks begin to surface, based on predefined ML models. In many cases, the ML models don’t need training as the defined characteristics being “hunted” are well understood. This means the process of analyzing traffic entails both automatic identification of threats as well as “training” to ensure maximum efficacy over time.
Training time varies by traffic type. Login flows tend to converge quickly, since credential stuffing and account takeover attempts have well-documented behavioral signatures. Less common request patterns take longer, because Cequence needs enough legitimate traffic to establish what normal looks like first. Retraining isn’t a one-time exercise, either – attackers retool constantly, rotating proxy networks and user agents the moment a detection starts working against them.
Turning Detections Into Mitigation Policies
The next step is to translate threat findings into mitigation policies based on a wide range of factors. Stacking policies and enabling mitigation allows Cequence Bot Management to take simple steps like marking the traffic for the customer to further analyze. We can block the traffic if desired or we can be a bit more mischievous and trap the traffic in a honeypot and let the attacker think they have succeeded.
Which mitigation option makes sense depends on what the customer needs from that traffic. Marking suits a team still investigating. Blocking suits a confirmed attack where the priority is stopping the drain on infrastructure. Honeypotting serves a different purpose: it keeps the attacker engaged with traffic that looks real but tells them nothing useful, buying time to study their tooling.
Catching Attacks Without Client-Side Code
Once Bot Management are configured and running, the act of Threat Hunting transitions to catching with periodic tuning as attackers retool and watching for anomalous signals that indicate attacker traffic. Oftentimes, we will be challenged with the question of how can you prevent bots when you are not integrating JavaScript or an SDK into the web or mobile app? The answer lies in the power of the 150+ customizable ML models built into Cequence, which allows a minimally staffed team to easily keep pace with the attack example above of 50,000 requests per minute.
That combination changes the staffing math: a team can scale detection coverage by tuning models instead of hiring analysts to read more logs. The volume in the example above isn’t an edge case – it’s what Cequence is built to handle as a matter of course.
