Blog
/
Cloud
/
November 13, 2023

OracleIV: A dockerized DDoS botnet

OracleIV is a DDoS botnet exploiting misconfigured Docker Engine APIs. It delivers a malicious Python ELF executable within a Docker container ("oracleiv_latest") to perform various DoS attacks. The botnet communicates with a C2 server for commands, demonstrating attackers' continued use of exposed Docker instances.
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
Nate Bill
Threat Researcher
Default blog image
13
Nov 2023

Introduction: OracleIV

Researchers from Cado Security Labs (now part of Darktrace) discovered a novel campaign targeting publicly exposed instances of the Docker Engine API.

Attackers are exploiting this misconfiguration to deliver a malicious Docker container, built from an image named "oracleiv_latest" and containing Python malware compiled as an ELF executable. The malware itself acts as a Distributed Denial of Service (DDoS) bot agent, capable of conducting Denial of Service (DoS) attacks via a number of methods.

It’s not the first time the Docker Engine API has been targeted by attackers. This method of initial access has been increasing in recent years and is often used to deliver cryptojacking malware [1]. Inadvertent exposure of the Docker Engine API occurs frequently enough that several unrelated campaigns have been observed scanning for it. 

This should come as no surprise, given the move to microservice-driven architectures by many software teams. Once a valid endpoint is discovered, it’s trivial to pull a malicious image and launch a container from it to carry out any conceivable objective. Hosting the malicious container in Docker Hub, Docker’s container image library, streamlines this process even further.

Initial access

In keeping with other attacks of this kind, initial access typically begins with a HTTP POST request to the /images/create endpoint of Docker’s API. This effectively runs a docker pull command on the host to retrieve the specified image from Docker Hub. A follow-up container start command is then used to spawn a container from the pulled image. 

An example of the image create command used in the OracleIV command can be seen below:

POST /v1.43/images/create?
tag=latest&fromImage=robbertignacio328832/oracleiv_latest 

‍

Malicious Docker hub image

As can be seen in the Docker API command above, the attacker retrieves an image named oracleiv_latest which was uploaded to Docker Hub. This image was still live at the time of writing and had over 3,000 pulls. Furthermore, the image itself appeared to be undergoing regular iteration, with the most recent changes pushed only 3 days prior to the writing of this blog.

The user also added the description Mysql image for docker to the image’s Docker Hub page, likely to make it seem more innocuous.

Examining the image layers reveals commands used by the attacker to retrieve their malicious payload - named oracle.sh, despite being an ELF executable - and bake it into the resulting image.

Image layer RUN command to retrieve malicious payload
Figure 1: Image layer RUN command to retrieve malicious payload

The image also includes additional wget commands to retrieve a copy of XMRig and an associated miner configuration file.

Image layer RUN command to retrieve xmrig miner
Figure 2: Image layer RUN command to retrieve xmrig miner
Image layer RUN command to retrieve miner configuration file
Figure 3: Image layer RUN command to retrieve miner configuration file

It is worth noting that Cado researchers did not observe any mining performed by this malicious container, but with these files baked into the image it would certainly be possible.

Static analysis

Since the bundled version of XMRig is both unused and a vanilla release of the miner, this section will focus on analysis of the oracle.sh executable embedded in the malicious container.

Static analysis of this executable revealed a 64-bit, statically linked ELF, with debug information intact. Further investigation led to the discovery of a number of functions with CyFunction in the name, confirming that the malware is Python code compiled with Cython.

Embedded Cython functions
Figure 4: Embedded Cython functions

The attacker code is relatively concise, the majority of it is dedicated to the different DoS methods present. The following functions were identified:

  • bot.main
  • bot.init_socket
  • bot.checksum
  • bot.register_ssl
  • bot.register_httpget
  • bot.register_slow
  • bot.register_five
  • bot.register_vse
  • bot.register_udp
  • bot.register_udp_pps
  • bot.register_ovh

Functions with the register_ prefix correspond to DoS attack methods, the details of which will be discussed in the following section.

Dynamic analysis

The bot connects back to a Command-and-Control server (C2) at 46.166.185[.]231 on TCP port 40320. It then performs primitive authentication, where the bot supplies the C2 with basic information about its environment in addition to a hardcoded password.

 : client hello from zombie! : X86 : key: b'bjN0ZzM0cnAwd24zZA==' : os: linux

