S0342: GreyEnergy
GreyEnergy is a backdoor written in C and compiled in Visual Studio. GreyEnergy shares similarities with the BlackEnergy malware and is thought to be the successor of it.[1]
Analyst context for executives and security teams
GreyEnergy is a Windows backdoor described by MITRE as written in C, compiled in Visual Studio, and similar to BlackEnergy. Its practical significance is not just the malware family name: the ATT&CK relationships show behaviors that matter to resilience, including credential theft from LSASS, keylogging, command execution, registry and service changes for persistence, obfuscation, file deletion, and encrypted web/proxy command-and-control. For leaders, this is a useful test case for whether Windows endpoint, identity, and network monitoring can connect post-compromise activity into an incident story quickly enough to contain it.
Executive priority
Prioritize GreyEnergy as a coverage-validation scenario for high-value Windows environments, especially where credential theft, persistence, and covert command-and-control would create business continuity or incident response risk. Because MITRE provides no official detection guidance for this software object, leadership should ask for evidence-based answers: are LSASS access, suspicious service/registry changes, rundll32 abuse, tool transfer, encrypted outbound traffic, and cleanup activity visible and retained long enough for investigation? The ATT&CK relationship to Sandworm Team increases threat-intelligence relevance, but local risk decisions should still be based on exposed Windows assets, identity controls, segmentation, logging maturity, and response readiness.
Technical view
SOC and IR teams should validate coverage against the related techniques rather than relying on a single malware signature. On Windows endpoints, confirm visibility for LSASS memory access, keylogging indicators, cmd.exe execution, PE injection, rundll32 proxy execution, registry modification, Windows service creation or modification, suspicious packed/encoded files, and file deletion. On the network side, validate monitoring for web-protocol C2, multi-hop proxy patterns, ingress tool transfer, and encrypted C2 characteristics. Detection engineering should correlate endpoint process, registry, service, file, credential-access, and outbound network events into chains that distinguish administrative activity from suspicious post-compromise behavior.
Likely telemetry
- Windows endpoint process creation and command-line telemetry, including cmd.exe and rundll32.exe usage
- Windows security and EDR events related to LSASS access, credential dumping attempts, and suspicious handle access
- Registry modification events and Windows service creation or modification records
- File creation, deletion, packing/encoding indicators, and executable or DLL metadata including code-signing status
- Memory/process behavior telemetry for portable executable injection or abnormal process access
Detection direction
- Build detections around behavior clusters mapped to the related ATT&CK techniques, not only known GreyEnergy indicators.
- Tune LSASS access detections to separate expected security tooling from unusual administrative, SYSTEM, or injected-process access patterns.
- Monitor service and registry changes in context: new or modified autostart paths, unusual binaries, and changes made by unexpected parent processes should receive higher priority.
- Review rundll32 and cmd.exe executions for unusual parent-child relationships, command-line arguments, network activity, or execution from nonstandard paths.
- Account for obfuscation blind spots: software packing, encrypted or encoded files, and code signing can reduce the value of static signatures alone.
Mitigation priorities
- Harden Windows credential protections and reduce opportunities for LSASS credential theft through least privilege and administrative access control.
- Restrict and monitor service creation, registry autorun modifications, and administrative tools that can support persistence.
- Apply application control and script/executable governance where feasible, with attention to signed-but-untrusted or unusual binaries.
- Strengthen egress controls and proxy logging so web-protocol, encrypted, and multi-hop command-and-control patterns can be investigated.
- Ensure endpoint security tooling records process, memory, file, registry, and service activity with sufficient retention for IR timelines.
Analyst notes and limits
The supplied ATT&CK object identifies GreyEnergy as malware and provides a Windows platform plus technique relationships. The object has no official detection guidance and no tactics listed directly on the malware record, so this take uses the related techniques to frame defensive validation. MITRE also relates GreyEnergy to Sandworm Team; that relationship is useful for threat-intelligence context but should not be treated as proof of current activity in any specific environment.
This summary is limited to the supplied ATT&CK fields, external references, and relationships. It does not include indicators of compromise, campaign timing, victimology, exploit details, or guaranteed detection logic. Local asset criticality, logging coverage, endpoint tooling, network architecture, and administrative baselines are required to determine actual exposure and detection confidence.
GreyEnergy
GreyEnergy is a backdoor written in C and compiled in Visual Studio. GreyEnergy shares similarities with the BlackEnergy malware and is thought to be the successor of it.[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 | T1090.003 | Multi-hop Proxy Sub-technique | GreyEnergy has used Tor relays for Command and Control servers.CitationESET GreyEnergy Oct 2018 |
| Enterprise | T1218.011 | Rundll32 Sub-technique | GreyEnergy uses PsExec locally in order to execute rundll32.exe at the highest privileges (NTAUTHORITY\SYSTEM).CitationESET GreyEnergy Oct 2018 |
| Enterprise | T1070.004 | File Deletion Sub-technique | GreyEnergy can securely delete a file by hooking into the DeleteFileA and DeleteFileW functions in the Windows API.CitationESET GreyEnergy Oct 2018 |
| Enterprise | T1543.003 | Windows Service Sub-technique | GreyEnergy chooses a service, drops a DLL file, and writes it to that serviceDLL Registry key.CitationESET GreyEnergy Oct 2018 |
| Enterprise | T1071.001 | Web Protocols Sub-technique | GreyEnergy uses HTTP and HTTPS for C2 communications.CitationESET GreyEnergy Oct 2018 |
| Enterprise | T1553.002 | Code Signing Sub-technique | GreyEnergy digitally signs the malware with a code-signing certificate.CitationESET GreyEnergy Oct 2018 |
| Enterprise | T1007 | System Service Discovery | GreyEnergy enumerates all Windows services.CitationESET GreyEnergy Oct 2018 |
| Enterprise | T1573.002 | Asymmetric Cryptography Sub-technique | GreyEnergy encrypts communications using RSA-2048.CitationESET GreyEnergy Oct 2018 |
| Enterprise | T1059.003 | Windows Command Shell Sub-technique | GreyEnergy uses cmd.exe to execute itself in-memory.CitationESET GreyEnergy Oct 2018 |
| Enterprise | T1105 | Ingress Tool Transfer | GreyEnergy can download additional modules and payloads.CitationESET GreyEnergy Oct 2018 |
| Enterprise | T1055.002 | Portable Executable Injection Sub-technique | GreyEnergy has a module to inject a PE binary into a remote process.CitationESET GreyEnergy Oct 2018 |
| Enterprise | T1573.001 | Symmetric Cryptography Sub-technique | GreyEnergy encrypts communications using AES256.CitationESET GreyEnergy Oct 2018 |
| Enterprise | T1112 | Modify Registry | GreyEnergy modifies conditions in the Registry and adds keys.CitationESET GreyEnergy Oct 2018 |
| Enterprise | T1027.002 | Software Packing Sub-technique | GreyEnergy is packed for obfuscation.CitationESET GreyEnergy Oct 2018 |
| Enterprise | T1056.001 | Keylogging Sub-technique | GreyEnergy has a module to harvest pressed keystrokes.CitationESET GreyEnergy Oct 2018 |
| Enterprise | T1027.013 | Encrypted/Encoded File Sub-technique | GreyEnergy encrypts its configuration files with AES-256 and also encrypts its strings.CitationESET GreyEnergy Oct 2018 |
| Enterprise | T1003.001 | LSASS Memory Sub-technique | GreyEnergy has a module for Mimikatz to collect Windows credentials from the victim’s machine.CitationESET GreyEnergy Oct 2018 |
Groups, software, and campaigns
G0034: Sandworm Team
Sandworm Team is a destructive threat group that has been attributed to Russia's General Staff Main Intelligence Directorate (GRU) Main Center for Special Technologies (GTsST) military unit 74455.[1][2] This group has been active since at least 2009.[3][4][5][6]
In October 2020, the US indicted six GRU Unit 74455 officers associated with Sandworm Team for the following cyber operations: the 2015 and 2016 attacks against Ukrainian electrical companies and government organizations, the 2017 worldwide NotPetya attack, targeting of the 2017 French presidential campaign, the 2018 Olympic Destroyer attack against the Winter Olympic Games, the 2018 operation against the Organisation for the Prohibition of Chemical Weapons, and attacks against the country of Georgia in 2018 and 2019.[1][2] Some of these were conducted with the assistance of GRU Unit 26165, which is also referred to as APT28.[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.2 | Current bundle | 73ea76a637d6… |
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]
ESET GreyEnergy Oct 2018
Cherepanov, A. (2018, October). GREYENERGY A successor to BlackEnergy. Retrieved November 15, 2018.
Open source URL -
[2]
GreyEnergy
(Citation: ESET GreyEnergy Oct 2018)
-
[3]
mitre-attack S0342Open 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.