Everybody Has an Abuse Form. Nobody Has an Abuse Problem.

by hal9000human experience, policies3 Comments 14 min read
report malicious iaas instances

We have previously attempted to report attacks against the 7312.us domain being carried out by IAAS instances from various cloud providers. We asked Hal9000 (Claude): “How many cloud IAAS providers (AWS, Google, Oracle, etc) provide for non customers to report attacks being carried by malicious instances they host? I am only aware of AWS. Can you write an article on that topic? What can be done to held IAAS providers to limit malicious use of their environment for the security posture of all?“

There is a common belief among defenders that AWS is the only major cloud provider that lets an outsider — someone with no account, no contract, no commercial relationship — report that one of its instances is attacking them.

That belief is wrong, and the reason it is wrong is more interesting than the belief itself.

Nearly every meaningful IaaS provider on earth accepts abuse reports from non-customers. AWS, Google Cloud, Microsoft Azure, Oracle Cloud, DigitalOcean, Akamai Cloud (formerly Linode), OVHcloud, Hetzner, Vultr, Contabo, Alibaba Cloud, IBM, Fastly, Gcore — all of them have either a web form, an abuse@ mailbox, or both. Most of them have had one for a decade or more. The channel exists.

What does not exist is any obligation to do anything with it, any obligation to tell you what was done, and any way for you to find out whether the thing you reported is still running. The abuse form is a mailbox with no return address, no delivery confirmation, and no postmaster.

That is the actual problem. It was never a coverage problem. It is an accountability problem wearing a coverage problem’s clothes.

Part 1: The inventory

Here is roughly where the major providers sit today. The pattern is not “who has a channel” — it is “how much friction, and how much comes back.”

ProviderNon-customer channelNotes
AWSWeb form + trustandsafety@support.aws.comPublic, indexed, no account required. Forwards to the customer while withholding your identity. Reports surface in the customer’s Health Dashboard, not just email.
Google CloudWeb abuse report formPublic form, no account required. Separate legal/DMCA path. Little visible feedback.
Microsoft AzureReport-a-site (guest submission), MSRC, abuse@Historically the most criticized. Public complaints about the difficulty of reporting Azure-hosted phishing without a Microsoft account go back years.
Oracle Cloud (OCI)abuse@oracle.com — email onlyNo public abuse web form. Fragmented across several addresses, none documented as “report an attack from an OCI instance.”
DigitalOceanWeb form + abuse@digitalocean.comRouted to their SOC. Historically responsive by hyperscaler standards.
Akamai Cloud / LinodeCategory-specific abuse forms + separate EU DSA pathExplicitly enumerates report categories — botnet C2, brute-force, phishing, malware. Openly states report details may be shared with the customer.
OVHcloudAbuse formFramed around “illegal content or activities.” Independently measured cleanup performance has historically been poor.
HetznerDocumented abuse formDocumented in their public docs. Measured cleanup performance has historically been good.
Vultr, Contabo, Gcore, Alibaba, Tencent, IBMabuse@ and/or formCoverage exists. Responsiveness ranges from “same day” to “cosmic background radiation.”

Any of these can also be reached the old-fashioned way: whois the offending IP, read the abuse-c or OrgAbuseEmail field, and mail that. RIPE has required and periodically validated an abuse contact on its resources for years. ARIN and APNIC carry equivalent fields. RFC 2142 has specified abuse@ since 1997.

So the coverage is near-total. Why does it feel like it isn’t?

Because AWS is the only one that reliably produces an artifact. The report leaves a mark: a ticket, an ID, a dashboard entry on the customer side, occasionally a reply. Everywhere else, the report enters a system that emits nothing. From the outside, a channel that never confirms receipt and a channel that does not exist are indistinguishable. Defenders conclude the channel is missing. It isn’t. It’s mute.

Part 2: Why providers are structurally indifferent

The uncomfortable answer is that abuse reporting is a textbook negative externality, and the economics were mapped out carefully more than a decade ago.

When a rented instance scans your SSH port, brute-forces your login page, or hosts a phishing kit aimed at your customers, the cost lands entirely on you. The provider is still collecting revenue for the compute. Cleanup costs them money — investigation time, customer support, potential churn from a legitimate customer whose instance was merely compromised rather than malicious. The academic literature on abuse reporting is blunt about this: intermediaries are routinely criticized for insufficient vigilance, and the standard explanation is a straightforward absence of incentives. The abuse frequently does not harm the intermediary at all.

There are only two forces that reliably reverse this. One is blocklisting — hosting providers that refuse to handle abuse requests promptly find their address space listed, and suddenly the externality is internalized because their other customers start complaining. The other is regulation, which until recently barely existed for infrastructure.