The key decodes to “n3tg34rp0wn3d”. Supplying an incorrect key causes the C2 to reply with a string of expletive language, followed by the connection being terminated.

Following successful authentication, the C2 will continuously send “routine ping, greetz Oracle IV”. This is likely due to an implementation quirk, where many novice programmers new to socket programming will implement the blocking receive operation in a loop and require constant input to keep the loop going.

Cado Security Labs has performed monitoring of the botnet activity and has observed the botnet being used to DDoS a number of targets, with the operator preferring to use a UDP based flood in addition to an SSL based flood.

Botnet commands

C2 commands used to initiate the different DoS attacks take the following form:

<attack type> <target IP/domain> <attack duration> <rate> <target port>

For example, to conduct an SSL DoS attack on the website example.com for 30 seconds, a rate of 30, and on port 80, the C2 server would send the following command:

ssl example.com 30 30 80

Cado Security Labs were able to trick a botnet agent into connecting to a mimic C2 server instead of the real one and issued commands to observe the capabilities of the botnet. The botnet has the following DDoS capabilities:

UDP:

  • Performs a UDP flood with 40,000-byte packets
  • These far exceed the threshold and consequently get fragmented. This will create an additional computational overhead on both the target and source due to the reassembly of fragments, however it is unclear if this is intentional.

UDP_PPS:

  • Seems non-functional, when the command was issued no activity was observed.

SSL:

  • Opens a TCP connection, sends a large amount of data, and then closes. This process then repeats. The Cado dummy target server rejected all the fake requests with an error 400, so it would appear that the attack aims at flooding the target rather than exploiting some protocol specific function.
Tcpdump output for SSL Dos method
Figure 5: Tcpdump output for SSL DoS method

SYN:

  • It was anticipated that this would be a SYN flood, however the observed behavior is identical to SSL.

HTTPGET:

  • Seems non-functional, when the command was issued no activity was observed.

SLOW:

  • This is a “slowloris” style attack. The agent opens up many connections to the server and continuously sends small amounts of data to keep the connection open.

FIVE:

  • This is a UDP flood with 18-byte packets. Likely the packets are a part of the FiveM server protocol, and designed to cause a denial of service a FiveM server

VSE:

  • This is a UDP flood with 20-byte packets. Similar to FIVE, this seems protocol specific to Valve source engine.

OVH:

  • This is a UDP flood with 8-byte packets, designed to circumvent OVH’s DDoS protection.

Conclusion

OracleIV demonstrates that attackers are still intent on leveraging misconfigured Docker Engine API deployments as a means of initial access for a variety of campaigns. The portability that containerization brings allows malicious payloads to be executed in a deterministic manner across Docker hosts, regardless of the configuration of the host itself. 

Whilst OracleIV is not technically a supply chain attack, users of Docker Hub should be aware that malicious container images do indeed exist in Docker’s image library. Cado researchers reported the malicious user behind OracleIV to Docker.

Despite this, users of Docker Hub are encouraged to perform periodic assessments of the images they are pulling from the registry, to ensure that they have not been polluted with malicious code. 

Consistent with other attacks reliant on a misconfigured internet-facing service (e.g. Jupyter, Redis etc), Cado researchers strongly urge users of these services to periodically review their exposure and implement network defenses accordingly.

Indicators of compromise (IoCs)

File name SHA256

oracle.sh (embedded in container) 5a76c55342173cbce7d1638caf29ff0cfa5a9b2253db9853e881b129fded59fb

xmrig (embedded in container) 20a0864cb7dac55c184bd86e45a6e0acbd4bb19aa29840b824d369de710b6152

config.json (embedded in container) 776c6ef3e9e74719948bdc15067f3ea77a0a1eb52319ca1678d871d280ab395c

IP addresses

46[.]166[.]185[.]231

Docker image

robbertignacio328832/oracleiv_latest:latest

References

  1. https://blog.aquasec.com/threat-alert-anatomy-of-silentbobs-cloud-attack
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
Nate Bill
Threat Researcher

More in this series

No items found.

Blog

/

Network

/

October 14, 2026

