March 4, 2019

The VR Goldilocks Problem and Value of Continued Recognition

Security and Operations Teams face challenges when it comes to visibility and recognition. Learn more about how we find a solution to the problems!

Written by

Max Heinemeyer

Global Field CISO

Inside the SOC

Darktrace cyber analysts are world-class experts in threat intelligence, threat hunting and incident response, and provide 24/7 SOC support to thousands of Darktrace customers around the globe. Inside the SOC is exclusively authored by these experts, providing analysis of cyber incidents and threat trends, based on real-world experience in the field.

Written by

Max Heinemeyer

Global Field CISO

Mar 2019

First, some context about VR

Security Operations teams face two fundamental challenges when it comes to 'finding bad'.

The first is gaining and maintaining appropriate visibility into what is happening in our environments. Visibility is provided through data (e.g. telemetry, logs). The trinity of data sources for visibility concern accounts/credentials, devices, and network traffic.

The second challenge is getting good recognition within the scope of what is visible. Recognition is fundamentally about what alerting and workflows you can implement and automate in response to activity that is suspicious or malicious.

Visibility and Recognition each have their own different associated issues.

Visibility is a problem about what is and can be generated and either read as telemetry, or logged and stored locally, or shipped to a central platform. The timelines and completeness of what visibility you have can depend on factors such as how much data you can or can't store locally on devices that generate data - and for how long; what your data pipeline and data platform look like (e.g. if you are trying to centralise data for analysis); or the capability of host software agents you have to process certain information locally.

The constraints on visibility sets the bar for factors like coverage, timelines and completeness of what recognition you can achieve. Without visibility, we cannot recognize at all. With limited visibility, what we can recognize may not have much value. With the right visibility, we can still fail to recognise the right things. And with too much recognition, we can quickly overload our senses.

A good example of a technology that offers the opportunity to solve these challenges at the network layer is Darktrace. Their technology provides visibility, from a network traffic perspective, into data that concerns devices and the accounts/credentials associated with them. They then provide recognition on top of this by using Machine Learning (ML) models for anomaly detection. Their models alert on a wide range of activities that may be indicative of threat activity, (e.g. malware execution and command and control, a technical exploit, data exfiltration and so on).

The major advantage they provide, compared to traditional Intrusion Detection Systems (IDS) and other vendors who also use ML for network anomaly detection, is that you can a) adjust the sensitivity of their algorithms and b) build your own recognition for particular patterns of interest. For example, if you want to monitor what connections are made to one or two servers, you can set up alerts for any change to expected patterns. This means you can create and adjust custom recognition based on your enterprise context and tune it easily in response to how context changes over time.

The Goldilocks VR Matrix

Below is what we call the VR Goldilocks Matrix at PBX Group Security. We use it to assess technology, measure our own capability and processes, and ask ourselves hard questions about where we need to focus to get the most value from our budget, (or make cuts / shift investment) if we need to.

In the squares are some examples of what you (maybe) should think about doing if you find yourself there.

Important questions to ask about VR

One of the things about Visibility and Recognition is that it’s not a given they are ‘always on’. Sometimes there are failure modes for visibility (causing a downstream issue with recognition). And sometimes there are failure modes or conditions under which you WANT to pause recognition.

The key questions you must have answers to about this include:

Under what conditions might I lose visibility?
How would I know if I have?
Is that loss a blind spot (i.e. data is lost for a given time period)…
…or is it 'a temporal delay’ (e.g. a connection fails and data is batched for moving from A to B but that doesn’t happen for a few hours)?
What are the recognitions that might be impacted by either of the above?
What is my expectation for the SLA on those recognitions from ‘cause of alert’ to ‘response workflow’?
Under what conditions would I be willing to pause recognition, change the workflow for what happens upon recognition, or stop it all together?
What is the stacked ranked list of ‘must, should, could’ for all recognition and why?

Alerts. Alerts everywhere.

More often than not, Security Operations teams suffer the costs of wasted time due to noisy alerts from certain data sources. As a consequence, it's more difficult for them to single out malicious behavior as suspicious or benign. The number of alerts that are generated due to out of the box SIEM platform configurations for sources like Web Proxies and Domain Controllers are often excessive, and the cost to tune those rules can also be unpalatable. Therefore, rather than trying to tune alerts, teams might make a call to switch them off until someone can get around to figuring out a better way. There’s no use having hypothetical recognition, but no workflow to act on what is generate (other than compliance).

This is where technologies that use ML can help. There are two basic approaches...

