Home
Glossary
CustomerLoader
Table of contents
5 min
H2 title on one or more lines.
Share
Updated on
August 14, 2026

CustomerLoader malware

CustomerLoader is a .NET malware loader whose purpose is to deliver other malware. It arrives on a Windows machine, unpacks itself, and runs a further payload in memory. Reporting has associated it with dozens of malware families, including information stealers, remote access trojans, and ransomware, depending on which criminal customer is using it. CustomerLoader was identified and named by Sekoia's Threat Detection & Research (TDR) team in July 2023. Analysts observed the string customer repeatedly in its command-and-control communications and used it to name the malware. That origin matters because Sekoia's analysis was the first public description of CustomerLoader, and much of the later coverage draws on it directly or indirectly. A CustomerLoader detection is evidence that something else may have been delivered. The loader itself does not carry out the final theft, surveillance, or encryption. The important investigation starts with identifying the payload that followed it.

Key takeaways

  • CustomerLoader is a delivery mechanism, not a final payload. Its job is to install and launch another piece of malware.
  • It has delivered a wide range of malware. Dozens of families have been associated with the loader, including infostealers, remote access trojans, and ransomware.
  • It runs payloads in memory. Process injection allows the next stage to execute inside another process, reducing what file-based detection can observe.
  • It was named by Sekoia. The name comes from the customer string observed in its command-and-control traffic during the original 2023 analysis.

What CustomerLoader does

A loader occupies a specific stage in an intrusion. CustomerLoader's sequence is short:

  1. It arrives. Observed delivery routes include phishing messages, public videos promoting supposed software, and websites that imitate download pages for well-known applications. These sites commonly offer cracked or free versions of paid software.
  2. It unpacks itself. The code is written in .NET and wrapped in layers of obfuscation intended to frustrate analysis before execution.
  3. It fetches and injects the next stage. Rather than saving the final malware to disk, CustomerLoader uses process injection to run it inside another process, in memory. Reporting has linked this step to a publicly available injector.
  4. It hands over control. The delivered malware performs the actual activity, whether that involves stealing credentials, providing remote access, or deploying ransomware.

A CustomerLoader detection is therefore not a resolved incident. It shows that a delivery stage ran and that another payload may have followed. The next steps are to identify the payload, check for persistence, review the accounts used on the machine, and investigate activity after execution.

Why the range of payloads matters

Many loaders are linked to a small number of payloads, often because one group operates them. CustomerLoader has been associated with a much wider set, which suggests a delivery service used by multiple criminal customers. Each customer can choose a different final malware, so the same loader can appear before attacks with completely different objectives.

This creates an efficient detection opportunity. Detection for one infostealer covers one threat. Detection for the loader covers the delivery stage shared by many threats, regardless of what the operator intends to install. For a security team deciding where to spend limited detection engineering time, a stage common to many attacks can be more valuable than a rule for one final payload.

How CustomerLoader is delivered

CustomerLoader has been observed through social engineering and unofficial software downloads rather than as a standalone exploit. Common routes include:

  • Phishing messages: A message directs the recipient to a download or a supposed software offer.
  • Public videos: Videos promote fake software or game-related downloads and direct viewers to a malicious site.
  • Imitation download pages: Websites copy the appearance of legitimate application pages and offer cracked or free versions of paid products.
  • Obfuscated installers: The loader is packaged and wrapped to make analysis harder before it executes.

The delivery stage depends on someone downloading and running software from an untrusted source. That makes software provenance and endpoint behavior central to prevention and detection.

Sekoia's research on CustomerLoader

Sekoia's TDR team published the original analysis of CustomerLoader in July 2023. The research documented the infection chain from initial delivery through payload execution, examined how the loader obfuscates itself and communicates with its infrastructure, and catalogued the range of malware families distributed through it.

The payload variety was the finding that made CustomerLoader notable. The loader was not associated with one narrow campaign or one final objective. It functioned as a delivery layer for multiple criminal customers, which made the same detection relevant to different types of intrusion.

Because the analysis was the first public description of CustomerLoader, much of the subsequent coverage traces back to it. That is a statement about provenance. It does not require a claim that every later source or every associated payload is identical.

How to detect and defend against CustomerLoader

Because the loader is obfuscated and runs the next stage in memory, useful controls target behavior and delivery rather than only files:

  1. Restrict software sources. Allow installation from approved applications and official vendor sites. Cracked and pirated software is a reliable delivery route for CustomerLoader and similar loaders.
  2. Monitor process injection. Injection into a legitimate process to execute code in memory is central to the loader's operation. Endpoint detection that covers this behavior addresses a stage that file scanning can miss.
  3. Monitor scripting and developer utilities. Unusual use of interpreters and tools already present on Windows can reveal a staged execution chain.
  4. Watch outbound connections after execution. A newly executed process contacting unfamiliar infrastructure shortly after launch is a useful signal, especially when combined with the software's origin and process behavior.
  5. Treat a detection as an active intrusion. Identify what the loader delivered, check for persistence, review account activity, and assume credentials on the machine may be exposed until the investigation shows otherwise.

Expert insight: The delivery stage is the efficient place to detect

There is a tendency to rank malware by what it does directly, which puts loaders near the bottom. CustomerLoader steals no data by itself, encrypts no systems by itself, and provides no remote access without a payload. Its significance comes from its position in the intrusion chain and the number of outcomes that can follow it.

That position makes it an efficient detection target. Sekoia is a European cybersecurity vendor whose in-house TDR team produced the original analysis of CustomerLoader. Detection on the Sekoia AI SOC platform correlates behavior across endpoint, network, and identity signals and maps it to the MITRE ATT&CK framework. For a loader that obfuscates its code and executes the next stage in memory, the reliable signals are behavioral: an application from an unofficial source running, code being injected into another process, and an unfamiliar outbound connection following execution.

Those steps persist across variants and payloads. Detecting the delivery stage can therefore cover many possible outcomes at once, which is more efficient than chasing every malware family CustomerLoader may deliver.