Absent either, the rational provider posture is to accept reports, forward them politely, and measure success by whether the reporter goes away.

And the data on outcomes is genuinely sobering. Controlled notification studies consistently find that notified operators remediate far more often than unnotified controls — one study found roughly 49% of notified recipients remediated versus about 4% of the control group — which proves the mechanism works when it is actually engaged. But provider-level performance varies enormously. A separate measurement of compromised-website cleanup found some hosts remediating essentially everything within four days while others cleaned only about one in five reported sites, taking over a week to do even that. Same report, same evidence, wildly different outcomes depending purely on which company received it.

More recent work interviewing hosting providers directly found that remediation rates remain persistently low, and that the bottlenecks are organizational rather than technical — how reports are triaged internally, whether the abuse desk is staffed or automated, whether it can even reach the responsible party.

Translation: the report is not the bottleneck. The desk is.

Part 3: The asymmetry that makes this worse every year

The provisioning gap has widened to the point of absurdity.

An attacker with a stolen card, a trial credit, or a free-tier account can have a globally routable instance running arbitrary code in under ninety seconds. That instance inherits a reputable ASN, a clean IP with no history, and — critically — the implicit trust that defenders extend to hyperscaler address space because blocking it wholesale would break half their vendor integrations.

The takedown path for the same instance runs: detection, correlation, evidence assembly, form submission, unacknowledged queue, human triage, customer notification, customer remediation window, escalation, suspension. Days at best. Weeks routinely. Never, frequently.

Ninety seconds to arm. Nine days to disarm. Every campaign is profitable inside that window, and the attacker simply re-provisions on suspension. Abuse handling as currently practiced does not deter; it imposes a modest, predictable tax on operations that are already priced to absorb it.

Part 4: What would actually change the behavior

Moral suasion has had twenty years and has produced abuse forms that nobody reads. The levers that would move this are unglamorous and mostly not technical.

Regulation that makes a report legally consequential

The single most significant development here is European, and most defenders have not noticed it applies to them.

The EU Digital Services Act obliges providers of hosting services to maintain notice-and-action mechanisms that let any individual or entity — explicitly not just customers — report illegal content, and requires those mechanisms to be easy to access and user-friendly. The definition of hosting service reaches infrastructure: cloud computing and web hosting services are in scope alongside platforms. National regulators have said so directly.

The teeth are in the legal effect. A sufficiently precise and substantiated notice is deemed to give the provider actual knowledge — which is the trigger that strips the liability shield. The provider can no longer claim ignorance about a thing you told them about in writing. Recital 52 expects action in a timely manner, with urgency scaled to the harm.

And Article 15 requires transparency reporting that includes, for hosting providers, the number of notices received, categorized by type, what action was taken, how many were handled automatically, and — the number that matters most — the median time to action.

That last requirement is the closest thing the industry has to a scoreboard. It is the mechanism defenders should be paying attention to, and applying pressure to extend.

Regulation that makes provisioning consequential

The US approach has focused on the front door rather than the back. Executive Order 13984 directed Commerce to propose know-your-customer rules for IaaS providers specifically to address malicious cyber actors’ use of US cloud infrastructure. BIS published the proposed rule in January 2024, with a Customer Identification Program requirement modeled on financial-sector KYC, mandatory reporting of certain foreign transactions, and authority to impose special measures against jurisdictions or persons engaged in a pattern of malicious cyber-enabled activity. Penalties proposed ran to $250,000 per violation civilly, with criminal exposure above that.

The comment period closed in April 2024. As of mid-2026 the rule has not been finalized. Industry pushback centered on cost and complexity, particularly for smaller providers and resellers.

Whatever one thinks of KYC as policy — and the privacy objections are real, as are the concerns about pushing anonymous-hosting demand toward jurisdictions with no oversight at all — the observation stands that identity friction at signup is the only intervention that raises the attacker’s per-instance cost rather than their aggregate cost.

Procurement, which is faster than legislation

Enterprises buy cloud under negotiated master agreements. Almost none of those agreements contain a single word about abuse handling. That is a self-inflicted wound.

Terms worth demanding, in descending order of achievability:

  • Acknowledgement SLA. A case ID returned within a defined window, to any reporter, customer or not.
  • Disposition notification. Confirmation that the report was actioned, closed, or rejected — with a reason. Not the customer’s identity; just the outcome.
  • Time-to-action reporting. Median and 95th-percentile, by abuse category, disclosed to the customer annually. The DSA already forces this in Europe; ask for it globally.
  • Trusted-reporter status. A named channel for security teams and CERTs that bypasses the general queue, with reciprocal accuracy obligations on the reporter.
  • Egress reputation commitments. Contractual acknowledgement that the provider monitors outbound abuse from its own address space, not merely inbound threats to itself.

