Sednit’s paired implants and cloud tradecraft

Sednit’s paired implants and cloud tradecraft
March 10, 2026 at 12:00 AM

Sednit is back operating at a higher tier, pairing a custom implant with a refurbished open source framework and hiding command traffic in consumer cloud services. This is not a rerun of old tradecraft, it is a modernized playbook rooted in code that first made the group notorious.

What follows maps the toolchain, explains why the pieces fit together, and gives concrete ways to find them. The lens is practical for defenders, but it keeps the technical detail that analysts expect.

Code continuity in service of espionage, from Xagent to SlimAgent

Analysts have long treated code reuse as a weak signal. Here it is a strong one. SlimAgent, a compact spy utility seen on government endpoints, behaves like a peeled-out module of the group’s earlier flagship backdoor. The lineage is not just aesthetic, it shows up in mechanics: HTML based activity logs with consistent color tags, a keystroke recorder that only activates when the pointer stays nearly still, and process guardrails that confine execution to a familiar shell process. The shared implementation details reduce operator training costs and let developers recycle battle tested components without reintroducing noise.

Concrete hunt tips: search for hidden files that look like HTML reports with repeatable color tag patterns, pivot to the parent process and check whether it is a desktop shell process that would not normally load custom DLLs. On workstations, review Component Object Model hijacks that point to unexpected DLLs in user-writable locations. If this approach yields nothing, it may be that logging is encrypted end to end or file system journaling has been pruned, so widen to memory scans that look for HTML fragments allocated by long lived desktop processes.

BeardShell, opaque predicates, and cloud mimicry

Why the math trick matters

BeardShell executes PowerShell inside a managed runtime and speaks to a consumer cloud drive as its control channel. Its developers wrapped key routines with opaque predicates, arithmetic conditions that can never be true, so a disassembler sees fake branches and duplicated instructions. Opaque predicates slow human review and break naive deobfuscators, but they also leave a tell. When the same quirky predicate shape shows up in two distinct toolsets years apart, it fingerprints a developer’s toolbox more than it hides anything.

Detectable side effects

  • Cloud API replay, not official SDK use. BeardShell reimplements private client calls to a storage provider, so the traffic looks like a real client but emerges from a process that should not behave like one.
  • PowerShell without PowerShell. The commands run in process without invoking the usual console, so rely on AMSI bypasses and .NET reflection. ETW gaps or silenced script block logging become high value signals.
  • Rapid protocol drift. When the provider changes an endpoint, operators push a fresh variant quickly. Short lived DLLs that appear, achieve bidirectional traffic, then vanish deserve a closer look.

Actionable example: baseline the user agents, TLS client fingerprints, and header ordering of official cloud clients on a clean host. Alert when the same patterns are emitted by task host processes or by office suites. This works when egress logs retain header order and TLS details. It fails if traffic is tunneled through a local proxy that normalizes headers or if corporate TLS interception erases client fingerprints.

Covenant retooled for long haul control

Covenant began life as a red team framework, short lived, chatty, easy to spin up. Sednit’s version bends it toward months long access. The major shifts cluster around identity, staging, and transport, all of which trade a bit of stealth for operator efficiency across campaigns. The important twist is not the framework choice, it is the engineering discipline applied to make it stick.

AspectStock CovenantModified for espionageDefender angle
Host identityRandom per runDeterministic from machine traitsCorrelate reboots to a stable agent ID, unusual for red team defaults
StagingTwo separate stages, fixed entryAttribute guided entry, experiments with single binaryLook for attribute based reflection in loaders, not just fixed method calls
TransportHTTP or SMBCustom messenger over consumer cloud storageHunt for file based beaconing patterns inside cloud drive APIs from non client processes
Operator UXEasy, cluttered with flapping IDsSimplified dashboard, stable host labelingRepeated connections from the same host name after reboots signal long haul intent

