InfoSec Briefing - June 03, 2026

🎧 Audio Briefing

Playback Speed:

Cyber security developments for Wednesday the 3rd of June 2026 covering articles added to the BlueTeamSec community on infosec.pub. Today we have 6 articles to cover. All attribution is by the article authors. All article analysis is automated.

Wiz, Socket, and StepSecurity all covered the Miasma supply chain attack, which compromised Red Hat's npm namespace through a hijacked employee GitHub account. Attackers pushed orphan commits that bypassed code review and triggered automated publishing workflows, injecting malicious code into 32 package releases with about 80,000 weekly downloads. The malicious preinstall scripts used multi-stage obfuscation to harvest credentials from developer workstations and CI pipelines. One for anyone running Red Hat Cloud Services packages in their build chain.

Sekoia documented new infection vectors from Gamaredon, the Russian threat actor targeting Ukrainian government and military infrastructure. The campaign deploys GammaWorm, a nearly fileless malware that hides modules in NTFS Alternate Data Streams and uses legitimate Windows features for command and control. Worth flagging if you're tracking Eastern European threat activity or defending critical infrastructure in the region.

A researcher published details on RedSun, a local privilege escalation vulnerability in Windows Defender's file remediation workflow. The flaw lets unprivileged users manipulate Defender's system-level file operations through junction points and opportunistic locks, achieving arbitrary writes to protected directories and eventually NT AUTHORITY SYSTEM privileges. Patched as CVE-2026-41091.

ETSI has published a technical standard under the EU Cyber Resilience Act defining mandatory security requirements for routers, modems, and switches intended for internet connection. The standard establishes baseline security controls for these network devices across the European market, which is relevant if you're involved in vendor selection or compliance for hardware deployments in the EU.

That concludes today's briefing.

📰 Articles Covered

Miasma: Supply Chain Attack Targeting RedHat npm Packages - Wiz

The "Miasma" supply chain attack, identified by Wiz Research on June 1, 2026, involved the compromise of the `@redhat-cloud-services` npm namespace. Attackers successfully injected malicious code into at least 32 package releases, which collectively average approximately 80,000 weekly downloads 【1】.

### What Happened
The attack was executed by compromising a specific Red Hat employee's GitHub account. The attacker used this access to push malicious orphan commits to two `RedHatInsights` repositories, effectively bypassing standard code review processes 【1】. These commits triggered a GitHub Actions workflow that requested an OIDC token for npm publishing and executed an obfuscated payload, resulting in the publication of malicious packages that included valid SLSA provenance attestations 【1】.

### Who Is Affected
Any organization or developer that downloaded or installed the compromised versions of the `@redhat-cloud-services` packages is potentially affected. A list of the specific compromised packages and versions is provided below:

