InfoSec Briefing - August 26, 2026

🎧 Audio Briefing

Playback Speed:

Security news from the BlueTeamSec community for Wednesday the 26th of August 2026, with ten stories to get through.

The DFIR Report has published the first part of a detailed write-up on BengalSEO, a financially motivated group based in Rajasthan that's been running SEO poisoning campaigns since 2015. They're targeting consumers searching for software support, using keyword stuffing and dynamic evasion techniques to funnel victims into tech support scams and malware drops. Worth reading if you're tracking the mechanics of large-scale scam infrastructure.

VulnCheck has written up the technical detail behind a critical SharePoint remote code execution flaw patched in the August Cumulative Update. The vulnerability lets attackers upload malicious files that trigger unsafe type instantiation, giving them code execution on the server. One for SharePoint admins who haven't yet applied this month's patches.

A piece from Ananda Dhakal explores how large language models have changed vulnerability research workflows, shifting the work from manual code review to AI orchestration and validation. The argument is that professionals now face a choice: specialise in infrastructure that validates AI output, or focus on novel vulnerability classes that still require human expertise. Particularly relevant if you're thinking about where security research is headed.

David Adrian's published a short essay arguing that the industry is stuck in an unsustainable reactive patching loop. The piece advocates shifting toward systems with enforced invariants and inherent robustness, rather than playing detective after the fact. He notes that AI has made vulnerability discovery cheaper, but risks accelerating the same ineffective cycle unless teams adopt proactive architectures.

AlloySecureGroup has released MADHATTER, a research tool for studying adversarial attacks against Qwen-based language models. It uses gradient-guided token perturbations to bypass safety mechanisms, and the tool can help researchers distinguish vulnerabilities in base models from those introduced through fine-tuning. One for offensive AI researchers or defenders testing AI-driven agents.

A Beacon Object File implementation of DNS server remote code execution has been published by a researcher going by Paradoxis. The tool exploits the ServerLevelPluginDll functionality in Microsoft DNS to escalate to SYSTEM on Domain Controllers, and requires DnsAdmins group membership. We covered a couple of similar BOF projects last week, so this fits into a wider pattern of tooling for post-compromise pivoting.

Researchers have broken Rhysida ransomware without paying the ransom, thanks to a cryptographic flaw in how the malware seeds its random number generator. The ransomware uses predictable system time to generate encryption keys, which allows brute-force recovery of the master key from the encrypted blob appended to files. Useful if you're responding to Rhysida incidents or tracking ransomware tradecraft failures.

A debugger prototype called GhostDebug has been released, designed to evade anti-debugging checks in malware and protected applications. It uses stealth hooks to bypass detection mechanisms like hardware breakpoint checks and the IsDebuggerPresent API. One for reverse engineers working with evasive samples.

Dominik Reichel has written up SLEEPWALKER, a passive backdoor that sits dormant in memory until activated by a magic trigger packet, then executes encrypted bytecode commands. It targets ESET Management Agent endpoints through DLL side-loading and employs its own command language for post-compromise operations. Notable for the degree of stealth involved, particularly the lack of network activity while dormant.

And finally, Datadog Security Labs has published detection primitives for eBPF rootkits, covering three families that manipulate kernel introspection to evade detection tools. The malware overwrites user-space memory, forces deceptive kernel return values, and crashes debugging utilities to stay hidden from standard security tooling. Particularly relevant if you're defending Linux environments or tracking rootkit evolution.

That's everything for today. The articles are the work of their original authors — the analysis here was automated.

📰 Articles Covered

BengalSEO Part 1: Anatomy of the Operation - The DFIR Report

This report summarizes the "BengalSEO" operation, a long-standing and sophisticated threat actor identified by The DFIR Report.

### Overview of BengalSEO
BengalSEO is an actor group based in Rajasthan, India, that has been active since at least 2015 【1】. The group is financially motivated, utilizing SEO poisoning to lure victims into either installing malware or participating in tech support scams 【1】.

### Who is Affected
The campaign targets a broad consumer base searching for software and online service support. Since 2020, the group has expanded its focus across five primary categories 【1】:
* **Tax software/support**
* **Antivirus software/support**
* **Gaming software/support**
* **Streaming service activation/support**
* **Activation for credit, healthcare, and gift cards**

