ShadowV2 Botnet Builds Cloud Scale Attacks from Exposed Docker APIs

Threat Group – ShadowV2 operators cybercrime as a service actors
Threat Type – DDoS as a Service and botnet
Exploited Vulnerabilities – Publicly exposed or unauthenticated Docker daemon APIs on cloud hosts, weak network segmentation, deficient egress controls, inadequate governance of infrastructure as code
Malware Used – Python based spreader and control scripts, Go based remote agent and DDoS payload, headless browser automation components for mitigation bypass
Threat Score – 7.8 🔴 High
Last Threat Observation – 24 September 2025 AEST based on vendor and media reporting

Overview

ShadowV2 is a sophisticated cloud native Distributed Denial of Service platform that industrialises the DDoS for hire model. Rather than herding vast numbers of low power consumer devices, operators exploit a common cloud misconfiguration. They scan for Docker daemons that are reachable from the public internet and accept unauthenticated API requests. Once found, they take full control of the container runtime, build and deploy a malicious image directly on the victim, and register the host into a managed attack network. The platform exposes a professional multi tenant interface with role based access, an operator API, and a modular toolkit that includes high rate HTTP floods, HTTP slash two rapid reset attacks, and automated bypasses for web application protections. By conscripting cloud virtual machines, ShadowV2 harnesses significant compute and bandwidth per node. This yields a higher return on compromise than legacy botnets and raises the ceiling on achievable impact.

The Core Problem

The success of ShadowV2 does not hinge on a zero day exploit. It feeds on basic security gaps. An unauthenticated Docker daemon API on a public address is equivalent to a master key for the host. With this single misconfiguration, an adversary can create containers, mount host resources, build images locally, and plant a resident agent. No additional privilege escalation is required. This is emblematic of a wider industry challenge. Cloud misconfiguration has become a primary attack surface. ShadowV2 demonstrates that modern adversaries are aligning to the realities of cloud adoption and DevOps velocity. Where configuration drift or lax governance exists, attackers convert it into operational scale.

Key Recommendations

Defenders must extend control from the perimeter into the cloud control plane and the container runtime. Priority actions include a top down governance review that forbids public exposure of container management APIs, a rapid audit to identify any reachable Docker endpoints, and a defence in depth programme that hardens the platform, restricts egress, and focuses on behavioural detection. Since ShadowV2 builds unique images on each host, traditional file based indicators will not suffice. Security teams should instrument for anomalous Docker API usage, unexpected container lifecycle events, headless browser behaviour inside containers, and sudden outbound HTTP or HTTP slash two surges from cloud instances.

The ShadowV2 Threat Profile – Context for a Cloud Native Adversary

A New Breed of Cybercrime – From Quantity to Capability

Historic DDoS botnets such as Mirai emphasised scale through volume. They compromised many low power devices and won by numbers. ShadowV2 reflects a strategic shift from volume to capability. Each compromised cloud instance provides high throughput and strong compute characteristics. Operators can assemble a potent network with fewer nodes and less noise. The economics change in the adversary’s favour. With fewer moving parts, orchestration becomes simpler, resilience improves, and the attack surface is concentrated where defenders may lack deep visibility. The cloud first operating model and the ubiquity of container tooling combine to make this shift both practical and profitable for attackers.

DDoS as a Service – A Professionalised Model

Research indicates ShadowV2 operates as a structured service. The control plane presents a login panel for users and administrators, a policy for tiered privileges, and a documented operator API. Modern frameworks such as FastAPI and Pydantic are used to define and validate requests, and the presence of an OpenAPI specification signals deliberate engineering. Analysts observed an exposed endpoint during investigation that allowed partial enumeration of functions. Those functions included user management, target configuration, attack parameters, and exclusion lists. This subscription like approach commoditises DDoS capacity. It lowers the barrier to entry for would-be attackers and aligns to broader cybercrime trends where malicious infrastructure is packaged like a product. Some reporting further notes a possibility of paid protection or exclusion offers, which echoes the double service model seen in other for hire markets.

