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.
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
Share
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.
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.
Figure 2: Image layer RUN command to retrieve xmrig miner
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.
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:
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.
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
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.
Hiding in Plain Sight: Uncovering a Multi-Stage Ransomware Attack Through Behavioral Detection
Why ransomware has changed
Ransomware attacks have continued to increase globally, with 698 incidents reported in May 2026, representing a 48% rise compared to 472 incidents in May 2025 [1]. At the same time, the ransomware landscape is evolving. Several major ransomware groups, including LockBit [2], have been disrupted by successful joint law enforcement operations, resulting in a shift away from a small number of dominant actors towards a more fragmented and distributed ecosystem. This is increasingly composed of smaller groups who play a specialized role in the attack, such as initial access brokers, affiliates or developers.
As a result, ransomware tactics, techniques, and procedures (TTPs) are becoming more diverse and less predictable. On top of this, adversaries are leveraging native tools and legitimate penetration testing frameworks to evade detection. Anomaly-based detection is therefore critical to identify pre-ransomware activity, rather than relying on signatures associated with a handful of well-known ransomware groups.
As these attacks often unfold over several days, there is a critical window for defenders to act. In this context, behavioral-based detection plays a vital role in identifying suspicious pre-ransomware activity, and enabling early intervention before encryption or exfiltration occurs.
Inside a modern ransomware intrusion
In early 2026, Darktrace detected activity within a customer’s environment related to a multi-stage ransomware intrusion from the initial compromise. This activity does not appear to be attributable to a specific ransomware group, and no known ransomware payload was observed until the final stage.
The attack aligns with a broader industry trend in which compromised virtual private network (VPN) credentials are used as an entry point, followed by rapid internal reconnaissance and lateral movement using legitimate administrative tools. This growing preference for native tools and legitimate frameworks in cyber-attacks illustrates that it is increasingly unreliable to depend solely on traditional indicators of compromise such as known malware signatures or exploit detection.
The intrusion also involved the use of Sliver, an open-source adversary emulation framework, which is increasingly observed in real-world attacks. Originally designed for penetration testing and red teaming, Sliver has gained traction among threat actors as a stealthier alternative to more heavily signatured frameworks such as Cobalt Strike. As a legitimate framework, its use further complicates detection for security tools that rely on known malicious signatures.
Darktrace’s detection of a ransomware event in a customer’s environment
The initial compromise appears to have occurred via compromised credentials used over the VPN shortly before, or at the onset of the first indicators of suspicious activity. While it remains unclear as to how or when the threat actors gained access to these credentials, the use of initial access brokers (IABs) is a common feature of modern ransomware operations. This suggests that access to the environment may have been established several days or weeks beforehand.
The intrusion unfolded over three days, presenting multiple opportunities for early detection and intervention before ransomware deployment. The attack progressed through a compressed but structured sequence: initial access and reconnaissance were completed within hours, followed by privilege escalation and lateral movement the next day, and culminating in data exfiltration and encryption shortly thereafter. Throughout each stage, distinct behavioral anomalies emerged across the network providing clear indicators of malicious activity well before the ransomware was deployed.
While Darktrace’s Autonomous Response capability was enabled within the customer’s environment, it was not fully configured across the impacted devices, allowing the attack to progress to ransomware deployment. Had Autonomous Response been fully deployed across the affected systems, it could have taken targeted action against the earliest stages of malicious activity, potentially disrupting the intrusion before it escalated.
Figure 1: Timeline of the attack progression.
Day 1: Reconnaissance and privilege escalation
The threat actor gained access via compromised VPN credentials and initiated internal reconnaissance. Darktrace detected anomalous scanning behavior, including unusual port scanning activity and widespread network enumeration.
Specifically, Darktrace detected a high volume of east-west scanning activity across a broad range of ports, with TCP connections targeting ports 21, 80, 445, 4899 and 8080. Associated URIs suggested the use of Nmap, a widely used penetration testing tool. This highlights how attackers often leverage legitimate penetration testing tools for malicious reconnaissance, enabling them to blend into normal network activity and evade traditional signature-based detection methods.
Figure 2: Darktrace's detection of a sharp increase in anomalous internal connections, triggering multiple high-severity model alerts associated with reconnaissance activity.
Several devices were observed using administrative credentials to carry out privileged actions in a manner that was highly anomalous for the environment. This activity was accompanied by behavior consistent with SMB authentication scanning, suggesting efforts to identify and access additional systems. As the activity intensified, an increasing number of devices became involved, signalling lateral movement and further spread across the network.
Darktrace also identified privilege escalation through active directory (AD) replication abuse, specifically via the drsuapi::DRSGetNCChanges function. This technique allows an attacker with sufficient privileges to request directory replication data from a domain controller (DC), enabling them to extract credentials, including password hashes, without directly interacting with user accounts. Commonly associated with ‘DCSync’ attacks, this technique is frequently used to obtain highly privileged credentials and enable further escalation within an environment.
Figure 3: Darktrace’s detection of anomalous AD replication activity indicative of privilege escalation.
This activity was seen alongside the use of the now obsolete SMBv1, repeated NTLM authentication attempts using multiple variations of ‘Administrator’ credentials, reverse DNS scanning, and large-scale network scanning. Darktrace observed widespread use of SMBv1 across the customer’s environment, exposing a significant security weakness. As a legacy protocol with well-documented weaknesses, SMBv1 can be exploited to facilitate lateral movement, allowing the attackers to expand their access following initial compromise.
Day 3: Lateral Movement, Command & Control, and Exfiltration
Two days later, the attacker escalated privileges and expanded their foothold using living-off-the-land (LOTL) techniques such as PSExec, WMI, and RDP. Concurrently, Darktrace identified command-and-control (C2)-style communications consistent with the Sliver framework, alongside rare outbound connections to cloud infrastructure indicating potential data exfiltration. The volume and severity of observed activity increased as attack behavior intensified.
The device was observed conducting extensive lateral movement, leveraging LOTL techniques to evade detection. Activity included WMI execution (e.g. ExecQuery), DCE-RPC activity, SMB sessions and file writes, most of which were successful, as well as the deployment of PSEXESVC.exe via ADMIN$ shares and prolonged RDP sessions. Darktrace identified this behavior as highly anomalous for the environment. Such activity is commonly associated with the transfer of attacker tooling, remote command execution, and the establishment of persistent access across compromised systems.
Figure 4: Darktrace’s detection of a spike in RPC binding events indicative of potential lateral movement.
On the same day, Darktrace detected C2-style SSL communications originating from multiple internal devices to rare external endpoints. These connections exhibited anomalous characteristics, including invalid SSL certificates and repeated connection patterns resembling beaconing. Analysis of the observed JA3 fingerprint further linked the activity to Sliver, the adversary simulation framework referenced earlier, as the hash has previously been associated with Sliver-related infrastructure [3]. The use of this framework reflects a broader trend of attackers repurposing legitimate offensive security tools for stealthy C2 communications. Connections to 137[.]220[.]59[.]55 (ASN AS20473 AS-VULTR) indicated that the communications were likely routed via a virtual private server (VPS) hosted by Vultr. Attackers often utilize VPS infrastructure from legitimate cloud providers like Vultr to obscure their true origin, blend into benign traffic, and evade IP-based detection mechanisms [4].
Figure 5: Darktrace’s Cyber AI Analyst detection of two linked unusual connections to Vultr infrastructure.
Darktrace also observed a device initiating SSL connections to safedata.s3[.]wasabisys[.]com, an endpoint associated with Wasabi cloud storage. Darktrace recognized that neither the destination nor the associated IP address had previously been observed within the environment. More than 200 MB of data was subsequently uploaded externally to endpoints sharing the same JA3 client hash, indicating a sustained transfer session and potential data exfiltration to third-party storage. The apparent exfiltration prior to encryption is consistent with a double-extortion ransomware strategy.
Figure 6: Darktrace’s Cyber AI Analyst detection of more than 30 rare outbound connections to a Wasabi cloud storage endpoint, indicative of potential data exfiltration
Day 4: Encryption
The attack culminated in ransomware deployment, marking the transition from suspicious network activity to a business-impacting incident. Using SMB-based propagation, the threat actor encrypted thousands of files across the network, affecting multiple systems and disrupting normal operations. Throughout the encryption event, the legacy SMBv1 protocol was used extensively across multiple internal systems, resulting in a significant increase in newly encrypted files.
Figure 7: Darktrace’s detection of abnormal spikes in SMB activity and associated model alerts, indicative of ransomware encryption and propagation.
Darktrace’s Cyber AI Analyst automatically investigated and correlated the encryption activity and related events into a single incident narrative, providing the customer with real-time visibility into the attack while significantly reducing investigation time.
Figure 8: Darktrace’s Cyber AI Analyst’s investigation into the encryption activity. AI Analyst incident detailing example encryption activity in real time. Related events are automatically correlated and summarized into a clear narrative, reducing investigation time.
Defender action recommendations
What Could Have Stopped the Attack Earlier?
Although the attack ultimately resulted in ransomware deployment, there were multiple opportunities to detect, contain, and disrupt the intrusion before encryption occurred. The following actions could have significantly reduced the overall impact:
Detect and investigate indicators of reconnaissance and lateral movement
Unusual scanning
Active Directory replication anomalies consistent with DCSync activity
Anomalous use of native tools and processes indicative of LOTL attacks
Unusual use of common reconnaissance tools such as Nmap and NetScan
Contain compromised credentials and affected devices
Disable and reset compromised VPN credentials
Isolate devices performing anomalous scanning and lateral movement activity
Block suspicious external communications and data exfiltration
Use anomaly-based detection to detect and block repeated outbound connections to rare external infrastructure
Prevent data exfiltration to unauthorized cloud storage services such as Wasabi
Conclusion
The incident highlights the importance of anomaly-based detection, particularly against attacks that primarily use native or legitimate tools to evade traditional security measures. Darktrace identified suspicious activity from the first day of the compromise, providing multiple opportunities to disrupt the intrusion before it progressed to lateral movement and data exfiltration.
In this instance, detection was not the limiting factor; response time was. Prompt investigation and containment of devices exhibiting anomalous behavior could have prevented lateral movement, data exfiltration, and ultimately ransomware deployment.
As adversaries increasingly prioritize stealth over custom malware, relying instead on legitimate tools, valid credentials, and trusted infrastructure, traditional signature-based detection becomes less effective. Identifying subtle behavioral deviations early remains critical to disrupting attacks before they escalate into full-scale ransomware incidents.
Credit to Alexandra Evzona (Cyber Analyst), Priya Thapa (Senior Cyber Analyst) Edited by Ryan Traill (Content Manager)
Darktrace / EMAIL Expands Behavioral Defense Across Email and Collaboration Workflows
Email and collaboration tools do more than carry messages. They are where organizations approve payments, share sensitive data, reset credentials, and make thousands of everyday decisions. Increasingly, they are interfaces through which humans direct AI agents in their daily activity. Email, Slack and Teams are high volume, rich with sensitive data, and an easy place to hide malicious activity.
The opportunity isn’t lost on bad actors. Darktrace / EMAIL detected more than 32 million high-confidence phishing emails globally in 2025, and 70% of those messages passed DMARC authentication. Phishing is increasingly difficult to detect and familiar trust signals alone are not enough. People and security teams need to understand how a message fits the normal behavior of the sender, recipient, and organization. They also need to correlate activity across platforms to spot threats that span multiple channels.
To effectively secure against today’s evolved threats, security teams need to act at two levels: they need to help each employee make a safer decision ‘in the moment’, and they need to understand the wider patterns that may expose the business to risk.
Darktrace is introducing four new capabilities in Darktrace / EMAIL to address both challenges. The new features explain suspicious content more clearly to end users, strengthen the capabilities of Darktrace / Adaptive Human Defense with richer guidance, let organizations define their own patterns for detecting sensitive data in messages, and give security teams a process-level view of risk across email and collaboration workflows.
Darktrace / EMAIL Inbox Analysis highlights risky content within your emails
A warning is more useful when it explains what the user should look at. To help do that, we’ve expanded Darktrace / EMAIL’s Inbox Analysis Add-In to highlight potentially dangerous content within the body of emails that Darktrace / EMAIL flags as potentially suspicious or high risk.
The add-in can highlight language designed to create urgency, financial references, requests for payment, suspicious links, and content that is unusual for the sender. Each highlighted element includes a pop up that explains why it may be suspicious. Instead of asking an employee to accept a verdict without context, the analysis helps them examine the message and make a more informed decision.
Enhanced Just-In-Time Training Banners in Darktrace / Adaptive Human Defense
Enhanced Just-In-Time Training Banners build on the same principle. The banners now include a contextual header, actionable advice, and specific detection context. This gives employees more useful guidance at the point of risk without adding unnecessary information or cognitive load.
Together, the capabilities help turn a warning into a short learning moment. Employees can see what looks unusual, understand what action to take, and build their judgment.
Custom Sensitive Data Detection in Darktrace / EMAIL - Data Loss Prevention
Sensitive data is different for every business. Standard categories such as payment card details or government identifiers matter, but organizations also have their own customer codes, project names, research formats, account structures, and internal identifiers.
Custom Sensitive Data Detection in Darktrace / EMAIL - Data Loss Prevention allows administrators to write custom expressions for the data their organization needs to protect. Matched content can trigger existing model actions and data loss prevention (DLP) workflows, extending Darktrace's DLP capabilities.
This extends data loss detection beyond a fixed library of common data types. Security teams can apply controls to information that is sensitive in the context of their own organization and adapt those controls as the business changes.
Introducing Email and Collaboration Workflow Risk Posture Dashboards
Some of the most important risks are not isolated events. They are repeated ways of working that create an opening for error, misuse, or attack. For example, a payment request may be one suspicious message, but a recurring approval workflow that relies on weak verification is a business process risk.
The new Email and Collaboration Workflow Risk Posture Dashboard analyzes email and collaboration data across Email, Microsoft Teams, Slack and Zoom to provide a process-level view of risk in the organization. These may include financial authorization workflows, sensitive data sharing patterns, and activity that could expose credentials.
The dashboard brings these patterns into a view and provides actionable recommendations. This helps security teams determine where to investigate or strengthen controls, where ownership needs to be clarified, and where the business may need to change a risky process. It gives CISOs a clearer view of how human and communication risk is embedded in everyday operations, not only where individual alerts occur.
Behavior connects the individual decision to the wider risk
These capabilities build on Darktrace’s unique behavioral approach to security. We use Adaptive AI to learn how people and AI normally behave within an organization, creating the context needed to recognize when activity changes.
Within the Darktrace Behavioral Defense Platform, Darktrace / EMAIL helps protect people against phishing, account takeover, data exfiltration, and human risk across email and collaboration tools. The new capabilities extend that protection in both directions. They give employees clearer context for the decision in front of them, while giving security leaders a broader view of the workflows and behavior that create risk across the organization.
The result is not simply more alerts. It is a better understanding of why something is risky, what action to take, and where the organization can reduce risk before a familiar process becomes an easy route for an attacker.
.jpg)