### Technical Details
* **Infrastructure & SEO Manipulation:** The group uses a massive network of lure pages that mimic legitimate brand portals. They employ keyword stuffing and submit sitemaps to webmaster tools to ensure high search engine rankings 【1】.
* **Evasion Techniques:** To bypass duplicate content penalties and spam filters, they use a dynamic JavaScript function that randomizes the Document Object Model (DOM) of their pages based on the current month 【1】.
* **Traffic Distribution System (TDS):** A sophisticated TDS manages traffic, cloaking, and campaign performance, utilizing Matomo analytics for victim fingerprinting 【1】.
* **Malware (MayaBot):** In use since 2022, MayaBot is custom malware delivered via a ZIP file containing a JavaScript dropper that masquerades as an `.exe` and executes via `wscript.exe` 【1】.

### Security Implications
The operation represents a dual threat: the deployment of persistent malware (MayaBot) and high-touch social engineering through telephone-based scams. Their ability to maintain high SEO rankings and evade automated detection allows them to operate at scale, posing a significant risk to consumers who trust search engine results for technical support.

### What Defenders Should Know
* **Indicators of Compromise (IOCs):** The DFIR Report provides an extensive list of infrastructure and IOCs to monitor, which can be found in their [GitHub repository](https://github.com/The-DFIR-Report/DFIR-Report-Indicators/blob/main/2026-08-24-bengalseo-part-1-anatomy-of-the-operation.md) 【1】.
* **Detection Strategy:** Organizations should monitor for suspicious `wscript.exe` activity stemming from downloaded files. Defenders should also educate users on the risks of clicking on "support" links in search results, particularly for the categories mentioned above.
* **Backlink Spam:** Note that the actors generate backlinks at scale using user-generated content (UGC) spam in forums and blogs; identifying this activity may help in preemptive blocking of malicious domains 【1】.
Exploiting SharePoint: CVE-2026-55040 and CVE-2026-63520 RCE Chain | Blog | VulnCheck - VulnCheck

CVE-2026-63520 is a critical Remote Code Execution (RCE) vulnerability affecting Microsoft SharePoint. Below is a detailed precis based on the technical analysis provided by VulnCheck.

### What Happened
The vulnerability resides within SharePoint’s Business Connectivity Services (BCS), a feature that allows SharePoint to connect to external data sources. An attacker can exploit this by uploading a malicious Business Data Connectivity Model (BDCM) file—an XML file used to define how SharePoint interacts with external systems—to a document library. By manipulating the model definition to reference specific unsafe .NET types and binding them to an automated "Finder" operation, an attacker can achieve arbitrary code execution on the server when that list is subsequently accessed.

### Who is Affected
Organizations running vulnerable versions of Microsoft SharePoint Server that have not been updated with the patches released in the August 2026 Cumulative Update (CU) are affected.

### Security Implications
This vulnerability allows unauthenticated or low-privileged users (depending on the environment configuration) to achieve full Remote Code Execution on the SharePoint server. This level of access grants an attacker the ability to execute arbitrary commands, compromise sensitive data, potentially move laterally within the network, or establish persistent access to the server infrastructure.

### Technical Details
* **Root Cause:** The flaw stems from unsafe .NET type instantiation within the `GetEntityObject` function in `DotNetAssemblyConnectionManager.cs`. The application takes a `Class` property from a BDC model, resolves it as a .NET type, and calls `Activator.CreateInstance` on that type without sufficient validation 【1】.
* **The Exploit Mechanism:**
* The attacker defines a `LobSystem` of type `DotNetAssembly` within a malicious BDCM XML file.
* They specify an unsafe class (e.g., `System.Web.UI.LosFormatter`) designed to trigger deserialization of malicious input.
* This is bound to a "Finder" operation—a method SharePoint automatically calls to fetch entity rows when an external list is viewed.
* When the list is accessed, the "Finder" triggers the `Deserialize` method, passing the malicious gadget as an argument and resulting in code execution 【1】.

### What Defenders Should Know
* **Remediation:** The primary defense is to apply the August 2026 Cumulative Update (CU) for SharePoint.
* **Security Mechanism:** Microsoft introduced a new function, `ValidateSafeBcsType`, within the BCS infrastructure to address the issue 【1】.
* **Allow Listing:** Post-patch, SharePoint enforces an allow list via the `BCSAllowedTypeNames` configuration. Only .NET types explicitly defined in this list are permitted for use in BCS models; all others are blocked to prevent unsafe type instantiation 【1】.
More Criticals, Less Dopamine - Ananda Dhakal

The article "More Criticals, Less Dopamine" by Ananda Dhakal explores how Large Language Models (LLMs) have fundamentally transformed the workflow of security researchers and vulnerability discovery. Rather than a report on a specific security incident, it is a reflective analysis on the evolution of the cybersecurity profession in the age of AI.

### Precis

| Category | Details |
| :--- | :--- |
| **What Happened** | The standard methodology for security research is shifting from manual, deep-dive code analysis to AI-assisted workflows. LLMs now perform much of the initial triage, path identification, and even Proof of Concept (PoC) generation, drastically changing the day-to-day tasks of security professionals. |
| **Who is Affected** | Security researchers, bug bounty hunters, and application security professionals. The industry is moving away from purely manual "code-reading" tasks toward roles that prioritize AI-orchestration and higher-level strategic research. |
| **Security Implications** | The barrier to finding vulnerabilities has lowered, effectively raising the "floor" for everyone. This means that common, low-hanging fruit vulnerabilities are likely to be discovered and reported much faster, potentially leading to a higher volume of vulnerability reports and a shift in the nature of "critical" findings. |
| **Technical Details** | Researchers increasingly use LLMs to analyze codebases and generate PoCs, which are then validated externally. The focus is shifting toward the supporting infrastructure: creating harnesses, building orchestration layers, and designing robust automated validation pipelines to verify the outputs of the models. |
| **What Defenders Should Know** | The era of relying solely on manual expertise is evolving. Professionals should consider specializing in one of two directions: **The Super Engineer** (building the infrastructure, orchestration, and validation pipelines required to leverage AI) or **The Super Researcher** (focusing on complex, novel vulnerability classes and the intersection of AI and security). |

***

### Conclusion
The author emphasizes that the "dopamine" hit from manual discovery is being replaced by a more systemic approach to security. Success in the current landscape depends less on individual manual effort and more on the ability to build and manage automated systems that can effectively harness the intelligence provided by AI models 【1】.
Playing whack-a-mole is losing - David Adrian

The article "Whack-a-Mole is Losing" by Dan Amodio argues that the cybersecurity industry is currently trapped in a reactive, unsustainable cycle of vulnerability management. Rather than viewing security as a series of problems to be solved by "detective" work, it advocates for a shift toward building systems that are fundamentally robust.

Here is the precis of the article:

### What Happened
The author identifies that many security teams prioritize "whack-a-mole"—a reactive process of finding and patching individual vulnerabilities as they appear. While this approach is popular because it produces easily measurable metrics (e.g., number of incidents resolved, time-to-resolution), the author argues it is a failing strategy. Every "mole" patched is an opportunity already missed, and the reactive nature of this work fails to prevent the underlying classes of vulnerabilities from recurring.

### Who is Affected
The critique primarily targets security professionals and engineering organizations. The author specifically contrasts two types of security practitioners:
* **"Security as Identity" (The Hackers):** Practitioners who define their professional identity around being clever "detectives" who find insights others miss. Their worldview is rooted in an edgy, counterculture persona.
* **"Security as Robustness" (The Builders):** Practitioners motivated by building correct, resilient systems that maintain their intended properties even during failures or attacks.

### Security Implications
* **The Trap of Reactive Metrics:** Relying on incident resolution metrics can create the illusion of success while the actual security of the system remains stagnant or declines.
* **Ineffectiveness of VRPs:** Vulnerability Reward Programs (VRPs), when used as the primary strategy, are inherently "interrupt-driven" and unmanaged. They force teams to play catch-up rather than allowing them to drive the security roadmap.
* **AI and Escalation:** While AI has made vulnerability discovery cheaper than ever, it also accelerates the "whack-a-mole" cycle. If security teams only use AI to find more bugs, they remain stuck in the same reactive loop.

### Technical Details
* **The Invariant-Based Approach:** A vulnerability is identified as evidence that a system invariant is missing, incorrect, or unenforced.
* **Systemic Remediation:** Instead of patching individual bugs, defenders should implement invariants through code, interfaces, and safe abstractions. These should be enforced in CI/CD pipelines using tools like static analysis or simple `grep`-based checks.
* **Class-Based Reduction:** The goal should not be to count bugs, but to track the incidence of specific *classes* of bugs over time. Success is defined as driving the frequency of these classes toward zero.

### What Defenders Should Know
* **Shift Focus:** Defenders must move from searching for "bad" behavior (reactive) to enforcing "good" behavior (proactive).
* **Define Invariants:** Start by defining what should be true about the system. If an invariant is broken, it is a failure, regardless of whether an attacker was involved.
* **Strategic Engineering:** Successful security teams intervene in engineering roadmaps to build systems that prevent entire classes of vulnerabilities from being possible in the first place.
* **AI for Enforcement:** Use AI not just for bug discovery, but to help implement and enforce the system's invariants, allowing non-security engineers to produce more verifiable, secure code.
* **Overcoming Identity:** The author warns that resistance to these changes often stems from an identity crisis; if one’s professional worth is tied to "finding bugs," building systems that prevent bugs may feel like a loss. Defenders must prioritize actual security outcomes over their personal detective personas.
MADHATTER: Gradient-Guided Token Perturbation for Qwen - MadHatter can be used as a defensive disruption layer against an offensive Qwen-based AI agent by introducing small, targeted token changes - AlloySecureGroup

MADHATTER is an open-source research laboratory environment developed by AlloySecureGroup, designed for the study of adversarial attacks against Large Language Models (LLMs), specifically focusing on the Qwen architecture. It serves as a testing platform for understanding how gradient-guided perturbations impact model behavior when subjected to different training configurations.

### What Happened
The repository was released as a research tool to simulate and investigate how malicious actors might attempt to bypass model safety through gradient-based adversarial attacks. It provides a structured environment to create, test, and analyze the effectiveness of these attacks on both base models and models modified via Low-Rank Adaptation (LoRA).

### Who Is Affected
The research is primarily relevant to:
* **LLM Developers and Researchers:** Those building and fine-tuning models who need to understand potential vulnerabilities in their deployment pipelines.
* **AI Security Teams:** Professionals tasked with red-teaming and fortifying LLM deployments against input manipulation.
* **Organizations using Qwen-based architectures:** While the tool defaults to `Qwen/Qwen3-0.6B`, the methodology is applicable to any Hugging Face compatible model.

### Security Implications
* **Transferability:** The project enables users to differentiate between "universal" adversarial perturbations (which affect the base model) and "targeted" perturbations (which are specific to a particular LoRA adapter). This allows for a deeper understanding of whether a vulnerability is inherent to the core model weights or introduced during the fine-tuning process.
* **Robustness Gaps:** It highlights that simple fine-tuning or adding adapters without security considerations may introduce new, exploitable sensitivities that were not present in the original base model.

### Technical Details
* **Attack Methodology:** It uses a white-box "HotFlip-style" search technique. It approximates gradients to find optimal token perturbations, calculating scores via `score(i, j) ≈ grad(E_i) · (E_j - E_i)`. These candidates are then verified against actual token IDs to ensure the final output is a discrete sequence of tokens rather than a theoretical embedding space manipulation.
* **Infrastructure:** The system is containerized, running two Docker services—a "lab" instance for attack generation/training and a "clean" instance for verification—to ensure scientific isolation during testing.
* **Resource Requirements:** Because it requires loading two full model instances simultaneously, it has significant VRAM requirements, though it provides CPU fallbacks for constrained environments.

### What Defenders Should Know
* **Validation is Key:** Attackers may generate perturbations that work in an embedding space but fail in practice due to tokenization round-trip issues. Defenders should always validate defenses using both raw text and exact `input_ids`.
* **Adversarial Training:** The project explicitly includes a "robust" LoRA training objective, demonstrating that it is possible to train adapters specifically designed to suppress these types of perturbation-induced deviations.
* **Isolation in Testing:** To accurately assess a model's vulnerability, defensive testing must be performed in isolated environments, comparing the behavior of the "hardened" model against a "clean" baseline.
DNSRPC-BOF: Beacon Object File (BOF) implementation of the dnscmd.exe functionality used to obtain remote code execution on an ADIDNS server by using MS-DNSP. - Paradoxis

The **DNSRPC-BOF** project is a security tool implemented as a Beacon Object File (BOF) designed to facilitate remote code execution (RCE) on Active Directory Integrated DNS (ADIDNS) servers 【1】. It provides a way for attackers to leverage the `DnsAdmins` group membership to escalate privileges within a Windows domain environment.

### What Happened & Who Is Affected
The project provides an automated, stealthy method for attackers to exploit the `ServerLevelPluginDll` functionality of the Microsoft DNS service.
* **Target:** Organizations running Active Directory Domain Services (AD DS) with ADIDNS enabled.
* **Requirement:** An attacker must have already compromised a user account that is a member of the **`DnsAdmins`** security group 【1】.

### Security Implications
Successful exploitation allows an attacker to execute arbitrary code on a Domain Controller (DC) with high privileges (typically `SYSTEM` level, as the DNS service runs as such). Because this allows for full control over a Domain Controller, it is a critical escalation vector in Active Directory environments.

The project also carries a significant risk of self-inflicted denial-of-service (DoS) if the malicious DLL payload is inaccessible to the DC, which can prevent the DNS service from starting and potentially impact the entire domain's name resolution capabilities 【1】.

### Technical Details
* **Mechanism:** The tool uses the MS-DNSP protocol to interact with the DNS server. It sets the `ServerLevelPluginDll` registry value to point to a malicious DLL. Upon restarting the DNS service, the server loads this DLL, leading to code execution 【1】.
* **Implementation:** As BOFs do not natively support C exceptions, the tool hooks `RtlRaiseException` to manage flow control during RPC calls, as Microsoft's RPC implementation relies heavily on `RpcTryExcept` 【1】.
* **Tool Capabilities:**
* `dnsrpc_probe`: Verifies if the ADIDNS server is responsive.
* `dnsrpc_info`: Retrieves current ADIDNS server settings.
* `dnsrpc_coerce_write`: Tests network connectivity to a share to ensure the DC can reach the payload DLL before triggering the exploit.
* `dnsrpc_set_plugin_dll`: Configures the server to load the target DLL.
* `dnsrpc_restart_server`: Triggers a service restart (causing approximately two minutes of DNS downtime) to load the DLL.
* `dnsrpc_cleanup`: Cleans up registry artifacts after the operation 【1】.

### What Defenders Should Know
* **Monitor `DnsAdmins` Membership:** Regularly audit the `DnsAdmins` group. Members of this group have the potential to compromise the entire domain.
* **Watch for DNS Service Restarts:** Unexpected or frequent restarts of the DNS service, especially those followed by unusual network traffic or unauthorized file access (e.g., to an external network share from a DC), may indicate abuse.
* **Registry Monitoring:** Monitor for changes to the `ServerLevelPluginDll` registry value on Domain Controllers.
* **Testing Caution:** The tool itself includes a "coerce" function to test connectivity, demonstrating that attackers may test their payload reachability before executing the full attack. Defenders should look for anomalous SMB/network traffic initiated by domain controllers.
Time as a Key: Breaking Rhysida Ransomware with the Attacker's Own Ciphertext - Adam Taguirov

The paper *"Time as a Key: Breaking Rhysida Ransomware with the Attacker’s Own Ciphertext"* details a critical cryptographic vulnerability discovered in the Rhysida ransomware family, which allows for the decryption of affected files without paying the ransom 【1】.

### What Happened
Researchers discovered that the Rhysida ransomware uses a flawed implementation for its encryption key generation. Specifically, the ransomware seeds its Pseudo-Random Number Generator (PRNG) using the current system time (`srand(time(0))`) 【1】. Because the PRNG is predictable and seeded with a coarse timestamp, attackers can brute-force the seeds to reconstruct the encryption keys.

### Who is Affected
Organizations or individuals targeted by the Rhysida ransomware family are potentially affected. Because the vulnerability relies on predictable seeding, it is highly likely that any files encrypted by versions of Rhysida using this implementation are decryptable.

### Security Implications
The primary implication is that the ransomware’s security model is fundamentally broken. By turning the encrypted data (the "blob" appended to files) into an "oracle" for guessed keys, defenders can verify if a guessed key is correct offline, rendering the encryption effectively useless against an adversary with the necessary technical resources to perform the search 【1】.

### Technical Details
* **PRNG Weakness:** The ransomware uses `time(0)` as the seed for its PRNG.
* **RSA Wrap Vulnerability:** The seed used for the OAEP (Optimal Asymmetric Encryption Padding) in the RSA-wrapped key is drawn from the same flawed PRNG.
* **Key Confirmation Oracle:** The blob appended to every encrypted file allows for an offline "key-confirmation test." By brute-forcing the possible timestamps, a defender can identify the correct seed used during the encryption process and subsequently recover the master key 【1】.

### What Defenders Should Know
* **Recovery Potential:** If your organization has been affected by Rhysida, do not assume data loss is permanent. There is a documented path for recovering encrypted files by exploiting the cryptographic flaws in the ransomware's implementation 【2】.
* **Technical Consultation:** Recovering files using this method requires specialized technical know-how and hardware resources to execute the search efficiently 【3】. Affected entities should seek assistance from professional cybersecurity firms or organizations that specialize in ransomware recovery, as they may have the tools and expertise to apply these findings.
ghostdebug: Debugger utilizing stealth hooks to hide from debugger detection - VollRagm

GhostDebug is a specialized Windows x64 debugger prototype designed to circumvent debugger-detection techniques often employed by malware or protected applications 【1】. Rather than a malicious exploit, it is a development project created to explore the mechanics of "undetected" debugging 【1】.

### What Happened
The project was created by the developer VollRagm to research and implement techniques that allow for the debugging of processes that typically detect and terminate when under the observation of standard debugging tools. The project is documented in its GitHub repository and accompanied by a blog post detailing the design process.

### Who is Affected
The project is a tool for security researchers, reverse engineers, and malware analysts. It does not "affect" users in the traditional sense, but it does target software that uses anti-debugging protection mechanisms (e.g., checks for `IsDebuggerPresent` or Hardware Breakpoints) 【1】.

### Security Implications
GhostDebug highlights the ongoing cat-and-mouse game between software protection (anti-debugging) and analysis tools.
* **Stealth Analysis:** By using Vectored Exception Handling (VEH) or other stealth techniques mentioned in the author's blog, it attempts to operate without triggering common indicators that traditional debuggers (like x64dbg or WinDbg) often leave behind.
* **Research Value:** It serves as a pedagogical tool for understanding how anti-debugging checks work and how they can be subverted by custom-built debugger engines.

### Technical Details
GhostDebug is built as a modular system 【1】:
* **Architecture:** It consists of a native C++ DLL (`ghostdebug-core.dll`) which handles the low-level debugging operations, paired with a .NET Framework 4.8 command-line interface (CLI) for user interaction 【1】.
* **Capabilities:** It provides essential debugging primitives including:
* Process attachment (by PID or name).
* Breakpoint management (including automated command execution upon hitting a breakpoint, e.g., `bp 1234 rw rax 0;g`).
* Memory and register modification (e.g., `rw <register> <value>`).
* Instruction stepping and process resumption 【1】.
* **Address Referencing:** It supports flexible address resolution, including absolute addresses, offsets from module bases (e.g., `ntdll+1234`), and symbol names (e.g., `kernel32!ExitProcess`) 【1】.

### What Defenders Should Know
* **Environment Constraints:** The tool requires an x64 Windows environment and strict adherence to directory structure; the CLI must be run from the same folder as the core DLL, and both the target and the CLI must share the same x64 architecture 【1】.
* **Detection Challenges:** If an adversary were to use or adapt techniques found in this prototype, they could potentially bypass basic anti-debugging checks that monitor for common Windows API-based debugger detection. Defenders should focus on more advanced heuristic and behavioral analysis—such as monitoring for unexpected exceptions, timing-based detection, or unusual memory integrity checks—rather than relying solely on standard API flags like `BeingDebugged` in the Process Environment Block (PEB).
SLEEPWALKER: A Passive Backdoor With Its Own Command Language - Dominik Reichel

The discovery of "SLEEPWALKER" highlights a sophisticated, passive backdoor designed for stealth and evasiveness. Below is a detailed precis of the malware based on the analysis.

### What Happened
An analyst discovered a novel, passive backdoor named SLEEPWALKER that avoids conventional detection methods. Unlike typical malware that communicates with a Command-and-Control (C2) server, SLEEPWALKER remains dormant in memory, performing no network activity until it detects a specifically crafted "magic" trigger packet. Upon activation, it can interpret encrypted bytecode to execute arbitrary tasks 【1】.

### Who Is Affected
The malware specifically targets endpoints utilizing the ESET Management Agent. It is designed to be side-loaded into the legitimate process `ERAAgent.exe` by impersonating Microsoft’s `dpapi.dll`. It enforces its operation by checking the host process name, ensuring it only triggers when running within the ESET agent environment 【1】.

### Security Implications
The backdoor’s design makes it exceptionally difficult to detect and block:
* **Passive Nature:** It does not open listening ports or initiate outbound connections, rendering standard network-based C2 detection ineffective.
* **Covert Transport:** Commands are delivered through various stealthy channels, including TCP, UDP, ICMP, SMB named pipes, VMware VMCI, and DNS queries.
* **In-Memory Execution:** It supports a custom bytecode-based language that facilitates the in-memory execution of arbitrary shellcode, minimizing footprint.
* **Persistent Security Weakening:** To facilitate its operation, the malware modifies local Windows security configurations, specifically enabling anonymous SMB access 【1】.

### Technical Details
* **Initialization:** SLEEPWALKER validates that the host process is `ERAAgent.exe` before activating.
* **Command Language:** It features a custom interpreter with 23 unique opcodes used to process tasks.
* **Payload Verification:** It employs AES-256-CCM for encrypted command delivery and uses SHA-256 verification for staged payloads.
* **Infrastructure:** The malware contains no hard-coded domains or IP addresses, as it relies on passive network sniffing for commands 【1】.

### What Defenders Should Know
Because traditional indicators of compromise (IoCs) like C2 IP addresses do not apply, defenders must look for local artifacts and configuration changes:
* **File Anomalies:** Inspect the directory containing `ERAAgent.exe` for the presence of an illegitimate `dpapi.dll` or `dpapisvc.dll`.
* **Configuration Indicators:** Monitor the Windows registry for the `EveryoneIncludesAnonymous` setting (which should not be set to `1`) and review `NullSessionPipes` for unauthorized entries.
* **Detection Resources:** The analyst has provided YARA rules and a PowerShell scanning script, which are available in the appendix of the original article, to help identify infected endpoints 【1】.
Detection primitives for eBPF rootkits - Datadog Security Labs

The following precis details the emergence and operational mechanics of eBPF-based rootkits as outlined in the Datadog Security Labs report.

### **Overview**
Recent Linux malware has increasingly utilized eBPF (extended Berkeley Packet Filter) to build stealthy rootkits. By operating within the kernel, these programs manipulate system state and tamper with kernel introspection, allowing them to hide their own malicious activity and bypass traditional security monitoring tools that rely on standard interfaces like `ss`, `ptrace`, and `bpftool`.

### **Families and Technical Details**
The article highlights three prominent malware families that employ specific, high-risk eBPF helper functions to maintain persistence and stealth:

* **VoidLink:** Utilizes `bpf_probe_write_user()` to overwrite user-space memory. It intercepts and modifies Netlink messages to hide active network connections, effectively evading tools like `ss`.
* **LinkPro:** Employs `bpf_override_return()` to force kernel functions to return deceptive values (e.g., `-ENOENT`). By hooking `sys_enter_bpf`, it intercepts enumeration commands (like `BPF_PROG_GET_NEXT_ID`) and forces the kernel to report that the malware's programs do not exist, causing `bpftool` to truncate its list.
* **Atomic Arch:** Uses `bpf_send_signal(9)` (SIGKILL) to crash any process attempting to attach to hidden PIDs via `ptrace`. This ensures that debuggers or analysis tools (like `gdb` or `strace`) crash without explanation before they can interact with the malicious process.

### **Security Implications**
These rootkits represent a significant shift in stealth capabilities. By moving the "hiding logic" into the kernel's own execution path, attackers can make the operating system itself provide false information to security administrators. Because these tools intercept and alter data before it reaches user space—or cause security tools to crash before they can collect data—they defeat most modern detection tools that do not specifically account for kernel-level eBPF subversion.

### **Advice for Defenders**
The authors emphasize that detection must occur at **load time** (`BPF_PROG_LOAD`), when the eBPF program is being submitted to the kernel and before it has the opportunity to hook into system processes and begin its concealment logic.

* **Capture Load-Time Fingerprints:** Security sensors should extract and log the "helper bitmap" for every eBPF program during the `BPF_PROG_LOAD` syscall.
* **Implement High-Risk Helper Rules:** Alert on the use of dangerous helper functions, including `BPF_PROBE_WRITE_USER`, `BPF_OVERRIDE_RETURN`, and `BPF_SEND_SIGNAL` / `BPF_SEND_SIGNAL_THREAD`.
* **Correlate Signals:** Since legitimate tools may occasionally use these helpers, defenders should prioritize alerts where multiple high-risk helpers appear in a single program, or where such programs originate from suspicious loaders (e.g., interactive shells or world-writable directories).
* **Verify Discrepancies:** Defenders can occasionally spot inconsistencies by cross-referencing different enumeration methods (e.g., comparing `bpftool prog list` output against specific `BPF_PROG_GET_FD_BY_ID` calls, which certain hooks may miss).