Threat Score – Re-evaluation and Justification

A score of 7.8 High is sustained after deeper review.

• Attack surface. Exposed Docker APIs are a known and widespread misconfiguration. Basic scans discover them at internet scale.
• Ease of exploitation. Once found, unauthenticated API access enables full container management with trivial scripting. No kernel exploit or privilege escalation is required.
• Scale and impact. Cloud hosts provide significant egress bandwidth and CPU. Aggregated across even a modest set of nodes, the potential attack throughput is substantial.
• Detection difficulty. The tooling builds unique images on each host, which defeats static hash based detection. The traffic patterns can mimic real clients by using headless browsers and randomised headers.
• Operational maturity. A multi tenant backend and attack orchestration API signal a repeatable and resilient operation.

The combination of low effort, high payoff, and service driven orchestration results in material operational risk for any organisation that runs containerised workloads.

Deep Dive – The Cloud Native Attack Chain

Initial Access and Reconnaissance – The Attack Surface

1. Scanning. Adversaries sweep the internet for open Docker daemons and other management services. They target the TCP endpoint that exposes the Docker Engine API and test for unauthenticated access.
2. Validation. Once a host responds, a Python script using the Docker SDK queries version details and capabilities.
3. Preparation. The script creates a staging container from a generic base image. The intent is to keep early forensic artefacts bland and low profile.
4. Governance gap. The root cause is not a novel exploit. It is an absence of basic controls. Exposure of a management API to the public network, without authentication, violates secure design and makes compromise a process rather than a challenge.

Malware Deployment and Evasion – The Anti-forensic Strategy

ShadowV2 avoids pulling a known malicious image from a registry. Instead, the spreader script performs a local build on the victim.

• Setup container. A base image such as Ubuntu is launched.
• Tool installation. Package managers and fetch utilities are installed inside the container. Headless browser components may be added to enable challenge solving.
• Payload placement. A compiled Go agent is dropped into the container.
• Imaging. The modified container is committed as a new local image and then launched as the active worker.

This on the fly imaging produces unique artefacts per host. There is no single hash to share. Defenders must look for the process of compromise rather than the artefact of compromise. Suspicious markers include unexpected use of package managers inside a running container, the sudden appearance of headless browser binaries, and local commits that do not match the organisation’s build pipeline.

Command and Control and Bot Functionality

The deployed Go agent operates as a remote access component and attack worker.

• Beaconing. The agent issues periodic heartbeats to a command endpoint and polls for tasks.
• Hardening awareness. It may check for traffic capture tools and virtualised analysis environments to frustrate sandboxing.
• Tasking. Instructions contain method, target, duration, and header configuration. Exclusion lists can be enforced globally to avoid unwanted attention.
• Infrastructure shielding. The control domain is fronted by a protection service to conceal the origin of the servers. One domain publicly associated with the campaign is shadow.aurozacloud[.]xyz.

Offensive Capabilities and Evasion – The Attack Toolkit

HTTP slash two rapid reset
This technique abuses stream multiplexing. The worker opens many request streams over a single connection and immediately cancels them with reset frames. The cost to the attacker is low since a single connection can generate significant server side work. The cost to the defender is high because the server must allocate and then tear down resources for each stream. Large operations have measured attacks at extreme request rates using this method. Effective mitigation requires protocol aware controls that limit stream creation and reset patterns rather than only connection counts.

Automated defence bypass
ShadowV2 integrates headless browser automation to overcome JavaScript based challenges such as those presented by common web protection services. The worker simulates a real session, obtains a clearance token, and proceeds to deliver flood traffic that now appears to have passed an interactive gate. This blurs distinctions between human and automation. It forces defenders to employ techniques such as TLS fingerprinting and behaviour analysis rather than relying on simple checks.

Header and identity randomisation
Traffic generation routines vary user agents and headers, manipulate forwarding headers, and adjust request pacing to reduce signature overlap. The goal is to make flows look like diverse legitimate clients and to frustrate rules that key off repeated patterns.

