Evasive DLL sideloading and C2 masking raise endpoint defense gaps

At a glance

What this is: This is an endpoint malware analysis showing how a trojanised signed application, DLL sideloading, persistence, and C2 masking were chained to evade detection.

Why it matters: It matters to IAM and security teams because the same trust assumptions that protect legitimate software can be abused to execute code, persist, and hide command traffic inside normal business activity.

👉 Read Expel's analysis of evasive DLL sideloading and C2 masking

Context

Endpoint defenders increasingly face attacks that abuse legitimate software behaviour rather than obvious malicious files. In this case, the key gap is not a novel exploit chain so much as the reuse of trusted components, signed code, and ordinary network patterns to make malware look routine.

The identity intersection is indirect but real: once a trusted executable and its loaded components are abused, the environment is effectively treating malicious code as a legitimate workload. That makes application trust, process integrity, and privilege boundaries part of the same governance problem, which is typical of modern evasive malware rather than an edge case.

Key questions

Q: What breaks when DLL sideloading is possible in trusted software downloads?

A: DLL sideloading breaks the assumption that a trusted executable only runs trusted code. If an attacker can place a malicious library where the application looks first, the binary becomes a launch point for attacker-controlled execution inside a legitimate process context. Teams should watch for downloaded software in user-writable paths and treat nearby DLLs as part of the trust boundary.

Q: Why do signed binaries and portable apps increase endpoint risk?

A: They increase risk when security tools rely on binary reputation more than runtime behaviour. A signed executable can still be repurposed as a loader, and portable applications often run from user-controlled paths with looser control over dependencies. That combination gives attackers a credible execution vehicle without needing to introduce an obviously malicious file.

Q: How do security teams detect memory-resident malware that uses indirect syscalls?

A: They need telemetry that goes beyond user-mode hooks, including kernel-aware detection, process ancestry, suspicious memory allocation patterns, and unusual transitions from writable to executable memory. Indirect syscalls are designed to bypass inline instrumentation, so behavioural correlation is more reliable than a single endpoint alert.

Q: How should organisations respond when command traffic is hidden inside normal HTTPS requests?

A: They should correlate endpoint, proxy, and TLS metadata rather than relying on URL patterns alone. Requests that look like benign library fetches but carry unusual cookie payloads, mismatched user agents, or out-of-profile destinations should be investigated as possible covert channels. Network inspection must be paired with endpoint context.

Technical breakdown

DLL sideloading through a trusted signed executable

DLL sideloading occurs when an application loads a library from the local execution path and the attacker substitutes that library with a malicious one. Here, the executable remains signed and appears legitimate, while the DLL changes the behaviour of the application at runtime. That matters because many controls evaluate the parent binary more heavily than the dynamically loaded component. The loader can therefore inherit trust from a benign executable while executing attacker code through normal application flow.

Practical implication: inspect application load chains, not just file signatures, and block unsafe DLL search behaviour where possible.

Persistence through scheduled tasks and memory-resident loading

The malware creates a scheduled task to relaunch on reboot, then decrypts shellcode into memory rather than dropping a clearly malicious payload to disk. This combines persistence with a file-light execution model, making static detection harder and recovery more uncertain. Memory allocation followed by permission changes is a common red flag, but only if the telemetry is available and correlated with the parent process. The key failure is assuming that signed software plus a benign file path equals benign execution.

Practical implication: monitor scheduled task creation alongside suspicious memory allocation and execution transitions in userland processes.

Indirect syscalls and cookie-based c2 reduce visibility

Indirect syscalls are used to bypass user-mode hooks by reaching kernel functionality through unhooked syscall stubs, while the C2 channel hides inside ordinary-looking HTTPS requests. In practice, this undermines endpoint tools that rely on user-mode instrumentation and network tools that key on URL paths alone. The request looks like a fetch for a common library, but the payload is carried in a cookie field, which can survive basic TLS inspection and content allowlisting. That is a classic evasion pattern in advanced malware.

Practical implication: correlate endpoint telemetry with proxy and TLS inspection data, and treat unusual cookie payloads as a detection signal.

Threat narrative

Attacker objective: The attacker’s objective is to establish stealthy, persistent execution on the endpoint while preserving access to remote command infrastructure.

1. Entry begins with a browser-cached payload and a trojanised copy of a signed screenshot tool that is launched as though it were a compliance checker.
2. Escalation occurs when the malicious DLL sideloads a second loader, creates persistence through a scheduled task, and decrypts shellcode into memory for execution.
3. Impact is achieved through indirect syscalls and disguised HTTPS traffic, which allow the actor to run code and communicate with command infrastructure while reducing detection visibility.