One is to avoid alerting until multiple conditions are met that indicate a high probability of threat activity. In this scenario, rather than alerting on the 1st, 2nd, 3rd and 4th ‘suspicious activities’, you wait until you have a critical mass of indicators, and then you generate one high fidelity alert that has a much greater weighting to be malicious. This requires both a high level of precision and accuracy in alerting, and naturally some trade off in the time that can pass before an alert for malicious activity is generated.

The other is to alert on ‘suspicious actives 1-4' and let an analyst or automated process decide if this merits further investigation. This approach sacrifices accuracy for precision, but provides rapid context on whether one, or multiple, conditions are met that push the machine(s) up the priority list in the triage queue. To solve for the lower level of accuracy, this approach can make decisions about how long to sustain alerting. For example, if a host triggers multiple anomaly detection models, rather than continue to send alerts (and risk the SOC deciding to turn them off), the technology can pause alerts after a certain threshold. If a machine has not been quarantined or taken off the network after 10 highly suspicious behaviors are flagged, there is a reasonable assumption that the analyst will have dug into these and found the activity is legitimate.

Punchline 1: the value of Continued Recognition even when 'not malicious'

The topic of paused detections was raised after a recent joint exercise between PBX Group Security and Darktrace in testing Darktrace’s recognition. After a machine being used by the PBX Red Team breached multiple high priority models on Darktrace, the technology stopped alerting on further activity. This was because the initial alerts would have been severe enough to trigger a SOC workflow. This approach is designed to solve the problem of alert overload on a machine that is behaving anomalously but is not in fact malicious. Rather than having the SOC turn off alerts for that machine (which could later be used maliciously), the alerts are paused.

One of the outcomes of the test was that the PBX Detect team advised they would still want those alerts to exist for context to see what else the machine does (i.e. to understand its pattern of life). Now, rather than pausing alerts, Darktrace is surfacing this to customers to show where a rule is being paused and create an option to continue seeing alerts for a machine that has breached multiple models.

Which leads us on to our next point…

Punchline 2: the need for Atomic Tests for detection

Both Darktrace and Photobox Security are big believers in Atomic Red Team testing, which involves ‘unit tests’ that repeatedly (or at a certain frequency) test a detection using code. Unit tests automate the work of Red Teams when they discovery control strengths (which you want to monitor continuously for uptime) or control gaps (which you want to monitor for when they are closed). You could design atomic tests to launch a series of particular attacks / threat actor actions from one machine in a chained event. Or you could launch different discreet actions from different machines, each of which has no prior context for doing bad stuff. This allows you to scale the sample size for testing what recognition you have (either through ML or more traditional SIEM alerting). Doing this also means you don't have to ask Red Teams to repeat the same tests again, allowing them to focus on different threat paths to achieve objectives.

Mitre Att&ck is an invaluable framework for this. Many vendors are now aligning to Att&ck to show what they can recognize relating to attack TTPs (Tools, Tactics and Procedures). This enables security teams to map what TTPs are relevant to them (e.g. by using threat intel about the campaigns of threat actor groups that are targeting them). Atomic Red Team tests can then be used to assure that expected detections are operational or find gaps that need closing.

If you miss detections, then you know you need to optimise the recognition you have. If you get too many recognitions outside of the atomic test conditions, you either have to accept a high false positive rate because of the nature of the network, or you can tune your detection sensitivity. The opportunities to do this with technology based on ML and anomaly detection are significant, because you can quickly see for new attack types what a unit test tells you about your current detections and that coverage you think you have is 'as expected'.

Punchline 3: collaboration for the win

Using well-structured Red Team exercises can help your organisation and your technology partners learn new things about how we can collectively find and halt evil. They can also help defenders learn more about good assumptions to build into ML models, as well as covering edge cases where alerts have 'business intelligence' value vs ‘finding bad’.

If you want to understand the categorisations of ways that your populations of machines act over time, there is no better way to do it than through anomaly detection and feeding alerts into a system that supports SOC operations as well as knowledge management (e.g. a graph database).

Working like this means that we also help get the most out of the visibility and recognition we have. Security solutions can be of huge help to Network and Operations teams for troubleshooting or answering questions about network architecture. Often, it’s just a shift in perspective that unlocks cross-functional value from investments in security tech and process. Understanding that recognition doesn’t stop with security is another great example of where technologies that let you build your own logic into recognition can make a huge difference above protecting the bottom line, to adding top line value.

Written by

Max Heinemeyer

Global Field CISO

Inside the SOC

Written by

Max Heinemeyer

Global Field CISO

The Darktrace Community

Watch the NIS2 Webinar

Blog

July 1, 2025

