S0371: POWERTON
Analyst context for executives and security teams
POWERTON matters because it represents a Windows PowerShell backdoor used as a late-stage capability, meaning its presence would likely indicate an intrusion has progressed beyond initial access into persistence, command-and-control, and credential-risk territory. For leaders, the practical issue is not just “malware detection,” but whether Windows monitoring, PowerShell governance, credential protection, and incident response procedures can expose and contain a backdoor that may blend into legitimate administration activity.
Executive priority
Prioritize validation of Windows endpoint visibility and response readiness around PowerShell, WMI persistence, Registry Run Keys, credential access against the SAM database, and web-based encrypted command-and-control. Because ATT&CK links POWERTON to APT33, a group described as targeting aviation and energy among other sectors, organizations in operationally sensitive industries should treat related controls as resilience and incident-decision priorities. This object has no official ATT&CK detection guidance, so executives should ask for evidence of telemetry coverage and tested response playbooks rather than assume tool coverage exists.
Technical view
ATT&CK identifies POWERTON as a custom PowerShell backdoor on Windows, with relationships to PowerShell execution, SAM credential access, WMI event subscription persistence, Registry Run Key or Startup Folder persistence, web protocol command-and-control, and symmetric cryptography for C2. SOC and IR teams should validate whether they can correlate suspicious PowerShell activity with persistence artifacts, credential-access indicators, and outbound HTTP/S-like traffic patterns. Since the malware object has no ATT&CK-provided detection text and no tactics listed directly, detection engineering should be driven by the related techniques and local baselines for legitimate administration.
Likely telemetry
- Windows process creation telemetry, especially PowerShell command-line and parent-child process context
- PowerShell script block, module, and transcription logs where enabled
- Windows Registry monitoring for Run Key changes and Startup Folder modifications
- WMI repository and event subscription telemetry, including filters, consumers, and bindings
- Windows Security and system events relevant to credential access and privilege context, including activity requiring SYSTEM-level access to SAM material
Detection direction
- Build detections around behavior chains rather than a single malware name: PowerShell execution followed by persistence creation, credential-access attempts, or unusual outbound web traffic should receive higher priority.
- Tune PowerShell analytics against known administrative scripts to reduce false positives while preserving visibility into encoded, remote, unusual, or rarely used script activity.
- Validate monitoring for WMI event subscriptions and Registry Run Keys because these persistence locations are common administrative blind spots and may not be retained by default logging.
- Correlate endpoint and network data: web protocol traffic alone is noisy, but it becomes more meaningful when tied to suspicious PowerShell or newly created persistence artifacts.
- Assess whether encrypted C2 would limit content inspection; ensure detections do not depend solely on payload visibility.
Mitigation priorities
- Harden and monitor PowerShell use on Windows, including policy controls and enhanced logging appropriate to the environment.
- Restrict administrative privileges and protect local credential stores to reduce the value of SAM credential access.
- Monitor and control persistence mechanisms such as WMI event subscriptions, Registry Run Keys, and Startup Folder entries.
- Apply egress controls and proxy visibility for web protocol traffic, with attention to unusual destinations or host behavior.
- Ensure incident response playbooks include containment steps for suspected backdoors, credential exposure review, persistence removal, and host-level forensic collection.
Analyst notes and limits
This take is based on the official ATT&CK POWERTON software object, its FireEye external reference, and ATT&CK relationships to APT33 and specific techniques. The strongest defensive value comes from the relationship context: PowerShell execution, Windows persistence, credential access, and web/encrypted C2. Local environment baselines are essential because several behaviors overlap with legitimate Windows administration.
ATT&CK does not provide official detection guidance for POWERTON, lists no direct tactics for the malware object, and supplies only Windows as the platform for the software. The relationship to APT33 says POWERTON has typically been deployed by that group, but this should not be treated as proof of attribution in any incident without independent evidence. No claim is made here about current active exploitation or guaranteed detectability.
POWERTON
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 | T1573.001 | Symmetric Cryptography Sub-technique | POWERTON has used AES for encrypting C2 traffic.CitationFireEye APT33 Guardrail |
| Enterprise | T1071.001 | Web Protocols Sub-technique | POWERTON has used HTTP/HTTPS for C2 traffic.CitationFireEye APT33 Guardrail |
| Enterprise | T1059.001 | PowerShell Sub-technique | POWERTON is written in PowerShell.CitationFireEye APT33 Guardrail |
| Enterprise | T1003.002 | Security Account Manager Sub-technique | POWERTON has the ability to dump password hashes.CitationFireEye APT33 Guardrail |
| Enterprise | T1547.001 | Registry Run Keys / Startup Folder Sub-technique | POWERTON can install a Registry Run key for persistence.CitationFireEye APT33 Guardrail |
| Enterprise | T1546.003 | Windows Management Instrumentation Event Subscription Sub-technique | POWERTON can use WMI for persistence.CitationFireEye APT33 Guardrail |
Groups, software, and campaigns
G0064: APT33
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 | 465eda109ad6… |
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 APT33 Guardrail
Ackerman, G., et al. (2018, December 21). OVERRULED: Containing a Potentially Destructive Adversary. Retrieved January 17, 2019.
Open source URL -
[2]
mitre-attack S0371Open 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.