---
title: Denial of Wallet (DoW) Attacks
url: https://www.emergentmind.com/topics/denial-of-wallet-dow-8d682fb0-1624-424e-87d9-d7651524cdb7
type: topic
---

# Denial of Wallet (DoW) Attacks

Searching arXiv for the provided papers to ground the article in current literature.
Denial of Wallet (DoW) is a denial attack class in which an adversary exploits the billing semantics of serverless computing to inflict financial exhaustion rather than merely technical unavailability. In the formal wording of the foundational serverless paper, “DoW attacks are the intentional mass, and continual, invocation of serverless functions, resulting in financial exhaustion of the victim in the form of inflated usage bills.” The “wallet” in this usage denotes the victim’s fiat-money cloud budget, not a blockchain wallet. DoW is therefore defined by its target asset: the attacker seeks to make continued operation economically unsustainable under pay-as-you-go pricing, often without needing to crash the platform outright [2104.08031].

## 1. Definition and target asset

DoW was introduced as a financially motivated analogue of Denial of Service for serverless cloud platforms. The core distinction is not simply that requests are malicious, but that the harm is measured in billing impact. In classic DoS, the attacker tries to exhaust CPU, bandwidth, memory, or connection limits so that legitimate users lose access. In DoW, the attacker exploits the fact that serverless resource consumption is monetized per request or per unit time, so every forced invocation can impose direct monetary cost on the application owner even if the service remains technically reachable [2104.08031].

This change in target asset is central. DoS primarily targets availability; DoW targets financial resources. The two can overlap, because a flood of invocations may both degrade service and increase cost, but the serverless literature treats DoW as distinct because autoscaling and per-request charging allow an attacker to generate charges without necessarily saturating a single bottleneck in the classic DoS sense. Later serverless work characterizes the same threat in operational terms: DoW attacks “aim to silently drain tenant budgets” by repeatedly invoking costly functions, including inference for machine learning models and data-intensive workflows [2507.04969].

The initial serverless paper also frames DoW as an emerging attack class with limited direct field evidence. It explicitly notes that there were no publicly disclosed occurrences on record. That makes the original contribution partly conceptual: naming the attack, formalizing its target, and establishing a threat model specific to serverless billing semantics rather than to network congestion alone [2104.08031].

## 2. Economic enablers in serverless and FaaS platforms

Serverless computing is especially exposed because its commercial model couples elasticity with fine-grained metering. Users are charged for function invocations, execution time, resource consumption, and related platform costs rather than for fixed reserved capacity. Review literature extends these billing dimensions to invocation count, execution duration, memory allocation, and sometimes additional upstream or downstream service usage. In this environment, an attacker does not need to deny execution; it is sufficient to induce execution repeatedly enough that cost accrues faster than the tenant expects or can tolerate [2104.08031][2508.19284].

The attack surface is broad because serverless functions are often exposed through public APIs, HTTP endpoints, queues, webhook integrations, and event triggers. An attacker can repeatedly invoke these interfaces, and the platform may keep scaling instead of rejecting traffic because elasticity is a design goal. That same elasticity, beneficial under legitimate demand spikes, becomes a liability under billing abuse. A single malicious trigger can also fan out across chained or cascading functions, multiplying the number of billable operations across a workflow graph [2104.08031][2508.19284].

The serverless review summarizes the economic relationship in provider-agnostic terms: total cost increases with `invocation rate × execution duration × resource allocation × time window`. That expression is not presented as a universal billing equation, but it captures the metering levers DoW exploits. More invocations increase cost; longer execution time increases cost; larger memory or resource allocation increases cost; chained workflows amplify cost across multiple billable steps; sustained low-intensity activity accumulates spend over time [2508.19284].

A further complication is observability. The review notes that the cloud abstraction reduces visibility into infrastructure-level behavior, while the anomaly-detection vision paper emphasizes fragmented telemetry, delayed metrics, and difficulty correlating short-lived executions across isolated functions. A service may appear operational from a latency or correctness perspective while cost rises anomalously in the background [2508.19284][2507.04969].

## 3. Position within the denial-attack taxonomy