Practical check: if a single workstation keeps showing an identical agent label across restarts, pull its process creation records and verify whether the loader picks an entry point by scanning for attributes inside a .NET assembly. That pattern is rare outside bespoke loaders and it points to persistence engineered for longevity.

The cross cloud failover pattern

Across recent operations, the group runs two implants together, each tied to a different consumer cloud provider. Call this the cross cloud failover pattern: a custom tool that is nimble in constrained environments, paired with a heavier framework that is comfortable for operators, both riding separate storage backends. This pairing shrinks mean time to recover access when one channel is burned, and it complicates takedown work because hosting abuse teams are split across unrelated providers.

What not to do

Avoid single provider takedown thinking when one cloud drive shows up, because the adversary likely prepared a sibling path. Blocking one provider alone can give a false sense of closure. The mechanism that fails here is incident scoping by infrastructure domain rather than by host identity and operator workflow.

Falsifiable claim: when a host shows consumer cloud control traffic that mimics an official client and the agent identity remains stable across reboots, a second, distinct provider will surface in telemetry or disk artifacts on the same host within a short window. This fails if the operation is smash and grab rather than espionage, or if the environment applies strict egress partitioning so the second provider never becomes reachable.

Scenario, a representative cascade in enterprise Windows

Context: A midsize agency runs Windows workstations joined to a domain, a cloud security proxy, and an endpoint detection and response agent. Consumer cloud storage is permitted for a subset of business units.

T+0 Trigger: A targeted email delivers a document that abuses a client side flaw to run a loader under the user’s context. The loader writes a DLL into a user writable path and registers a Component Object Model hijack so the desktop shell loads it on next login.

T+6h Cascade: On login, SlimAgent starts quietly, capturing clipboard and keystrokes only while the pointer is idle, reducing noise. Minutes later, BeardShell spins inside a task host process, reaching out to a storage provider using headers that match the official client. The proxy sees allowed traffic, because the domain is on the business allowlist. PowerShell logs are silent, because commands run in process via reflection.

T+1d Cascade: Operators deploy a Covenant variant that communicates through a different storage provider. The loader chooses the entry point by scanning method attributes, so behavior rules that key off fixed method names do not fire. The deterministic agent ID keeps the console readable for operators across reboots.

T+2d Response: Analysts block the first provider and quarantine the BeardShell DLL. The adversary pivots to Covenant through the second provider. A hunt for desktop processes emitting storage client style headers reveals the mismatch, and EDR memory scans confirm a managed runtime hosting suspicious PowerShell strings. Host isolation follows.

Lesson: Controls failed where policy treated consumer storage as a monolith. The second channel was viable because egress rules were global and PowerShell monitoring assumed the console host would appear. Partitioning egress by business unit and enforcing in process script logging would have narrowed the blast radius.

Detection playbook, tests that scale

Collect and correlate

  • Full proxy logs with header order and user agent strings for sanctioned cloud storage providers, plus TLS client fingerprinting when interception is off.
  • Process lineage, module loads, and COM registration audits on endpoints that routinely start desktop shell or task host processes.
  • Script block and managed runtime telemetry, including reflection and attribute usage where feasible.

Hunts that pay off

  • Official cloud client fingerprints emitted by non client processes, especially desktop shell or task hosts.
  • Hidden files with HTML like structure created by interactive logon sessions, plus recent process access to them.
  • .NET loaders that iterate method attributes to locate an entry point, a rare pattern outside bespoke implants.

Prioritize these hosts for triage when at least two of the above co-occur within a short interval. This works when data sources preserve granularity, such as header order and module paths. It fails if proxies normalize traffic or if endpoint policies block collection from desktop processes.

Control advice: segment egress for consumer cloud by business unit and device posture, require client application tokens for access to sanctioned storage, and flag API like patterns from browsers or system processes. Do not rely on blanket bans, they tend to break collaboration and get rolled back under pressure. Instead, enforce conditional access and monitor for protocol misuse. The approach assumes that sanctioned providers support granular access controls. If they do not, substitute with a broker that can enforce the same constraints.

Back…
More articles