S0210: Nerex
Analyst context for executives and security teams
Nerex is a Windows Trojan documented by MITRE as a backdoor used by Elderwood. Its practical significance is not the malware name alone, but the control questions it raises: can the organization spot a Windows host that receives additional tools, changes Registry state, installs or modifies a service for persistence, or relies on signed code to appear trustworthy? Those behaviors affect incident containment, endpoint hardening, and evidence quality for audits and response decisions.
Executive priority
Treat this as a validation case for Windows endpoint resilience and SOC readiness rather than as a standalone malware priority. Leaders should ask whether critical Windows systems have telemetry for service creation, Registry modification, file/tool ingress, and code-signing trust decisions, and whether incident responders can quickly distinguish authorized administration from backdoor persistence. The business value is faster containment and stronger evidence when a suspicious Windows host may be maintaining access or staging additional tooling.
Technical view
ATT&CK provides no dedicated detection text for Nerex, so coverage should be driven by its documented relationships: T1105 Ingress Tool Transfer, T1112 Modify Registry, T1543.003 Windows Service, and T1553.002 Code Signing. SOC and IR teams should validate Windows endpoint visibility for new or modified services, Registry writes tied to persistence or service configuration, unexpected inbound or C2-channel file transfer activity, and execution of signed binaries where the signer, path, or parent process is unusual. Because the object’s own tactics are not specified, detections should be behavior-led and correlated across these related techniques rather than built only around the Nerex name.
Likely telemetry
- Windows endpoint process creation and command-line telemetry
- Windows service creation, modification, and start events
- Registry modification telemetry, especially service and persistence-related keys
- File creation or download evidence on Windows hosts
- Network connection and file transfer logs that can support ingress tool transfer analysis
Detection direction
- Validate that monitoring covers service creation or modification on Windows hosts and correlates service executable paths with recent file creation events.
- Tune Registry modification alerts toward persistence-relevant locations and administrative context to reduce noise from legitimate software installation and management tools.
- Correlate suspected tool transfer with subsequent execution, service registration, or Registry changes instead of alerting on file movement alone.
- Review signed executable trust logic: a valid signature should not automatically suppress investigation when path, signer, parent process, or host context is abnormal.
- Account for blind spots where endpoint logging is absent, service changes are not retained, code-signing metadata is not collected, or network controls cannot reconstruct transferred files.
Mitigation priorities
- Prioritize complete Windows endpoint logging and retention for services, Registry changes, process execution, file creation, and code-signing metadata.
- Restrict who can create or modify Windows services and sensitive Registry locations through least privilege and administrative control review.
- Harden execution policy and application control processes so trusted signing is one factor, not the only trust decision.
- Monitor and control external file transfer paths into the environment, especially on systems with elevated business or operational importance.
- Prepare IR playbooks that collect service configuration, Registry persistence locations, binary metadata, hashes, and network history from a suspected Windows backdoor host.
Analyst notes and limits
The supplied ATT&CK object identifies Nerex as a Trojan/backdoor on Windows and provides relationships to ingress tool transfer, Registry modification, Windows service persistence, and code signing. Since official detection guidance is not provided, this take focuses on defensive validation around those related behaviors and the evidence needed to investigate them.
This summary is limited to the supplied MITRE STIX fields, external references, and relationships. It does not establish active exploitation, current prevalence, customer exposure, specific indicators, or guaranteed detection logic. Local environment baselines and telemetry quality are required to determine actual risk and coverage.
Nerex
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1105 | Ingress Tool Transfer | Nerex creates a backdoor through which remote attackers can download files onto a compromised host.CitationSymantec Ristol May 2012 |
| Enterprise | T1553.002 | Code Signing Sub-technique | Nerex drops a signed Microsoft DLL to disk.CitationSymantec Nerex May 2012 |
| Enterprise | T1543.003 | Windows Service Sub-technique | Nerex creates a Registry subkey that registers a new service.CitationSymantec Nerex May 2012 |
| Enterprise | T1112 | Modify Registry | Nerex creates a Registry subkey that registers a new service.CitationSymantec Nerex May 2012 |
Groups, software, and campaigns
G0066: Elderwood
Elderwood is a suspected Chinese cyber espionage group that was reportedly responsible for the 2009 Google intrusion known as Operation Aurora. [1] The group has targeted defense organizations, supply chain manufacturers, human rights and nongovernmental organizations (NGOs), and IT service providers. [2] [3]
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 66417f5e6543… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Symantec Elderwood Sept 2012
O'Gorman, G., and McDonald, G.. (2012, September 6). The Elderwood Project. Retrieved November 17, 2024.
Open source URL -
[2]
Symantec Nerex May 2012
Ladley, F. (2012, May 15). Backdoor.Nerex. Retrieved February 23, 2018.
Open source URL -
[3]
Nerex
(Citation: Symantec Nerex May 2012)
-
[4]
mitre-attack S0210Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.