Later work places DoW within a broader conditional taxonomy of denial attacks defined by six observable conditions \(C_0\) through \(C_5\). In that framework, DoW is the single-source, cloud-targeted, serverless-targeted sustainability attack:

$$
\text{DoW} = C_0 \cap C_1 \cap C_4 \cap C_5
$$

and in tree form:

$$
C_0 \rightarrow C_1 \rightarrow C_4 \rightarrow C_5 \rightarrow \text{DoW}
$$

where \(C_0\) denotes malicious requests sent to a target, \(C_1\) denotes a single source, \(C_4\) denotes scalable cloud infrastructure resources, and \(C_5\) denotes serverless infrastructure [2508.19283].

| Attack type | Conditions | Primary emphasis |
|---|---|---|
| DoS | \(C_0 \cap C_1\) | Single-source availability denial |
| DDoS | \(C_0 \cap C_2\) | Multi-source availability denial |
| EDoS | \(C_0 \cap C_4\) | Cloud cost and scaling abuse |
| DoW | \(C_0 \cap C_1 \cap C_4 \cap C_5\) | Single-source serverless billing exhaustion |
| DDoW | \(C_0 \cap C_2 \cap C_4 \cap C_5\) | Distributed serverless billing exhaustion |

This taxonomy clarifies several boundary cases. DoW differs from classic DoS because the defining conditions are not exhausted by malicious requests from a single source; DoW additionally requires cloud targeting and serverless specificity. It differs from EDoS because EDoS is the broader economic denial class for scalable cloud infrastructure, whereas DoW is the subtype uniquely characterized by targeting serverless architecture or cloud functions. It also differs from LDoS and LDDoS because low-rate stealth, represented by \(C_3\), is not a defining condition of DoW even though low-rate behavior may appear in practice [2508.19283].

The same paper interprets this distinction conceptually as a shift from availability-based attacks to sustainability-based attacks. Availability attacks disrupt operation directly. Sustainability attacks make operation too expensive to sustain. DoW occupies the serverless region of that sustainability space [2508.19283].

## 4. Operational patterns and empirical study

The review literature identifies three major DoW-family attack classes, following Mileski and Mihajloska. **Blast DDoW** is the bursty form: a large number of function invocations in a short period drive rapid autoscaling and immediate billing spikes. **Continual Inconspicuous DDoW** is the slow-burn form: a low, steady stream of invocations blends into background traffic and accumulates spend over days or weeks. **Background Chained DDoW** exploits orchestration and microservice dependencies so that one malicious trigger causes a chain or cascade of billable internal executions [2508.19284].

The serverless anomaly-detection vision paper adds a complementary operational vocabulary. It emphasizes repeated invocation of expensive functions, low-rate persistent attacks, trigger abuse, event injection, workflow fan-out, and burst patterns that cause cold starts and prolonged recovery. Concrete examples include malicious files uploaded to a storage bucket, spoofed webhooks or timers, and repeated execution of ML inference or data-intensive functions. These mechanisms matter because serverless platforms are event-driven and correctness-preserving behavior can still be financially abusive [2507.04969].

The original DoW paper supported its conceptual argument with an isolated experimental environment. In response to reviewer feedback, the authors reconfigured their “Isolated Test Platform” because OpenFaaS no longer supported Docker Swarm as its container coordinator; they migrated the experiments to Kubernetes and reran them. The paper states that simulated experiments were included to highlight the potential financial damage such attacks can cause and to provide an isolated test bed for continued safe research. Although the excerpt does not report the numerical billing values, it makes clear that the experimental goal was to validate the feasibility of continual invocation as a source of measurable financial harm in a real serverless platform environment [2104.08031].

## 5. Detection, observability, and mitigation

Mitigation research remains early stage. The foundational paper does not claim a fully resolved prevention mechanism; it outlines potential mitigation strategies and argues that classical DoS defenses may not be sufficient. An adversary may remain below obvious volumetric thresholds, distribute requests over time, or use normal API gateways and permitted triggers. As a result, a traffic pattern that does not trip standard DoS alarms can still steadily generate cost [2104.08031].