| Package | Compromised Versions |
| :--- | :--- |
| `@redhat-cloud-services/topological-inventory-client` | 3.0.10, 3.0.11, 3.0.13 |
| `@redhat-cloud-services/compliance-client` | 4.0.3, 4.0.4, 4.0.6 |
| `@redhat-cloud-services/rbac-client` | 9.0.3, 9.0.4, 9.0.6 |
| `@redhat-cloud-services/insights-client` | 4.0.4, 4.0.5, 4.0.7 |
| `@redhat-cloud-services/frontend-components` | 7.7.2, 7.7.3, 7.7.5 |
| `@redhat-cloud-services/frontend-components-utilities` | 7.4.1, 7.4.2, 7.4.4 |
| `@redhat-cloud-services/remediations-client` | 4.0.4, 4.0.5, 4.0.7 |
| `@redhat-cloud-services/frontend-components-notifications` | 6.9.2, 6.9.3, 6.9.5 |
| `@redhat-cloud-services/patch-client` | 4.0.4, 4.0.5, 4.0.6 |
| `@redhat-cloud-services/host-inventory-client` | 5.0.3, 5.0.4, 5.0.6 |
| `@redhat-cloud-services/rule-components` | 4.7.2, 4.7.3, 4.7.5 |
| `@redhat-cloud-services/frontend-components-advisor-components` | 3.8.2, 3.8.3, 3.8.5 |
| `@redhat-cloud-services/notifications-client` | 6.1.4, 6.1.5, 6.1.7 |
| `@redhat-cloud-services/sources-client` | 3.0.10, 3.0.11, 3.0.13 |
| `@redhat-cloud-services/integrations-client` | 6.0.4, 6.0.5, 6.0.7 |
| `@redhat-cloud-services/frontend-components-config` | 6.11.3, 6.11.4, 6.11.6 |
| `@redhat-cloud-services/frontend-components-config-utilities` | 4.11.2, 4.11.3, 4.11.5 |
| `@redhat-cloud-services/hcc-pf-mcp` | 0.6.1, 0.6.2, 0.6.4 |
| `@redhat-cloud-services/frontend-components-remediations` | 4.9.2, 4.9.3, 4.9.5 |
| `@redhat-cloud-services/eslint-config-redhat-cloud-services` | 3.2.1, 3.2.2, 3.2.4 |
| `@redhat-cloud-services/javascript-clients-shared` | 2.0.8, 2.0.9, 2.0.11 |
| `@redhat-cloud-services/quickstarts-client` | 4.0.11, 4.0.12, 4.0.14 |
| `@redhat-cloud-services/config-manager-client` | 5.0.4, 5.0.5, 5.0.7 |
| `@redhat-cloud-services/hcc-feo-mcp` | 0.3.1, 0.3.2, 0.3.4 |
| `@redhat-cloud-services/entitlements-client` | 4.0.11, 4.0.12, 4.0.14 |
| `@redhat-cloud-services/tsc-transform-imports` | 1.2.2, 1.2.3, 1.2.5 |
| `@redhat-cloud-services/hcc-kessel-mcp` | 0.3.1, 0.3.2, 0.3.4 |
| `@redhat-cloud-services/frontend-components-testing` | 1.2.1, 1.2.2, 1.2.4 |
| `@redhat-cloud-services/types` | 3.6.1, 3.6.2, 3.6.4 |
| `@redhat-cloud-services/chrome` | 2.3.1 |
| `@redhat-cloud-services/frontend-components-translations` | 4.4.1 |
| `@redhat-cloud-services/vulnerabilities-client` | 2.1.8 |

### Security Implications
The malware is designed to harvest cloud identities, specifically targeting GCP and Azure environments to gain access to the cloud infrastructure itself 【1】. Because the malware targets developer credentials and secrets, organizations should assume that any GitHub tokens, SSH keys, cloud credentials, or CI/CD secrets present on infected machines have been exposed.

### Technical Details
* **Payload:** The malware uses installation-time execution mechanisms, specifically preinstall scripts that trigger a malicious `index.js` file 【1】.
* **Obfuscation:** The payload is heavily obfuscated using `eval()` and ROT-based decoding, and it generates a uniquely encrypted payload for each infection to hinder detection and version tracking 【1】【1】.
* **Origin:** The malware is derived from the "Mini Shai-Hulud" malware, with cosmetic changes replacing Dune-themed references with Greek mythology themes (e.g., "spartan") 【1】.

### What Defenders Should Know
* **Immediate Actions:** Investigate developer workstations, CI/CD environments, and repositories for signs of compromise. Audit systems for the affected packages, suspicious GitHub Actions, and unauthorized access tokens 【1】.
* **Credential Rotation:** Assume all secrets (GitHub tokens, SSH keys, cloud credentials) on potentially affected systems are compromised and rotate them immediately 【1】.
* **Supply Chain Hardening:** Strengthen defenses by implementing dependency allowlisting, SBOM generation, package verification, and enhanced monitoring of build environments 【1】.
* **Attribution:** While the tradecraft aligns with TeamPCP, the public availability of their tooling means this could be a copycat actor; similarities should be viewed as TTP overlap rather than definitive attribution 【1】.
Mini Shai-Hulud Campaign Hits Red Hat Cloud Services npm Packages - Socket

The "Mini-Shai-Hulud" campaign is a sophisticated supply-chain attack that targeted the npm ecosystem by compromising packages associated with Red Hat Cloud Services. The campaign is notable for its aggressive credential harvesting and its ability to execute malicious payloads during the installation phase of a package.