CikaBika Bot: Inside a Discord RAT

Default blog imageDefault blog image

‍

Key Takeaways

·      Darktrace malware researchers have found an ongoing malware campaign using a document-themed lure containing a malicious LNK file and a PDF with an embedded payload.

·      The Nim based loader deploys a Rust-based remote access trojan (RAT), using a UAC bypass and DLL search-order hijacking technique targeting Microsoft Edge.

·      The RAT uses Discord for C2, creating dedicated channels to manage infected devices and execute commands.

·      CikaBika Bot supports system reconnaissance, remote command execution, screenshot capture, and file transfers.

‍

Introduction

In a threat landscape where attackers continue to rely on social engineering techniques to deliver malware, legitimate services are increasingly being abused to support malicious operations. Communications platforms like Discord can provide attackers with a ready-made channel for command-and-control (C2), allowing them to manage compromised devices without establishing dedicated infrastructure.

Malware researchers at Darktrace have identified a campaign distributing CikaBika, a Rust-based RAT that uses Discord for C2. The infection chain begins with a disk image and a malicious Windows shortcut. A Nim loader extracts the final payload and attempts to plant it in Microsoft Edge’s installation directory using a PowerShell UAC bypass. Once running, the RAT collects host information, registers the device with Discord, and accepts commands through a dedicated channel.

Technical Analysis

‍

Figure 1: Contents of Proposition_Projet.img.

‍

Initial access and PDF payload

The malware is packaged within a disk image named Proposition_Projet.img. Inside are a PDF titled “Presentation_Generale.pdf.pdf” and a Windows shortcut (LNK) disguised as a Word document, “Proposition_Projet_Personnalisable.docx”. The delivery method has not been confirmed; however, the filenames and document-themed lure are consistent with a phishing campaign.

‍

Figure 2: PowerShell command embedded in the malicious shortcut.


Opening the shortcut launches a hidden PowerShell process while displaying the PDF as a decoy. The French-language document explains how to produce a written summary or contraction of a text. In the background, PowerShell reads the PDF as bytes and uses the value at offset 239 (0x20) as an XOR key to decode an embedded executable. The resulting payload is written to %TEMP%\IfyuUapz.txt and executed using cmd /c.

Nim loader and UAC bypass

“IfyuUapz.txt” is a Nim-based loader that contains two Base64-encoded blobs: a Rust dynamic-link library (DLL)  and a PowerShell deployment script. Both are decoded and written to temporary files, referenced to within the loader as “dllFile” and “copyPs1”. The loader runs the script through a hidden PowerShell process using an encoded command, then attempts to load the DLL using Nim’s loadLib function. If loading fails, it invokes regsvr32.exe and retries.

Figure 3: Silent DLL deployer.

The PowerShell component is responsible for moving the DLL to C:\Program Files (x86)\Microsoft\Edge\Application\dbghelp.dll. It first copies the DLL to C:\Windows\Temp\dbghelp.tmp, then modifies HKCU\Software\Classes\ms-settings\shell\open\command so that launching computerdefaults.exe can trigger a command to move the staged DLL into the protected Edge directory. This is an attempt to bypass User Account Control (UAC), which depends on the target’s Windows configuration.

The script also compiles a small C# helper that calls ShowWindow to hide windows associated with Windows Settings and ApplicationFrameHost. It launches the bypass helper three times, checks for the presence of the destination DLL, and attempts to delete the temporary scripts, intermediate DLL, and associated registry changes.

‍

Figure 4: Legitimate msedge.exe function to load the legitimate dbghelp.dll.

‍

The legitimate msedge.exe has a delay-loaded dependency on dbghelp.dll, and the malicious DLL exports a subset of the functions associated with Microsoft’s debugging library. The attacker appears to be exploiting this dependency through DLL search-order hijacking. However, it does not export every function in Edge’s delay-import table, meaning its compatibility with the host is incomplete. The observed code establishes the intended sideloading route, rather than proving that Edge successfully loaded the planted DLL.

‍

Rust RAT payload

Figure 5: Discord configuration within the RAT.