NHI Mgmt Group analysis

Trusted software is now an attack surface, not a trust boundary. Signed binaries, portable applications, and normal update-like behaviours can all be repurposed to carry malicious load. This matters because endpoint policy often still separates “trusted application” from “malware,” while attackers increasingly operate inside that boundary. Practitioners should treat application trust as conditional and continuously verified.

Process lineage and load order are the real control points in evasive malware cases. The malicious code here is not relying on one dramatic exploit but on the sequence of legitimate executable, malicious DLL, secondary loader, and persistence task. That sequence is exactly where EDR, application control, and allowlisting need to correlate behaviour. A file verdict alone is no longer enough to explain risk.

Indirect syscall abuse shows why user-mode telemetry gaps matter. When malware reaches kernel functionality through less-observable paths, controls that depend on user-mode hooks lose fidelity. That does not make EDR useless, but it does mean defenders need kernel-level visibility, process ancestry, and memory execution telemetry to close the gap. The practical conclusion is that evasion resistance must be designed into detection architecture, not added after compromise.

Network camouflage is becoming a detection problem for endpoint teams, not only SOC teams. By hiding command traffic inside benign-looking HTTPS requests and cookie fields, the actor pushes the burden onto cross-domain correlation. Endpoint alerts, proxy logs, and TLS metadata need to be reviewed together or the campaign will look like routine web activity. Security teams should assume attackers will keep borrowing normal browser and software patterns to blend in.

Malware loaders increasingly exploit the same governance gap that affects NHI sprawl: trusted entities without tight lifecycle control. In this case the trusted entity is a signed application and its load chain, not a service account, but the pattern is familiar. Identity and access governance works only when trust is scoped, monitored, and revoked when behaviour changes. That is the same governance lesson seen in broader NHI security failures, where implicit trust outlives safe use.

What this signals

Evasive malware increasingly behaves like a governance problem because trust is being abused at the point of execution, not only at the point of delivery. That means endpoint teams should think in terms of process trust boundaries, not just clean or dirty files. The control objective is to make it harder for signed software to become a covert loader without leaving a behavioural trail.

Trusted-load-chain risk: a signed executable, an unexpected DLL, and a persistence task can look benign in isolation but form a hostile execution chain in aggregate. This is where correlation matters more than any one detector. Practitioners should combine application control, endpoint telemetry, and network inspection so a single trusted binary cannot silently become the container for malicious behaviour.

For practitioners

• Harden DLL loading paths Restrict unsafe DLL search order, validate library provenance, and monitor for unexpected sibling DLLs loaded by signed applications in user-writable locations.
• Correlate scheduled task creation with memory execution Alert on new scheduled tasks that relaunch newly seen binaries and pair that with process-memory transitions such as RW to RX changes or shellcode-like allocation patterns.
• Inspect proxy logs for hidden payload channels Look for suspicious cookie values, odd user-agent combinations, and requests that mimic common CDN or library fetches while carrying encoded data.
• Use process ancestry to validate trusted software Build detections around the full chain from parent process to loaded modules to network session, especially when a signed executable behaves unlike its normal baseline.

Key takeaways

• This campaign shows how attackers can combine trusted software, DLL sideloading, and persistence to turn legitimate application behaviour into an execution path.
• The strongest evidence in the analysis is the blend of signed-binary abuse, memory-resident shellcode loading, and network camouflage that reduces visibility at multiple layers.
• Defenders need process-lineage correlation, memory execution telemetry, and proxy context to catch threats that do not look malicious in any single control plane.

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.
• Memory-resident payload: A memory-resident payload executes primarily in RAM rather than leaving a clear file footprint on disk. Defenders still can detect it through process, syscall, and temporary-storage telemetry, but file-only hunting becomes much less reliable once the payload avoids persistent artefacts.
• 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.

What's in the full article

Expel's full post covers the technical detail this post intentionally leaves for the source:

• The exact reverse-engineering walk-through of the malicious GreenshotPlugin.dll and updater.dll chain
• The indirect syscall technique and how the loader calculates syscall numbers to bypass hooks
• The full C2 request structure, including the cookie field used to hide encrypted data
• The indicators of compromise and hashes for the files observed in the campaign

👉 The full Expel post covers the malware chain, persistence mechanism, and evasion techniques in detail.

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 helps practitioners connect identity controls to the broader attack paths that modern threats exploit.