### What Happened
The attackers published malicious versions of legitimate `@redhat-cloud-services` npm packages. When these packages were installed—typically during `npm install` or within CI/CD pipelines—a `preinstall` lifecycle script triggered the execution of a malicious `index.js` file. This script acted as a downloader and executor for a secondary, more complex payload, which was designed to harvest sensitive information from the host environment.

### Who Is Affected
Any organization or developer that installed the compromised versions of the `@redhat-cloud-services` packages is potentially affected. Because the malicious code executes during the installation process, exposure is not limited to runtime use; it extends to any system where the package was installed, including:
* CI/CD pipelines (e.g., GitHub Actions).
* Developer workstations.
* Container build environments.
* Internal package caches.

### Security Implications
The primary goal of the campaign is credential theft. The malware is designed to exfiltrate a wide array of high-value secrets, including:
* **CI/CD Secrets:** GitHub tokens (`GITHUB_TOKEN`), npm publishing tokens, and cloud deployment credentials.
* **Cloud Credentials:** AWS, Azure, and Google Cloud Platform (GCP) access keys, session tokens, and configuration files.
* **Infrastructure Secrets:** Kubernetes service account tokens, Vault tokens, and Docker registry credentials.
* **Developer Secrets:** SSH keys, Git credentials, and local environment files (`.env`, `.npmrc`, etc.).

The malware also possesses persistence capabilities, potentially allowing attackers to maintain access to compromised systems even after the initial malicious package is removed.

### Technical Details
* **Execution Trigger:** The payload uses the `preinstall` npm lifecycle script to execute `node index.js`.
* **Payload Delivery:** The initial script downloads and executes further malicious code, often leveraging `bun` (a JavaScript runtime) to facilitate the extraction and execution of secondary payloads in temporary directories (e.g., `/tmp/b-*`).
* **Exfiltration:** The malware uses encrypted outbound data transfer to exfiltrate collected data. It also includes a fallback mechanism that writes encrypted results into GitHub repositories, using specific markers like `Miasma: The Spreading Blight`.
* **Indicators of Compromise (IoCs):**
* **Files/Paths:** `/tmp/p*.js`, `/tmp/b-*/b.zip`, `tmp.0987654321.lock`.
* **Commands:** `node index.js`, `bun run`, `curl -sSL`, `gh auth token`.
* **Strings:** `f4abccab2`, `thebeautifulmarchoftime`, `createDecipheriv("aes-128-gcm"`.

### What Defenders Should Know
* **Assume Compromise:** If an affected package was installed, treat the system as compromised. Simply deleting the package or `node_modules` is insufficient.
* **Rotate Everything:** Assume all credentials accessible to the environment where the package was installed have been stolen. This includes cloud keys, CI/CD tokens, and SSH keys.
* **Audit CI/CD:** Review CI/CD logs for suspicious activity, such as unexpected outbound network connections or the creation of new files/repositories.
* **Strengthen Controls:**
* Implement least-privilege for CI/CD tokens.
* Use dependency allowlisting and lockfile enforcement.
* Disable npm lifecycle scripts by default where possible.
* Monitor for unexpected network egress from build environments.
* **Verify Provenance:** Do not rely solely on provenance or "trusted publishing" as a complete security control, as this campaign demonstrated that malicious releases can be published through trusted upstream automation.
Multiple redhat-cloud-services npm Packages compromised - StepSecurity

This incident involved a sophisticated supply-chain attack targeting the Red Hat Cloud Services npm ecosystem. Attackers compromised multiple legitimate packages, turning them into vehicles for credential theft, persistence, and self-propagation.

### What Happened
Attackers injected malicious code into 30+ npm packages under the `@redhat-cloud-services` scope. The compromise was triggered automatically during the `npm install` process via a `preinstall` script. The payload utilized a multi-stage execution chain, including ROT-21 obfuscation, AES-128-GCM encrypted blobs, and custom B5 ciphering, to download and execute a secondary runtime (Bun) that performed the malicious activities.