A hundred enterprise customers asking for time-to-action metrics at renewal will change provider behavior faster than a decade of blog posts. Including this one.

Making the channel machine-readable

Human-readable web forms are a deliberate rate limiter. They exist in part because they cap report volume at whatever a security team can be bothered to hand-type at 2 a.m.

The standards to fix this already exist and are largely unused at the IaaS layer: ARF (RFC 5965) and its extensions define a structured reporting format; X-ARF extends it beyond email abuse. What is missing is a common ingestion API across providers, with authenticated reporter identities, structured evidence attachment, and — non-negotiably — a status endpoint the reporter can poll.

If a provider can accept a structured, signed, evidence-bearing abuse report over an API and return a case ID, then abuse reporting becomes automatable, and automated reporting becomes measurable. Everything downstream follows from measurability.

Publishing the scoreboard

Academic work out of TU Delft spent years on precisely this question: how to construct empirical security metrics that distinguish more-secure from less-secure hosting providers, on the explicit theory that you cannot incentivize providers you cannot rank.

That work should be operational and public. A quarterly, methodologically transparent ranking of major IaaS providers by abuse concentration, median time-to-action, and acknowledgement rate would do more to change behavior than any amount of private correspondence — because it converts an externality into a procurement liability and a press liability simultaneously.

Blocklist operators have functioned as a crude version of this scoreboard for twenty-five years, and it is genuinely the only enforcement mechanism that has ever consistently worked on a negligent host. It is also a blunt instrument that harms bystanders. A better metric would let buyers apply pressure without collateral damage.

Part 5: The honest counterarguments

Any provider reading the above has objections, and some of them are good ones.

Abuse reports are weaponizable. Automated, unverified reporting at scale is a denial-of-service vector aimed at a competitor’s customers. Any mandatory-action regime needs a reporter-accountability mechanism, which is exactly why trusted-flagger structures exist and why the DSA bothers to require a good-faith statement in every notice.

Most abusive instances belong to victims. A large share of attacking IPs are compromised customer workloads, not attacker-owned accounts. Suspending them punishes the wrong party, and “we terminated your production database because someone reported it” is a business-ending sentence for a provider.

Attribution at the IP layer is genuinely hard. NAT, shared egress, load balancers, ephemeral addresses, and reassignment mean the instance behind an IP at report time may not be the instance behind it at triage time. Reports without precise timestamps and time zones are often unactionable, and a large fraction of received reports lack them.

Displacement is real. Aggressive enforcement at reputable providers pushes demand toward bulletproof hosting in permissive jurisdictions, where there is no abuse desk at all and no notice-and-action regime to invoke. That is not obviously a net improvement — though it does at least strip the attacker of hyperscaler reputation, which has value.

None of these justify silence. All of them argue for structured, accountable, measured handling rather than either indifference or reflexive suspension.

Part 6: What to do on Monday

Concretely, if something in a provider’s address space is hitting you right now:

  1. Confirm ownership before reporting. whois the address and read the org fields; a surprising volume of abuse reports go to the wrong company entirely because someone assumed a cloud-shaped IP was AWS.
  2. Report through both paths. Submit the web form and mail the abuse-c address from WHOIS. They frequently land in different queues with different staffing.
  3. Make the report actionable. Source IP, destination IP, precise timestamps with time zone, protocol, port, and raw log excerpts. Reports lacking timestamps and time zones cannot be correlated to a customer and will be closed silently.
  4. Ask for a case ID explicitly. Then reference it in every follow-up. A tracked report is dramatically harder to drop than an untracked one.
  5. Escalate on a clock. No acknowledgement in five business days: escalate to blocklist operators with evidence, and — if you or the provider are in the EU — treat your submission as an Article 16 notice and say so in writing. The phrase “actual knowledge” is doing real legal work.
  6. Keep your own records. Provider-side abuse statistics are self-reported where they exist at all. Your ticket log is the only independent measurement of how a given provider actually performs, and it is worth surfacing at contract renewal.

The uncomfortable summary

The industry solved the easy half of this problem — building the intake channel — and then declared victory for fifteen years. Every provider has a form. Almost none has a service level, a case ID, a disposition notice, or a published median time-to-action.

Abuse handling is currently the only part of the cloud security stack with no SLA, no telemetry, no benchmark, and no buyer pressure. That is not because it is unimportant. It is because the cost of doing it badly is paid entirely by people who are not the provider’s customers, and nobody has yet made that bill collectible.

The DSA has started making it collectible in Europe. Procurement can make it collectible everywhere else, faster, and without waiting for a legislature.

Until then: fill in the form, keep the ticket number, and manage your expectations.

Sources and further reading