APT31 Targets Russian IT via Yandex Cloud & OneDrive C2

APT31 has operated for years as a flexible, well-resourced espionage group, and this latest activity against Russian networks shows how far its tradecraft has evolved. In this campaign, the operators focus on Russian IT contractors and government integrators instead of going directly after ministries or state agencies. That choice gives them access to multiple downstream environments through a single compromised supplier. At the same time, they hide their command-and-control traffic behind popular cloud services and legitimate tools, which makes detection significantly harder for defenders who focus only on obvious malware or suspicious domains.

Because of that combination of target selection and stealth, the campaign looks less like a single intrusion and more like a methodical program. The operators build footholds, extend them slowly and adjust techniques each time defenders close a gap. For blue teams that work inside complex supply-chain environments, this is exactly the kind of long-term, low-noise APT activity they have to assume exists even when nothing obvious appears in logs.

𝐓𝐚𝐫𝐠𝐞𝐭 𝐬𝐞𝐥𝐞𝐜𝐭𝐢𝐨𝐧 𝐚𝐧𝐝 𝐬𝐞𝐜𝐭𝐨𝐫 𝐟𝐨𝐜𝐮𝐬

APT31’s focus on Russian IT contractors is not accidental. Integrators and managed service providers often sit at the center of connectivity maps: they manage infrastructure, maintain remote access, support line-of-business systems and sometimes operate security tools on behalf of customers. When an attacker compromises that kind of company, it effectively gains a platform for exploring many other networks through support portals, VPN tunnels and shared management accounts.

In this campaign, the targeted organizations work closely with Russian government bodies and other high-value entities. They maintain critical applications, host shared services and sometimes control update channels for bespoke software. That creates a powerful leverage point for espionage. Instead of breaching multiple ministries directly, APT31 can insert itself where administration and integration work actually happens.

Furthermore, IT contractors often sit under pressure to deliver services rather than security. They may lag on endpoint telemetry rollouts, segment networks less strictly and prioritize uptime over rigorous control of every remote-access tool in use. Attackers with patience can exploit those realities, live “between the cracks” of responsibility and move through shared infrastructure without raising obvious alarms.

𝐂𝐥𝐨𝐮𝐝-𝐬𝐞𝐫𝐯𝐢𝐜𝐞 𝐚𝐛𝐮𝐬𝐞 𝐟𝐨𝐫 𝐂𝟐 𝐚𝐧𝐝 𝐞𝐱𝐟𝐢𝐥𝐭𝐫𝐚𝐭𝐢𝐨𝐧

One of the most important aspects of this campaign is how APT31 uses trusted cloud platforms as command-and-control and exfiltration channels. Rather than rely exclusively on self-hosted servers that defenders can quickly block, the group leans on Yandex Cloud, Microsoft OneDrive and other mainstream services. From the victim’s point of view, outbound connections to those platforms often look like normal business traffic.

The operators take advantage of that trust in several ways. First, they host staging scripts and payloads on cloud storage so initial downloads appear as legitimate file access. Second, they configure implants to send beacon traffic and results through cloud APIs, which makes the traffic blend into ordinary synchronization or backup flows. Third, they use short-lived tokens and rotating folders so infrastructure indicators change over time, complicating static blocklist-based defenses.

This approach also helps during incident response. If security teams simply block a suspicious IP, the attacker may re-establish connectivity by switching to a new tenant or resource inside the same cloud provider, while keeping the overall pattern consistent. Defenders who do not correlate device behavior, process lineage and cloud resource usage at a deeper level risk missing the underlying C2 pattern even after shuffling a few firewall rules.

𝐃𝐞𝐥𝐢𝐯𝐞𝐫𝐲 𝐚𝐧𝐝 𝐩𝐞𝐫𝐬𝐢𝐬𝐭𝐞𝐧𝐜𝐞 𝐦𝐞𝐜𝐡𝐚𝐧𝐢𝐬𝐦𝐬