### Who Is Affected
Developers and CI/CD pipelines that installed or updated these specific versions of Red Hat Cloud Services packages are affected. The list includes widely used components such as:
* `@redhat-cloud-services/types` (v3.6.1)
* `@redhat-cloud-services/frontend-components` (v7.7.2)
* `@redhat-cloud-services/rbac-client` (v9.0.3)
* `@redhat-cloud-services/chrome` (v2.3.1)

### Security Implications
The attack was designed for maximum impact, focusing on credential harvesting and long-term persistence:
* **Credential Theft:** The payload performed a comprehensive sweep of environment variables, configuration files, and SSH keys, targeting GitHub, AWS, GCP, Azure, HashiCorp Vault, Kubernetes, npm, PyPI, and Docker.
* **Secret Extraction:** It bypassed GitHub Actions log-masking by reading directly from the `Runner.Worker` process memory to extract secrets marked as `isSecret`.
* **Supply-Chain Worm:** Using harvested npm tokens, the malware attempted to publish backdoored versions of other packages, using the `bypass_2fa` parameter to circumvent security controls.
* **Persistence:** The malware established persistence on developer workstations by hijacking Claude Code sessions and injecting malicious tasks into VS Code configurations.
* **Covert Exfiltration:** Stolen data was exfiltrated via the GitHub Contents API, making the traffic appear as legitimate git operations.

### Technical Details
* **Entry Point:** A `preinstall` script in `package.json` executed a 4.2 MB `index.js` file.
* **Execution Chain:**
* **Stage 1:** `preinstall` triggers `node index.js`.
* **Stage 2:** ROT-21 decoding reveals two encrypted blobs.
* **Stage 3:** AES-128-GCM decryption extracts a Bun downloader and the main implant.
* **Stage 4:** The main implant uses `obfuscator.io` and a custom **B5 cipher** (PBKDF2-derived keys) to hide C2 communication and sensitive strings.
* **C2:** The malware used a "dead-drop" technique, routing exfiltrated data through `api.github.com` to evade network-level detection.

### What Defenders Should Know
* **Immediate Action:** Audit CI/CD logs and developer workstations for the presence of the identified malicious package versions.
* **Credential Rotation:** Assume all secrets present in environments where these packages were installed (GitHub tokens, cloud provider keys, SSH keys, etc.) are compromised and rotate them immediately.
* **CI/CD Hardening:** Implement strict egress filtering and monitor for unusual API calls to GitHub from CI runners.
* **Package Integrity:** Use tools to monitor for unexpected `preinstall` scripts in dependencies and consider pinning dependencies to known-good versions with hash verification.
* **Workstation Hygiene:** Inspect `~/.claude/settings.json` and `.vscode/tasks.json` for unauthorized hooks or tasks.
RedSun: Exploiting Windows Defender's Remediation Workflow for Local Privilege Escalation - blog.calif.io

The provided summary accurately captures the core aspects of the RedSun (CVE-2026-41091) vulnerability as detailed in the article. To ensure the precis is comprehensive, here is a consolidated overview based on the information provided:

### What Happened
RedSun (CVE-2026-41091) is a local privilege escalation (LPE) vulnerability affecting the file remediation workflow within Windows Defender. Discovered by Nightmare Eclipse, the flaw allows an unprivileged user to manipulate Defender's file operations, enabling arbitrary file writes into protected system directories (such as `C:\Windows\System32`) and ultimately achieving code execution with `NT AUTHORITY\SYSTEM` privileges 【1】.

### Who is Affected
Any Windows system running Windows Defender is susceptible to this exploit 【1】.

### Security Implications
This vulnerability constitutes a significant privilege boundary violation. By weaponizing the `SYSTEM`-privileged remediation process, a standard user can escalate their privileges to the highest level, granting them full control over the compromised machine 【1】.

