How should security teams detect malware that disguises itself as legitimate software and uses cloud services as dead drop resolvers?

Security teams should look for a combination of masquerading filenames, unusual cloud-service downloads, and outbound requests that resolve to command-and-control infrastructure. In this campaign, the malware repeatedly pretended to be legitimate software while using OneDrive or GDrive as a dead drop resolver. Behavioral detection, proxy visibility, and endpoint telemetry are more useful than file names alone.

Why Cloud-Hosted Dead Drops Matter to Security Teams

Cloud services used as dead drop resolvers are effective because they blend into ordinary enterprise traffic. The malware is not relying on an exotic exploit chain alone, it is abusing trusted SaaS reachability to fetch the next stage, update destinations, or resolve command paths after initial execution. That makes filename checks and reputation filters weak on their own, especially when the payload also masquerades as legitimate software.

For defenders, the security problem is not just “is this file malicious?” but “does this process behave like software that should be talking to consumer or business cloud storage at this time, from this host, with this pattern of access?” Behavioral analysis matters because the abuse sits at the intersection of malware disguise, proxy-visible downloads, and outbound resolution to infrastructure that may otherwise look normal. In practice, many teams only notice this pattern after cloud access logs and endpoint telemetry are correlated, rather than during initial file triage.

How It Works in Practice

The detection model should join three views: endpoint execution, network egress, and cloud-service activity. A disguised binary may drop from a user-facing lure, execute under a believable name, and then retrieve or resolve additional payload data through a cloud storage location. The cloud service is not the command server itself in the classic sense, but a dead drop resolver, so the resolver traffic often looks like routine SaaS access until the surrounding context is examined.

On the endpoint, look for mismatches between the process name, file location, signer status, and parent-child process chain.
In the proxy or secure web gateway, look for unusual downloads from cloud storage domains that do not match the host’s normal business purpose.
In DNS and outbound connection logs, look for repeated resolution or retrieval behavior tied to newly seen cloud objects, short-lived URLs, or staged beaconing.
In SIEM and EDR telemetry, correlate the first execution with subsequent cloud access, then compare that sequence against normal user or software update behavior.

Detections should focus on rarity and sequence, not only on indicators of compromise. A legitimate-looking filename is useful context, but it is not a trustworthy signal if the process tree, network pattern, and cloud access timing disagree. Cloud services also create false comfort because they are often allowed by policy, which means the control point shifts to content inspection, process behavior, and identity of the initiating host rather than simple domain blocking. Using CIS Controls v8 for malware defence, logging, and account control gives teams a practical baseline, while MITRE ATT&CK Enterprise Matrix helps analysts map the observed sequence to credential access, persistence, or command-and-control behavior.

These controls tend to break down when cloud access is broadly permitted, endpoint telemetry is sparse, or the malware uses user-like timing and token reuse that makes the traffic look like ordinary collaboration activity.

Common Variations and Edge Cases

Tighter cloud inspection often increases operational friction, so teams have to balance SaaS usability against the need to notice covert staging and dead drop behavior. That tradeoff becomes sharper when the same cloud services are genuinely required for business workflows or software distribution.

Some variants use personally controlled cloud accounts, shared folders, or APIs rather than obvious public download links, which means allowlisting by domain alone is too coarse. Other campaigns split the behavior across multiple stages, with one process handling the masquerade and another handling cloud retrieval, so single-event detections miss the chain. Current guidance suggests treating the cloud service as a transport and rendezvous layer, not as the final indicator of compromise.

Where defenders already have strong egress controls, the remaining gap is usually visibility into what was fetched, by which process, and whether the retrieval happened immediately after execution. For that reason, teams should expect more value from correlated detections than from static signatures alone. CSA Cloud Controls Matrix is useful when cloud governance needs to be aligned with detection requirements, and NIST Cybersecurity Framework 2.0 supports the broader detect and respond workflow that this kind of malware is designed to evade.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	10 — Malware Defenses	Covers detecting and containing disguised malware and suspicious execution behavior.
	8 — Audit Log Management	Needed to correlate endpoint, proxy, and cloud events into one detection chain.
	13 — Network Monitoring and Defense	Applies because outbound cloud retrieval and resolver traffic are network-visible abuse patterns.
Recommendation — Deploy malware defenses that correlate file, process, and network signals before trusting a binary. Centralize and retain endpoint, proxy, and cloud logs for sequence-based detection. Inspect egress traffic for unusual cloud downloads and resolver-like outbound patterns.
MITRE ATT&CK	T1036 — Masquerading	Directly matches malware pretending to be legitimate software.
	T1105 — Ingress Tool Transfer	Applies when cloud services are used to retrieve staged payloads or follow-on tools.
	T1071 — Application Layer Protocol	Fits malware that hides command or retrieval activity inside ordinary SaaS traffic.
Recommendation — Map suspicious binaries to T1036 and alert on deceptive names, paths, and metadata. Hunt for staged downloads from cloud services and unexpected follow-on tool transfer. Classify cloud-based resolver traffic as application-layer abuse and inspect the sequence closely.
NIST CSF 2.0	DE.CM — Continuous Monitoring	Supports behavioral detection across endpoint, proxy, and cloud telemetry.
	RS.AN — Analysis	Applies because analysts must correlate disparate telemetry to confirm malicious cloud usage.
Recommendation — Continuously monitor host and network behavior to detect disguised malware chains. Correlate endpoint and cloud evidence during analysis before declaring a benign download.

Practitioner Guidance

What to prioritise: Prioritise the join between endpoint execution and cloud egress. If the process looks legitimate but the network behavior does not fit the software’s normal purpose, treat that as a higher-confidence lead than the filename alone.

What to verify: Verify whether the cloud-service access is expected for that host, user, and time window. A good test is whether the same pattern appears in normal software updates or business collaboration traffic, or whether it only appears during suspicious execution chains.

Decision rule: If a trusted cloud domain is involved, do not downgrade the alert automatically. Escalate when the cloud request is part of a short sequence that begins with masqueraded execution and ends with outbound resolution or staged retrieval.

What practitioners underestimate: Teams often underestimate how much cloud storage can function as an innocent-looking rendezvous point. The key question is not whether the service is trusted, it is whether the observed sequence of process behavior, access pattern, and destination makes sense for that software on that endpoint.

Practitioner takeaway: The most reliable detections come from correlation, not identity by filename, and the highest-value question is whether the endpoint and its cloud activity tell the same story.