Later taxonomy work therefore argues that cloud-native observability must include billing alerts, invocation-rate anomalies, per-function cost trends, request-pattern similarity checks, and cloud usage telemetry. The point is methodological as much as operational: a system can be healthy from an availability perspective while still being under attack economically [2508.19283].

The anomaly-detection vision paper expands the relevant telemetry set. Signals useful for identifying DoW include response time, number of active function instances, CPU usage, cold-start flags or cold-start frequency, queueing delay, invocation patterns, and platform logs such as controller traces, invoker logs, and message queue events. It specifically names OpenWhisk’s `waitTime` as the duration an invocation spends awaiting dispatch to an available container. At the same time, it stresses why detection is difficult in stateless systems: functions are ephemeral, observability is fragmented, monitoring granularity is inconsistent, and high-level symptoms may be temporally misaligned with low-level platform behavior [2507.04969].

The review groups existing mitigations into practical classes: API rate limiting and throttling, execution time limits, cost management alerts, adaptive billing caps, and native cloud-provider monitoring using tools such as CloudTrail, CloudWatch, and X-Ray. It also surveys machine-learning approaches. **Gringotts** uses fine-grained performance metrics and Mahalanobis distance, with a reported detection delay of **1.86 seconds**, accuracy above **95.75%**, and overhead below **1.1%**. **DoWNet** uses convolutional neural networks over visual heatmaps and reports **97.98%** accuracy. **FODWNN-DoWAD** combines deep wavelet neural networks with optimization methods and reports **99.05% accuracy**. **FaaSMT** focuses on invocation-chain integrity using Merkle trees and task inlining. The same review argues that traditional rule-based detection tends to fail against low-visibility DoW, whereas ML approaches are better suited to anomaly-rich, high-noise serverless environments [2508.19284].

## 6. Scope, terminology, and adjacent literatures

A common source of confusion is the word “wallet.” In the serverless literature, DoW is explicitly not about blockchain wallets. That distinction matters because cryptocurrency-wallet research uses related but non-identical terminology. A systematic survey of cryptocurrency wallet design, vulnerabilities, and defenses does not explicitly use the term “Denial of Wallet.” Its closest equivalents are network-layer DoS and DDoS, DoS on connectivity, DoS on local resources, DoS on smart contracts, gas-costly patterns, greedy contracts, destroyable contracts, and inaccessible cryptocurrency wallet scenarios [2307.12874].

This suggests that the economic-denial intuition behind DoW extends beyond serverless even when the term itself does not. In proof-of-work blockchains, “Blockchain Denial-of-Service” attacks the reward mechanism so that rational miners conclude it is more profitable to stop mining than to continue; the paper reports that Bitcoin could be halted with about **21%** hash power under March 2020 conditions [1912.07497]. In MimbleWimble, a transaction-denial attack exploiting Dandelion++ and transaction aggregation can prevent over **45%** of transactions from ending up in the blockchain when the adversary controls **10%** of the network nodes, forcing users to resend [2112.13009]. These are not serverless DoW in the narrow sense, but they illustrate the same broader pattern: denial can be achieved by manipulating incentives, fees, or transaction inclusion rather than by saturating bandwidth alone.

Within the serverless field itself, the evidence base remains constrained. The literature repeatedly identifies the lack of real-world datasets as a major obstacle, and the absence of publicly disclosed incidents remains part of the problem statement. This is why **DoWTS (Denial-of-Wallet Test Simulator)** is treated as foundational in the review: it creates a safe simulated serverless environment, generates synthetic attack data, supports both burst and low-and-slow scenarios, and produces labeled datasets for machine learning. The same review presents itself as the first comprehensive literature review dedicated strictly to Denial of Wallet attacks, reflecting both the novelty of the topic and the still-forming state of its methodology [2508.19284].

Taken together, these works establish DoW as a serverless-native sustainability attack in which the decisive coupling is between invocation semantics and billing semantics. The central security implication is that availability defenses alone are insufficient: in pay-as-you-go cloud systems, billing abuse is itself a first-class security objective.

Source: https://www.emergentmind.com/topics/denial-of-wallet-dow-8d682fb0-1624-424e-87d9-d7651524cdb7