Why do attackers use legitimate software and trusted services to deliver malware and command traffic in modern campaigns?

Why trusted software and services are such effective malware delivery paths

Attackers prefer legitimate software and trusted services because those channels already sit inside normal business traffic. Signed installers, admin tools, cloud storage, collaboration apps, and email platforms are less likely to be blocked outright, so the malicious activity inherits credibility, blends with routine operations, and often survives perimeter controls that focus on known-bad infrastructure.

That trust advantage also changes the defender’s job. Instead of asking only whether a file or domain is known malicious, teams have to determine whether the software, account, process, or service is being used in a way that fits its normal purpose.

Why this works technically, not just socially

Modern campaigns exploit the gap between reputation and intent. A trusted binary can still launch a malicious child process, reach out to an unusual host, or load an unexpected payload. A trusted cloud or email service can still carry command traffic because the network sees a normal service endpoint rather than an obviously hostile one. That is why defenders look for process lineage, suspicious parent-child relationships, and abnormal use of approved platforms.

Legitimate services also help attackers reduce the friction of command and control. Traffic may look like ordinary SaaS usage, token-based API access, or user-driven collaboration activity, which makes simple blocklists and domain reputation checks less effective. For that reason, CIS Controls v8 remains useful because it pushes visibility, logging, malware defence, and account management as operational controls rather than relying on reputation alone.

Defenders also need to distinguish allowed use from allowed abuse. A service can be trusted and still be abused for staging, payload delivery, or callback traffic. That distinction is why MITRE ATT&CK Enterprise is valuable for mapping the downstream tactics that follow initial trust abuse, including credential access, execution, persistence, and lateral movement.

Where defenders should focus detection and response

The practical question is not whether the software is legitimate, but whether its behaviour is legitimate in context. Process lineage is critical because a trusted process spawned by an unusual parent, executed from an odd path, or loading an unfamiliar module is often the first sign of abuse. Cloud and email services deserve the same scrutiny when they carry command traffic, especially if the account, tenant, sender pattern, or access time does not match normal business use.

That is why the best detections combine host telemetry, identity signals, and service usage patterns. A suspicious installer, an unexpected child process, or a cloud session from a rarely used account becomes more meaningful when it lines up with abnormal authentication, privilege use, or data movement. The deeper the trust relationship, the more important it is to verify how the service was used rather than assuming it was safe because it was approved.

When those patterns appear, the response priority is usually containment of the trust path, not just removal of a file. Rotate exposed secrets, revoke suspicious sessions, review service tokens and delegated permissions, and inspect whether the same channel was used to move laterally or exfiltrate data.

Risk and Threat Considerations

Trusted software and trusted services create a persistent abuse surface because the defender’s first-line filters are often tuned to trust the platform, not the action. Attackers use that gap to reduce alert volume, delay triage, and keep command traffic hidden inside everyday business workflows.

Failure mechanism: A signed binary, cloud service, or collaboration platform is treated as benign by default, then used to fetch payloads, relay commands, or launch secondary execution from an otherwise approved context.

Impact: Detection becomes slower, investigation becomes noisier, and compromise can spread farther before defenders recognise that a trusted channel has been repurposed for malicious activity.

Practitioner Guidance

What to verify: Verify whether the process tree, account, tenant, or API call sequence matches the normal operating pattern for that software or service. If it does not, treat the trust relationship itself as the lead indicator.

What to prioritise: Prioritise telemetry that ties execution to identity and lineage, not just reputation. The most useful signals are unusual parent-child chains, rare service usage, nonstandard destinations, and unexpected authentication context.

Decision rule: If a trusted service is being used for delivery or command traffic, investigate the service abuse path first, then scope endpoints and accounts that touched it, rather than assuming the problem is limited to a single malicious file.

Practitioner takeaway: The control gap is rarely “unknown malware” alone, it is trusted infrastructure being used outside its intended behaviour, so defenders win by validating context, lineage, and session legitimacy together.

Related resources from NHI Mgmt Group

• How should security teams respond when attackers use legitimate software installers and scripting tools to deliver malware?
• How should security teams detect AI model abuse when attackers use legitimate AI services to blend into normal traffic?
• How should security teams stop command and control traffic before attackers can use it for remote control and malware spread?
• What happens when phishing campaigns use legitimate email services and trusted support platforms?