How do attackers use Exfiltration Over Web Service?

Attackers use Exfiltration Over Web Service to send stolen data through legitimate cloud or web service traffic so it blends in with normal activity. They may abuse approved applications, APIs, or user accounts. Defenders should inspect unusual upload volumes, new destinations, impossible travel patterns, and web service use that does not match business behaviour.

How exfiltration over web service works in practice

Attackers use legitimate cloud and web services as the delivery path for stolen data because normal HTTPS traffic is harder to distinguish from ordinary business use. The abuse can look like routine uploads, sync activity, API calls, or file sharing, which helps hide the theft inside trusted infrastructure and common browser or application behaviour.

The technique becomes effective when the attacker can blend into an approved service channel rather than open a suspicious outbound connection. That often means using a real user account, a compromised API token, or a sanctioned application connector so the traffic inherits the trust, reputation, and allow-listing of the service itself.

For defenders, the important point is that the exfiltration channel may be technically normal while the behaviour is not. Large or repeated uploads, unusual destinations, unfamiliar tenants, API use outside normal hours, or data movement that does not match the user or workload’s usual role all matter more than the fact that the destination is a popular service.

Why attackers prefer approved cloud and SaaS channels

Web service exfiltration is attractive because it reduces friction. Many organisations permit broad access to collaboration platforms, storage services, code repositories, messaging tools, and SaaS APIs, so an attacker can often move data without needing a custom malware channel or obviously malicious infrastructure.

This approach also helps the attacker survive partial containment. If one destination is blocked, the same stolen data can often be redirected through another approved service, a different account, or a different API path. That flexibility makes the method useful both for quick opportunistic theft and for longer campaigns that try to look like legitimate synchronisation or integration traffic.

Web service exfiltration is especially effective when the defender relies on coarse controls such as domain allow-lists alone. A service that is acceptable for business use can still become a covert transfer path when the attacker abuses a valid session, uploads staged archives, or breaks the transfer into smaller requests that resemble normal application activity. Data Exfiltration Guide covers the wider exfiltration patterns and the telemetry that helps separate benign transfer from theft.

What to look for when the channel is a legitimate service

Detection depends on behaviour, not just destination reputation. Useful signals include sudden spikes in outbound volume, repeated uploads to a new cloud tenant or webhook, transfers that happen at odd times, and access from geographies or devices that do not fit the user’s normal pattern.

It also helps to compare service use against the business purpose of the account or integration. A finance user uploading source archives to a personal storage workspace, or a service account pushing bulk data to a new API endpoint, is much more suspicious than the same service being used for its documented workflow.

Session context matters too. Impossible travel, repeated token refreshes from inconsistent locations, unusual user-agent strings, and API calls that appear after privilege changes can indicate that the attacker has taken over a real identity and is using its trusted access path to move data outward. Service Account Security Guide is useful when the exfiltration path is an application or integration identity rather than a human user.

Risk and Threat Considerations

Legitimate web services are attractive exfiltration channels because they often sit inside normal business trust boundaries. That means a defender may see the traffic as permitted while the attacker is using the service precisely because it is trusted, externally reachable, and difficult to block without breaking business operations.

Failure mechanism: The attacker stages data locally, then sends it through an approved cloud or SaaS path using a valid account, token, or connector, which makes the transfer look like ordinary application activity and can bypass simple egress controls.

Impact: Stolen data can leave the environment with low noise, delayed detection, and a smaller chance of triggering perimeter alerts. Once the attacker controls the account or integration used for the transfer, they can often repeat the exfiltration, pivot to other data sources, or preserve access for later theft.

Practitioner Guidance

What to verify: Check whether the service use matches the account’s normal business function, then validate transfer volume, destination novelty, and whether the same identity is being used from unfamiliar locations or devices. If the identity is an integration or automation account, review its expected API scope and whether it should ever move bulk data externally.

Decision rule: If the service path is trusted but the behaviour is not, treat the event as a potential data-theft investigation first and a networking issue second. Contain the account, token, or connector before debating whether the destination itself is approved.

Practitioner takeaway: exfiltration over web service is dangerous because it borrows the legitimacy of normal business traffic, so the decisive control is behavioural context around the identity, destination, and transfer pattern, not simple destination blocking.

Related resources from NHI Mgmt Group

• What happens when attackers use valid accounts, web shells, and custom exfiltration tools against a Defense Industrial Base network?
• How do attackers use exfiltration over other network medium?
• Exfiltration Over Web Service
• Why is visibility over NHIs critical for security?