filen.io as a C2 Channel: How APT28 Turned Zero-Knowledge Cloud Storage Into a Command Path DPI Can't Read

The Beacon You're Looking For Is a File Sync to a Service Nobody Blocks

A workstation in a government network is talking to filen.io over TLS. The domain resolves cleanly, the certificate is valid, the traffic looks like any other cloud storage sync. Your proxy passes it. Your DPI can't read inside it because the payload was encrypted client-side before it ever hit the wire. Your threat-intel feeds have nothing on the domain because it belongs to a legitimate German cloud storage provider with real paying customers. Every reputation-based control you own says this connection is fine. It is not fine. It's the command-and-control channel for a Covenant Grunt beacon that APT28 dropped forty minutes ago, and the file that just synced down is a second-stage backdoor.

This is where C2 detection is heading, and filen.io is the current sharp edge of it. In the multi-stage campaign Trellix and CERT-UA documented against European military, maritime, and government targets, APT28 weaponized a Microsoft Office flaw and routed the entire post-exploitation chain through end-to-end encrypted cloud storage. The tradecraft matters more than the specific victim set, because the design deliberately defeats the detection stack most organizations have spent a decade building. IP reputation, domain blocklists, TLS inspection, JA3 fingerprinting, beacon-timing analysis: the choice of a zero-knowledge cloud provider as the C2 substrate neutralizes most of them at once.

If your C2 detection strategy assumes the command channel points at attacker-controlled infrastructure with a bad reputation, this class of attack is built to walk straight past it. The channel points at infrastructure with a spotless reputation, shared by millions of legitimate users, carrying content the provider itself cannot decrypt.

Why Zero-Knowledge Storage Is Close to an Ideal C2 Substrate

Living-off-trusted-services C2 isn't new. Attackers have used Telegram, Discord, Pastebin, GitHub, Google Drive, and Dropbox as command channels for years. What makes the current wave different is the specific properties of zero-knowledge, end-to-end encrypted providers like filen.io, and it's worth being precise about why they're such a good fit for an operator who wants to disappear.

The encryption model is the core of it. filen.io encrypts data client-side before upload, and the provider holds no keys. That's the selling point for privacy-conscious customers, and it's the same property that makes the service opaque to defenders. Even if you could compel the provider to cooperate, or intercept the session and break TLS, the content is encrypted with keys the provider never sees. There is no server-side plaintext to subpoena, inspect, or scan. When an attacker stages a payload there, the payload sits inside a container that neither the provider nor a network sensor can open. DPI, TLS-inspecting proxies, and content-aware DLP all see the same thing: opaque bytes flowing to a legitimate storage endpoint.

Reputation is the second property, and it's the one that quietly breaks the most tooling. Threat intelligence platforms rank infrastructure by reputation, and a domain like filen.io scores as clean because it is clean. It's a real business with real customers. You cannot blocklist it the way you'd blocklist a freshly registered domain on bulletproof hosting, because blocking it means blocking a legitimate service that some of your users may rely on. The attacker inherits the provider's reputation for free, and every IP-reputation and domain-reputation control in your stack inherits the attacker's cover story.

The traffic shape is the third. Cloud storage sync is bursty, irregular, and bidirectional by nature. Files go up, files come down, at human-driven and application-driven intervals that don't look like the metronomic beaconing that timing-based detection is tuned to catch. An implant that checks a filen.io folder for tasking and writes results back looks, at the flow level, like a sync client doing its job. Beacon-jitter analysis and JA3/JA3S fingerprinting were built for a world where the C2 endpoint was suspicious. Here the TLS client is often a legitimate library or the provider's own SDK, and the endpoint is a service your CFO might also be using.

Put those three together and you have a channel that is encrypted end-to-end, hosted on trusted infrastructure, and shaped like normal activity. That's not an incremental evasion. It's a channel that sidesteps the entire reputation-and-inspection paradigm.

How APT28 Assembled the Chain

The filen.io channel doesn't appear in isolation. It's the C2 layer of a multi-stage chain APT28 built for resilience, and walking the chain shows how the encrypted-storage endpoint fits into a broader living-off-the-land design.

