Evasive DLL sideloading and C2 masking raise endpoint defense gaps

At a glance

What this is: Expel analyses a second-stage loader that uses DLL sideloading, scheduled-task persistence, indirect syscalls, and masked C2 to evade endpoint controls.

Why it matters: It matters because defenders need to treat signed binaries, DLL loading behavior, and outbound request patterns as governance points, especially where endpoint telemetry and TLS inspection can be bypassed.

Context

DLL sideloading is a technique where a legitimate executable loads an attacker-controlled library because of how the application searches for dependencies. In this case, the security problem is not simply malware execution but trust abuse inside a signed software chain, which makes conventional allowlisting and reputation checks less reliable.

The article also shows how endpoint evasion now blends execution, persistence, and network camouflage into one chain. That matters to identity and access teams because the same trust assumptions that protect legitimate software, service accounts, and managed endpoints can be turned into a delivery path for malicious code.

Key questions

Q: What breaks when a signed application can load an attacker-controlled DLL?

A: The trust model breaks at the dependency boundary. A signed executable can appear legitimate while loading malicious code from a writable location, so allowlisting the binary alone does not stop execution. Teams need to govern module loading, not just publisher reputation, because the malicious behavior is introduced through the library path rather than the original executable.

Q: Why do scheduled tasks and in-memory shellcode increase endpoint risk?

A: They separate persistence from payload visibility. The task keeps the malware returning after reboot, while shellcode loaded into memory avoids the durable file artifacts that many endpoint controls expect. That combination makes behavioural detection more important than file matching, because the most harmful stage may never exist as a visible on-disk sample.

Q: What are the signs that indirect syscalls are being used to bypass detection?

A: Look for processes that allocate executable memory, resolve native functions unusually, or jump into syscall instructions instead of using normal API paths. Those signals matter because indirect syscalls are designed to evade user-mode hooks, so standard function-level telemetry may show less than the process is actually doing.

Q: How should teams inspect HTTPs traffic that looks like normal browser activity?

A: Treat destination, request shape, and process context as a single decision. A browser-like user agent, ordinary path, or cookie field can still carry C2 if the request originates from an unexpected process or host. Teams should alert when network semantics do not match the application that generated them.

Technical breakdown

How DLL sideloading turns signed software into a loader

DLL sideloading works when a signed application loads a library from its own directory or another predictable location, instead of a protected system path. Attackers replace that library with a malicious one, so the trusted executable becomes the delivery vehicle even though its signature remains valid. In this case, the renamed Greenshot binary did not need to be modified to be abused. The abuse happened because the application trusted the local DLL resolution process. That makes the signed executable part of the attack surface, not a guarantee of safety.

Practical implication: treat signed binaries and their adjacent DLLs as a single trust boundary, not as separate assets.

Why staged loaders use scheduled tasks and in-memory shellcode

The second-stage loader creates persistence through a scheduled task, then decrypts shellcode into memory instead of dropping an obvious payload to disk. That combination reduces the value of simple file-based detection because the malicious code is transient, process-bound, and launched indirectly after reboot. Memory allocation, decryption, and execution happen inside the compromised process, which is why endpoint tools need behavioral visibility into process creation, task registration, and memory protection changes. This is a common pattern in evasive malware because it separates delivery from execution and hides the final stage behind ordinary operating-system features.

Practical implication: monitor scheduled-task creation and in-memory execution together, because either one alone gives an incomplete picture.

How indirect syscalls and cookie-based C2 bypass inspection

Indirect syscalls let malware avoid user-mode hooks by reusing native system-call instructions from ntdll rather than invoking hooked functions directly. That weakens EDR-style inline monitoring because the malware can allocate and run memory without taking the obvious API path defenders expect. The network side is equally deliberate: the sample disguises command traffic as a benign JQuery fetch and hides the real content inside a cookie field. That raises the burden on TLS inspection and proxy analytics, because the request can look ordinary unless defenders inspect context, destination, and payload structure together.

Practical implication: correlate endpoint API behavior with HTTP semantics, or each control can be individually bypassed.

Threat narrative

Attacker objective: The apparent objective is to maintain stealthy code execution and remote command capability on the compromised endpoint while avoiding detection long enough to deliver a final payload.

1. Entry occurs through a trojanized, digitally signed application that is delivered as part of the campaign’s second stage and masquerades as a FortiClient compliance checker.
2. Credential or trust abuse follows when the application loads a malicious replacement DLL, turning a legitimate executable into the loader for the malicious chain.
3. Escalation continues as the loader establishes scheduled-task persistence, decrypts shellcode into memory, and uses indirect syscalls to reduce EDR visibility.
4. Impact is delayed and obscured by HTTPs C2 that mimics a JQuery request while hiding commands in the cookie field, which makes command traffic harder to inspect.