Pre-CVE Threat Detection: 8 Examples Identifying Malicious Activity Prior to Public Disclosure of a Vulnerability

Can you detect cyber threats before the world knows about them?

Every year, tens of thousands of Common Vulnerabilities and Exposures (CVEs) are disclosed, over 40,000 in 2024 alone [1], and a predicted higher number for 2025 by the Forum for Incident Response and Security Teams (FIRST).

However, cybercriminals don't wait for disclosure. They exploit zero-days while defenders remain in the dark.

Traditional, signature-based tools struggle to detect these early-stage threats. That’s why anomaly detection is becoming essential for organizations seeking pre-CVE detection.

Understanding the gap between zero-day attacks and public CVE disclosure

When a vulnerability is discovered, the standard practice is to report it to the vendor or the responsible organization, allowing them to develop and distribute a patch or fix before the details are made public. This is known as responsible disclosure.

The gap between exploitation of a zero-day and the disclosure of the vulnerability can sometimes be considerable, and retroactively attempting to identify successful exploitation on your network can be challenging, particularly if taking a signature-based approach.

However, abnormal behaviors in networks or systems, such as unusual login patterns or data transfers, can indicate attempted cyber-attacks, insider threats, or compromised systems.

Detecting threats without relying on CVE disclosure

Since Darktrace does not rely on rules or signatures, it can detect malicious activity that is anomalous even without full context of the specific device or asset in question.

For example, during the Fortinet exploitation late last year, the Darktrace Threat Research team were investigating a different Fortinet vulnerability, namely CVE 2024-23113, for exploitation when Mandiant released a security advisory around CVE 2024-47575, which aligned closely with Darktrace’s findings.

Retrospective analysis like this is used by Darktrace’s threat researchers to better understand detections across the threat landscape and to add additional context.

Below are eight examples from the past year where Darktrace detected malicious activity days or even weeks before a vulnerability was publicly disclosed.

ten examples from the past year where Darktrace detected malicious activity days or even weeks before a vulnerability was publicly disclosed.

Trends in pre-cve exploitation

The attack vs. patch race

In many cases, the disclosure of an exploited vulnerability can be off the back of an incident response investigation related to a compromise by an advanced threat actor using a zero-day. Once the vulnerability is registered and publicly disclosed as having been exploited, it can kick off a race between the attacker and defender.

Skilled nation-state actors

Nation-state actors, highly skilled with significant resources, are known to use a range of capabilities to achieve their target, including zero-day use. Often, pre-CVE activity is “low and slow”, last for months with high operational security.

After CVE disclosure, the barriers to entry lower, allowing less skilled and less resourced attackers, like some ransomware gangs, to exploit the vulnerability and cause harm. This is why two distinct types of activity are often seen: pre and post disclosure of an exploited vulnerability.

Examples of exploitation

Darktrace saw this consistent story line play out during several of the Fortinet and PAN OS threat actor campaigns highlighted above last year, where nation-state actors were seen exploiting vulnerabilities first, followed by ransomware gangs impacting organizations [2].

The same applies with the recent SAP Netweaver exploitations being tied to a China based threat actor earlier this spring with subsequent ransomware incidents being observed [3].

You spotted the anomaly but did you stop the breach?

Anomaly-based detection offers the benefit of identifying malicious activity even before a CVE is disclosed; however, security teams still need to quickly contain and isolate the activity.

For example, during the Ivanti chaining exploitation in the early part of 2025, a customer had Darktrace’s Autonomous Response capability enabled on their network. As a result, Darktrace was able to contain the compromise and shut down any ongoing suspicious connectivity by blocking internal connections and enforcing a “pattern of life” on the affected device.

This pre-CVE detection and response by Darktrace occurred 11 days before any public disclosure, demonstrating the value of an anomaly-based approach.

In some cases, customers have even reported that Darktrace stopped malicious exploitation of devices several days before a public disclosure of a vulnerability.

For example, During the ConnectWise exploitation, a customer informed the team that Darktrace had detected malicious software being installed via remote access. Upon further investigation, four servers were found to be impacted, while Autonomous Response had blocked outbound connections and enforced patterns of life on impacted devices.

Conclusion

By continuously analyzing behavioral patterns, systems can spot unusual activities and patterns from users, systems, and networks to detect anomalies that could signify a security breach.

Through ongoing monitoring and learning from these behaviors, anomaly-based security systems can detect threats that traditional signature-based solutions might miss, while also providing detailed insights into threat tactics, techniques, and procedures (TTPs). This type of behavioral intelligence supports pre-CVE detection, allows for a more adaptive security posture, and enables systems to evolve with the ever-changing threat landscape.