The malicious dbghelp.dll (IfyuUapz.txt) is a Rust-based RAT. At startup, the RAT registers the compromised device with Discord and begins collecting information about the host. Its reconnaissance routine gathers system details, runs tasklist to enumerate processes, executes ipconfig to obtain network configuration, and attempts to take a screenshot. The resulting artifacts include tasklist_startup.txt, network_info.txt, and screenshot.png.

Figure 6: Network configuration notification in Discord channel.

‍

Figure 7: Network configuration output from network_info.txt.

‍

Discord C2

The RAT uses Discord channels to send commands and report results. The operator can send commands to the device’s channel and receive the resulting output in the same conversation. This gives the attacker an interactive command interface without having to operate and maintain a dedicated C2 server.

Figure 8: Commands available in Discord.

The command set includes !shell for remote command execution; !sysinfo and !info for host details; !isOn for status checks; !tasklist and !ps for process enumeration; and !kill for process termination. File-transfer commands include !upload and !download. Additional strings and command handlers reference screenshots (!src), camera access (!camera), streaming (!stream), and broadcasting (!broadcast).

‍

Figure 9: Device registration in Discord.

During device registration, the malware retrieves the victim’s public IP address using ipify.com. The registration message records the device ID, hostname, registration time, private and public IP addresses, status, uptime, and the Discord channel assigned to that device.

Operator activity and exfiltration

Figure 10: Powershell commands sent through Discord to exfiltrate data.

Once a device is registered, the attacker can issue commands through its dedicated Discord channel. In the observed activity, the attacker compressed a directory into a ZIP and exfiltrated it using ngrok.

Figure 11: Download command to retrieve a document from the target.

‍

The operator can also use !download to retrieve files from target. The example above displays a request for a specific document on the victim’s desktop. The requested file is then returned through the device’s Discord channel, giving the attacker a direct way to store and access selected data.

Conclusion

CikaBika Bot demonstrates how attackers continue to rely on social engineering techniques to deliver malware. Although the initial distribution method has not been confirmed, the use of a disk image containing a shortcut disguised as a Word document, alongside a legitimate-looking PDF, suggests the campaign was designed for phishing.

While Nim is less commonly encountered than C in Windows malware, it has increasingly appeared in malicious tooling. In this case, Nim is used to unpack and deploy a Rust-based RAT, adding another layer to the infection chain.

Once installed, CikaBika Bot uses Discord as its C2 platform, allowing the attacker to manage compromised devices, execute commands, and retrieve files without maintaining dedicated C2 infrastructure. The observed use of Discord channels for individual victims, alongside additional data exfiltration through ngrok, shows how legitimate services can be repurposed to support malicious operations.

Credit to Tara Gould (Malware Research Lead)

Indicators of Compromise (IoCs)

Presentation_Generale.pdf.pdf - eeb52cb95113a131c2c7713c17872da6

Proposition_Projet_Personnalisable.docx.lnk - 62e3e85eca78a0cd7e6669e9f33d936d

dbghelp.dll - c66858718d883bcfb9ce2c19b59f96c9

IfyuUapz.txt - 2deb724a709b0b892248405323350e9b

MITRE ATTACK

T1204.002 – User Execution: Malicious File
T1036.007 – Masquerading: Double File Extension
T1059.001 – PowerShell
T1027 – Obfuscated Files or Information
T1140 – Deobfuscate/Decode Files or Information
T1548.002 – Bypass User Account Control
T1112 – Modify Registry
T1574.001 – DLL Search Order Hijacking
T1036.005 – Masquerading: Match Legitimate Resource Name or Location
T1082 – System Information Discovery
T1016 – System Network Configuration Discovery
T1057 – Process Discovery
T1113 – Screen Capture
T1059.003 – Command and Scripting Interpreter: Windows Command Shell
T1102.002 – Web Service: Bidirectional Communication
T1560.001 – Archive Collected Data: Archive via Utility
T1567 – Exfiltration Over Web Service
T1070.004 – Indicator Removal: File Deletion
T1218.010 – Regsvr32
T1005 – Data from Local System
T1074.001 – Data Staged: Local Data Staging
T1041 – Exfiltration Over C2 Channel
T1564.003 – Hide Artifacts: Hidden Window
T1027.013 – Encrypted/Encoded File

Continue reading
About the author
Tara Gould
Malware Research Lead

Blog

/

AI

/