Breaches seen in the wild

• CircleCI breach 2023: Malware stole a CircleCI engineer's SSO session; attackers exfiltrated customers' CI/CD secrets and keys, forcing a platform-wide rotation.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Signed-binary trust is now an attack path, not a protection layer. When defenders trust publisher signatures without also validating adjacent DLLs and load behavior, sideloading becomes a reliable abuse pattern. The weakness is not the signature itself but the assumption that a trusted executable cannot be made to load untrusted code. Practitioners should treat signed software ecosystems as identity-bound execution chains, not as static allowlist entries.

Persistence plus in-memory execution creates a governance blind spot. Scheduled tasks, memory decryption, and shellcode execution combine to push malicious activity outside the view of file-centric controls. That means endpoint governance has to account for how code is launched, where it lives, and how long it persists. The specific failure mode here is reliance on disk artifacts to explain an attack that is already living in memory.

Network deception is only effective when telemetry is evaluated in isolation. A request for a JQuery file can be harmless or malicious depending on the host, cookie structure, and preceding process behavior. This is where endpoint, proxy, and inspection data need to be joined into a single verdict path. Practitioners should assume that benign-looking web traffic can carry C2 until the process and destination context are reconciled.

Evasion tooling now targets the seams between controls. Indirect syscalls, signed binaries, and cookie-based C2 each weaken a different defensive assumption, but the campaign succeeds because they are combined into one chain. That is the broader lesson for endpoint programs: detection quality is limited by the weakest trust boundary in the chain. Practitioners should prioritise control overlap at the seams where EDR, application trust, and web inspection meet.

Process lineage is the named concept this campaign exposes. Security teams often watch what starts, but this threat shows why they also need to govern what a process is allowed to load, spawn, and persist through. A trustworthy binary can become untrustworthy the moment its lineage is redirected by a malicious library. Practitioners should make lineage and module-loading visibility a first-class control objective.

What this signals

Process lineage is the control gap most endpoint teams still underweight. A trusted binary that is allowed to load arbitrary local modules effectively becomes an execution bridge for an attacker, even when the original file remains signed. Endpoint programmes should therefore measure module-loading trust as carefully as they measure binary reputation.

Evasion now works by combining ordinary system features in abnormal sequences. Scheduled tasks, in-memory payload loading, and HTTPs C2 masking each look familiar on their own, but together they create a chain that defeats single-control thinking. Practitioners should expect the next wave of endpoint abuse to exploit control seams rather than obvious malware signatures.

For practitioners

• Audit DLL search-order exposure in signed applications Identify signed binaries that load libraries from writable or user-controlled directories, then restrict side-loaded module paths and verify dependency integrity.
• Monitor scheduled-task creation tied to unusual loaders Flag persistence tasks that point to recently extracted archives, renamed utilities, or binaries that are not normally launched by the environment.
• Correlate memory allocation with indirect syscall behavior Prioritise processes that allocate executable memory after decrypting embedded payloads and that avoid normal user-mode API call patterns.
• Inspect outbound requests for hidden C2 structure Review suspicious HTTPs sessions where benign-looking paths, browser-like headers, and cookie-bearing payloads do not match the application role or destination reputation.

Key takeaways

• The campaign shows how a trusted application, a malicious DLL, and staged in-memory execution can be chained into a stealthy endpoint compromise.
• The core defensive issue is not just malware detection, but trust in signed binaries, module loading, persistence, and web traffic interpretation.
• Endpoint teams need control overlap across process, memory, and network telemetry because any single layer can be made to look benign.

Key terms

• DLL Sideloading: A technique where a legitimate executable loads a malicious library from a location the application checks before the real system path. It works because the program’s trust is inherited by the code it loads, which makes execution control as important as file reputation.
• Indirect Syscall: An indirect syscall is a way of reaching kernel functionality without using a visibly hooked user-mode function entry point. Malware uses it to reduce the chance that endpoint products will intercept the call, making memory allocation, injection, and similar actions harder to detect.
• Scheduled-Task Persistence: A condition where an AI agent creates or modifies recurring automation that continues after the original interaction. It matters because a one-time injection can become durable influence, making later actions look legitimate even though the underlying instruction was attacker-shaped.
• Command and Control Masking: Command and control masking is the practice of making attacker communications look like normal web traffic or application activity. The goal is to blend into expected HTTPS patterns, hide payloads in benign fields, and frustrate network inspection and policy enforcement.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives security practitioners a structured way to connect identity controls to broader access and trust decisions.