September 3, 2025

From PowerShell to Payload: Darktrace’s Detection of a Novel Cryptomining Malware

Cryptojacking attacks are rising as threat actors exploit hard-to-detect cryptomining malware. Learn how Darktrace detected and contained a cryptojacking attempt in its early stages using Autonomous Response, with expert analysis of the malware itself revealing insights into a novel cryptomining strain.

Written by

Keanna Grelicha

Cyber Analyst

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

Keanna Grelicha

Cyber Analyst

Sep 2025

What is Cryptojacking?

Cryptojacking remains one of the most persistent cyber threats in the digital age, showing no signs of slowing down. It involves the unauthorized use of a computer or device’s processing power to mine cryptocurrencies, often without the owner’s consent or knowledge, using cryptojacking scripts or cryptocurrency mining (cryptomining) malware [1].

Unlike other widespread attacks such as ransomware, which disrupt operations and block access to data, cryptomining malware steals and drains computing and energy resources for mining to reduce attacker’s personal costs and increase “profits” earned from mining [1]. The impact on targeted organizations can be significant, ranging from data privacy concerns and reduced productivity to higher energy bills.

As cryptocurrency continues to grow in popularity, as seen with the ongoing high valuation of the global cryptocurrency market capitalization (almost USD 4 trillion at time of writing), threat actors will continue to view cryptomining as a profitable venture [2]. As a result, illicit cryptominers are being used to steal processing power via supply chain attacks or browser injections, as seen in a recent cryptojacking campaign using JavaScript [3][4].

Therefore, security teams should maintain awareness of this ongoing threat, as what is often dismissed as a "compliance issue" can escalate into more severe compromises and lead to prolonged exposure of critical resources.

While having a security team capable of detecting and analyzing hijacking attempts is essential, emerging threats in today’s landscape often demand more than manual intervention.

This blog will discuss Darktrace’s successful detection of the malicious activity, the role of Autonomous Response in halting the cryptojacking attack, include novel insights from Darktrace’s threat researchers on the cryptominer payload, showing how the attack chain was initiated through the execution of a PowerShell-based payload.

Darktrace’s Coverage of Cryptojacking via PowerShell

In July 2025, Darktrace detected and contained an attempted cryptojacking incident on the network of a customer in the retail and e-commerce industry.

The threat was detected when a threat actor attempted to use a PowerShell script to download and run NBMiner directly in memory.

The initial compromise was detected on July 22, when Darktrace / NETWORK observed the use of a new PowerShell user agent during a connection to an external endpoint, indicating an attempt at remote code execution.

Specifically, the targeted desktop device established a connection to the rare endpoint, 45.141.87[.]195, over destination port 8000 using HTTP as the application-layer protocol. Within this connection, Darktrace observed the presence of a PowerShell script in the URI, specifically ‘/infect.ps1’.

Darktrace’s analysis of this endpoint (45.141.87[.]195[:]8000/infect.ps1) and the payload it downloaded indicated it was a dropper used to deliver an obfuscated AutoIt loader. This attribution was further supported by open-source intelligence (OSINT) reporting [5]. The loader likely then injected NBMiner into a legitimate process on the customer’s environment – the first documented case of NBMiner being dropped in this way.

Figure 1: Darktrace’s detection of a device making an HTTP connection with new PowerShell user agent, indicating PowerShell abuse for command-and-control (C2) communications.

Script files are often used by malicious actors for malware distribution. In cryptojacking attacks specifically, scripts are used to download and install cryptomining software, which then attempts to connect to cryptomining pools to begin mining operations [6].

Inside the payload: Technical analysis of the malicious script and cryptomining loader

To confidently establish that the malicious script file dropped an AutoIt loader used to deliver the NBMiner cryptominer, Darktrace’s threat researchers reverse engineered the payload. Analysis of the file ‘infect.ps1’ revealed further insights, ultimately linking it to the execution of a cryptominer loader.

Figure 2: Screenshot of the ‘infect.ps1’ PowerShell script observed in the attack.

The ‘infect.ps1’ script is a heavily obfuscated PowerShell script that contains multiple variables of Base64 and XOR encoded data. The first data blob is XOR’d with a value of 97, after decoding, the data is a binary and stored in APPDATA/local/knzbsrgw.exe. The binary is AutoIT.exe, the legitimate executable of the AutoIt programming language. The script also performs a check for the existence of the registry key HKCU:\\Software\LordNet.