October 5, 2026

AI-Assisted Attacks Still Leave a Behavioral Trace  

Default blog imageDefault blog image

Key Insights

  • Darktrace identified behavioral indicators associated with two campaigns linked to AI-assisted threat activity, highlighting the growing role of AI in modern cyber-attacks.
  • Observed activity involved suspicious WebDAV file transfers, disguised executable downloads, beaconing to rare infrastructure, unusual process execution, and communications with C2 infrastructure linked to active intrusion campaigns.

Introduction

Just as organizations are incorporating AI into their operations to take advantage of its benefits, threat actors are doing the same, creating new challenges for defenders.

Much of the discussion around AI risk has focused on the expanding attack surface created by AI systems within organizations. These systems are often granted privileged access and heightened permissions to carry out their duties, introducing new security risks and unintended consequences.

At the same time, threat actors are learning to leverage AI to enable malicious activities such as vulnerability discovery, exploit creation, and progressing through the Cyber Kill Chain more quickly. By accelerating development, adaptation, and scaling, AI enables attackers to operate more efficiently while making some capabilities more accessible to less skilled operators.

Whether AI is the target or the enabler, the resulting activity still manifests through networks, identities, endpoints and cloud services. Those interactions create observable signals that defenders can investigate, regardless of how the attack was developed.

AI as part of the attacker’s workflow

Darktrace has previously documented how threat actors are increasingly incorporating AI into offensive operations [1]. Two recent investigations from open-source intelligence (OSINT) illustrate this. In both cases, researchers identified the role of AI within malicious operations. Separately, Darktrace detected activity in customer environments that aligned with the infrastructure and techniques reported in those campaigns. These perspectives provide a view of both attacker workflow and operational consequences.

Although AI played different roles in each campaign, it did not remove the need for the attackers to interact with their targets. Payloads still had to be delivered, processes executed, and command-and-control (C2) connections established, creating behavioral anomalies that Darktrace was able to identify.

‍

Case 1: A Mexican government impersonation campaign with LLM-assisted malware development

Rapid7 reported on a malware delivery operation that used generative AI to assist development, testing, documentation and refinement of attacker infrastructure. Between May and June 2026, Darktrace similarly observed two chains of suspicious activity across customer environments in the Americas that exhibited clear similarities in behavior.

In both cases Darktrace observed:

  • WebDAV communication with onedrive[.]cv·138.124.123[.]87, retrieving a file from the path /Downloads/CURP/
  • Transfer of a masqueraded .scr executable
  • Subsequent communication with google.services[.]ug·77.110.127[.]205 over unusual high ports
  • Additional Darktrace detections correlating the unusual behavior seen spanning payload delivery and C2 communication
  • Darktrace’s Autonomous Response capability alerted across multiple stages of the attack

The infrastructure and behavior observed by Darktrace closely aligned with a campaign reported by Rapid7, in which a WebDAV malware delivery environment was exposed. Rapid7 assessed that threat actors had used generative AI to support the development, testing, documentation and refinement of the operation. The observed activity also aligned with reporting on a campaign in which impersonation of Mexico’s government Unique Population Registry Code (CURP) identity-record service led to delivery of PureRAT, a .NET-based information stealer and remote access trojan (RAT) [2]. The infrastructure overlap and consistent behavioural sequence provides strong alignment and offers a view of how an AI-assisted development pipeline ultimately manifested inside target environments.

Case 2: A suspected China-linked intrusion campaign with AI-assisted automation

In July 2026, Hunt.io published research into a suspected China-based intrusion operation targeting government and financial services organizations [3]. Material recovered from exposed attacker infrastructure by Hunt.io indicated that Claude Code and DeepSeek-v4-pro were being used as active components of the attacker’s workflow. According to the research, the models supported activities including attack reasoning, script generation, execution, exploit adaptation, and phishing-page development.

The investigation identified 192.229.115[.]229 and 192.229.115[.]230 as infrastructure associated with suspected TencShell operations and a possible second C2 framework known as Gshell [3].

Darktrace identified likely related activity within a financial services customer environment involving a newly observed laptop running the Windows 11 Pro operating system. Over a six-day period in July, the device made repeated outbound connections to 192.229.115[.]229 over port 8083.