Credit to Nathaniel Jones (VP, Security & AI Strategy, Field CISO), Emma Fougler (Global Threat Research Operations Lead), Ryan Traill (Analyst Content Lead)

References and further reading:

Realted Darktrace blogs:

‍

*Self-reported by customer, confirmed afterwards.

**Updated January 2024 blog now reflects current findings

About the author

Blog

Network

June 27, 2025

Patch and Persist: Darktrace’s Detection of Blind Eagle (APT-C-36)

login on laptop dual factor authentication

What is Blind Eagle?

Since 2018, APT-C-36, also known as Blind Eagle, has been observed performing cyber-attacks targeting various sectors across multiple countries in Latin America, with a particular focus on Colombian organizations.

Blind Eagle characteristically targets government institutions, financial organizations, and critical infrastructure [1][2].

Attacks carried out by Blind Eagle actors typically start with a phishing email and the group have been observed utilizing various Remote Access Trojans (RAT) variants, which often have in-built methods for hiding command-and-control (C2) traffic from detection [3].

What we know about Blind Eagle from a recent campaign

Since November 2024, Blind Eagle actors have been conducting an ongoing campaign targeting Colombian organizations [1].

In this campaign, threat actors have been observed using phishing emails to deliver malicious URL links to targeted recipients, similar to the way threat actors have previously been observed exploiting CVE-2024-43451, a vulnerability in Microsoft Windows that allows the disclosure of a user’s NTLMv2 password hash upon minimal interaction with a malicious file [4].

Despite Microsoft patching this vulnerability in November 2024 [1][4], Blind Eagle actors have continued to exploit the minimal interaction mechanism, though no longer with the intent of harvesting NTLMv2 password hashes. Instead, phishing emails are sent to targets containing a malicious URL which, when clicked, initiates the download of a malicious file. This file is then triggered by minimal user interaction.

Clicking on the file triggers a WebDAV request, with a connection being made over HTTP port 80 using the user agent ‘Microsoft-WebDAV-MiniRedir/10.0.19044’. WebDAV is a transmission protocol which allows files or complete directories to be made available through the internet, and to be transmitted to devices [5]. The next stage payload is then downloaded via another WebDAV request and malware is executed on the target device.

Attackers are notified when a recipient downloads the malicious files they send, providing an insight into potential targets [1].

Darktrace’s coverage of Blind Eagle

In late February 2025, Darktrace observed activity assessed with medium confidence to be associated with Blind Eagle on the network of a customer in Colombia.

Within a period of just five hours, Darktrace / NETWORK detected a device being redirected through a rare external location, downloading multiple executable files, and ultimately exfiltrating data from the customer’s environment.

Since the customer did not have Darktrace’s Autonomous Response capability enabled on their network, no actions were taken to contain the compromise, allowing it to escalate until the customer’s security team responded to the alerts provided by Darktrace.

Darktrace observed a device on the customer’s network being directed over HTTP to a rare external IP, namely 62[.]60[.]226[.]112, which had never previously been seen in this customer’s environment and was geolocated in Germany. Multiple open-source intelligence (OSINT) providers have since linked this endpoint with phishing and malware campaigns [9].

The device then proceeded to download the executable file hxxp://62[.]60[.]226[.]112/file/3601_2042.exe.

Figure 1: Darktrace’s detection of the affected device connecting to an unusual location based in Germany.

Figure 2: Darktrace’s detection of the affected device downloading an executable file from the suspicious endpoint.

The device was then observed making unusual connections to the rare endpoint 21ene.ip-ddns[.]com and performing unusual external data activity.

This dynamic DNS endpoint allows a device to access an endpoint using a domain name in place of a changing IP address. Dynamic DNS services ensure the DNS record of a domain name is automatically updated when the IP address changes. As such, malicious actors can use these services and endpoints to dynamically establish connections to C2 infrastructure [6].

Further investigation into this dynamic endpoint using OSINT revealed multiple associations with previous likely Blind Eagle compromises, as well as Remcos malware, a RAT commonly deployed via phishing campaigns [7][8][10].

Figure 3: Darktrace’s detection of the affected device connecting to the suspicious dynamic DNS endpoint, 21ene.ip-ddns[.]com.

Shortly after this, Darktrace observed the user agent ‘Microsoft-WebDAV-MiniRedir/10.0.19045’, indicating usage of the aforementioned transmission protocol WebDAV. The device was subsequently observed connected to an endpoint associated with Github and downloading data, suggesting that the device was retrieving a malicious tool or payload. The device then began to communicate to the malicious endpoint diciembrenotasenclub[.]longmusic[.]com over the new TCP port 1512 [11].

Around this time, the device was also observed uploading data to the endpoints 21ene.ip-ddns[.]com and diciembrenotasenclub[.]longmusic[.]com, with transfers of 60 MiB and 5.6 MiB observed respectively.

Figure 4: UI graph showing external data transfer activity.

This chain of activity triggered an Enhanced Monitoring model alert in Darktrace / NETWORK. These high-priority model alerts are designed to trigger in response to higher fidelity indicators of compromise (IoCs), suggesting that a device is performing activity consistent with a compromise.

Figure 5: Darktrace’s detection of initial attack chain activity.

A second Enhanced Monitoring model was also triggered by this device following the download of the aforementioned executable file (hxxp://62[.]60[.]226[.]112/file/3601_2042.exe) and the observed increase in C2 activity.

Following this activity, Darktrace continued to observe the device beaconing to the 21ene.ip-ddns[.]com endpoint.

Darktrace’s Cyber AI Analyst was able to correlate each of the individual detections involved in this compromise, identifying them as part of a broader incident that encompassed C2 connectivity, suspicious downloads, and external data transfers.

Figure 6: Cyber AI Analyst’s investigation into the activity observed on the affected device.

Figure 7: Cyber AI Analyst’s detection of the affected device’s broader connectivity throughout the course of the attack.

As the affected customer did not have Darktrace’s Autonomous Response configured at the time, the attack was able to progress unabated. Had Darktrace been properly enabled, it would have been able to take a number of actions to halt the escalation of the attack.

For example, the unusual beaconing connections and the download of an unexpected file from an uncommon location would have been shut down by blocking the device from making external connections to the relevant destinations.

Conclusion

The persistence of Blind Eagle and ability to adapt its tactics, even after patches were released, and the speed at which the group were able to continue using pre-established TTPs highlights that timely vulnerability management and patch application, while essential, is not a standalone defense.

Organizations must adopt security solutions that use anomaly-based detection to identify emerging and adapting threats by recognizing deviations in user or device behavior that may indicate malicious activity. Complementing this with an autonomous decision maker that can identify, connect, and contain compromise-like activity is crucial for safeguarding organizational networks against constantly evolving and sophisticated threat actors.

Credit to Charlotte Thompson (Senior Cyber Analyst), Eugene Chua (Principal Cyber Analyst) and Ryan Traill (Analyst Content Lead)

Appendices

IoCs

IoC – Type - Confidence
Microsoft-WebDAV-MiniRedir/10.0.19045 – User Agent

62[.]60[.]226[.]112 – IP – Medium Confidence

hxxp://62[.]60[.]226[.]112/file/3601_2042.exe – Payload Download – Medium Confidence

21ene.ip-ddns[.]com – Dynamic DNS Endpoint – Medium Confidence

diciembrenotasenclub[.]longmusic[.]com - Hostname – Medium Confidence

Darktrace’s model alert coverage

Anomalous File / Suspicious HTTP Redirect
Anomalous File / EXE from Rare External Location
Anomalous File / Multiple EXE from Rare External Location
Anomalous Server Activity / Outgoing from Server
Unusual Activity / Unusual External Data to New Endpoint
Device / Anomalous Github Download
Anomalous Connection / Multiple Connections to New External TCP Port
Device / Initial Attack Chain Activity
Anomalous Server Activity / Rare External from Server
Compromise / Suspicious File and C2
Compromise / Fast Beaconing to DGA
Compromise / Large Number of Suspicious Failed Connections
Device / Large Number of Model Alert

Mitre Attack Mapping:

Tactic – Technique – Technique Name

Initial Access - T1189 – Drive-by Compromise
Initial Access - T1190 – Exploit Public-Facing Application
Initial Access ICS - T0862 – Supply Chain Compromise
Initial Access ICS - T0865 – Spearphishing Attachment
Initial Access ICS - T0817 - Drive-by Compromise
Resource Development - T1588.001 – Malware
Lateral Movement ICS - T0843 – Program Download
Command and Control - T1105 - Ingress Tool Transfer
Command and Control - T1095 – Non-Application Layer Protocol
Command and Control - T1571 – Non-Standard Port
Command and Control - T1568.002 – Domain Generation Algorithms
Command and Control ICS - T0869 – Standard Application Layer Protocol
Evasion ICS - T0849 – Masquerading
Exfiltration - T1041 – Exfiltration Over C2 Channel
Exfiltration - T1567.002 – Exfiltration to Cloud Storage