S0146: TEXTMATE
TEXTMATE is a second-stage PowerShell backdoor that is memory-resident. It was observed being used along with POWERSOURCE in February 2017. [1]
Analyst context for executives and security teams
TEXTMATE matters because it represents a Windows, memory-resident second-stage PowerShell backdoor rather than a simple file-based malware artifact. For leaders, the practical issue is whether the organization can see suspicious PowerShell activity, command-shell execution, and DNS-based command-and-control behavior after initial compromise. ATT&CK links TEXTMATE to FIN7 usage and to DNS communications, so this is most relevant to organizations validating endpoint, DNS, and incident response visibility against financially motivated intrusion tradecraft without assuming current exposure.
Executive priority
Prioritize TEXTMATE as a coverage validation case for post-compromise resilience: can the business detect and investigate a memory-resident PowerShell backdoor that may use Windows command execution and DNS for command-and-control? The decision value is in confirming that SOC monitoring, DNS logging, endpoint telemetry, and IR playbooks can produce evidence quickly enough to support containment decisions, audit defensibility, and continuity planning. Because ATT&CK provides no official detection text for this object, leaders should treat this as a gap-assessment prompt rather than a claim of existing detection coverage.
Technical view
TEXTMATE is described by ATT&CK as a second-stage, memory-resident PowerShell backdoor on Windows, observed with POWERSOURCE in February 2017. Relationship context says the malware uses Windows Command Shell (T1059.003) and DNS application-layer communication (T1071.004), and that FIN7 uses the object. SOC and IR teams should validate visibility across PowerShell process behavior, cmd.exe invocation, parent-child process chains, command-line arguments, script-block or PowerShell operational logs where available, and DNS query patterns from Windows endpoints. Since ATT&CK does not provide object-specific detection logic, detections should be behavior-led and tuned around the related techniques rather than a malware-name signature alone.
Likely telemetry
- Windows endpoint process creation telemetry, especially powershell.exe and cmd.exe execution
- PowerShell operational logging, script block logging, module logging, and command-line capture where enabled
- EDR memory-resident or script-based execution alerts and related process lineage
- DNS resolver logs, endpoint DNS telemetry, and network DNS query metadata
- Network security logs showing unusual DNS volume, frequency, domain structure, or endpoint-to-resolver patterns
Detection direction
- Validate whether detections cover suspicious PowerShell launched without a durable file artifact, since TEXTMATE is described as memory-resident.
- Correlate PowerShell and Windows command shell activity with DNS behavior rather than relying only on static malware indicators.
- Use the related DNS technique to review for unusual DNS query patterns, but tune carefully because DNS is common and high-volume in normal environments.
- Review process parent-child relationships involving PowerShell and cmd.exe for abnormal launch paths, automation contexts, or user activity mismatches.
- Because no official ATT&CK detection guidance is supplied, document which detections are technique-based, which are environment-specific, and which require local baselining.
Mitigation priorities
- Ensure PowerShell and command-line logging are enabled and retained long enough to support investigation.
- Centralize DNS logging from endpoints and resolvers so command-and-control hypotheses can be tested during incidents.
- Harden and monitor script execution on Windows systems using approved administrative patterns and least-privilege access.
- Prepare IR procedures for memory-resident PowerShell activity, including rapid endpoint isolation, volatile data capture where appropriate, and scoping through DNS and endpoint telemetry.
- Map existing controls and detections to T1059.003 and T1071.004 to identify practical visibility gaps before an incident.
Analyst notes and limits
The object is sparse: tactics are not specified and ATT&CK provides no official detection section. The strongest defensive value comes from the official description and relationships: Windows platform, second-stage PowerShell backdoor, memory-resident behavior, observed with POWERSOURCE, relationship to FIN7, and use of Windows Command Shell and DNS. Cisco/Talos and FireEye references indicate naming overlap with DNSMessenger Stage 4, so analysts should account for aliasing or split-family naming when searching intelligence and historical detections.
This take does not assert active exploitation, current campaigns, customer exposure, or guaranteed detection. The supplied ATT&CK data supports Windows as the platform for TEXTMATE; DNS technique platform metadata includes other platforms, but that should not be interpreted as TEXTMATE platform coverage. Local telemetry quality, logging configuration, retention, and environment baselines are required to determine actual defensive coverage.
TEXTMATE
TEXTMATE is a second-stage PowerShell backdoor that is memory-resident. It was observed being used along with POWERSOURCE in February 2017. [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 | T1071.004 | DNS Sub-technique | TEXTMATE uses DNS TXT records for C2.CitationFireEye FIN7 March 2017 |
| Enterprise | T1059.003 | Windows Command Shell Sub-technique | TEXTMATE executes cmd.exe to provide a reverse shell to adversaries.CitationFireEye FIN7 March 2017CitationCisco DNSMessenger March 2017 |
Groups, software, and campaigns
G0046: FIN7
FIN7 is a financially-motivated threat group that has been active since 2013. FIN7 has targeted the retail, restaurant, hospitality, software, consulting, financial services, medical equipment, cloud services, media, food and beverage, transportation, pharmaceutical, and utilities industries in the United States. A portion of FIN7 was operated out of a front company called Combi Security and often used point-of-sale malware for targeting efforts. Since 2020, FIN7 shifted operations to big game hunting (BGH), including use of REvil ransomware and their own Ransomware-as-a-Service (RaaS), Darkside. FIN7 may be linked to the Carbanak Group, but multiple threat groups have been observed using Carbanak, leading these groups to be tracked separately.[1][2][3][4][5][6][7]
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 | 6c02a16a51d1… |
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]
FireEye FIN7 March 2017
Miller, S., et al. (2017, March 7). FIN7 Spear Phishing Campaign Targets Personnel Involved in SEC Filings. Retrieved March 8, 2017.
Open source URL -
[2]
Cisco DNSMessenger March 2017
Brumaghin, E. and Grady, C.. (2017, March 2). Covert Channels and Poor Decisions: The Tale of DNSMessenger. Retrieved March 8, 2017.
Open source URL -
[3]
DNSMessenger
Based on similar descriptions of functionality, it appears S0146, as named by FireEye, is the same as Stage 4 of a backdoor named DNSMessenger by Cisco's Talos Intelligence Group. However, FireEye appears to break DNSMessenger into two parts: S0145 and S0146. (Citation: Cisco DNSMessenger March 2017) (Citation: FireEye FIN7 March 2017)
-
[4]
TEXTMATE
(Citation: FireEye FIN7 March 2017)
-
[5]
mitre-attack S0146Open 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.