APT31 uses more than one delivery path, yet several patterns repeat. In one well-documented intrusion, the attack begins with a spear-phishing email that contains a compressed RAR archive. Inside that archive, the victim finds a Windows shortcut (LNK) file that impersonates a legitimate document or utility. When the user double-clicks it, the shortcut launches a sideloading chain that abuses a legitimate executable and a malicious DLL placed alongside it.

The malicious library acts as a loader many reports refer to it as 𝐂𝐥𝐨𝐮𝐝𝐲𝐋𝐨𝐚𝐝𝐞𝐫 or a similar naming variant. Once it runs, the loader resolves API calls dynamically, unpacks an embedded payload or reaches out to a cloud location, and then injects the next stage into memory. That next stage might implement direct C2, or it might act as a plug-in style module that retrieves specific tools on demand.

Persistence rarely depends on a single artifact. The operators often create scheduled tasks with names that resemble legitimate software update jobs or synchronization processes. For example, a task may claim to belong to Yandex Disk synchronization, browser maintenance or system-level telemetry. They sometimes drop helper binaries such as SharpChrome-based tools for credential extraction, small utilities to query Active Directory user-to-IP mappings or custom network beacons that tunnel traffic through VPN-style channels.

Because each component looks modest on its own, defenders must evaluate them together. A scheduled task that launches a signed binary from a non-standard directory, which then loads an untrusted DLL, which in turn reaches out to an unusual cloud endpoint, paints a very different picture than any one of those details in isolation.

𝐋𝐨𝐧𝐠 𝐝𝐰𝐞𝐥𝐥 𝐭𝐢𝐦𝐞𝐬 𝐚𝐧𝐝 𝐦𝐢𝐧𝐢𝐦𝐚𝐥 𝐧𝐨𝐢𝐬𝐞

APT31 clearly optimizes for longevity rather than speed. Activity clusters often appear during weekends, holidays or late-night windows when staff coverage drops. The operators make small, incremental moves: a new scheduled task here, a new credential dump there, a short burst of lateral movement followed by long quiet periods.

That pattern complicates detection strategies built around “big” events. Many SOC playbooks tune thresholds to catch spikes, such as massive authentication failures or sudden large exfiltration volumes. APT31 takes the opposite path. It spreads activity over weeks or months, uses modest volumes of data per transfer and improves its situational awareness before taking any risky post-exploitation steps.

In addition, the group tends to reuse legitimate tooling wherever possible. It leans on built-in administrative utilities, off-the-shelf remote-access tools and vendor-supplied components, so process names and binary hashes look familiar. Where custom malware appears, it often hides behind obfuscation or packers, and it may execute in memory only. As a result, traditional detection methods that focus exclusively on “known bad” binaries or noisy behavior will miss a substantial portion of the campaign.

𝐒𝐮𝐩𝐩𝐥𝐲-𝐜𝐡𝐚𝐢𝐧 𝐚𝐧𝐝 𝐩𝐚𝐫𝐭𝐧𝐞𝐫 𝐞𝐜𝐨𝐬𝐲𝐬𝐭𝐞𝐦 𝐚𝐭𝐭𝐚𝐜𝐤 𝐯𝐞𝐜𝐭𝐨𝐫

The choice to target IT contractors and integrators turns this campaign into a supply-chain problem rather than a simple single-tenant breach. In many cases, these companies manage remote administration portals, maintain VPN connections into customer networks and deploy software updates on behalf of clients. When a threat actor gains control of those pathways, it can pivot quietly into multiple connected organizations without triggering typical external intrusion alerts.

APT31 appears to understand that dynamic well. Once it secures access to an IT supplier, it spends time mapping which customers connect through that infrastructure, which servers handle cross-tenant tasks and where credentials shared between environments live. From there, it can decide which downstream networks merit further effort and which simply serve as stepping stones.

This strategy also complicates remediation. Even if one compromised organization cleans up the intrusion successfully, the attacker may still retain access through another partner that links back into the same environment. Without a coordinated response across all affected entities, residual footholds remain. That reality reinforces the need for clear contractual language and communication channels around incident handling between IT providers and their customers.