### Technical Details
The exploit effectively turns Defender's remediation workflow into a powerful write primitive through the following mechanisms:
* **Root Cause:** The vulnerability exists because Defender performs file I/O operations with `SYSTEM` privileges on paths that are ultimately controlled by the user, without adequately validating that these paths have not been redirected via NTFS junction points or symbolic links 【1】.
* **Exploitation Chain:**
* **Triggering:** The attacker forces a scan of a malicious "bait" file.
* **Manipulation:** Using batch opportunistic locks (oplocks), the attacker freezes Defender’s operations at precise moments. This allows for the manipulation of the filesystem, such as swapping the bait file for a Cloud Files placeholder and establishing junction points 【1】.
* **Cloud Files API:** By registering a directory as a cloud sync root without hydration callbacks, the attacker ensures Defender's remediation workflow remains active and engaged 【1】.
* **Execution:** Once the arbitrary write is achieved in `System32`, the attacker plants a malicious binary and triggers a COM service (Storage Tiers Management) to execute it as `SYSTEM` 【1】.

### What Defenders Should Know
* **Deterministic Exploitation:** The use of batch oplocks makes this exploit highly reliable by transforming complex, non-deterministic race conditions into a controlled, deterministic timing window 【1】.
* **Defensive Insight:** This vulnerability underscores the inherent risks of performing privileged operations on user-controlled filesystem paths. Defenders should be aware that attackers can leverage advanced filesystem features—specifically NTFS junctions and Cloud Files placeholders—to redirect or manipulate these privileged workflows 【1】.
Cybersecurity (CYBER); Cyber Resilience Act (CRA); Cybersecurity requirements for routers, modems intended for the connection to the internet and switches - ETSI

Thank you for the detailed precis. I have noted the information provided regarding ETSI EN 304 627.

Since you have already provided a comprehensive summary of the document, I have no further questions at this time. If you need me to investigate specific clauses, annexes, or technical requirements within that document in the future, please let me know.
Gamaredon’s gifts that keeps unpacking - GammaPhish and GammaWorm - Sekoia.io

The recent report from Sekoia.io, titled "FSB’s matryoshka #1/3," details a sophisticated and evolving cyberespionage campaign conducted by the Russian-linked threat actor **Gamaredon** (also known as Primitive Bear) 【1】. This campaign focuses on long-term data exfiltration and espionage, primarily targeting Ukrainian government, military, and critical infrastructure entities 【2】【4】.

### What Happened
Gamaredon has introduced new initial access and infection vectors, dubbed **GammaPhish** and **GammaWorm**, as part of a multi-stage operation. The campaign is characterized by its "matryoshka" (nested) nature, where each layer of the infection chain reveals further malicious components designed to maintain stealth and persistence 【1】.

### Technical Details
* **GammaPhish:** This component serves as the initial access vector, utilizing phishing techniques to compromise targets 【1】.
* **GammaWorm:** A highly stealthy, nearly fileless worm. Instead of dropping traditional files on the disk, it hides its modules within **NTFS Alternate Data Streams (ADS)**—a native Windows feature that allows data to be stored alongside existing files without appearing in standard directory listings 【3】.
* **Infection Chain:** The operation leverages legitimate Windows features and cloud services for Command and Control (C2), making detection significantly more difficult 【2】.

### Security Implications
The primary implication is a significant increase in the stealth and persistence capabilities of Gamaredon. By utilizing fileless techniques and native Windows features like ADS, the attackers can evade traditional signature-based security solutions. The focus on espionage against sensitive Ukrainian sectors suggests a continued, high-priority effort to gather intelligence through long-term access 【2】【4】.

### What Defenders Should Know
* **Detection Challenges:** Standard file-based scanning may fail to detect the GammaWorm due to its reliance on NTFS Alternate Data Streams. Defenders should look for anomalous usage of ADS and monitor for suspicious processes interacting with these streams.
* **Behavioral Monitoring:** Because the campaign uses legitimate cloud services for C2 and native Windows features, defenders should prioritize behavioral analysis and network traffic monitoring to identify unauthorized communication patterns.
* **Phishing Awareness:** Given the role of GammaPhish, robust email security and user awareness training remain critical defenses against the initial entry point.
* **Continuous Vigilance:** This report is part of a series; defenders should anticipate further disclosures regarding loaders and other components of the Gamaredon toolkit as the "matryoshka" layers are further unpacked 【1】.