guardsix blog

Open source can be sovereign, but running it yourself comes with costs

aumi@guardsix.com (Austin Mitchell) — Thu, 18 Jun 2026 09:51:47 GMT

When the European Commission set out its Technological Sovereignty Package in June 2026, it did two things at once. It proposed the Cloud and AI Development Act (CADA), which grades cloud and AI services by sovereignty level and steers sensitive public-sector workloads towards providers that keep data under European control. And alongside it, in the same package, it published an EU Open Source Strategy that puts open source at the centre of how Europe expects to win that control back.

The message looks simple: open source is the recommended route to sovereignty. The Commission is making a sound recommendation. Open source can deliver genuine sovereignty—but comes with costs that are easy to overlook.

What Does CADA Mean for European Security Leaders?

aumi@guardsix.com (Austin Mitchell) — Fri, 12 Jun 2026 12:37:41 GMT

On 3 June 2026 the European Commission proposed the Cloud and AI Development Act (CADA), part of its Technological Sovereignty Package. As of publishing, this is still a proposal. But it is already shifting the conversations between European cybersecurity leaders and the technology partners they rely on, putting new emphasis on security data that stays under European control, within European jurisdiction.

One more race to SYSTEM: RoguePlanet extends the BlueHammer–RedSun–Plasma lineage

Akanksha Giri — Thu, 11 Jun 2026 11:13:37 GMT

Overview

On June 10, 2026, the researcher known as Chaotic Eclipse (also operating under the alias Nightmare Eclipse) released another Windows local privilege escalation PoC, dubbed RoguePlanet. This marks the latest entry in a series of Windows zero-day discoveries from the same researcher that we have been tracking and analyzing over recent months.

Inside the Latest Chaotic-Eclipse Releases: Mini-Plasma, GreenPlasma, and YellowKey

Guardsix — Fri, 05 Jun 2026 11:45:05 GMT

— By Akanksha Giri & Anish Bogati

Overview

In May 2026, security researcher Chaotic Eclipse (also known as Nightmare Eclipse) publicly disclosed three new Windows zero-day vulnerabilities dubbed YellowKey, GreenPlasma, and MiniPlasma, releasing a proof-of-concept (PoC) exploit for each. The timing was deliberate: all three dropped in the five days immediately following Microsoft's May 2026 Patch Tuesday (May 12), ensuring no official fix would be available for weeks.

Quasar Linux (QLNX): A Developer-Targeted Linux RAT and Detection Strategy

Aashish Karki — Mon, 25 May 2026 10:37:54 GMT

Overview

Compromising a developer workstation is one of the highest-leverage moves an attacker can make on a Linux network. A single infected machine can expose source repositories, signing keys, package registry tokens, and production cloud credentials all at once. Recently identified by researchers at TrendMicro, Quasar Linux (QLNX) is a previously undocumented Linux Remote Access Trojan (RAT) purpose-built to exploit exactly that leverage while remaining almost entirely invisible to traditional file-based defenses. Despite the name, QLNX is not related to the Windows-based QuasarRAT commonly known as Quasar RAT.

Qilin (formerly Agenda): From emergence to global ransomware dominance

Nischal Khadgi — Fri, 15 May 2026 08:29:20 GMT

Supply Chain Attacks - abusing good nature for profit

John Coughlan — Mon, 11 May 2026 08:21:18 GMT

Executive Summary

Software supply chain attacks have evolved from opportunistic tampering to structured, repeatable campaigns targeting the trust fabric of modern software delivery. The current wave is not defined solely by malicious packages but also includes maintainer social engineering, CI/CD compromise, tag hijacking, secret harvesting from runners, malicious artifact publication, and lateral movement across interconnected tools.

Detecting DirtyFrag: A New Linux Local Privilege Escalation

Anish Bogati — Fri, 08 May 2026 11:24:59 GMT

Overview

Not every privilege escalation vulnerability stems from a simple coding mistake. In some cases, root access can be achieved by combining legitimate kernel features in unintended ways.

Linux Privilege Escalation (CVE-2026-31431): Copy Fail Exploit and Detection

Anish Bogati — Thu, 30 Apr 2026 12:13:39 GMT

Overview

Not every privilege escalation comes from a broken piece of code. In some cases, combining normal kernel features in the wrong way is enough to get root. “Copy Fail” is one of those cases.

From N-Days to Multiple Arch: Inside RondoDox’s Delivery Pipeline

Anish Bogati — Tue, 21 Apr 2026 07:18:24 GMT

The RondoDox Shift

RondoDox is a Linux botnet family first identified by FortiGuard Labs in September 2024 and documented more broadly through 2025. Early activity focused on exploiting internet-exposed DVRs and routers to recruit devices into a DDoS-capable botnet.

What’s changed is that the campaign increasingly behaves like an exploitation and delivery pipeline: compromise widely, fingerprint hosts quickly, then deploy whatever payload best matches the operator’s goals.

What makes it stand out is scale and adaptability:

Operational phasing: CloudSEK describes a progression from reconnaissance/testing → automated exploitation → broad IoT botnet deployment across 2025.
Exploit “shotgun” model: Trend Micro/ZDI observed RondoDox exploiting 50+ vulnerabilities across 30+ vendors, reflecting a volume-first strategy rather than a single vulnerability propagation chain.
Scaled further in v2: Later reporting on RondoDox v2 describes 75+ distinct exploit payloads fired in rapid succession, showing that exploit coverage keeps expanding over time.
Rapid adoption of new server-side CVEs: reporting links activity to XWiki RCE (CVE-2025-24893) in November and React2Shell (CVE-2025-55182) exploitation against Next.js servers in December.

RondoDox is best understood as a scalable exploitation framework, not just “a botnet with a couple of bugs.” The advantage is operational: keep probing, keep enrolling, keep refreshing exploit coverage, then opportunistically jump to whichever enterprise CVE is drawing the most exploitation activity.

That kind of volume-first model only works if the backend can keep up. When you’re firing dozens of exploits across many targets, you need infrastructure that can scan at scale, host staging content, and rotate delivery endpoints quickly when they get burned.

The infrastructure layer that makes the “pipeline” durable

That pipeline depends on more than exploit coverage; it also depends on churn-friendly infrastructure. Mapping tied to the broader RondoDox delivery ecosystem suggests a constellation pattern: an enabling transit/backbone layer with multiple downstream abuse-tolerant hosting lanes used for scanning, staging, and distribution, plus parallel capacity that helps operations survive takedowns and blocklists.

The practical takeaway is simple: RondoDox can lose nodes and still keep operating, because staging and delivery endpoints are designed to rotate. That’s why IOC-only defense tends to decay quickly here; detection improves when you combine IOCs with behavioral signals (scanning bursts, repeated staging patterns, short-lived nodes) and contextual enrichment (infra clustering by ASN/provider patterns). Importantly, an ASN is not proof of “RondoDox infrastructure” on its own. These networks are better treated as reusable hosting lanes that operators can rent and repurpose to stand up, move, and rebuild staging and delivery endpoints quickly.

Representative infrastructure artifacts

Transit/backbone overlap (enabler): AS401110 (Sovy Cloud Services)
Core hosting cluster (recent activity): AS401120 (Cheapy-Host / cheapy.host)
- Representative /24s: 196.251.70.0/24, 196.251.71.0/24, 196.251.72.0/24
Additional lanes observed in the same constellation: AS401116 (Nybula), AS401115 (EKABI), AS401109 (Zhongguancun)
Parallel spillover capacity (outside core): AS270824 (ENX, Brazil), AS208220 (Offerhost, Seychelles), AS210848 (Telkom Internet, Seychelles)

With infrastructure optimized for churn, the first stage must be equally disposable. That’s where RondoDox’s lightweight shell-based loader fits: it bridges initial access into a portable delivery step that can quickly fetch the “right” payload for the host’s CPU architecture.

Parallel spillover capacity (outside core): AS270824 (ENX, Brazil), AS208220 (Offerhost, Seychelles), AS210848 (Telkom Internet, Seychelles)

With infrastructure built for churn, the next piece fits naturally: a lightweight first-stage that’s easy to redeploy and designed to bridge initial access into whatever payload is most profitable.

Infection chain

The “shell loader” is the workhorse

RondoDox typically relies on a lightweight shell-based loader as the main delivery mechanism. While infrastructure keeps the operation resilient, the shell loader makes the infection portable and scalable across Linux environments.

Key Behaviors Observed

Environment preparation and CPU architecture detection
Identifies the host architecture and retrieves the correct ELF payload variant.
Competitive displacement
Terminates and/or removes other malware or botnet processes to reduce contention.
Persistence enforcement and host “hygiene”
Uses aggressive process-killing and recurring checks in some chains to maintain control and stability.
Multi-architecture payload staging and execution
Stages the appropriate payload, executes it, and may perform cleanup to reduce artifacts.

The loader first approach is what enables scale: keep the initial intrusion disposable, then swap payloads based on what the operator wants to achieve on that host.

Main Payload — What the Bot Can Do

Static analysis indicates the RondoDox main payload is a Linux backdoor/bot agent designed for flexible capability delivery, C2-controlled operations, and long-term persistence.

Notable Capability Themes

1) Modular design

Uses a plug-in style structure rather than a single linear program flow.
Core functions are connected through function-pointer registries and dispatch tables, making analysis harder and allowing features to be swapped/extended.
CloudSEK’s reporting around React2Shell also points to multi-stage components (loader/health-checker).

2) C2-driven tasking with extensible handlers

Performs periodic C2 check-ins to receive instructions.
Uses a task routing model:

receive task → map to handler/capability → execute → return output

Handler-based structure suggests the bot can support new command types with minimal changes.

3) Persistence and stealth primitives

Built for durability and reduced visibility.
Includes multiple persistence options and masquerading behaviors (e.g., deceptive process/service naming).
Uses encoded/obfuscated strings to hinder static detection and reverse engineering.