How abandoned cloud storage becomes an attack vector

• 621 were unregistered and available for registration
• Roughly 4 percent had been abandoned
• Approximately half began receiving traffic immediately after we registered them

In several cases, traffic volumes reached millions of requests per day. These requests originated from corporate environments, SaaS platforms, public sector domains and security-related organisations.

The implication is straightforward. Active systems were still trying to retrieve code and content from storage locations that no longer belonged to the original owner. Control over those storage accounts would allow a third party to determine what gets delivered instead.

Remote code execution risk

One abandoned storage account stood out immediately. It was still serving PowerShell scripts that were being downloaded nearly 10,000 times per day from thousands of unique IP addresses.

PowerShell scripts can execute commands directly on Windows machines. Control over that single storage account would have enabled remote code execution on affected systems without exploiting a vulnerability in the traditional sense. The systems were voluntarily retrieving and executing whatever was hosted at that location.

We identified the original owner using open source intelligence techniques and coordinated the safe return of the storage account. The issue was handled responsibly and remediated.

JavaScript injection in live environments

A second category of findings involved JavaScript files.

When a website loads JavaScript from an external source, that code runs in the browser of every visitor. This creates a powerful trust relationship. If an attacker controls that external file, they can manipulate page content, capture session data or introduce credential harvesting mechanisms without compromising the website’s core infrastructure.

After registering several abandoned blob namespaces, we observed sustained requests for legacy JavaScript files from widely used platforms. Using a controlled proof of concept limited to our own IP address, we confirmed that injected JavaScript executed successfully in multiple live environments. This provided visibility into the full browser context, including session state and locally stored data.

  

One abandoned storage reference allowed JavaScript execution within Microsoft-owned web properties. The issue was responsibly disclosed through the Microsoft Security Response Center and has since been addressed. In coordination with Microsoft, specific application URLs have been masked in public materials.

We notified the maintainers of Ghidra, the reverse engineering tool developed by the NSA, after identifying a legacy JavaScript reference to one of the blob namespaces under our control. They acknowledged the disclosure and confirmed the reference would be addressed.

Beyond individual cases

The examples above are illustrative, but they are not isolated.

Across the 621 registered storage accounts, we observed thousands of third-party references. Most involved static content such as images or configuration files. While less immediately severe than executable scripts, these references still represent silent dependencies on infrastructure that no longer has a defined owner.

At scale, this becomes a lifecycle management problem rather than a single vulnerability. Cloud resources are created and decommissioned continuously. References to them persist in websites, mobile applications, installers and automated update mechanisms. Once the underlying storage account is removed, the reference often remains unnoticed.

When the name becomes available again, control can shift quietly. No intrusion is required. No exploit chain is necessary. The trust relationship simply changes hands.

Responsible handling and ongoing research

We did not exploit these findings.

For higher-risk cases, we transferred storage accounts back to verified original owners or sinkholed traffic to prevent abuse. For broader exposures, we used non-intrusive console notifications to alert affected organisations without disrupting users.

To date, 621 abandoned Azure Blob storage accounts have been registered to prevent malicious takeover. Several have already been returned to their original owners. The research is ongoing, as additional abandoned infrastructure continues to surface.

The broader implication

This research highlights a gap that is easy to overlook. Security does not stop at what an organisation currently owns. It must also extend to what its systems still trust.

As cloud adoption accelerates, forgotten infrastructure becomes part of the external attack surface. Legacy references, unmaintained storage accounts and outdated dependencies can introduce exposure long after the original project has ended.

Understanding and monitoring those external dependencies is no longer optional. It is part of maintaining control in a cloud-first environment.

Organisations that want clarity on whether abandoned infrastructure is part of their external footprint, or that need continuous monitoring of cloud and supply chain exposure, should treat this as a visibility challenge rather than a one-time clean-up exercise. This is precisely the type of structural risk that benefits from independent external validation and ongoing threat hunting.