S0164: TDTESS
TDTESS is a 64-bit .NET binary backdoor used by CopyKittens. [1]
Analyst context for executives and security teams
TDTESS is a Windows-focused 64-bit .NET backdoor documented by MITRE as used by CopyKittens. Its value for defenders is less about a named malware family alone and more about the behaviors connected to it: command-shell execution, tool transfer, Windows service persistence, and anti-forensic file deletion/timestomping. For leaders, this is a reminder to validate whether Windows endpoint, service-control, file-system, and command execution telemetry are strong enough to reconstruct an intrusion when malware-specific detections are not available.
Executive priority
Prioritize this as a Windows endpoint resilience and incident-response readiness issue. ATT&CK does not provide an official detection analytic for TDTESS, so organizations should not rely on a single signature. Executives should ask whether SOC and IR teams can prove visibility into suspicious Windows services, command shell activity, transferred tools, and file timestamp or deletion anomalies. This also supports audit and compliance evidence by showing that controls cover persistence, execution, command-and-control support activity, and anti-forensics rather than only known malware names.
Technical view
MITRE lists TDTESS as a 64-bit .NET binary backdoor on Windows and relates it to CopyKittens. Relationship context links the malware to Windows Command Shell, File Deletion, Timestomp, Ingress Tool Transfer, and Windows Service behaviors. SOC teams should validate detections around cmd.exe activity launched from unusual parents or service contexts, new or modified Windows services, suspicious service executable paths, unexpected file creation followed by deletion, and file timestamp inconsistencies. IR teams should preserve service configuration, registry evidence, process lineage, file-system metadata, and transferred artifacts quickly because related behaviors include deletion and timestomping.
Likely telemetry
- Windows endpoint detection and response process telemetry
- Command-line execution logs for cmd.exe and child processes
- Windows service creation and modification events
- Registry data related to service configuration and executable paths
- File creation, deletion, and rename events
Detection direction
- Do not depend on a TDTESS-specific signature because the supplied ATT&CK object includes no official detection guidance.
- Tune behavior-based detections for Windows service creation or modification followed by execution of unusual binaries.
- Correlate command shell execution with service context, recently written files, or suspected transferred tooling.
- Look for anti-forensic patterns such as deleted dropped files or timestamp changes that do not align with surrounding directory activity.
- Use the CopyKittens relationship as threat-intelligence context, not as proof of attribution in local incidents.
Mitigation priorities
- Strengthen Windows service governance: restrict who can create or modify services and review service executable paths.
- Improve endpoint logging retention so deletion and timestomping do not erase the only useful investigation trail.
- Control and monitor inbound tool transfer paths, including externally sourced files reaching Windows hosts.
- Apply least privilege for administrative accounts used to manage services and command execution.
- Prepare IR collection playbooks for Windows hosts that preserve process, service, registry, file metadata, and network evidence.
Analyst notes and limits
The most decision-useful context comes from the relationships: TDTESS is associated with Windows command shell execution, file deletion, timestomping, ingress tool transfer, and Windows service persistence. These relationships make it useful for validating managed detection, IR evidence collection, endpoint hardening, and Windows administrative control monitoring.
The official ATT&CK object is sparse: tactics are not specified for the malware object, aliases are not listed, and official detection text is not provided. The description supports Windows and 64-bit .NET backdoor characterization, but local telemetry is required to assess exposure, detection coverage, or incident relevance. The CopyKittens relationship should not be used as standalone attribution evidence.
TDTESS
TDTESS is a 64-bit .NET binary backdoor used by CopyKittens. [1]
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 | T1070.004 | File Deletion Sub-technique | TDTESS creates then deletes log files during installation of itself as a service.CitationClearSky Wilted Tulip July 2017 |
| Enterprise | T1105 | Ingress Tool Transfer | TDTESS has a command to download and execute an additional file.CitationClearSky Wilted Tulip July 2017 |
| Enterprise | T1059.003 | Windows Command Shell Sub-technique | TDTESS provides a reverse shell on the victim.CitationClearSky Wilted Tulip July 2017 |
| Enterprise | T1070.006 | Timestomp Sub-technique | After creating a new service for persistence, TDTESS sets the file creation time for the service to the creation time of the victim's legitimate svchost.exe file.CitationClearSky Wilted Tulip July 2017 |
| Enterprise | T1543.003 | Windows Service Sub-technique | If running as administrator, TDTESS installs itself as a new service named bmwappushservice to establish persistence.CitationClearSky Wilted Tulip July 2017 |
Groups, software, and campaigns
G0052: CopyKittens
CopyKittens is an Iranian cyber espionage group that has been operating since at least 2013. It has targeted countries including Israel, Saudi Arabia, Turkey, the U.S., Jordan, and Germany. The group is responsible for the campaign known as Operation Wilted Tulip.[1][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.1 | Current bundle | 2af1826e53c5… |
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]
ClearSky Wilted Tulip July 2017
ClearSky Cyber Security and Trend Micro. (2017, July). Operation Wilted Tulip: Exposing a cyber espionage apparatus. Retrieved August 21, 2017.
Open source URL -
[2]
TDTESS
(Citation: ClearSky Wilted Tulip July 2017)
-
[3]
mitre-attack S0164Open 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.