G0002: Moafee
Analyst context for executives and security teams
Moafee is an ATT&CK intrusion set with limited public detail in the supplied record. The main decision value is not a complete profile of the group, but the small set of relationships MITRE documents: use of PoisonIvy, a Windows remote access tool, and use of Binary Padding for stealth. For leaders, this means coverage should be judged less by the group name and more by whether the organization can detect and investigate commodity/custom RAT activity and malware that changes file hashes or size to evade static controls.
Executive priority
Treat Moafee as a threat-intelligence context item that can guide control validation, not as proof of current targeting. The priority questions are: can the SOC find remote access tooling behavior when signatures or hashes change, can incident responders preserve enough endpoint and file evidence to analyze padded binaries, and can security teams show audit-ready evidence that malware detection is not solely hash-based. Because ATT&CK does not provide tactics, platforms, or detection guidance for the group itself, investment decisions should be tied to the documented related software and technique rather than to unsupported assumptions about Moafee activity.
Technical view
Validate coverage around the documented relationships. For PoisonIvy, confirm visibility into Windows endpoint process, network, persistence, and remote access indicators relevant to RAT investigations, while recognizing the supplied relationship only states Moafee uses the software and does not provide specific procedures. For Binary Padding, test whether malware controls, sandboxing, endpoint detection, and triage workflows still inspect oversized or hash-shifted binaries instead of relying only on static signatures or blocklists. Detection engineering should map rules to observable behavior and file properties, not just known hashes tied to historical reporting.
Likely telemetry
- Endpoint process execution and parent-child process context, especially on Windows where the related PoisonIvy software is documented
- Network connection metadata and remote access session indicators associated with suspicious RAT-like behavior
- File creation, modification, size, hash, and reputation telemetry for executables and other binaries
- Endpoint security, antivirus, EDR, and sandbox verdicts, including cases where files exceed inspection limits
- Incident response artifact collection for suspicious binaries, including original file samples and metadata
Detection direction
- Do not depend exclusively on hash-based detection; Binary Padding is specifically relevant because it can change checksums and bypass static blocklists or signatures.
- Validate file-size handling limits in endpoint, email, web, sandbox, and malware-analysis pipelines; padded binaries may be missed if tooling skips large files.
- Use the PoisonIvy relationship as a hunting seed for RAT-like behavior, but avoid assuming every PoisonIvy-related alert is Moafee without corroborating intelligence.
- Tune detections to separate legitimate remote administration from suspicious remote access tooling by using process lineage, destination patterns, persistence evidence, and host context.
- Document gaps caused by the ATT&CK record’s lack of group-specific tactics, platforms, and detection text; local telemetry and threat intelligence are required to operationalize coverage.
Mitigation priorities
- Prioritize behavior-based malware and RAT detection over hash-only blocking.
- Confirm endpoint and malware-analysis tools inspect large or padded binaries rather than silently bypassing them.
- Maintain incident response procedures for collecting suspicious binaries, endpoint timelines, and network metadata for later analysis.
- Use least privilege, application control, and controlled remote administration practices to reduce the usefulness of unauthorized RAT deployment where appropriate.
- Keep threat-intelligence mappings current, especially the documented overlap or possible relationship with DragonOK, but require independent evidence before making attribution decisions.
Analyst notes and limits
The supplied ATT&CK description states Moafee appears to operate from Guangdong Province, China, and may have a direct or indirect relationship with DragonOK due to overlapping TTPs and similar custom tools, citing Haq 2014. The operationally useful relationships provided here are Moafee uses PoisonIvy and Moafee uses Binary Padding. This take intentionally frames those as defensive validation themes rather than making claims about current campaigns, targeting, or confirmed attribution.
Official detection is not provided, and the group object does not specify platforms or tactics. Relationship context supplies Windows only for PoisonIvy and Linux, macOS, and Windows for Binary Padding, but that does not establish the full platform scope of Moafee. Local environment telemetry, current threat intelligence, and incident evidence are required before concluding exposure, activity, or detection coverage.
Moafee
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 | T1027.001 | Binary Padding Sub-technique | Moafee has been known to employ binary padding.CitationHaq 2014 |
Groups, software, and campaigns
S0012: PoisonIvy
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 | d75d169657ff… |
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]
Haq 2014
Haq, T., Moran, N., Scott, M., & Vashisht, S. O. (2014, September 10). The Path to Mass-Producing Cyber Attacks [Blog]. Retrieved November 12, 2014.
Open source URL -
[2]
Moafee
(Citation: Haq 2014)
-
[3]
mitre-attack G0002Open 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.