Blog
/
Endpoint
/
December 12, 2022

ML Integration for Third-Party EDR Alerts

The advantages and benefits of combining EDR technologies with Darktrace: how this integration can enhance your cybersecurity strategy.
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
Default blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog image
12
Dec 2022

This blog demonstrates how we use EDR integration in Darktrace for detection & investigation. We’ll look at four key features, which are summarized with an example below:  

1)    Contextualizing existing Darktrace information – E.g. ‘There was a Microsoft Defender for Endpoint (MDE) alert 5 minutes after Darktrace saw the device beacon to an unusual destination on the internet. Let me pivot back into the Defender UI’
2)    Cross-data detection engineering
‘Darktrace, create an alert or trigger a response if you see a specific MDE alert and a native Darktrace detection on the same entity over a period of time’
3)    Applying unsupervised machine learning to third-party EDR alerts
‘Darktrace, create an alert or trigger a response if there is a specific MDE alert that is unusual for the entity, given the context’
4)    Use third-party EDR alerts to trigger AI Analyst
‘AI Analyst, this low-fidelity MDE alert flagged something on the endpoint. Please take a deep look at that device at the time of the Defender alert, conduct an investigation on Darktrace data and share your conclusions about whether there is more to it or not’ 

MDE is used as an example above, but Darktrace’s EDR integration capabilities extend beyond MDE to other EDRs as well, for example to Sentinel One and CrowdStrike EDR.

Darktrace brings its Self-Learning AI to your data, no matter where it resides. The data can be anywhere – in email environments, cloud, SaaS, OT, endpoints, or the network, for example. Usually, we want to get as close to the raw data as possible to get the maximum context for our machine learning. 

We will explain how we leverage high-value integrations from our technology partners to bring further context to Darktrace, but also how we apply our Self-Learning AI to third-party data. While there are a broad range of integrations and capabilities available, we will primarily look at Microsoft Defender for Endpoint, CrowdStrike, and SentinelOne and focus on detection in this blog post. 

The Nuts and Bolts – Setting up the Integration

Darktrace is an open platform – almost everything it does is API-driven. Our system and machine learning are flexible enough to ingest new types of data & combine it with already existing information.  

The EDR integrations mentioned here are part of our 1-click integrations. All it requires is the right level of API access from the EDR solutions and the ability for Darktrace to communicate with the EDR’s API. This type of integration can be setup within minutes – it currently doesn’t require additional Darktrace licenses.

Figure 1: Set-up of Darktrace Graph Security API integration

As soon as the setup is complete, it enables various additional capabilities. 
Let’s look at some of the key detection & investigation-focussed capabilities step-by-step.

Contextualizing Existing Darktrace Information

The most basic, but still highly-useful integration is enriching existing Darktrace information with EDR alerts. Darktrace shows a chronological history of associated telemetry and machine learning for each entity observed in the entities event log. 

With an EDR integration enabled, we now start to see EDR alerts for the respective entities turn up in the entity’s event log at the correct point in time – with a ton of context and a 1-click pivot back to the native EDR console: 

Figure 2: A pivot from the Darktrace Threat Visualizer to Microsoft Defender

This context is extremely useful to have in a single screen during investigations. Context is king – it reduces time-to-meaning and skill required to understand alerts.

Cross-Data Detection Engineering

When an EDR integration is activated, Darktrace enables an additional set of detections that leverage the new EDR alerts. This comes out of the box and doesn’t require any further detection engineering. It is worth mentioning though that the new EDR information is being made available in the background for bespoke detection engineering, if advanced users want to leverage these as custom metrics.

The trick here is that the added context provided by the additional EDR alerts allows for more refined detections – primarily to detect malicious activity with higher confidence. A network detection showing us beaconing over an unusual protocol or port combination to a rare destination on the internet is great – but seeing within Darktrace that CrowdStrike detected a potentially hostile file or process three minutes prior to the beaconing detection on the same device will greatly help to prioritize the detections and aid a subsequent investigation.

Here is an example of what this looks like in Darktrace:

Figure 3: A combined model breach in the Threat Visualizer

Applying Unsupervised Machine Learning to Third-Party EDR Alerts


Once we start seeing EDR alerts in Darktrace, we can start treating it like any other data – by applying unsupervised machine learning to it. This means we can then understand how unusual a given EDR detection is for each device in question. This is extremely powerful – it allows to reduce noisy alerts without requiring ongoing EDR alert tuning and opens a whole world of new detection capabilities.

As an example – let’s imagine a low-level malware alert keeps appearing from the EDR on a specific device. This might be a false-positive in the EDR, or just not of interest for the security team, but they may not have the resources or knowledge to further tune their EDR and get rid of this noisy alert.

While Darktrace keeps adding this as contextual information in the device’s event log, it could, depending on the context of the device, the EDR alert, and the overall environment, stop alerting on this particular EDR malware alert on this specific device if it stops being unusual. Over time, noise is reduced across the environment – but if that particular EDR alert appears on another device, or on the same device in a different context, it might get flagged again, as it now is unusual in the given context.

Darktrace then goes a step further, taking those unusual EDR alerts and combining them with unusual activity seen in other Darktrace coverage areas, like the network for example. Combining an unusual EDR alert with an unusual lateral movement attempt, for example, allows it to find these combined, high-precision, cross-data set anomalous events that are highly indicative of an active cyber-attack – without having to pre-define the exact nature of what ‘unusual’ looks like.

Figure 4: Combined EDR & network detection using unsupervised machine learning in Darktrace

Use Third-Party EDR Alerts to Trigger AI Analyst

Everything we discussed so far is great for improving precision in initial detections, adding context, and cutting through alert-noise. We don’t stop there though – we can also now use the third-party EDR alerts to trigger our investigation engine, the AI Analyst.

Cyber AI Analyst replicates and automates typical level 1 and level 2 Security Operations Centre (SOC) workflows. It is usually triggered by every native Darktrace detection. This is not a SOAR where playbooks are statically defined – AI Analyst builds hypotheses, gathers data, evaluates the data & reports on its findings based on the context of each individual scenario & investigation. 

Darktrace can use EDR alerts as starting points for its investigation, with every EDR alert ingested now triggering AI Analyst. This is similar to giving a (low-level) EDR alert to a human analyst and telling them: ‘Go and take a look at information in Darktrace and try to conclude whether there is more to this EDR alert or not.’

The AI Analyst subsequently looks at the entity which had triggered the EDR alert and investigates all available Darktrace data on that entity, over a period of time, in light of that EDR alert. It does not pivot outside Darktrace itself for that investigation (e.g. back into the Microsoft console) but looks at all of the context natively available in Darktrace. If concludes that there is more to this EDR alert – e.g. a bigger incident – it will report on that and clearly flag it. The report can of course be directly downloaded as a PDF to be shared with other stakeholders.

This comes in handy for a variety of reasons – primarily to further automate security operations and alleviate pressure from human teams. AI Analyst’s investigative capabilities sit on top of everything we discussed so far (combining EDR detections with detections from other coverage areas, applying unsupervised machine learning to EDR detections, …).

However, it can also come in handy to follow up on low-severity EDR alerts for which you might not have the human resources to do so.

The below screenshot shows an example of a concluded AI Analyst investigation that was triggered by an EDR alert:

Figure 5: An AI Analyst incident trained on third-party data

The Impact of EDR Integrations

The purpose behind all of this is to augment human teams, save them time and drive further security automation.

By ingesting third-party endpoint alerts, combining it with our existing intelligence and applying unsupervised machine learning to it, we achieve that further security automation. 

Analysts don’t have to switch between consoles for investigations. They can leverage our high-fidelity detections that look for unusual endpoint alerts, in combination with our already powerful detections across cloud and email systems, zero trust architecture, IT and OT networks, and more. 

In our experience, this pinpoints the needle in the haystack – it cuts through noise and reduces the mean-time-to-detect and mean-time-to-investigate drastically.

All of this is done out of the box in Darktrace once the endpoint integrations are enabled. It does not need a data scientist to make the machine learning work. Nor does it need a detection engineer or threat hunter to create bespoke, meaningful detections. We want to reduce the barrier to entry for using detection and investigation solutions – in terms of skill and experience required. The system is still flexible, transparent, and open, meaning that advanced users can create their own combined detections, leveraging unsupervised machine learning across different data sets with a few clicks.

There are of course more endpoint integration capabilities available than what we covered here, and we will explore these in future blog posts.

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

More in this series

No items found.

Blog

/

/

April 24, 2025

The Importance of NDR in Resilient XDR

picture of hands typing on laptop Default blog imageDefault blog image

As threat actors become more adept at targeting and disabling EDR agents, relying solely on endpoint detection leaves critical blind spots.

Network detection and response (NDR) offers the visibility and resilience needed to catch what EDR can’t especially in environments with unmanaged devices or advanced threats that evade local controls.

This blog explores how threat actors can disable or bypass EDR-based XDR solutions and demonstrates how Darktrace’s approach to NDR closes the resulting security gaps with Self-Learning AI that enables autonomous, real-time detection and response.

Threat actors see local security agents as targets

Recent research by security firms has highlighted ‘EDR killers’: tools that deliberately target EDR agents to disable or damage them. These include the known malicious tool EDRKillShifter, the open source EDRSilencer, EDRSandblast and variants of Terminator, and even the legitimate business application HRSword.

The attack surface of any endpoint agent is inevitably large, whether the software is challenged directly, by contesting its local visibility and access mechanisms, or by targeting the Operating System it relies upon. Additionally, threat actors can readily access and analyze EDR tools, and due to their uniformity across environments an exploit proven in a lab setting will likely succeed elsewhere.

Sophos have performed deep research into the EDRShiftKiller tool, which ESET have separately shown became accessible to multiple threat actor groups. Cisco Talos have reported via TheRegister observing significant success rates when an EDR kill was attempted by ransomware actors.

With the local EDR agent silently disabled or evaded, how will the threat be discovered?

What are the limitations of relying solely on EDR?

Cyber attackers will inevitably break through boundary defences, through innovation or trickery or exploiting zero-days. Preventive measures can reduce but not completely stop this. The attackers will always then want to expand beyond their initial access point to achieve persistence and discover and reach high value targets within the business. This is the primary domain of network activity monitoring and NDR, which includes responsibility for securing the many devices that cannot run endpoint agents.

In the insights from a CISA Red Team assessment of a US CNI organization, the Red Team was able to maintain access over the course of months and achieve their target outcomes. The top lesson learned in the report was:

“The assessed organization had insufficient technical controls to prevent and detect malicious activity. The organization relied too heavily on host-based endpoint detection and response (EDR) solutions and did not implement sufficient network layer protections.”

This proves that partial, isolated viewpoints are not sufficient to track and analyze what is fundamentally a connected problem – and without the added visibility and detection capabilities of NDR, any downstream SIEM or MDR services also still have nothing to work with.

Why is network detection & response (NDR) critical?

An effective NDR finds threats that disable or can’t be seen by local security agents and generally operates out-of-band, acquiring data from infrastructure such as traffic mirroring from physical or virtual switches. This means that the security system is extremely inaccessible to a threat actor at any stage.

An advanced NDR such as Darktrace / NETWORK is fully capable of detecting even high-end novel and unknown threats.

Detecting exploitation of Ivanti CS/PS with Darktrace / NETWORK

On January 9th 2025, two new vulnerabilities were disclosed in Ivanti Connect Secure and Policy Secure appliances that were under malicious exploitation. Perimeter devices, like Ivanti VPNs, are designed to keep threat actors out of a network, so it's quite serious when these devices are vulnerable.

An NDR solution is critical because it provides network-wide visibility for detecting lateral movement and threats that an EDR might miss, such as identifying command and control sessions (C2) and data exfiltration, even when hidden within encrypted traffic and which an EDR alone may not detect.

Darktrace initially detected suspicious activity connected with the exploitation of CVE-2025-0282 on December 29, 2024 – 11 days before the public disclosure of the vulnerability, this early detection highlights the benefits of an anomaly-based network detection method.

Throughout the campaign and based on the network telemetry available to Darktrace, a wide range of malicious activities were identified, including the malicious use of administrative credentials, the download of suspicious files, and network scanning in the cases investigated.

Darktrace / NETWORK’s autonomous response capabilities played a critical role in containment by autonomously blocking suspicious connections and enforcing normal behavior patterns. At the same time, Darktrace Cyber AI Analyst™ automatically investigated and correlated the anomalous activity into cohesive incidents, revealing the full scope of the compromise.

This case highlights the importance of real-time, AI-driven network monitoring to detect and disrupt stealthy post-exploitation techniques targeting unmanaged or unprotected systems.

Unlocking adaptive protection for evolving cyber risks

Darktrace / NETWORK uses unique AI engines that learn what is normal behavior for an organization’s entire network, continuously analyzing, mapping and modeling every connection to create a full picture of your devices, identities, connections, and potential attack paths.

With its ability to uncover previously unknown threats as well as detect known threats using signatures and threat intelligence, Darktrace is an essential layer of the security stack. Darktrace has helped secure customers against attacks including 2024 threat actor campaigns against Fortinet’s FortiManager , Palo Alto firewall devices, and more.  

Stay tuned for part II of this series which dives deeper into the differences between NDR types.

Credit to Nathaniel Jones VP, Security & AI Strategy, FCISO & Ashanka Iddya, Senior Director of Product Marketing for their contribution to this blog.

Continue reading
About the author
Nathaniel Jones
VP, Security & AI Strategy, Field CISO

Blog

/

/

April 22, 2025

Obfuscation Overdrive: Next-Gen Cryptojacking with Layers

man looking at multiple computer screensDefault blog imageDefault blog image

Out of all the services honeypotted by Darktrace, Docker is the most commonly attacked, with new strains of malware emerging daily. This blog will analyze a novel malware campaign with a unique obfuscation technique and a new cryptojacking technique.

What is obfuscation?

Obfuscation is a common technique employed by threat actors to prevent signature-based detection of their code, and to make analysis more difficult. This novel campaign uses an interesting technique of obfuscating its payload.

Docker image analysis

The attack begins with a request to launch a container from Docker Hub, specifically the kazutod/tene:ten image. Using Docker Hub’s layer viewer, an analyst can quickly identify what the container is designed to do. In this case, the container is designed to run the ten.py script which is built into itself.

 Docker Hub Image Layers, referencing the script ten.py.
Figure 1: Docker Hub Image Layers, referencing the script ten.py.

To gain more information on the Python file, Docker’s built in tooling can be used to download the image (docker pull kazutod/tene:ten) and then save it into a format that is easier to work with (docker image save kazutod/tene:ten -o tene.tar). It can then be extracted as a regular tar file for further investigation.

Extraction of the resulting tar file.
Figure 2: Extraction of the resulting tar file.

The Docker image uses the OCI format, which is a little different to a regular file system. Instead of having a static folder of files, the image consists of layers. Indeed, when running the file command over the sha256 directory, each layer is shown as a tar file, along with a JSON metadata file.

Output of the file command over the sha256 directory.
Figure 3: Output of the file command over the sha256 directory.

As the detailed layers are not necessary for analysis, a single command can be used to extract all of them into a single directory, recreating what the container file system would look like:

find blobs/sha256 -type f -exec sh -c 'file "{}" | grep -q "tar archive" && tar -xf "{}" -C root_dir' \;

Result of running the command above.
Figure 4: Result of running the command above.

The find command can then be used to quickly locate where the ten.py script is.

find root_dir -name ten.py

root_dir/app/ten.py

Details of the above ten.py script.
Figure 5: Details of the above ten.py script.

This may look complicated at first glance, however after breaking it down, it is fairly simple. The script defines a lambda function (effectively a variable that contains executable code) and runs zlib decompress on the output of base64 decode, which is run on the reversed input. The script then runs the lambda function with an input of the base64 string, and then passes it to exec, which runs the decoded string as Python code.

To help illustrate this, the code can be cleaned up to this simplified function:

def decode(input):
   reversed = input[::-1]

   decoded = base64.decode(reversed)
   decompressed = zlib.decompress(decoded)
   return decompressed

decoded_string = decode(the_big_text_blob)
exec(decoded_string) # run the decoded string

This can then be set up as a recipe in Cyberchef, an online tool for data manipulation, to decode it.

Use of Cyberchef to decode the ten.py script.
Figure 6: Use of Cyberchef to decode the ten.py script.

The decoded payload calls the decode function again and puts the output into exec. Copy and pasting the new payload into the input shows that it does this another time. Instead of copy-pasting the output into the input all day, a quick script can be used to decode this.

The script below uses the decode function from earlier in order to decode the base64 data and then uses some simple string manipulation to get to the next payload. The script will run this over and over until something interesting happens.

# Decode the initial base64

decoded = decode(initial)
# Remove the first 11 characters and last 3

# so we just have the next base64 string

clamped = decoded[11:-3]

for i in range(1, 100):
   # Decode the new payload

   decoded = decode(clamped)
   # Print it with the current step so we

   # can see what’s going on

   print(f"Step {i}")

   print(decoded)
   # Fetch the next base64 string from the

   # output, so the next loop iteration will

   # decode it

   clamped = decoded[11:-3]

Result of the 63rd iteration of this script.
Figure 7: Result of the 63rd iteration of this script.

After 63 iterations, the script returns actual code, accompanied by an error from the decode function as a stopping condition was never defined. It not clear what the attacker’s motive to perform so many layers of obfuscation was, as one round of obfuscation versus several likely would not make any meaningful difference to bypassing signature analysis. It’s possible this is an attempt to stop analysts or other hackers from reverse engineering the code. However,  it took a matter of minutes to thwart their efforts.

Cryptojacking 2.0?

Cleaned up version of the de-obfuscated code.
Figure 8: Cleaned up version of the de-obfuscated code.

The cleaned up code indicates that the malware attempts to set up a connection to teneo[.]pro, which appears to belong to a Web3 startup company.

Teneo appears to be a legitimate company, with Crunchbase reporting that they have raised USD 3 million as part of their seed round [1]. Their service allows users to join a decentralized network, to “make sure their data benefits you” [2]. Practically, their node functions as a distributed social media scraper. In exchange for doing so, users are rewarded with “Teneo Points”, which are a private crypto token.

The malware script simply connects to the websocket and sends keep-alive pings in order to gain more points from Teneo and does not do any actual scraping. Based on the website, most of the rewards are gated behind the number of heartbeats performed, which is likely why this works [2].

Checking out the attacker’s dockerhub profile, this sort of attack seems to be their modus operandi. The most recent container runs an instance of the nexus network client, which is a project to perform distributed zero-knowledge compute tasks in exchange for cryptocurrency.

Typically, traditional cryptojacking attacks rely on using XMRig to directly mine cryptocurrency, however as XMRig is highly detected, attackers are shifting to alternative methods of generating crypto. Whether this is more profitable remains to be seen. There is not currently an easy way to determine the earnings of the attackers due to the more “closed” nature of the private tokens. Translating a user ID to a wallet address does not appear to be possible, and there is limited public information about the tokens themselves. For example, the Teneo token is listed as “preview only” on CoinGecko, with no price information available.

Conclusion

This blog explores an example of Python obfuscation and how to unravel it. Obfuscation remains a ubiquitous technique employed by the majority of malware to aid in detection/defense evasion and being able to de-obfuscate code is an important skill for analysts to possess.

We have also seen this new avenue of cryptominers being deployed, demonstrating that attackers’ techniques are still evolving - even tried and tested fields. The illegitimate use of legitimate tools to obtain rewards is an increasingly common vector. For example,  as has been previously documented, 9hits has been used maliciously to earn rewards for the attack in a similar fashion.

Docker remains a highly targeted service, and system administrators need to take steps to ensure it is secure. In general, Docker should never be exposed to the wider internet unless absolutely necessary, and if it is necessary both authentication and firewalling should be employed to ensure only authorized users are able to access the service. Attacks happen every minute, and even leaving the service open for a short period of time may result in a serious compromise.

References

1. https://www.crunchbase.com/funding_round/teneo-protocol-seed--a8ff2ad4

2. https://teneo.pro/

Continue reading
About the author
Nate Bill
Threat Researcher
Your data. Our AI.
Elevate your network security with Darktrace AI