Darktrace recognized the destination was highly rare for the environment, and the connectivity exhibited beaconing characteristics. During the same timeframe, Darktrace also identified suspicious process behavior associated with process chains involving svchost.exe and cmd.exe. The device repeatedly communicated with infrastructure identified in the Hunt.io research while exhibiting beaconing characteristics and suspicious process activity, strengthening the assessment that the activity likely was associated with the same operation.

Unlike many previous examples of AI-assisted cybercrime, the Hunt.io investigation provided rare visibility into how large language models were being incorporated directly into operational workflows rather than being used solely for content generation. Darktrace, meanwhile, observed how activity associated with that operation ultimately manifested inside a target environment, providing a complementary view of its operational impact.

Operational consequences of AI-assisted attacks

These investigations provide two complementary perspectives on AI-assisted cyber operations. OSINT research revealed how AI was incorporated into attacker workflows, while Darktrace observed the resulting activity within customer environments.

Although AI played different roles in each campaign, it did not remove the need for attackers to interact with their targets, deliver payloads, execute processes, and communicate with C2, all of which generated observable signals.

In these cases, Darktrace identified suspicious file delivery, unusual process behavior, beaconing activity, and communication with rare external infrastructure that aligned with campaigns later linked to AI-assisted operations. While AI may influence how attacks are developed, adapted, and scaled, it does not make them operationally invisible.

For defenders, the broader lesson extends beyond these specific campaigns. As AI becomes increasingly embedded within both enterprise operations and attacker workflows, understanding what a model was asked to do is often less important than understanding the actions it ultimately took and the consequences those actions produced. Whether the actor is human, AI-assisted, or increasingly autonomous, activity still manifests through identities, endpoints, applications, cloud services and network infrastructure.

Credit to Angel Arribas Lopez (Associate Principal Cyber Analyst), Emma Foulger (Global Threat Research Operations Lead), Nathaniel Jones, SVP Global Threat Intelligence
Edited by Ryan Traill (Content Manager)

‍

Appendices

Darktrace Model Detections

Case 1

Anomalous File / Masqueraded File Transfer from New External Endpoint

Anomalous File / Script from Rare External Location

Anomalous File / EXE from Rare External Location

Anomalous File / Script and EXE from Rare External

Anomalous Connection / Multiple Failed Connections to Rare Endpoint

Anomalous Connection / Rare External SSL Self-Signed

Compromise / New or Repeated to Unusual SSL Port

Compromise / Large Number of Suspicious Failed Connections

Device / Initial Attack Chain Activity

Antigena / Network / External Threat::Antigena Suspicious File Block

Antigena / Network / Significant Anomaly::Antigena Enhanced Monitoring from Client Block

Antigena / Network / Significant Anomaly::Antigena Controlled and Model Alert

Antigena / Network / External Threat::Antigena File then New Outbound Block

Antigena / Network / Significant Anomaly::Antigena Significant Anomaly from Client Block

Antigena / Network / Significant Anomaly::Antigena Alerts Over Time Block

Case 2

Anomalous Connection / Multiple Failed Connections to Rare Endpoint

Compromise / High Volume of Connections with Beacon Score

Compromise / Large Number of Suspicious Failed Connections

‍

Indicators of Compromise (IoCs)

‍

Case 1

                                                                                                                                                                                                                                                 
IoCTypeDescription + Confidence
onedrive[.]cvHostnameLikely C2 server
138.124.123[.]87IP AddressPossible C2 server
hXXp://onedrive[.]cv/Downloads/CURP/ReportFinal.%E2%80%AE%E1%BA%9D%D4%81%EF%BD%90.scrURIPossible payload
google.services[.]ugHostnameLikely C2 server
77.110.127[.]205IP AddressLikely C2 server
google.services[.]ug:57666Hostname + PortLikely C2 communication
google.services[.]ug:57888Hostname + PortLikely C2 communication
google.services[.]ug:56001Hostname + PortLikely C2 communication

‍

Case 2

IoC Type Description + Confidence
192.229.115[.]229 IP Address Likely C2 communication
Continue reading
About the author
Angel Arribas Lopez
Associate Principal Cyber Analyst
Your data. Our AI.
Elevate your network security with Darktrace AI