A 90 Gbps flood came from six instances in an unrelated company's cloud account. How?
answer
- capacity created with credentials, not implants
- somebody else is paying the bill
- minutes to acquire, hours to lose
- quotas and spend limits set the ceiling
- six sources in published provider ranges
basics
~20 sStolen control-plane credentials. Someone used another organisation's cloud API access to launch a handful of very large instances aimed at the target, so capacity appeared in minutes, cost the attacker nothing, and was billed to the account owner.
solid answer
~50 sThat is the cloud control plane used as a bandwidth source. With working API credentials for someone else's account, an operator can launch a few of the largest instance types across several regions and have tens of gigabits of egress within minutes, with no fleet to build and no implant anywhere. The bill lands on the account owner, who is a second and entirely separate victim. The supply has a distinctive profile: enormous rate per host, a tiny source count concentrated in one provider's published address ranges, and a very short life, because it ends when the account owner or the provider reacts or when instance quotas and spend limits bite. That is also why an established account with raised quotas is worth more than a freshly created one. What it predicts about the operator is credential access, harvested or bought, rather than any ability to build and hold a botnet.
go deeper
Know that a flood can come from rented or stolen cloud capacity rather than infected home devices, and that whoever owns the account is a victim too, not the attacker.
Explain the mechanics: valid API credentials create hosts rather than being one host, large instance families carry very high network performance, and quotas per account and region set the ceiling.
Read the supply shape as evidence. Enormous rate from a handful of provider addresses says opportunistic use of stolen access, a burst rather than a siege, and a second victim who holds the record of what was launched.
Own the awkward part: the party paying for the attack is an uninvolved organisation who must be contacted, and the interaction with them, and with the provider, is a relationship question before it is a technical one.
## The supply model Most discussion of flood capacity assumes hosts have to be compromised one at a time. The cloud control plane collapses that: a single set of API credentials is not one host, it is the ability to *create* hosts, and the hosts it creates are far better connected than anything on a residential line. An operator with valid credentials for an unrelated organisation's account can launch instances chosen for network performance, spread them across regions, and point their egress wherever they like. Acquisition time is minutes. The attacker supplies no bandwidth of their own and pays nothing at all, because the account owner is paying by the second. How the credentials were obtained is a separate market and a separate question; treat it as an input to this one. ## What this supply is good at - **Rate per host.** Large instance families are provisioned with network performance measured in tens of gigabits. Six of them is a serious flood from six machines. - **Speed of acquisition.** No scanning, no exploitation, no fleet maintenance. Capacity exists on demand. - **Cost to the attacker.** Zero, and the cost that does exist lands on a third party who did nothing to the target. - **Reputation.** The addresses belong to a major provider and are not, in themselves, disreputable. ## What it is bad at, and why that shows The weaknesses are the mirror image of the strengths, and they are what makes this recognisable: - **Source count is tiny.** Six addresses, in published provider ranges, in a handful of regions. That is an enumerable list, and it is the opposite of the source diversity a consumer fleet is bought for. The supply is coarse and removable in one decision. - **Lifetime is short.** It ends when the account owner notices, when the provider reacts to abuse, or when the account's own limits stop it. The spend is visible to the owner almost immediately, because it is not a small number. - **Quotas cap it.** Providers limit how many instances of a family a given account may run, per region, and new accounts start low. This is why credentials for an established account with raised quotas are worth substantially more than credentials for a fresh one, and why an operator spreads launches across regions rather than piling into one. - **Everything ends together.** One account suspension removes the entire supply at once, which is never true of a dispersed fleet. ## The two-victim structure This is the part candidates most often miss. There are two unrelated victims. The flood target absorbs the traffic. The account owner absorbs the bill, and often learns about it from an invoice or a provider notice rather than from anything of their own. The account owner is not the attacker, and treating them as one is both wrong and, in a real engagement, a mistake with legal consequences. They also usually hold the only record of what was launched and when. ## What it predicts about the operator Read the supply as a statement about capability. Building and holding a hundred-thousand-device fleet is a long-running operation with maintenance costs. Using a stolen account is a short, opportunistic use of access obtained elsewhere. It predicts an operator whose strength is credential access, either harvested at scale or bought, rather than one who runs infrastructure. It predicts a burst rather than a siege, because the supply cannot be held. And it predicts that if the same operator returns, they will return with a different account rather than the same six addresses. ## Contrast that makes the point Set the two supply shapes side by side. Six stolen cloud instances: enormous rate, six sources, minutes to acquire, hours to lose, free to the attacker, funded by a stranger. A hundred thousand consumer devices: tiny rate each, tens of thousands of networks, months to acquire, durable, expensive to build, and worth it only because the sources cannot be separated from ordinary users. An operator choosing the first has decided that peak now matters more than persistence, and that is a real decision with real consequences for how the event unfolds. ## Answering well Name the mechanism (control-plane credentials, not compromised hosts), state who pays, then give the profile that makes it identifiable: enormous per-host rate, tiny source count in published ranges, quota-limited, short-lived. Finish with what it predicts about the operator. Do not drift into how the credentials leaked; that is somebody else's question and answering it here signals you have missed which part of the problem you were asked about.
- Why does this supply disappear faster than a botnet?Because it has one owner and one provider. A single account suspension removes all of it at once, and the cost is visible to the account owner almost immediately since it is a large, sudden spend. A dispersed fleet has no single point where it can be switched off.
- Why would an operator prefer credentials for an established account?Quotas. New accounts start with low instance and egress limits and often face verification, while an established account may have raised limits across many regions. The value of stolen credentials here is not the account's data but its provisioning headroom.
- What does the small source count cost the attacker?Everything that diversity would have bought. Six addresses in published provider ranges are an enumerable list with no legitimate users behind them, so separating the traffic costs the target nothing. The attacker has traded persistence and indistinguishability for immediate peak.
saying these in an interview costs you the question
- Assumes any large flood implies a large botnet
- Treats the cloud account owner as the attacker
- Believes the attacker paid for the capacity
- Ignores that a handful of sources sit in published provider ranges
- Explains how the credentials leaked instead of what the supply is