Service orchestration
The operator backend exposes a structured API and a console view. Users can define targets, set durations, select methods, and schedule attacks. Role based access limits which functions are available to customers versus administrators. The service model implies that attacks can be coordinated across many workers with minimal human effort at launch time.

Key Details

Delivery Method

• Internet wide scanning for reachable Docker management endpoints.
• Automated interaction with the Docker Engine API using Python scripts.
• Creation of a generic staging container followed by installation of tooling.
• Local commit of a modified image to avoid registry based detection.
• Launch of a resident worker that registers with command and control.
• Operator driven tasking that instructs workers to perform floods with chosen methods.

Target

• Primary. Cloud virtual machines that run Docker and expose the API to public networks.
• Secondary. Any container platform where management interfaces are reachable without strong access controls.
• Downstream victims. Internet facing services selected by customers of the platform.

Functions – Malicious Capabilities

• Remote command and control for worker orchestration.
• High rate HTTP floods and HTTP slash two rapid reset attacks.
• Headless browser challenge solving to acquire clearance tokens.
• Automated header and identity randomisation.
• Multi tenant operator API with user and target management.
• Minimal forensic footprint via unique local images.

Obfuscation

• Use of protection services to mask infrastructure origin.
• Behaviour that mimics real clients through browser automation.
• Removal of a common image artefact by building workers locally.
• Potential lockout of the Docker API from other sources to keep access exclusive.

Attack Vectors

• Management plane exposure. Docker API reachable from the public internet and unauthenticated.
• Weak segmentation. No separation between management networks and untrusted networks.
• Overly permissive infrastructure as code. Templates that open broad access without guardrails.
• Insufficient egress controls. Container hosts permitted to make arbitrary outbound connections.
• Runtime drift. Containers allowed to install packages at runtime, which enables headless browser and tool drops.
• Lack of rate shaping. No quotas or limits on outbound flows from container hosts.

Known Indicators of Compromise

Network and Behavioural Indicators

• Docker API calls such as container create and image commit originating from non management addresses.
• Unexpected container lifecycles on hosts that are not part of deployment pipelines.
• Package manager execution inside containers where builds are intended to be immutable.
• Presence of headless browser components within newly created containers.
• Regular outbound beaconing from containers to previously unseen domains.
• Sudden growth in outbound HTTP and HTTP slash two traffic volume from cloud instances.
• Header patterns that change rapidly or present as synthetic clients at scale.
• Local firewall or cron changes that attempt to block access to the Docker API from other sources.

Mitigation and Prevention

User Awareness and Governance

• Establish a clear policy that forbids public exposure of container management interfaces.
• Require controls for change management and peer review of infrastructure as code templates.
• Include container misconfiguration scenarios in tabletop exercises for platform and security teams.
• Define ownership for Docker daemon configuration and audit responsibility.

Network and Access Controls

• Do not enable the Docker TCP socket on public addresses. Prefer the local Unix socket for management.
• If remote access is needed, enforce mutual TLS with client certificates and restrict by source network.
• Place management interfaces behind bastion hosts and require multifactor authentication.
• Apply deny by default egress policies at the host and VPC layers. Only allow required destinations.
• Rate limit outbound traffic from container hosts and enforce per host quotas.
• Segment container networks and isolate high risk or public facing workloads.

Docker and Container Hardening

• Keep the Docker engine and host operating system patched.
• Consider rootless mode for the daemon where operationally feasible.
• Use image signing and verify provenance for all base images and layers.
• Block runtime package installation by policy. Treat unexpected package installs as an alert.
• Scan images in the CI pipeline and block builds that include headless browser binaries unless explicitly required.
• Use read only root filesystems and drop unnecessary capabilities from containers.
• Avoid bind mounting sensitive host paths into containers.

Detection and Logging

