This article delves into the interconnected issue of insecure hardware, exploring its journey from a local problem to a global threat. It begins at the source: the vulnerable devices in our homes and offices, and the legislative loopholes that govern their security. The piece then traces how these weaknesses are weaponised at scale, transforming cheap everyday IoT gadgets into a distributed botnet for criminal enterprises. Finally, it examines the often unaccountable role of major cloud platforms, whose infrastructure has become both a critical business tool and a weaponised asset for attackers. This isn’t a technical report, but rather the result of six months of research that began with a simple honeypot project and led me down a rabbit hole into the complex reporting procedures of major tech companies and the immense scale of modern attacks.
The Problem at Home and in the Office
The most relatable part of the unsecured hardware crisis lies in the devices we interact with daily. From the home Wi-Fi router to smart home gadgets such as CCTV and business-critical systems, there is a widespread failure to prioritise security that has left countless machines exposed. A basic but frequently ignored issue is the use of default credentials, such as admin or 123456, which attackers can exploit with ease and even with it continually harped on about, a simple search through online databases of exposed devices reveals thousands of machines with these factory set usernames and passwords, waiting to be compromised.
Beyond easily guessable passwords, devices often suffer from outdated firmware. Routers, cameras, and network switches in homes and small businesses frequently receive little to no patching, causing an accumulation of vulnerabilities. This issue is worsened by poor network segmentation, where a single infected device (such as a smart TV or a networked printer) can serve as a gateway to critical infrastructure like point-of-sale systems or employee laptops. This demonstrates that the problem is not only technical but also rooted in a mindset that seems to view security as a burden rather than a necessity (an update that interrupts a workflow or a capital expenditure that can be delayed) something I’ve been guilty of myself.
In recognition of this threat, the UK government has taken a significant step with the introduction of the Product Security and Telecommunications Infrastructure (PSTI) Act 2022. This landmark legislation, which took effect on 29 April 2024, is designed to enhance the resilience of consumer ‘connectable’ products against cyberattacks. The Act mandates that manufacturers, importers, and distributors of these products must comply with baseline security requirements before they can be sold in the UK market.
The PSTI Act’s core requirements are a direct response to the most common vulnerabilities. It prohibits weak, easily guessable default passwords, mandating that they must be unique to each product or definable by the user. Manufacturers are also now required to provide a clear and accessible public point of contact for reporting security issues and to publish a minimum period for security updates. This is a crucial, world-leading aspect of the law, as it applies not only to UK-based manufacturers but to all organisations importing or retailing products for the UK market. The enforcement of these rules is backed by significant financial penalties, including fines of up to £10 million or 4% of a company’s worldwide revenue, as well as the power to seize and destroy non-compliant products.
The Weaponisation of the Everyday
Rise of the Hybrid Botnet: From IoT to the Cloud
The most troubling consequence of insecure hardware is its weaponisation without the owner’s knowledge or consent, known as botnets. The infamous Mirai botnet in 2016 was a major event in which thousands of poorly secured IoT devices, such as cameras and DVR systems, were exploited to launch massive DDoS attacks that crippled major websites and services. The legacy of Mirai demonstrated that the sheer volume of low-power IoT devices could be harnessed to generate overwhelming force, and it exposed the inherent risks of default credentials and weak security protocols.
Today, attackers no longer rely exclusively on consumer IoT devices. They have created a far more resilient “hybrid” botnet by combining them with powerful cloud servers. It is surprisingly simple for a malicious actor to create multiple instances across different regions, configure each to flood a target with traffic, and launch a powerful, globally distributed attack. This new model is so effective because the malicious traffic originates from legitimate, trusted cloud infrastructure, making it extremely difficult for defenders to distinguish it from genuine user requests.
This blend of IoT and cloud resources represents a new, more advanced threat. IoT devices provide the mass scale and persistence for a botnet, while cloud servers offer the high-bandwidth, burst capacity, and operational reliability needed for precision strikes which was seen recently when cloudflare blocked its new largest DDoS attack “attack was a UDP flood that mainly came from Google Cloud”. The pervasive adoption of cloud computing for legitimate purposes has inadvertently created a powerful new weapon for cybercriminals, blurring the lines between benign and malicious traffic and complicating mitigation and attribution efforts.
The Unprecedented Scale of Modern Attacks
The trends in modern DDoS attacks provide a clear picture of the new threat landscape. In 2025, Cloudflare automatically mitigated a record-breaking volumetric DDoS attack that peaked at an astonishing 11.5 terabits per second (Tbps). This was not an anomaly. Just months earlier, Cloudflare reported another incident where 37.4 terabytes of data were delivered in only 45 seconds, an amount equivalent to approximately 9,000 high-definition films hurled at a single victim in less than a minute. The sources of these attacks are often a mix of IoT devices and cloud providers, including Google Cloud, reinforcing the threat posed by hybrid botnets.
Beyond pure volume, the nature of these attacks is also changing. Threat intelligence reports indicate a significant shift from simple, brute-force floods to more sophisticated, multi-vector attacks. The average botnet size has expanded rapidly, with the average botnet in Q2 2025 comprising 120,000 to 150,000 infected devices, a jump of 87% in just three months. Attackers are increasingly using “probing attacks” at a scale not seen before, with a 5,000 X year-over-year increase in Q2 2025 alone. These low volume attacks are a reconnaissance tactic used to test for weaknesses in a target’s defences before launching a full scale campaign. The rise of hacktivist groups using multi-vector, “APT-level” tactics and AI-enhanced automation suggests that sophisticated attack capabilities are now accessible to a much broader range of actors.
Insights from Honeypots and Threat Intelligence
To combat these new threats, cybersecurity researchers and intelligence firms are always trying to understand and anticipate attacker behaviour to help predict future attacks. One of the most effective of these is honeypot analysis, which involves intentionally creating a vulnerable decoy resource to attract and monitor malicious activity (I set one up about a year as part of a larger research project, which fell through due to the scale of it). By deploying a large, distributed network of these sensors, researchers gain a clear view of the “internet background noise” and can identify targeted attacks. While a single honeypot only provides a microscopic view, capturing a biased set of data from unsophisticated attackers to stale traffic, and routine scans. In contrast, a globally distributed honeypot network can provide an unbiased view of internet scanning traffic and reveal how much data is missed by a single, localised sensor.
Organisations like GreyNoise have successfully tackled this global deployment approach. Their analysis shows that a large percentage of malicious traffic originates from major cloud providers (Google Cloud Platform, DigitalOcean, and AWS to name a few). These massive datasets confirm that cloud infrastructure is a major source of malicious activity. The search engine Shodan reveals the sheer scale of the problem from a different angle. It catalogues millions of exposed and vulnerable devices (from power plants to refrigerators) that are directly accessible from the internet, providing a clear visual representation of the vast and unsecured attack surface exploited by botnets.
A crucial discovery from threat intelligence research is that malicious activity can serve as an “early warning signal.” GreyNoise’s research report, “Early Warning Signals: When Attacker Behavior Precedes New Vulnerabilities,” found that significant spikes in opportunistic attacker activity often preceedes the public disclosure of a new Common Vulnerabilities and Exposures (CVE) identifier by around six weeks. This takes on the traditional reactive security model, where defenders only patch vulnerabilities after they are made public. It indicates that attackers are not just reacting to new information but proactively probing for weaknesses, giving a valuable window for defenders to take preemptive action (such as blocking associated IP addresses) before a new flaw is publicly known.
The Cloud Accountability Crisis
When the Infrastructure Becomes the Threat
The widespread adoption of cloud computing has been driven by its amazing scalability and cost-effectiveness. However, these same features make platforms like AWS and Google Cloud so useful to attackers seeking to launch large scale assaults. The legal framework governing this environment is based on the “shared responsibility model“.
This model describes a clear division of labour: the cloud provider is responsible for the “security of the cloud,” which encmpasses the underlying hardware, physical infrastructure, and global availability zones. Essentially meaning that they are responsible for ensuring the foundation is secure. Contrarily, the customer is responsible for “security in the cloud.” Including the security of their data, applications and operating systems.
While this is a logical framework in principle, it breaks down when a third party is involved/attacked. When a cyber criminal uses cloud infrastructure to launch a botnet attack against a non-customer, the victim has no direct legal or contractual relationship with the attacking server’s host. This creates a legal vacuum where there is a lack of applicable laws, regulations, or legal precedent to address the situation. Cloud providers’ contracts often contain disclaimers that specifically point out that security is the customer’s responsibility, making it notoriously difficult to hold them liable for abuse originating from their platforms. This mismatch in responsibility creates a critical gap, as the provider’s contractual duties are limited, and the victim is left with little recourse against the source of the attack
The practical application of the shared responsibility model reveals a system of abuse reporting that is often frustrating and ineffective for the third party that has been involved. User forums on platforms like Reddit are filled with evidence of the challenges faced when attempting to report malicious activity originating from AWS and Google Cloud. Common complaints include overly complex forms that flag legitimate evidence as malicious and a lack of meaningful support from abuse desks. A user reporting a spam campaign from Amazon SES, for instance, documented that they “reported it many times but never got lucky enough to reach someone competent”.
This frustration is not limited to individual users. Even major security services and CDN providers, such as Cloudflare, have a similar policy for handling abuse reports. For the vast majority of their services, which are “pass-through,” their primary action is to forward the complaint to the website operator and the original hosting provider. While this process is designed to ensure the report reaches the party best equipped to handle it, it also serves as a form of risk transfer, placing the burden of remediation on the victim and the original hosting provider, while the platform enabling the abuse remains a conduit.
A Call to Action
For individuals and businesses, basic cybersecurity hygiene is no longer optional. This includes changing default credentials immediately, ensuring firmware and software are updated regularly, and segmenting networks to isolate critical systems from unsecured consumer devices.
As for the cloud giants, the time for change is long overdue. They’re the guardians of so much of the modern internet, and their job goes way beyond simply providing a platform. They need to step-up their abuse teams and complaints handling so that when someone reports a problem, it leads to swift, proper action instead of an endless loop of automated replies. They also have to start keeping a proactive eye out for anomalous usage patterns, shutting them down before they can be weaponised. The convenience of pay-as-you-go and anonymous services is a huge asset for legitimate users, but it’s also a powerful tool for malicious actors. We need to find a balance with stricter identity checks and more effective ways to prevent abuse.
The danger posed by insecure hardware is a complex problem we need to find a solution for rather than blocking the threats as they come. The sheer scale and sophistication of modern DDoS attacks prove that the trend is obvious: attack volumes will only get bigger as long as there’s a supply of compromised devices and a serious lack of accountability from the platforms that help these attacks happen.
Complacency simply isn’t an option and to build a true digital resilience demands a joint effort from every single person involved. Governments must keep on bringing in tough, globally influential laws like the PSTI Act. Companies have to build security in from the start. Users have to practise basic hardware hygiene. And, most importantly, cloud providers must accept their vital role as owners of such powerful web resources. It’s this shared journey, built on collective responsibility.