The second data blob ($cylcejlrqbgejqryxpck) is written to APPDATA\rauuq, where it will later be read and XOR decoded. The third data blob ($tlswqbblxmmr)decodes to an obfuscated AutoIt script, which is written to %LOCALAPPDATA%\qmsxehehhnnwioojlyegmdssiswak. To ensure persistence, a shortcut file named xxyntxsmitwgruxuwqzypomkhxhml.lnk is created to run at startup.

Figure 3: Screenshot of second stage AutoIt script.

The observed AutoIt script is a process injection loader. It reads an encrypted binary from /rauuq in APPDATA, then XOR-decodes every byte with the key 47 to reconstruct the payload in memory. Next, it silently launches the legitimate Windows app ‘charmap.exe’ (Character Map) and obtains a handle with full access. It allocates executable and writable memory inside that process, writes the decrypted payload into the allocated region, and starts a new thread at that address. Finally, it closes the thread and process handles.

The binary that is injected into charmap.exe is 64-bit Windows binary. On launch, it takes a snapshot of running processes and specifically checks whether Task Manager is open. If Task Manager is detected, the binary kills sigverif.exe; otherwise, it proceeds. Once the condition is met, NBMiner is retrieved from a Chimera URL (https://api[.]chimera-hosting[.]zip/frfnhis/zdpaGgLMav/nbminer[.]exe) and establishes persistence, ensuring that the process automatically restarts if terminated. When mining begins, it spawns a process with the arguments ‘-a kawpow -o asia.ravenminer.com:3838 -u R9KVhfjiqSuSVcpYw5G8VDayPkjSipbiMb.worker -i 60’ and hides the process window to evade detection.

The program includes several evasion measures. It performs anti-sandboxing by sleeping to delay analysis and terminates sigverif.exe (File Signature Verification). It checks for installed antivirus products and continues only when Windows Defender is the sole protection. It also verifies whether the current user has administrative rights. If not, it attempts a User Account Control (UAC) bypass via Fodhelper to silently elevate and execute its payload without prompting the user. The binary creates a folder under %APPDATA%, drops rtworkq.dll extracted from its own embedded data, and copies ‘mfpmp.exe’ from System32 into that directory to side-load ‘rtworkq.dll’. It also looks for the registry key HKCU\Software\kap, creating it if it does not exist, and reads or sets a registry value it expects there.

Zooming Out: Darktrace Coverage of NBMiner

Darktrace’s analysis of the malicious PowerShell script provides clear evidence that the payload downloaded and executed the NBMiner cryptominer. Once executed, the infected device is expected to attempt connections to cryptomining endpoints (mining pools). Darktrace initially observed this on the targeted device once it started making DNS requests for a cryptominer endpoint, “gulf[.]moneroocean[.]stream” [7], one minute after the connection involving the malicious script.

Figure 5: Darktrace Advanced Search logs showcasing the affected device making a DNS request for a Monero mining endpoint.

Though DNS requests do not necessarily mean the device connected to a cryptominer-associated endpoint, Darktrace detected connections to the endpoint specified in the DNS Answer field: monerooceans[.]stream, 152.53.121[.]6. The attempted connections to this endpoint over port 10001 triggered several high-fidelity model alerts in Darktrace related to possible cryptomining mining activity. The IP address and destination port combination (152.53.121[.]6:10001) has also been linked to cryptomining activity by several OSINT security vendors [8][9].

Figure 6: Darktrace’s detection of a device establishing connections with the Monero Mining-associated endpoint, monerooceans[.]stream over port 10001.

Darktrace / NETWORK grouped together the observed indicators of compromise (IoCs) on the targeted device and triggered an additional Enhanced Monitoring model designed to identify activity indicative of the early stages of an attack. These high-fidelity models are continuously monitored and triaged by Darktrace’s SOC team as part of the Managed Threat Detection service, ensuring that subscribed customers are promptly notified of malicious activity as soon as it emerges.

Figure 7: Darktrace’s correlation of the initial PowerShell-related activity with the cryptomining endpoint, showcasing a pattern indicative of an initial attack chain.

Darktrace’s Cyber AI Analyst launched an autonomous investigation into the ongoing activity and was able to link the individual events of the attack, encompassing the initial connections involving the PowerShell script to the ultimate connections to the cryptomining endpoint, likely representing cryptomining activity. Rather than viewing these seemingly separate events in isolation, Cyber AI Analyst was able to see the bigger picture, providing comprehensive visibility over the attack.

Figure 8: Darktrace’s Cyber AI Analyst view illustrating the extent of the cryptojacking attack mapped against the Cyber Kill Chain.

Darktrace’s Autonomous Response

Fortunately, as this customer had Darktrace configured in Autonomous Response mode, Darktrace was able to take immediate action by preventing the device from making outbound connections and blocking specific connections to suspicious endpoints, thereby containing the attack.

Specifically, these Autonomous Response actions prevented the outgoing communication within seconds of the device attempting to connect to the rare endpoints.

Figure 10: Darktrace’s Autonomous Response blocked connections to the mining-related endpoint within a second of the initial connection.

Additionally, the Darktrace SOC team was able to validate the effectiveness of the Autonomous Response actions by analyzing connections to 152.53.121[.]6 using the Advanced Search feature. Across more than 130 connection attempts, Darktrace’s SOC confirmed that all were aborted, meaning no connections were successfully established.

Figure 11: Advanced Search logs showing all attempted connections that were successfully prevented by Darktrace’s Autonomous Response capability.

Conclusion

Cryptojacking attacks will remain prevalent, as threat actors can scale their attacks to infect multiple devices and networks. What’s more, cryptomining incidents can often be difficult to detect and are even overlooked as low-severity compliance events, potentially leading to data privacy issues and significant energy bills caused by misused processing power.

Darktrace’s anomaly-based approach to threat detection identifies early indicators of targeted attacks without relying on prior knowledge or IoCs. By continuously learning each device’s unique pattern of life, Darktrace can detect subtle deviations that may signal a compromise.

In this case, the cryptojacking attack was quickly identified and mitigated during the early stages of malware and cryptomining activity. Darktrace's Autonomous Response was able to swiftly contain the threat before it could advance further along the attack lifecycle, minimizing disruption and preventing the attack from potentially escalating into a more severe compromise.

Credit to Keanna Grelicha (Cyber Analyst) and Tara Gould (Threat Research Lead)

Appendices

Darktrace Model Detections

NETWORK Models:

· Compromise / High Priority Crypto Currency Mining (Enhanced Monitoring Model)

· Device / Initial Attack Chain Activity (Enhanced Monitoring Model)

· Compromise / Suspicious HTTP and Anomalous Activity (Enhanced Monitoring Model)

· Compromise / Monero Mining

· Anomalous File / Script from Rare External Location

· Device / New PowerShell User Agent

· Anomalous Connection / New User Agent to IP Without Hostname

· Anomalous Connection / Powershell to Rare External

· Device / Suspicious Domain

Cyber AI Analyst Incident Events:

· Detect \ Event \ Possible HTTP Command and Control

· Detect \ Event \ Cryptocurrency Mining Activity

Autonomous Response Models:

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

· Antigena / Network::External Threat::Antigena Suspicious Activity Block

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

· Antigena / Network::External Threat::Antigena Crypto Currency Mining Block

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

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

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

List of Indicators of Compromise (IoCs)

(IoC - Type - Description + Confidence)

· 45.141.87[.]195:8000/infect.ps1 - IP Address, Destination Port, Script - Malicious PowerShell script

· gulf.moneroocean[.]stream - Hostname - Monero Endpoint

· monerooceans[.]stream - Hostname - Monero Endpoint

· 152.53.121[.]6:10001 - IP Address, Destination Port - Monero Endpoint

· 152.53.121[.]6 - IP Address – Monero Endpoint

· https://api[.]chimera-hosting[.]zip/frfnhis/zdpaGgLMav/nbminer[.]exe – Hostname, Executable File – NBMiner

· Db3534826b4f4dfd9f4a0de78e225ebb – Hash – NBMiner loader

MITRE ATT&CK Mapping

(Tactic – Technique – Sub-Technique)

· Vulnerabilities – RESOURCE DEVELOPMENT – T1588.006 - T1588

· Exploits – RESOURCE DEVELOPMENT – T1588.005 - T1588

· Malware – RESOURCE DEVELOPMENT – T1588.001 - T1588

· Drive-by Compromise – INITIAL ACCESS – T1189

· PowerShell – EXECUTION – T1059.001 - T1059

· Exploitation of Remote Services – LATERAL MOVEMENT – T1210

· Web Protocols – COMMAND AND CONTROL – T1071.001 - T1071

· Application Layer Protocol – COMMAND AND CONTROL – T1071

· Resource Hijacking – IMPACT – T1496

· Obfuscated Files - DEFENSE EVASION - T1027

· Bypass UAC - PRIVILEGE ESCALATION – T1548.002

· Process Injection – PRIVILEGE ESCALATION – T055

· Debugger Evasion – DISCOVERY – T1622

· Logon Autostart Execution – PERSISTENCE – T1547.009

References

[1] https://www.darktrace.com/cyber-ai-glossary/cryptojacking#:~:text=Battery%20drain%20and%20overheating,fee%20to%20%E2%80%9Cmine%20cryptocurrency%E2%80%9D.

[2] https://coinmarketcap.com/

[3] https://www.ibm.com/think/topics/cryptojacking

[4] https://thehackernews.com/2025/07/3500-websites-hijacked-to-secretly-mine.html

[5] https://urlhaus.abuse.ch/url/3589032/

[6] https://www.logpoint.com/en/blog/uncovering-illegitimate-crypto-mining-activity/

[7] https://www.virustotal.com/gui/domain/gulf.moneroocean.stream/detection

[8] https://www.virustotal.com/gui/domain/monerooceans.stream/detection

[9] https://any.run/report/5aa8cd5f8e099bbb15bc63be52a3983b7dd57bb92566feb1a266a65ab5da34dd/351eca83-ef32-4037-a02f-ac85a165d74e

^{The content provided in this blog is published by Darktrace for general informational purposes only and reflects our understanding of cybersecurity topics, trends, incidents, and developments at the time of publication. While we strive to ensure accuracy and relevance, the information is provided “as is” without any representations or warranties, express or implied. Darktrace makes no guarantees regarding the completeness, accuracy, reliability, or timeliness of any information presented and expressly disclaims all warranties.}

^{Nothing in this blog constitutes legal, technical, or professional advice, and readers should consult qualified professionals before acting on any information contained herein. Any references to third-party organizations, technologies, threat actors, or incidents are for informational purposes only and do not imply affiliation, endorsement, or recommendation.}

^{Darktrace, its affiliates, employees, or agents shall not be held liable for any loss, damage, or harm arising from the use of or reliance on the information in this blog.}

^{The cybersecurity landscape evolves rapidly, and blog content may become outdated or superseded. We reserve the right to update, modify, or remove any content without notice.}

Written by

Keanna Grelicha

Cyber Analyst

Inside the SOC

Written by

Keanna Grelicha

Cyber Analyst

Director, Product Marketing - Cloud Security

Watch the NIS2 Webinar

Blog

Cloud

September 23, 2025

It’s Time to Rethink Cloud Investigations

Cloud Breaches Are Surging

Cloud adoption has revolutionized how businesses operate, offering speed, scalability, and flexibility. But for security teams, this transformation has introduced a new set of challenges, especially when it comes to incident response (IR) and forensic investigations.

Cloud-related breaches are skyrocketing – 82% of breaches now involve cloud-stored data (IBM Cost of a Data Breach, 2023). Yet incidents often go unnoticed for days: according to a 2025 report by Cybersecurity Insiders, of the 65% of organizations experienced a cloud-related incident in the past year, only 9% detected it within the first hour, and 62% took more than 24 hours to remediate it (Cybersecurity Insiders, Cloud Security Report 2025).

Despite the shift to cloud, many investigation practices remain rooted in legacy on-prem approaches. According to a recent report, 65% of organizations spend approximately 3-5 days longer when investigating an incident in the cloud vs. on premises.

Cloud investigations must evolve, or risk falling behind attackers who are already exploiting the cloud’s speed and complexity.

4 Reasons Cloud Investigations Are Broken

The cloud’s dynamic nature – with its ephemeral workloads and distributed architecture – has outpaced traditional incident response methods. What worked in static, on-prem environments simply doesn’t translate.

Here’s why:

Ephemeral workloads
Containers and serverless functions can spin up and vanish in minutes. Attackers know this as well – they’re exploiting short-lived assets for “hit-and-run” attacks, leaving almost no forensic footprint. If you’re relying on scheduled scans or manual evidence collection, you’re already too late.
Fragmented tooling
Each cloud provider has its own logs, APIs, and investigation workflows. In addition, not all logs are enabled by default, cloud providers typically limit the scope of their logs (both in terms of what data they collect and how long they retain it), and some logs are only available through undocumented APIs. This creates siloed views of attacker activity, making it difficult to piece together a coherent timeline. Now layer in SaaS apps, Kubernetes clusters, and shadow IT — suddenly you’re stitching together 20+ tools just to find out what happened. Analysts call it the ‘swivel-chair Olympics,’ and it’s burning hours they don’t have.
SOC overload
Analysts spend the bulk of their time manually gathering evidence and correlating logs rather than responding to threats. This slows down investigations and increases burnout. SOC teams are drowning in noise; they receive thousands of alerts a day, the majority of which never get touched. False positives eat hundreds of hours a month, and consequently burnout is rife.
Cost of delay
The longer an investigation takes, the higher its cost. Breaches contained in under 200 days save an average of over $1M compared to those that linger (IBM Cost of a Data Breach 2025).

These challenges create a dangerous gap for threat actors to exploit. By the time evidence is collected, attackers may have already accessed or exfiltrated data, or entrenched themselves deeper into your environment.

What’s Needed: A New Approach to Cloud Investigations

It’s time to ditch the manual, reactive grind and embrace investigations that are automated, proactive, and built for the world you actually defend. Here’s what the next generation of cloud forensics must deliver:

Automated evidence acquisition
Capture forensic-level data the moment a threat is detected and before assets disappear.
Unified multi-cloud visibility
Stitch together logs, timelines, and context across AWS, Azure, GCP, and hybrid environments into a single unified view of the investigation.
Accelerated investigation workflows
Reduce time-to-insight from hours or days to minutes with automated analysis of forensic data, enabling faster containment and recovery.
Empowered SOC teams
Fully contextualised data and collaboration workflows between teams in the SOC ensure seamless handover, freeing up analysts from manual collection tasks so they can focus on what matters: analysis and response.

Attackers are already leveraging the cloud’s agility. Defenders must do the same — adopting solutions that match the speed and scale of modern infrastructure.

Cloud Changed Everything. It’s Time to Change Investigations.

The cloud fundamentally reshaped how businesses operate. It’s time for security teams to rethink how they investigate threats.

Forensics can no longer be slow, manual, and reactive. It must be instant, automated, and cloud-first — designed to meet the demands of ephemeral infrastructure and multi-cloud complexity.

The future of incident response isn’t just faster. It’s smarter, more scalable, and built for the environments we defend today, not those of ten years ago.

On October 9th, Darktrace is revealing the next big thing in cloud security. Don’t miss it – sign up for the webinar.

About the author

Kellie Regan

Director, Product Marketing - Cloud Security

Blog

Network

September 23, 2025

ShadowV2: An emerging DDoS for hire botnet

Introduction: ShadowV2 DDoS

Darktrace's latest investigation uncovered a novel campaign that blends traditional malware with modern devops technology.

At the center of this campaign is a Python-based command-and-control (C2) framework hosted on GitHub CodeSpaces. This campaign also utilizes a Python based spreader with a multi-stage Docker deployment as the initial access vector.

The campaign further makes use of a Go-based Remote Access Trojan (RAT) that implements a RESTful registration and polling mechanism, enabling command execution and communication with its operators.

ShadowV2 attack techniques

What sets this campaign apart is the sophistication of its attack toolkit.

‍The threat actors employ advanced methods such as HTTP/2 rapid reset, a Cloudflare under attack mode (UAM) bypass, and large-scale HTTP floods, demonstrating a capability to combine distributed denial-of-service (DDoS) techniques with targeted exploitation.

With the inclusion of an OpenAPI specification, implemented with FastAPI and Pydantic and a fully developed login panel and operator interface, the infrastructure seems to resemble a “DDoS-as-a-service” platform rather than a traditional botnet, showing the extent to which modern malware increasingly mirrors legitimate cloud-native applications in both design and usability.

Analysis of a SadowV2 attack

Initial access

The initial compromise originates from a Python script hosted on GitHub CodeSpaces. This can be inferred from the observed headers:

User-Agent: docker-sdk-python/7.1.0

X-Meta-Source-Client: github/codespaces

The user agent shows that the attacker is using the Python Docker SDK, a library for Python programs that allows them to interact with Docker to create containers. The X-Meta-Source-Client appears to have been injected by GitHub into the request to allow for attribution, although there is no documentation online about this header.

The IP the connections originate from is 23.97.62[.]139, which is a Microsoft IP based in Singapore. This aligns with expectations as GitHub is owned by Microsoft.

This campaign targets exposed Docker daemons, specifically those running on AWS EC2. Darktrace runs a number of honeypots across multiple cloud providers and has only observed attacks against honeypots running on AWS EC2. By default, Docker is not accessible to the Internet, however, can be configured to allow external access. This can be useful for managing complex deployments where remote access to the Docker API is needed.

Typically, most campaigns targeting Docker will either take an existing image from Docker Hub and deploy their tools within it, or upload their own pre-prepared image to deploy. This campaign works slightly differently; it first spawns a generic “setup” container and installs a number of tools within it. This container is then imaged and deployed as a live container with the malware arguments passed in via environmental variables.

Figure 1: Attacker creates a blank container from an Ubuntu image.

Figure 2: Attacker sets up their tools for the attack.

Figure 3: Attacker deploys a new container using the image from the setup container.

It is unclear why the attackers chose this approach - one possibility is that the actor is attempting to avoid inadvertently leaving forensic artifacts by performing the build on the victim machine, rather than building it themselves and uploading it.

Malware analysis

The Docker container acts as a wrapper around a single binary, dropped in /app/deployment. This is an ELF binary written in Go, a popular choice for modern malware. Helpfully, the binary is unstripped, making analysis significantly easier.

The current version of the malware has not been reported by OSINT providers such as VirusTotal. Using the domain name from the MASTER_ADDR variable and other IoCs, we were able to locate two older versions of the malware that were submitted to VirusTotal on the June 25 and July 30 respectively [1] [2]. Neither of these had any detections and were only submitted once each using the web portal from the US and Canada respectively. Darktrace first observed the attack against its honeypot on June 24, so it could be a victim of this campaign submitting the malware to VirusTotal. Due to the proximity of the start of the attacks, it could also be the attacker testing for detections, however it is not possible to know for certain.

The malware begins by phoning home, using the MASTER_ADDR and VPS_NAME identifiers passed in from the Docker run environmental variables. In addition, the malware derives a unique VPS_ID, which is the VPS_NAME concatenated with the current unix timestamp. The VPS_ID is used for all communications with the C2 server as the identifier for the specific implant. If the malware is restarted, or the victim is re-infected, the C2 server will inform the implant of its original VPS_ID to ensure continuity.

Figure 4: Snippet that performs the registration by sending a POST request to the C2 API with a JSON structure.

From there, the malware then spawns two main loops that will remain active for the lifetime of the implant. Every second, it sends a heartbeat to the C2 by sending the VPS_ID to hxxps://shadow.aurozacloud[.]xyz/api/vps/heartbeat via POST request. Every 5 seconds, it retrieves hxxps://shadow.aurozacloud[.]xyz/api/vps/poll/<VPS ID> via a GET request to poll for new commands.

The poll mechanism shadow v2 — Figure 5: The poll mechanism.

At this stage, Darktrace security researchers wrote a custom client that ran on the server infected by the attacker that mimicked their implant. The goal was to intercept commands from the C2. Based on this, it was observed initiating an attack against chache08[.]werkecdn[.]me using a 120 thread HTTP2 rapid reset attack. This site appears to be hosted on an Amsterdam VPS provided by FDCServers, a server hosting company. It was not possible to identify what normally runs on this site, as it returns a 403 Forbidden error when visited.

Darktrace’s code analysis found that the returned commands contain the following fields:

Method (e.g. GET, POST)
A unique ID for the attack
A URL endpoint used to report attack statistics
The target URL & port
The duration of the attack
The number of threads to use
An optional proxy to send HTTP requests through

The malware then spins up several threads, each running a configurable number of HTTP clients using Valyala’s fasthttp library, an open source Go library for making high-performance HTTP requests. After this is complete, it uses these clients to perform an HTTP flood attack against the target.

Figure 6: A snippet showing the fasthttp client creation loop, as well as a function to report the worker count back to the C2.

In addition, it also features several flags to enable different bypass mechanisms to augment the malware:

WordPress bypass (does not appear to be implemented - the flag is not used anywhere)
Random query strings appended to the URL
Spoofed forwarding headers with random IP addresses
Cloudflare under-attack-mode (UAM) bypass
HTTP2 rapid reset

The most interesting of these is the Cloudflare UAM bypass mechanism. When this is enabled, the malware will attempt to use a bundled ChromeDP binary to solve the Cloudflare JavaScript challenge that is presented to new visitors. If this succeeds, the clearance cookie obtained is then included in subsequent requests. This is unlikely to work in most cases as headless Chrome browsers are often flagged, and a regular CAPTCHA is instead served.

Figure 7: The UAM bypass success snippet.

Additionally, the malware has a flag to enable an HTTP2 rapid reset attack mode instead of a regular HTTP flood. In HTTP2, a client can create thousands of requests within a single connection using multiplexing, allowing sites to load faster. The number of request streams per connection is capped however, so in a rapid reset attack many requests are made and then immediately cancelled to allow more requests to be created. This allows a single client to execute vastly more requests per second and use more server resources than it otherwise would, allowing for more effective denial-of-service (DoS) attacks.

Figure 8: The HTTP2 rapid reset snippet from the main attack function.

API/C2 analysis

As mentioned throughout the malware analysis section, the malware communicates with a C2 server using HTTP. The server is behind Cloudflare, which obscures its hosting location and prevents analysis. However, based on analysis of the spreader, it's likely running on GitHub CodeSpaces.

When sending a malformed request to the API, an error generated by the Pydantic library is returned:

{"detail":[{"type":"missing","loc":["body","vps_id"],"msg":"Field required","input":{"vps_name":"xxxxx"},"url":"https://errors.pydantic.dev/2.11/v/missing"}]}

This shows they are using Python for the API, which is the same language that the spreader is written in.

One of the larger frameworks that ships with Pydantic is FastAPI, which also ships with Swagger. The malware author left this publicly exposed, and Darktrace’s researchers were able to obtain a copy of their API documentation. The author appears to have noticed this however, as subsequent attempts to access it now returns a HTTP 404 Not Found error.

Figure 9: Swagger UI view based on the obtained OpenAPI spec.

This is useful to have as it shows all the API endpoints, including the exact fields they take and return, along with comments on each endpoint written by the attacker themselves.

It is very likely a DDoS for hire platform (or at the very least, designed for multi-tenant use) based on the extensive user API, which features authentication, distinctions between privilege level (admin vs user), and limitations on what types of attack a user can execute. The screenshot below shows the admin-only user create endpoint, with the default limits.

The admin-only user create endpoint shadow v2 — Figure 10: The admin-only user create endpoint.

The endpoint used to launch attacks can also be seen, which lines up with the options previously seen in the malware itself. Interestingly, this endpoint requires a list of zombie systems to launch the attack from. This is unusual as most DDoS for hire services will decide this internally or just launch the attack from every infected host (zombie). No endpoints that returned a list of zombies were found, however, it’s possible one exists as the return types are not documented for all the API endpoints.

The attack start endpoint shadow v2 — Figure 11: The attack start endpoint.

There is also an endpoint to manage a blacklist of hosts that cannot be attacked. This could be to stop users from launching attacks against sites operated by the malware author, however it’s also possible the author could be attempting to sell protection to victims, which has been seen previously with other DDoS for hire services.

Blacklist endpoints shadow v2 DDoS — Figure 12: Blacklist endpoints.

Attempting to visit shadow[.]aurozacloud[.]xyz results in a seizure notice. It is most likely fake the same backend is still in use and all of the API endpoints continue to work. Appending /login to the end of the path instead brings up the login screen for the DDoS platform. It describes itself as an “advanced attack platform”, which highlights that it is almost certainly a DDoS for hire service. The UI is high quality, written in Tailwind, and even features animations.

Conclusion

By leveraging containerization, an extensive API, and with a full user interface, this campaign shows the continued development of cybercrime-as-a-service. The ability to deliver modular functionality through a Go-based RAT and expose a structured API for operator interaction highlights how sophisticated some threat actors are.

For defenders, the implications are significant. Effective defense requires deep visibility into containerized environments, continuous monitoring of cloud workloads, and behavioral analytics capable of identifying anomalous API usage and container orchestration patterns. The presence of a DDoS-as-a-service panel with full user functionality further emphasizes the need for defenders to think of these campaigns not as isolated tools but as evolving platforms.

Appendices

References

1. https://www.virustotal.com/gui/file/1b552d19a3083572bc433714dfbc2b75eb6930a644696dedd600f9bd755042f6 ‍

2. https://www.virustotal.com/gui/file/1f70c78c018175a3e4fa2b3822f1a3bd48a3b923d1fbdeaa5446960ca8133e9c

IoCs

Malware hashes (SHA256)

● 2462467c89b4a62619d0b2957b21876dc4871db41b5d5fe230aa7ad107504c99

● 1b552d19a3083572bc433714dfbc2b75eb6930a644696dedd600f9bd755042f6

● 1f70c78c018175a3e4fa2b3822f1a3bd48a3b923d1fbdeaa5446960ca8133e9c

C2 domain

● shadow.aurozacloud[.]xyz

Spreader IPs

● 23.97.62[.]139

● 23.97.62[.]136

Yara rule

rule ShadowV2 {

meta:

author = "nathaniel.bill@darktrace.com"

description = "Detects ShadowV2 botnet implant"

strings:

$string1 = "shadow-go"

$string2 = "shadow.aurozacloud.xyz"

$string3 = "[SHADOW-NODE]"

$symbol1 = "main.registerWithMaster"

$symbol2 = "main.handleStartAttack"

$symbol3 = "attacker.bypassUAM"

$symbol4 = "attacker.performHTTP2RapidReset"

$code1 = { 48 8B 05 ?? ?? ?? ?? 48 8B 1D ?? ?? ?? ?? E8 ?? ?? ?? ?? 48 8D 0D ?? ?? ?? ?? 48 89 8C 24 38 01 00 00 48 89 84 24 40 01 00 00 48 8B 4C 24 40 48 BA 00 09 6E 88 F1 FF FF FF 48 8D 04 0A E8 ?? ?? ?? ?? 48 8D 0D ?? ?? ?? ?? 48 89 8C 24 48 01 00 00 48 89 84 24 50 01 00 00 48 8D 05 ?? ?? ?? ?? BB 05 00 00 00 48 8D 8C 24 38 01 00 00 BF 02 00 00 00 48 89 FE E8 ?? ?? ?? ?? }

$code2 = { 48 89 35 ?? ?? ?? ?? 0F B6 94 24 80 02 00 00 88 15 ?? ?? ?? ?? 0F B6 94 24 81 02 00 00 88 15 ?? ?? ?? ?? 0F B6 94 24 82 02 00 00 88 15 ?? ?? ?? ?? 0F B6 94 24 83 02 00 00 88 15 ?? ?? ?? ?? 48 8B 05 ?? ?? ?? ?? }

$code3 = { 48 8D 15 ?? ?? ?? ?? 48 89 94 24 68 04 00 00 48 C7 84 24 78 04 00 00 15 00 00 00 48 8D 15 ?? ?? ?? ?? 48 89 94 24 70 04 00 00 48 8D 15 ?? ?? ?? ?? 48 89 94 24 80 04 00 00 48 8D 35 ?? ?? ?? ?? 48 89 B4 24 88 04 00 00 90 }

condition:

uint16(0) == 0x457f and (2 of ($string*) or 2 of ($symbol*) or any of ($code*))

}

‍

^{Darktrace, its affiliates, employees, or agents shall not be held liable for any loss, damage, or harm arising from the use of or reliance on the information in this blog.}

^{The cybersecurity landscape evolves rapidly, and blog content may become outdated or superseded. We reserve the right to update, modify, or remove any content without notice.}

About the author

Nate Bill

Threat Researcher

Your data. Our AI.

Elevate your network security with Darktrace AI

Get a demo

Check out this article by Darktrace: How Darktrace Detects Cryptomining: Threat Example & Walkthrough

From PowerShell to Payload: Darktrace’s Detection of a Novel Cryptomining Malware

What is Cryptojacking?

Darktrace’s Coverage of Cryptojacking via PowerShell

Inside the payload: Technical analysis of the malicious script and cryptomining loader

Zooming Out: Darktrace Coverage of NBMiner

Darktrace’s Autonomous Response

Conclusion

Appendices

List of Indicators of Compromise (IoCs)

MITRE ATT&CK Mapping

References

ShadowV2: An emerging DDoS for hire botnet

It’s Time to Rethink Cloud Investigations

Enjoying the blog?

More in this series

ShadowV2: An emerging DDoS for hire botnet

SEO Poisoning and Fake PuTTY sites: Darktrace’s Investigation into the Oyster backdoor

The benefits of bringing together network and email security

Blog

Cloud

September 23, 2025

It’s Time to Rethink Cloud Investigations

Cloud Breaches Are Surging

4 Reasons Cloud Investigations Are Broken

What’s Needed: A New Approach to Cloud Investigations

Cloud Changed Everything. It’s Time to Change Investigations.

Blog

Network

September 23, 2025

ShadowV2: An emerging DDoS for hire botnet

Introduction: ShadowV2 DDoS

ShadowV2 attack techniques

Analysis of a SadowV2 attack

Initial access

Malware analysis

API/C2 analysis

Conclusion

Appendices

References

IoCs

Yara rule