• Enable verbose logging for Docker API calls and container lifecycle events.
• Centralise logs from container hosts, the Docker daemon, and orchestration layers.
• Build SIEM rules that alert on container creation by users or sources outside the deployment system.
• Instrument for periodic beacon patterns and for HTTP slash two reset patterns at edge devices.
• Monitor DNS and network flow logs for new destinations contacted by container hosts.
• Apply TLS fingerprinting at egress points to detect automated headless browser traffic.

Patch and Update

• Maintain current versions of web servers, proxies, and libraries that implement HTTP slash two.
• Track vendor advisories for fixes and mitigations related to rapid reset behaviour.
• Periodically rescan external facing addresses to verify that management interfaces remain closed.

Incident Response and Forensic Preparedness

• Maintain a playbook for container compromise that includes rapid isolation and evidence preservation.
• Snapshot compromised virtual machines and export Docker artefacts such as images, layered filesystems, and container logs.
• Coordinate with cloud providers to throttle or suspend egress from affected instances while preserving data for analysis.
• Pre stage blocks for identified control domains and update them as intelligence is received.
• After containment, conduct a configuration review to remove the root cause of exposure and validate across all templates.

Actionable Intelligence for the Security Engineer

Behavioural Indicators and Data Sources

Building Practical Detections

• SIEM rules. Flag container creation events where the initiating principal is not in the deployment service account list. Flag image commits performed on production hosts.
• Runtime sensors. Alert when a container binary spawns headless browser processes or when a package manager runs after container start.
• Network analytics. Track per host baselines and alert on excursions. Add protocol aware detections for HTTP slash two stream resets.
• Threat hunting. Periodically query for Docker API calls from unknown addresses, and for containers that were created outside the normal change window.

Risk Assessment

Attack surface and exploitable conditions
Container adoption is strong across industries. Misconfiguration is common. It is simple to automate discovery of exposed Docker APIs. Once found, the adversary gains control of the container runtime without needing a privilege escalation.

Ease of exploitation and scale potential
A small Python script interacting with the Docker SDK is sufficient to stage the attack. Because each cloud instance offers strong throughput, the network scale required to reach significant volume is modest. Operators can keep the set of compromised hosts lean, which reduces churn and discovery.

Impact and detection difficulty
Targets may experience severe downtime and collateral financial impact. Traditional defences that focus on signatures or static IoCs are less effective. The attacker randomises headers and can present as a real client through headless automation. Detection success therefore depends on behavioural analytics and management plane telemetry.

Persistence and remediation complexity
If the root management exposure is not removed, re-abuse is likely. Remediation requires a configuration and governance fix across pipelines and not only host by host cleanup. Incident response must include control of egress to prevent the environment from being used as an attack amplifier during cleanup.

Overall risk conclusion
ShadowV2 is a high risk threat with modern tradecraft. It is efficient, modular, and aligned to cloud realities. Any organisation that runs containers should treat exposure of management interfaces as a critical issue and address it with urgency.

Conclusion and Recommendations

ShadowV2 demonstrates that adversaries are comfortable operating inside cloud norms. They build images, automate through APIs, and orchestrate attacks with the same discipline that well run platform teams use for legitimate purposes. Defenders must therefore meet the threat where it lives. That means governance that closes management exposure, platform hardening that enforces strong authentication and least privilege, and telemetry that observes both the management plane and the runtime. Exercise the response plan, validate that egress can be constrained when required, and keep pace with protocol level mitigations for HTTP slash two attack patterns. Above all, treat configuration as security. The most effective fix for ShadowV2 is to remove the door it uses to enter.

Sources

The Hacker News – ShadowV2 Botnet Exploits Misconfigured AWS Docker Containers for DDoS for Hire – https://thehackernews.com/2025/09/shadowv2-botnet-exploits-misconfigured.html
SecurityWeek – ShadowV2 DDoS Service Lets Customers Self-Manage Attacks – https://www.securityweek.com/shadowv2-ddos-service-lets-customers-self-manage-attacks/
CSO Online – ShadowV2 turns DDoS into a cloud native subscription service – https://www.csoonline.com/article/4061598/shadowv2-turns-ddos-into-a-cloud-native-subscription-service.html