Initial access came through a weaponized Office document exploiting CVE-2026-21509, a Microsoft Office flaw APT28 weaponized within roughly 24 hours of its disclosure. The lures carried geopolitically themed decoy content (transnational weapons smuggling narratives, military training programs, meteorological emergency bulletins) aimed at government and defense recipients. The exploit fires on document open, triggering code execution without requiring macros or user interaction, which removes the usual "enable content" friction that catches less capable operations.

From there the chain staged deliberately. The exploit pulled down a Microsoft Shortcut (LNK) and a DLL codenamed SimpleLoader, which was responsible for dropping one of two payloads: the NotDoor Outlook backdoor, or a Covenant Grunt beacon. The Covenant Grunt then contacted a filen.io endpoint to deliver BEARDSHELL, a custom C++ backdoor Ukrainian authorities have explicitly attributed to APT28. The whole sequence is engineered around minimizing forensic artifacts, with encrypted payloads, in-memory execution, and process injection at each hop, so that even a responder on the box finds little to work with.

NotDoor deserves its own attention because it's a second C2 primitive in the same toolkit, and it abuses a different trusted channel: Outlook itself. NotDoor is a VBA macro backdoor for Outlook, deployed through DLL side-loading using Microsoft's legitimately signed OneDrive.exe, which loads a malicious SSPICLI.dll. That loader installs the VBA project, disables Outlook's macro security protections, and suppresses dialog prompts. Once resident, NotDoor hooks the Application_MAPILogonComplete and Application_NewMailEx events, so it executes whenever Outlook starts or a new mail arrives. It waits for an inbound email containing a specific trigger string on a designated line, then treats email as the command channel: exfiltrating data, uploading files, and executing commands. Exfiltrated files are saved under %TEMP%\Temp, named to mimic ordinary business documents using a predefined name-and-extension list, encoded with a custom modified-Base64 routine, mailed out, and deleted. Reported exfiltration addresses have used Proton mailboxes such as a.matti444@proton[.]me.

So one campaign, two trusted-channel C2 mechanisms: encrypted cloud storage for staging and beaconing, and the victim's own Outlook mail flow for tasking and exfiltration. Neither points at anything with a bad reputation. Both hide inside services the organization already trusts and can't easily block.

Why Your Existing C2 Detection Misses This

It's worth being blunt about which controls fail here, because a lot of C2 detection budget sits in exactly the layers this tradecraft neutralizes.

Network-layer reputation fails first. Blocklists, threat-intel domain feeds, and IP-reputation scoring all key on infrastructure being known-bad or newly registered. filen.io is neither. The same applies to the Outlook channel: NotDoor's traffic is ordinary IMAP/SMTP or Exchange mail flow to legitimate mail infrastructure.

TLS inspection fails next, and fails harder than usual. Even a proxy that terminates TLS and inspects payloads gets nothing from filen.io, because the content was encrypted client-side before TLS. You can break the transport encryption and still face an opaque application-layer blob. This is the specific reason zero-knowledge providers are worse for defenders than something like a plain Google Drive link, where the content is at least theoretically inspectable server-side.

Beacon-timing and TLS-fingerprint analysis degrade too. Tooling that flags regular beacon intervals or anomalous JA3 hashes assumes the C2 client is distinguishable from normal traffic. When the implant rides cloud-storage sync patterns and, in some variants, uses legitimate client libraries or SDKs to talk to the service, the timing looks human and the fingerprint looks ordinary.

The uncomfortable conclusion is that the network is the wrong place to catch this. The command channel has been deliberately relocated into a blind spot in the network stack. Detection has to move to the endpoint and to behavioral context, where the attacker still has to do things that don't fit.

Where the Detection Actually Lives

The channel is invisible on the wire, but the activity around it isn't. Every one of these techniques requires the attacker to make something happen on the endpoint that deviates from normal, and that's the detection surface.

Start with process-to-service anomalies. Legitimate filen.io traffic comes from the filen.io desktop client or a browser. It does not come from powershell.exe, rundll32.exe, a Covenant Grunt, or an unsigned binary running out of %TEMP%. The high-value detection is a non-browser, non-sanctioned-client process establishing outbound connections to cloud-storage endpoints. In Microsoft Defender for Endpoint:

DeviceNetworkEvents
| where RemoteUrl has_any ("filen.io", "filen-1.com", "drive.filen.io")
| where InitiatingProcessFileName !in~ ("filen.exe", "msedge.exe", "chrome.exe", "firefox.exe")
| where InitiatingProcessFileName in~ ("powershell.exe", "rundll32.exe", "regsvr32.exe",
                                       "mshta.exe", "wscript.exe", "cscript.exe")
    or InitiatingProcessFolderPath has_any (@"\Temp\", @"\AppData\Local\Temp")
| project Timestamp, DeviceName, InitiatingProcessFileName,
          InitiatingProcessFolderPath, RemoteUrl

Extend the URL list to the other zero-knowledge and developer-tunnel services in current use, because the pattern generalizes well beyond one provider. The same campaign cluster and its neighbors have abused Microsoft Dev Tunnels (devtunnels.ms) to mask C2 behind Microsoft relay nodes, Telegram's Telegraph as a dead-drop resolver, Webhook.site (via the DNSHook service APT28 has used across campaigns), and, in a separate China-linked operation, Google Sheets as a covert channel. A standing rule for sanctioned-client-only access to cloud-storage and tunneling domains catches the category, not just the sample.

For the NotDoor / Outlook channel, the detection surface is entirely different and mostly host-side. The DLL side-loading step is the cleanest signal: OneDrive.exe loading SSPICLI.dll from an unexpected directory rather than from System32. In Sysmon, that's Event ID 7 (Image Loaded) where the image name matches a known system DLL but the load path is wrong, a generic side-loading detection that catches this and a large class of similar tradecraft:

Sysmon EID 7
  Image: *\OneDrive.exe
  ImageLoaded: *\SSPICLI.dll
  Signed: false OR ImageLoaded path NOT in (C:\Windows\System32\, C:\Windows\SysWOW64\)

The macro-security tampering is the second host signal. NotDoor disables Outlook's VBA protections to run, which means registry writes to the Outlook security keys. Monitor HKCU\Software\Microsoft\Office\<version>\Outlook\Security and the corresponding VBA warning values, and alert on any process lowering Level or setting VBAWarnings to allow all macros. Legitimate changes to these keys are rare and almost never made by a script.

The VBA project itself is the third. An Outlook VBA project (VbaProject.OTM) that hooks Application_NewMailEx or Application_MAPILogonComplete is unusual in most enterprises, and a VbaProject.OTM appearing or changing on a user's machine is worth surfacing on its own. Pair that with the working directory: files landing in %TEMP%\Temp with business-document names and extensions, created and deleted in quick succession around mail-send events, is the exfil-staging pattern.

The table below maps which detection layer each channel actually falls to, because the answer isn't the same for both.

Read down the columns and the point is hard to miss. Every network-layer control fails for both channels. Everything that catches this sits on the endpoint or in host-side behavioral context.

The Category, Not the Sample

The instinct after a writeup like this is to grab the IOCs, block filen.io, add the SSPICLI.dll hash, and move on. That's necessary and insufficient. The specific indicators are the least durable part of this. filen.io is one of a growing set of zero-knowledge providers, developer-tunnel services, and legitimate collaboration platforms that share the same defensive-blind-spot properties, and operators rotate between them as coverage improves. Blocking one provider moves the attacker to the next one with equivalent properties, and there are many.

The durable position is a policy stance toward the category. Decide which cloud-storage, tunneling, and collaboration services your organization actually sanctions, allow those from their legitimate client applications, and treat access to the rest, or access to sanctioned services from unsanctioned processes, as an event worth surfacing. That's a harder conversation than adding a domain to a blocklist, because it collides with users who have legitimate reasons to touch these services, and it demands you know what normal looks like on your own endpoints. But it's the only framing that survives the attacker swapping filen.io for the next zero-knowledge provider, and there will be a next one.

What this tradecraft is really exploiting is the gap between what a service is for and what it can be used for. filen.io exists to keep files private from everyone, including filen.io. That's a feature for its customers and, in the exact same mechanism, a channel your defenders cannot see into. The provider isn't complicit and the encryption isn't a flaw. The problem is structural: every service designed to be private to its users is, by construction, private to an attacker who uses it too, and the list of such services is growing faster than any blocklist can