Why do attackers use public file hosting and messaging platforms to control malware and exfiltrate data?

Why public platforms are attractive control planes for malware

Attackers use public file hosting and messaging platforms because they inherit trusted infrastructure, steady availability, and normal-looking traffic patterns. That makes command delivery, tasking, and data staging easier to hide inside services that users and defenders already expect to see, rather than inside obviously malicious infrastructure that can be blocked or sankholed quickly.

The practical advantage is not just camouflage. Public platforms also reduce operational overhead, since the attacker does not need to maintain the full stack of domains, servers, certificates, and hosting that a dedicated command-and-control environment would require. That lowers cost, improves resilience, and gives the malware a broader set of fallback paths if one service or account is disrupted.

How public services support command, staging, and exfiltration

These platforms can serve several jobs at once. A file host may carry payloads, updates, or encrypted archives; a chat or collaboration service may carry commands, status updates, or tasking; and both may be used to move stolen data in small, routine-looking batches that blend into ordinary user activity. That flexibility is why defenders often see them as part of the access path rather than merely the delivery path.

For attackers, the value is in layering. If the malware can retrieve instructions from a benign-looking endpoint and then push out compressed or encrypted data through the same kind of service, it becomes harder to separate malicious traffic from normal SaaS use. The 52 NHI Breaches Report illustrates how often real incidents chain stolen access, secret abuse, and downstream exfiltration rather than relying on a single noisy technique.

Why defenders struggle to shut this pattern down cleanly

The core defensive problem is that blocking the platform is usually too blunt, while allowing it unchanged can leave a control channel open. Many organisations depend on file sharing and messaging services for normal business work, so defenders have to inspect content, identity, and behaviour instead of relying only on destination reputation. That is especially important when the same platform can host both legitimate collaboration and malicious staging.

Attackers also benefit from policy friction. Public services are frequently exempted from hard blocks, lightly monitored, or allowed through because they are tied to productivity workflows. When a threat actor uses a common service for command delivery or exfiltration, a destination-based control can look healthy even while the content, timing, or account behaviour is clearly suspicious. CIS Controls v8 is relevant here because it pushes teams toward inventory, logging, data protection, and malware defence rather than destination-only trust.

Risk and Threat Considerations

Public hosting and messaging services create a control-confidence gap: the traffic looks familiar, but the actor, content, and intent may not be. That gap increases dwell time, helps attackers persist after initial compromise, and makes exfiltration easier to miss when teams assume “approved service” means “safe content.”

Failure mechanism: The defender monitors where traffic goes, but not what is being sent, who is sending it, or whether the service is being used as an indirect command channel or staging area. The attacker then hides commands, payloads, or stolen data inside normal SaaS interactions.

Impact: Malware can receive instructions longer, exfiltrate data in smaller and less obvious bursts, and survive longer before containment. That often increases the scope of compromise because the same trust relationship used for business collaboration is being repurposed for attack.

Practitioner Guidance

What to verify: Confirm whether your detections look at content patterns, authentication context, file behavior, and transfer volume, not just the domain name or application category. If an approved service can carry sensitive data, treat that service as an inspection target, not a trusted exception.

Decision rule: If a public platform can move files, messages, or tokens between an infected endpoint and an external account, prioritize behavioural detections, CASB or proxy telemetry, and egress anomaly review before debating whether the platform should be broadly blocked. The useful question is whether the platform is observable enough to detect misuse at speed.

Practitioner takeaway: The real control is not “block public SaaS,” it is “make SaaS misuse visible enough that malware cannot hide behind normal collaboration patterns.”

Related resources from NHI Mgmt Group

• How should security teams control shadow AI use when employees paste sensitive data into public models?
• What happens when attackers steal SaaS credentials and use built-in application features to exfiltrate data?
• How should security teams stop command and control traffic before attackers can use it for remote control and malware spread?
• Why does the use of multiple file sharing platforms increase data security risk for organisations?