Cloud Infrastructure Abuse

Deployment Period: February 1, 2026 to February 28, 2026

Honeypot: T-Pot Community Edition, Google Cloud Platform

Data Source: Elasticsearch DSL queries, Kibana Dev Tools

TLP: TLP:CLEAR

Summary

Three major cloud providers contributed 17,485,217 events across the 28-day deployment, accounting for 18.1% of all inbound attack traffic. DigitalOcean was the dominant source at 14.3% of total events. Google Cloud and Amazon combined added another 3.9%. These are not compromised home users or botnet-infected devices. They are VMs rented specifically to run attack tooling, which makes them easy to spin up and easy to abandon.

Background

When attackers use cloud infrastructure, the IP address in the log does not point to a home country, a hacking group, or even a consistent threat actor. It points to a data center. This is why geographic attribution breaks down for a large share of honeypot traffic because the source IP tells you which cloud provider a VM was rented from, not where the person who rented it is located.

Cloud providers have abuse teams and respond to reports. Because of that, attackers tend to use cloud infrastructure for short campaigns, rotate IPs frequently, or run persistent low-volume scanning that stays below abuse thresholds. All three patterns appeared in this deployment.

Findings

DigitalOcean: 13,767,116 Events

DigitalOcean was the second-largest attack source across the entire deployment, behind only Alsycon B.V. at 24,045,125 events. It accounted for 14.3% of total traffic.

Volume was high for the first 18 days, averaging 663,000 events per day. On 2026/02/17 it peaked at 972,638 events. Then it dropped sharply. Days 19 through 28 averaged 183,000 per day, a reduction of about 72% from the first-half average.

Five distinct IP addresses in the top 20 source IPs for the full deployment belong to DigitalOcean ranges. Their combined total across all 28 days was 8,161,131 events, meaning a small number of VMs accounted for the majority of DigitalOcean traffic.

The 134.199.x.x addresses in particular cluster tightly and generated consistent high-volume traffic. This pattern points to a coordinated scanning operation running across multiple VMs in the same DigitalOcean region.

Google Cloud: 3,064,962 Events

Google Cloud (AS396982 / Google LLC) generated 3,064,962 events, or 3.2% of total traffic. One IP, 129.212.176.30, appeared in the top 20 source IPs for the full deployment with 1,039,948 events. Daily volume was steady throughout February, averaging 109,463 events per day with no significant spikes or drop-offs.

The consistent daily pattern differs from DigitalOcean’s first-half surge. It points to a persistent scanner running on a single VM, maintaining steady output for the full 28 days without escalating or withdrawing.

Amazon: 653,139 Events

Amazon (AS16509, Amazon.com, Inc.) contributed 653,139 events, or 0.7% of total traffic. Daily counts were mostly in the 12,000 to 30,000 range. Two brief spikes appeared on 2026/02/04 (58,357 events) and 2026/02/05 (55,877 events), after which volume returned to baseline. No Amazon IPs appeared in the top 20 source IPs for the full deployment, which means the traffic was distributed across a larger number of addresses.

Analysis

Cloud Infrastructure as Attack Tooling

Renting a VM takes minutes. Most cloud providers offer hourly billing. An attacker running a scanning campaign can spin up a VM, run it for a few days, and discard it before an abuse report results in a suspension. The IP is then gone, and the campaign moves to a new address.

This also means that blocking a single cloud IP is often a temporary measure. The same campaign can resume from a different address within the same ASN.

DigitalOcean Volume Shift

The sharp drop after 2026/02/17 suggests the campaign running through DigitalOcean either completed its objective, rotated to other infrastructure, or was disrupted. A drop of 72% in average daily volume over ten days appears to be a deliberate stop.

The clustering of high-volume IPs in the same subnet range (134.199.x.x) suggests the attacker used several VMs in the same region simultaneously. This is a common approach for scanning campaigns that need to cover large IP ranges quickly.

Attribution limits

These event counts cannot be tied to a specific threat actor. DigitalOcean, Google Cloud, and Amazon are used by criminals, security researchers, bot operators, and legitimate businesses. The data shows which networks the traffic came from. It does not show who rented the VMs or what they were ultimately trying to accomplish beyond scanning for vulnerable services.

Defender Notes

Blocking entire cloud provider ASN ranges is usually not practical. A better approach is to track IP reputation at the address level and block or rate-limit individual addresses that generate sustained scanning volume.

If you are seeing high-volume traffic from a specific cloud IP, filing an abuse report with the provider is worth it. Cloud providers do act on reports. It may not stop the actor, but it does impose a cost on them in the form of having to rotate infrastructure.

For Google Cloud and Amazon traffic specifically, their own threat intelligence teams actively investigate abuse on their platforms. Both publish guidance on how to report malicious use of their infrastructure.

Data Reference

Table 1: Cloud Provider Summary

Total deployment events: 96,408,585

Table 2: Daily Event Counts by Provider

Methodology Notes

ASN totals are taken from the final full-dataset Elasticsearch query run on 2026/03/01, which covers all 28 days of indexed data. Daily counts per provider are extracted from per-day ASN aggregations in the daily JSON files. The daily totals for each provider will not sum to the final totals exactly in all cases due to the top-20 bucket limit on daily aggregations and the doc_count_error_upper_bound margins in Elasticsearch term aggregations.

Internal Google Cloud VM traffic (10.128.0.2) was excluded from all queries.

All data sourced from Elasticsearch DSL queries against T-Pot honeypot logs, February 1 through February 28, 2026. Raw query output is preserved in /data/.

References