𝐃𝐞𝐟𝐞𝐧𝐬𝐢𝐯𝐞 𝐫𝐞𝐜𝐨𝐦𝐦𝐞𝐧𝐝𝐚𝐭𝐢𝐨𝐧𝐬 𝐟𝐨𝐫 𝐜𝐥𝐨𝐮𝐝-𝐛𝐥𝐞𝐧𝐝𝐞𝐝 𝐀𝐏𝐓𝟑𝟏 𝐚𝐜𝐭𝐢𝐯𝐢𝐭𝐲

Defending against this kind of campaign requires more than adding a few new indicators to blocklists. Instead, organizations need to think in terms of behaviors and relationships, especially around cloud-service usage and remote-management workflows.

First, they should baseline how their environment normally uses platforms such as Yandex Cloud and OneDrive. Which hosts should legitimately contact those services, at what times and with what volumes? Once that baseline exists, deviations become easier to spot. A domain controller that suddenly begins talking to OneDrive, or a server in a restricted network segment that initiates outbound sessions to Yandex Cloud, deserves immediate attention.

Second, defenders should tighten process-creation and DLL-loading policies. Application-control frameworks can restrict which binaries may load libraries from writable directories, and EDR rules can flag cases where a signed executable launches from an unusual path or spawns scripting engines that do not align with its normal behavior. Even when such events turn out to be benign, the noise level remains far lower than that generated by blanket signature-based rules.

Third, organizations need visibility into scheduled tasks, services and other persistence mechanisms. Regular inventories of new or modified tasks, correlated with change-management records, highlight cases where persistence appears without any associated maintenance ticket or deployment plan. Security teams can then review those items manually and remove or quarantine suspicious entries before attackers benefit from them.

Finally, IT suppliers and their customers must collaborate more closely. That collaboration includes sharing telemetry, agreeing on joint incident-response runbooks and validating which remote-access tools and cloud resources the supplier legitimately uses. When both sides understand “normal” behavior, they can spot APT31-style anomalies far earlier, even when the actor hides behind well-known brands and cloud platforms.

𝐂𝐨𝐧𝐜𝐥𝐮𝐬𝐢𝐨𝐧

This APT31 campaign against Russian IT contractors demonstrates how modern espionage operations increasingly revolve around supply-chain leverage and cloud-service camouflage. The group does not rush. It selects integrators with access to high-value environments, compromises them quietly and then hides its C2 patterns inside mainstream cloud platforms. Over time, it builds a resilient web of persistence mechanisms and access paths that make eviction difficult.

For defenders, the lesson is straightforward but demanding. They must treat contractor networks as extensions of their own, demand deeper transparency into remote-access and update channels, and instrument their environments to see beyond host-based indicators into the behavior surrounding cloud usage and identity. When organizations adopt that mindset, they stand a better chance of catching groups like APT31 before a “stealthy cloud-based campaign” turns into a years-long fixture inside their critical systems.

FAQs

Q1: What makes APT31 different from other Chinese-linked groups?
APT31 has shown a long-term focus on intelligence collection, targeting supply-chain and contractor ecosystems rather than broad disruptive attacks. Their use of legitimate cloud services as C2 and low-noise persistence distinguishes their tradecraft.

Q2: Does this campaign only target Russian organizations?
While the current wave focuses on the Russian IT sector, APT31 is a global actor with a history of targeting governments, financial, telecom, construction and media across multiple regions since at least 2010.

Q3: How should an organization detect possible APT31 activity?
Look for unexpected cloud service use, especially by endpoints that would not normally access those services, scheduled tasks created by non-admin users, DLL side-loading from uncommon paths, and dev/tunnel activity such as Tailscale or custom VPNs.

Q4: If we’re an IT contractor, how do we reduce risk of being used as a pivot by APT31?
Segment your network so that government-facing assets are isolated, apply strict application control, monitor third-party library or script injections, enforce MFA, and maintain a supply-chain incident-response plan that includes partners and integrators.