Masquerading (MITRE ATT&CK T1036) is an adversary technique in which malicious files, processes, or services are disguised to appear legitimate. The most common sub-technique, T1036.005, involves renaming malicious executables to match trusted Windows system processes such as svchost.exe or dllhost.exe, then executing them from non-standard directories such as AppData or ProgramData. This identity-based deception has appeared in campaigns ranging from commodity cryptominers to nation-state operations including WannaCry and SolarWinds SUNBURST. Detection relies on validating execution path, digital signature, and process lineage — not process name alone. Cynet research across multiple production environments identified six distinct instances of svchost.exe executing outside its legitimate directories (System32 and SysWOW64), confirming that masquerading remains an actively leveraged tactic in modern enterprise intrusions.
Masquerading (MITRE ATT&CK T1036) is a well-known adversary technique in which malicious files or processes are made to appear legitimate. Although the technique itself is not new, recent campaign activity demonstrates that it is still actively leveraged in real-world attacks.
Across years of analyzing large-scale malware campaigns and intrusion activity, one recurring pattern consistently stands out: the use of renamed executables that closely resemble legitimate system components. While masquerading can take multiple forms, including manipulated services and scheduled tasks, renamed binaries repeatedly emerge as stable and low-friction components within modern attack chains. Their effectiveness does not stem from technical sophistication, but from familiarity. When a process name appears consistent with operating system conventions, it is less likely to attract immediate scrutiny.
Recent telemetry across multiple independent campaigns and production environments reinforces this observation. The most common implementation remains masqueraded executables (T1036.005), in which malicious payloads are renamed to mimic legitimate system components. By blending into normal endpoint activity, these binaries reduce suspicion during triage, delay investigative response, establish execution and persistence, and exploit implicit trust assumptions in both analysts and security tooling.
As detection technologies increasingly focus on advanced behaviors such as memory injection, exploit chains, and fileless execution, simpler identity-based deception continues to succeed. In practice, renamed executables often function not as peripheral artifacts, but as identity anchors within the attack chain, enabling persistence and operational continuity under the guise of legitimacy.
This report examines the continued use of masqueraded executables, explains why the technique remains effective in modern enterprise environments, and outlines practical detection considerations based on observed activity in the wild.
Masquerading has long been part of adversary tradecraft. Historically, it was often associated with basic malware operations and straightforward evasion attempts. Over time, as detection technologies matured and shifted focus toward advanced techniques such as memory injection, exploit chains, and fileless execution, masquerading was sometimes viewed as low sophistication.
Recent activity challenges that perception.
In modern campaigns, the practice of renaming executables to mimic legitimate system processes continues to appear with notable consistency. Rather than relying solely on technical complexity, attackers frequently leverage familiarity – adopting trusted process names and aligning artifacts with expected operating system structures to reduce scrutiny.
This report focuses primarily on masqueraded executables (T1036.005), while also referencing related variants within the broader masquerading technique. Through historical context, real-world campaign observations, and controlled lab validation, we examine why renamed executables remain an effective and practical component of modern attack chains.
Masquerading includes multiple variations and sub-techniques that can affect different layers of the operating system. Rather than attempting to cover every possible implementation, this section focuses on some of the most observed and operationally relevant patterns seen in real-world campaigns.
At a technical level, masquerading is an identity manipulation technique. Attackers modify visible attributes of system artifacts such as file names, service names, scheduled task names, or file extensions to make them appear legitimate. The objective is not deep concealment but reducing suspicion through familiarity.
This category of activity typically intersects with execution, persistence, and defense evasion phases of an intrusion lifecycle.
One of the most frequently observed implementations involves renaming malicious executables to match legitimate operating system processes or commonly deployed system utilities.
In this pattern, a payload adopts a trusted process name while residing outside its expected directory or executing under unusual parent processes. Because process names are often used during alert triage and prioritization, this alignment reduces immediate suspicion.
In environments with high alert volume and time pressure, analysts may initially assess risk based on process name and basic context. If validation of execution path, digital signature, and process lineage is not performed, a malicious binary operating under a trusted name may evade early-stage detection.
This behavior aligns with commonly categorized defense evasion patterns within adversary modeling frameworks.
A common real-world implementation of renamed executable masquerading aligned with T1036.005 involves malware deployed under the filename svchost.exe, a legitimate and widely observed Windows system process, while residing outside its expected directory.
Under normal conditions, svchost.exe is located in C:\Windows\System32\ or SysWOW64\ and is digitally signed by Microsoft. In observed cases, malicious binaries using the same filename were written to user-accessible locations such as C:\Users\<username>\AppData\ or C:\ProgramData\.
Because svchost.exe routinely runs multiple instances to host Windows services, its presence in process listings does not immediately raise suspicion. If execution path, digital signature, and process lineage are not validated during triage, a renamed binary can blend into normal endpoint activity despite clear structural inconsistencies.
This example highlights how simple identity alignment, without advanced exploitation techniques, can still provide effective defense evasion when baseline validation is insufficient.
Another frequently observed pattern involves the manipulation of service and scheduled task identities.
Attackers may register malicious binaries as Windows services using names that closely resemble legitimate system services. During incident response, service enumeration is often performed quickly. If the name appears consistent with expected system components and deeper validation of the binary path or signature is not conducted, malicious services may persist unnoticed.
Similarly, scheduled tasks may be created or modified with names that imitate default operating system tasks or enterprise automation jobs. Minor naming differences may not stand out during rapid review. When attention is focused on the task label rather than the action it executes, malicious persistence mechanisms can remain active.
In both scenarios, the attacker leverages trust in administrative structures rather than technical stealth. The artifact is visible, but its identity reduces scrutiny.
A representative implementation aligned with T1036.004 has been observed in TrickBot-related attack chains, where attackers established persistence by creating Windows services and scheduled tasks with names designed to closely resemble legitimate system components.
In documented cases, services were registered under labels such as “Windows Update Service”, “Security Center Service”, or slight variations like “WinDefender”, intentionally mirroring native Windows functionality. Scheduled tasks were similarly created using names resembling legitimate maintenance entries, including examples such as “MicrosoftEdgeUpdateTaskMachineCore” or “SystemUpdateTask”, while executing attacker-controlled binaries from non-standard directories such as C:\ProgramData\ or user-level AppData\ paths.
Because enterprise systems routinely contain numerous update and security-related services, these entries blended into expected system listings. During manual review or high-volume triage, slightly modified yet plausible service and task names may receive limited scrutiny compared to overtly suspicious executables.
TrickBot campaigns frequently served as an initial access and persistence layer that later enabled follow-on activity, including large-scale ransomware deployment. In this context, masqueraded services and scheduled tasks were not isolated artifacts, but part of a broader intrusion chain that ultimately facilitated high-impact operations. This pattern demonstrates how service and task name alignment can provide reliable persistence while reducing immediate detection within large-scale, multi-stage attack campaigns.
File naming and extension manipulation represent another common form of masquerading.
Double extensions such as document.pdf.exe rely on visual confusion, particularly in environments where file extensions are hidden by default. In other cases, executables may be renamed to resemble configuration files, logs, or other benign file types.
Although technically simple, these methods remain effective in user-driven execution scenarios or environments where file validation is superficial.
This variation demonstrates identity manipulation at the file system level rather than the process or service layer.
A common implementation aligned with T1036.007 involves the use of double file extensions to disguise executable content as a benign document.
Malicious files distributed through phishing campaigns often use names such as “Invoice.pdf.exe” or “Report.docx.lnk”. When Windows hides known file extensions by default, only the first extension is visible, making the file appear as a legitimate document and increasing the likelihood of user execution. In the case of .lnk files, the shortcut may execute attacker-controlled commands or payloads while appearing as a document.
Although technically simple, this technique remains effective because it exploits default system configurations and user trust in familiar file types. When file type validation and execution context are not properly enforced, double extension masquerading can successfully initiate the attack chain without requiring advanced evasion methods.
While masquerading appears in multiple forms, recent activity shows a clear operational emphasis on renamed executables. This section focuses on how this pattern is being applied in real-world campaigns and how it fits into modern attack chains.
In observed campaigns, payloads were deployed under names resembling legitimate Windows components and, in some cases, configured to imitate built-in services or scheduled tasks. Although executed from abnormal paths, they presented themselves as trusted system processes.
These renamed executables were not peripheral artifacts. They became recurring identity anchors within the attack chain.
This pattern is not simply a contemporary shift in tradecraft, but a modern recurrence of a tactic that has shaped some of the most consequential cyber incidents in history. Renamed executables and identity-aligned artifacts have repeatedly enabled attackers to operate under reduced scrutiny by embedding themselves within trusted system and software conventions. To illustrate how powerful this approach can be at scale, it is instructive to revisit two landmark cases where masquerading became a defining operational enabler: WannaCry and the SolarWinds compromise.
WannaCry incorporated masquerading at both the service and binary level. After exploiting SMB via EternalBlue for lateral movement, the ransomware created a Windows service named MSSECSVC, with its ImagePath pointing to the malicious executable mssecsvc.exe. The naming was deliberately crafted to resemble “Microsoft Security Center,” closely aligning with legitimate Windows security components. Because administrators expect to see similarly named security services and binaries in enterprise environments, the malicious artifacts blended into normal operating system structures and were less likely to raise immediate suspicion during incident response. This straightforward yet effective identity imitation contributed to WannaCry’s rapid global spread and operational impact.
The SolarWinds compromise represents one of the most sophisticated real-world examples of masquerading through trusted software identity abuse. The malicious backdoor known as SUNBURST was embedded inside digitally signed SolarWinds Orion updates, causing the malware to execute under the identity of a legitimate enterprise management platform. By inheriting the trust of the Orion application, the implant blended seamlessly into expected network traffic and system activity. The SUNBURST component naming followed SolarWinds internal development conventions, making it appear as a routine Orion library rather than an external implant. Instead of introducing clearly malicious artifacts, the attackers made their code look native to the product itself, enabling long-term stealth across government and enterprise networks.
The continued relevance of renamed executables is not limited to historical incidents or recent field observations. Across multiple years of MITRE ATT&CK Evaluations, different forms of masquerading have been consistently incorporated into adversary emulation scenarios.
MITRE evaluations simulate structured intrusion activity based on publicly documented tradecraft of real-world APT groups. Over time, masquerading has appeared in various implementations, including manipulated services, deceptive file paths, and renamed binaries aligned with legitimate system components.
One particularly notable example, aligned with the primary focus of this report, is Masquerading: Match Legitimate Name or Location (T1036.005). In the 2024 MITRE ATT&CK Evaluations, within the DPRK scenario, this technique was demonstrated through malware that masquerades as a legitimate Docker file.
The emulated activity illustrates how adversaries use trusted file names and expected locations to make malicious binaries appear legitimate within normal system structures.
While this tactic has shaped some of the most consequential cyber incidents in history, it is far from a relic of past campaigns. Recent activity demonstrates that renamed executables and identity-aligned artifacts remain actively leveraged in modern intrusions observed in the wild. Across multiple contemporary campaigns, attackers continue to deploy payloads under system-like names, align them with legitimate service conventions, and position them within expected operational contexts. The objective remains consistent: reduce friction within the environment, delay suspicion, and establish durable footholds by blending into what defenders are conditioned to trust.
In a recent incident observed and detected by Cynet, an unsigned executable was executed with SYSTEM integrity privileges under the command line svchost.exe -k netsvcs -p -s Schedule, indicating execution via a scheduled task. The binary was launched from the following path:
C:\Users\*\AppData\Roaming\dll\dlihost.exe
Figure 1 shows the Cynet detection view, highlighting the unsigned binary, SYSTEM integrity level, and its execution context under svchost.exe.
At first glance, the filename appears legitimate. However, closer inspection reveals that dlihost.exe was intentionally crafted to visually mimic the legitimate Windows binary dllhost.exe, substituting the letter “l” with the character “i” to create near identical visual similarity. This subtle character manipulation is a classic masquerading technique designed to evade cursory review and exploit visual trust bias.
Further reinforcing the deception, the malicious binary was executed from AppData\Roaming, a user space directory inconsistent with the legitimate dllhost.exe, which resides in C:\Windows\System32 or C:\Windows\SysWOW64.
Figure 2 illustrates the process execution details and abnormal file path as observed within the Cynet UI.
The abuse of a trusted process context, scheduled task execution, system level privileges, and visually deceptive naming demonstrates how renamed executables continue to function as identity anchors within modern attack chains, blending into expected system behavior while operating from abnormal locations.
To further investigate the masqueraded executable, analysis was conducted in a controlled lab environment, following a structured static-to-dynamic validation process.
The binary dlihost.exe was first examined using PeStudio to identify suspicious characteristics without executing the sample. Within the Indicators tab, reference to RandomX was identified.
RandomX is a Proof of Work algorithm used by the Monero cryptocurrency. It is specifically optimized for CPU-based mining and widely implemented in cryptomining software due to its resistance to ASIC optimization. The presence of RandomX-related artifacts strongly suggested that the binary was associated with cryptocurrency mining functionality rather than legitimate Windows operations.
2. Static Analysis – String Inspection and Mining Protocol IdentificationTo further validate the hypothesis, the executable was opened in IDA for rapid static inspection. Using the Strings window, a search for “RandomX” revealed multiple embedded references. Additional strings included references to stratum and SSL-based communication routines.
Notably, we observed the explicit string:
stratum+ssl://randomx.xmrig.com:443
Stratum is a mining communication protocol used by cryptocurrency miners to interact with mining pools. It enables persistent, low-overhead coordination between distributed mining clients and centralized pool servers responsible for aggregating Proof of Work computations. The use of stratum+ssl over port 443 indicates encrypted mining pool communication designed to blend with legitimate HTTPS traffic. The inclusion of both “randomx” and “xmrig” within the same connection string further reinforced attribution to an XMRig-based Monero mining implementation.
Further string inspection revealed additional references to xmrig, a widely used open source cryptocurrency mining application that supports the RandomX algorithm. The alignment between RandomX, stratum protocol indicators, SSL communication artifacts, and xmrig references provided strong static evidence of miner functionality.
At this stage, static analysis strongly indicated cryptomining capability. Dynamic validation was then performed to confirm runtime behavior and persistence mechanisms.
The sample was executed in a controlled lab environment under SYSTEM privilege via a scheduled task, mirroring the execution context observed in the original incident.
The reproduction confirmed the same process chain, including execution under:
svchost.exe -k netsvcs -p -s Schedule
This execution pattern is consistent with scheduled task-based persistence operating under a trusted Windows service host.
4. Runtime Behavior – Resource Consumption AnalysisShortly after execution, elevated CPU utilization was observed, consistent with active cryptocurrency mining behavior. In systems with compatible hardware and configuration, GPU utilization may also increase depending on the build parameters.
The sustained resource consumption pattern aligned with Monero mining workloads and further supported the XMRig attribution established during static analysis.
5. Runtime Memory Inspection – Attribution ConfirmationTo strengthen runtime attribution, memory inspection was conducted while the process was active. String artifacts extracted from memory revealed explicit references to xmrig components, confirming that the running process contained mining-related functionality beyond static indicators alone.
This runtime confirmation significantly reduces the likelihood of misclassification and provides high-confidence attribution to an XMRig-based miner.
6. Network Activity – Mining Infrastructure CommunicationTo validate the operational intent beyond host-level behavior, network activity was analyzed during controlled execution. Shortly after launch, dlihost.exe initiated outbound TCP connections to an external IP address associated with cryptocurrency mining infrastructure.
The communication pattern included persistent session establishment and periodic data exchange consistent with stratum-based mining pool interaction.
7. Infrastructure Intelligence ValidationTo corroborate infrastructure classification, the destination IP and associated domain were analyzed using open-source intelligence sources. VirusTotal categorized the domain/IP as related to cryptocurrency mining activity, with multiple engines and community tags identifying it as mining pool or cryptominer infrastructure.
The convergence of static indicators such as RandomX and stratum, dynamic behavioral evidence including elevated CPU and GPU utilization, in-memory xmrig artifacts, sustained outbound mining communication, and external intelligence classification confirms that the visually deceptive dlihost.exe binary was operating as an XMRig-based cryptocurrency miner.
This layered validation process demonstrates that the masquerading observed in the filename was not incidental. By adopting a near-legitimate Windows binary name and executing under a trusted service context, the malware was able to blend into expected system structures while persistently monetizing compromised computational resources.
In this case, masquerading functioned as a strategic enabler, directly supporting the malware’s economic objective of maintaining long-term, low-visibility resource exploitation.
While the XMRig case provides a fully validated example of how renamed executables function within a modern attack chain, it is not an isolated occurrence. Across recent campaigns observed in the wild, similar identity-aligned artifacts continue to surface in production environments, reinforcing that masquerading remains an actively leveraged and operationally effective tactic. Recent telemetry highlights repeated abuse of trusted system process names, particularly svchost.exe, executed from non-legitimate directories inconsistent with standard Windows installations. These cases illustrate how attackers continue to rely on familiar binary names and subtle contextual manipulation to reduce scrutiny and extend dwell time across diverse intrusion attempts.
The legitimate svchost.exe binary resides exclusively within:
Any execution outside these directories represents a strong indicator of masquerading.
The following instances were observed across multiple independent campaigns and distinct production environments:
Although the filename in each case matched a legitimate core Windows process, the repeated execution of svchost.exe from non-standard directories represents a clear deviation from expected system behavior. The primary issue is the consistent use of a highly trusted process name outside its legitimate context.
In some instances, the directories were structured to resemble system-related locations, such as Windows\System, Windows\Resources, or update-like paths. In others, the binary was executed directly from user-accessible or temporary directories. Regardless of structure, the pattern remains the same: a trusted Windows process name reused from an abnormal path.
The recurrence of this behavior across multiple environments indicates deliberate use of svchost.exe as a masquerading mechanism. By relying on a familiar and widely occurring system process name, attackers reduce the likelihood of detection mechanisms that depend primarily on filename recognition rather than path and context validation.
The repeated misuse of svchost.exe across unrelated environments reinforces a simple but critical defensive principle: effective detection often depends less on recognizing the unusual name, and more on recognizing unusual context.
A useful reference in this regard is the SANS “Find Evil – Know Normal” poster, which outlines baseline expectations for common Windows system processes, including their legitimate file paths, parent processes, and typical execution context. The guidance emphasizes that understanding what is normal on a Windows host significantly reduces investigative noise and allows analysts to focus attention on outliers.
Within this reference, svchost.exe is documented with its expected execution paths and parent-child relationships. When compared against the previously observed cases involving svchost.exe executing from directories such as C:\Users\Public\, C:\ProgramData\, or other non-standard locations, the deviation becomes immediately apparent.
(Double click – inserted a PDF, no idea if it is legit to use it or not – maybe we can credit SANS)
Baseline awareness benefits not only security analysts, but also security teams, IT administrators, and even technically inclined end users. When there is a clear understanding of where core system processes should reside and how they should behave, masquerading attempts become significantly easier to detect. As the preceding examples demonstrate, attackers frequently reuse trusted system process names. The differentiator is rarely the filename itself, but whether it aligns with established operating system norms.
As discussed throughout this report, this technique has appeared in multiple forms across the years and is often categorized as simple or unsophisticated. In some circles, renamed executables are dismissed as a low-skill tactic associated primarily with smaller campaigns or inexperienced operators.
That perception is inaccurate.
Renamed executables have been observed not only in opportunistic malware operations, but also within advanced threat campaigns and large-scale botnet or malware distribution infrastructures. The technique is not defined by the sophistication of the actor, but by its reliability within the attack chain.
Simplicity should not be confused with weakness. In practice, some of the most persistent and operationally effective techniques are those that rely on fundamental assumptions rather than technical complexity.
As defensive technologies continue to evolve toward increasingly advanced detection models, it remains critical not to overlook foundational techniques. Identity-based deception may appear basic, but when left unvalidated, it can be both effective and disruptive.
Covering these “basic” techniques is not optional. It is necessary.
Masquerading (MITRE ATT&CK T1036) is a defense-evasion technique in which an attacker modifies the visible identity of a malicious file, process, service, or scheduled task to make it appear legitimate. Common implementations include renaming malware to match trusted Windows system binaries such as svchost.exe or explorer.exe, placing executables in directories that resemble standard system paths, creating services with names that mirror native Windows components, and using double file extensions such as invoice.pdf.exe to disguise executable files as documents. The technique succeeds not through technical sophistication but through exploiting the implicit trust that analysts, users, and security tools place in familiar names and structures.
Attackers rename malicious payloads to match high-frequency Windows processes such as svchost.exe, dllhost.exe, or lsass.exe, then execute them from non-standard directories such as C:\Users\Public\, C:\ProgramData\, or C:\Windows\Resources\. Because these process names appear routinely in normal system activity, they receive less scrutiny during alert triage. Detection systems or analysts that rely primarily on process name rather than validating the full execution path, digital signature, and parent-child process relationship may overlook the intrusion. In the Cynet-observed case detailed in this report, the binary dlihost.exe — a near-identical visual mimic of the legitimate dllhost.exe — was executed from AppData\Roaming under SYSTEM privileges via a scheduled task, functioning as a persistent XMRig cryptocurrency miner.
Effective detection of T1036.005 requires validating three attributes beyond process name: (1) Execution path — legitimate Windows binaries such as svchost.exe should only run from C:\Windows\System32\ or C:\Windows\SysWOW64\; any other path is a strong indicator of masquerading. (2) Digital signature — core Windows processes are signed by Microsoft; an unsigned binary using a system process name warrants immediate investigation. (3) Process lineage — verify that the parent process matches expected behavior; for example, legitimate svchost.exe instances are spawned by services.exe, not by user-space applications or scheduled tasks invoking binaries from AppData. Leveraging baseline references such as the SANS “Find Evil — Know Normal” poster helps analysts quickly identify deviations from expected process behavior.
Two landmark examples demonstrate the operational impact of masquerading at scale. In the 2017 WannaCry ransomware campaign, the malware created a Windows service named MSSECSVC with its ImagePath pointing to mssecsvc.exe, deliberately mimicking “Microsoft Security Center” to blend into enterprise environments during rapid lateral movement via EternalBlue. In the 2020 SolarWinds SUNBURST compromise, the malicious backdoor was embedded within digitally signed Orion software updates and named to follow SolarWinds’ internal development conventions, causing it to appear as a routine platform library rather than an external implant. Both cases illustrate how identity alignment — inheriting the trust of a legitimate name or software identity — can enable long-term, low-visibility operation across government and enterprise networks.
Yes. Despite being a well-documented technique, masquerading remains actively leveraged in modern intrusions. Cynet research across multiple independent production environments identified repeated instances of svchost.exe executing from non-standard directories including C:\Users\Public\, C:\Windows\System\, C:\Windows\Resources\, and user AppData paths — all clear deviations from legitimate Windows behavior. The 2024 MITRE ATT&CK Evaluations also incorporated T1036.005 in the DPRK adversary emulation scenario, demonstrating that the technique is considered relevant enough by MITRE to include in structured APT simulations. As detection capabilities shift focus toward advanced behaviors such as memory injection and fileless execution, simpler identity-based deception continues to succeed, particularly when baseline validation of process paths and signatures is not enforced.
Looking for a powerful, cost effective XDR solution?
Search results for:
