Framework mapping
MITRE ATT&CK® Enterprise mapping
Relationship: Canonical Enterprise ATT&CK group record
Open the official ATT&CK object ↗Canonical ATT&CK entity profile. Identifier, name, associated-name context, and public-reporting scope were reconciled to the official Enterprise ATT&CK directory; the official object page remains controlling for complete and current relationships.
What this ATT&CK group record represents
Andariel (G0138) is an Enterprise ATT&CK group record. ATT&CK uses a Group to represent an adversary activity cluster tracked under a common name—not necessarily a single legal organization, government office, crew, or set of people.
The official directory summarizes public reporting that describes a North Korean state-sponsored cluster associated with destructive and financially motivated activity, with acknowledged overlap in public naming. That statement establishes a research starting point, not a complete attribution judgment or a prediction that the same activity will appear in every environment.
Use the stable ATT&CK identifier as the anchor when sources use different names. Preserve the source, publication date, observation period, affected environment, and confidence behind every local association.
Associated names and analytic boundaries
Associated names recorded for this BMC launch profile are: Silent Chollima, PLUTONIUM, Onyx Sleet
Associated names are awareness aids, not proof that two vendors observed exactly the same operators, infrastructure, malware, or mission. Definitions can overlap partially, change over time, or split as analysts gain better evidence.
A defensible case distinguishes the ATT&CK record, the reporting vendor’s cluster definition, the evidence actually observed by your organization, and any intelligence assessment that connects them.
- Retain the exact name used by each source before normalizing it to an ATT&CK identifier.
- Record the time window and geography of the reporting rather than assuming a permanent operating pattern.
- Separate confirmed technical evidence from contextual or geopolitical assessment.
- Document competing explanations and the evidence that would raise or lower confidence.
Build an evidence package before attribution
Start with observable facts: timestamps, identities, process trees, command lines, network destinations, file hashes, cloud audit events, persistence changes, and affected assets. Then compare those observations with public reporting linked from the official ATT&CK page.
Attribution should be the output of analysis, not the label placed on an alert at the beginning. A name can help organize research, but it should never replace incident scoping, containment, or validation.
- Identify which evidence was collected directly and which came from a third party.
- Preserve original telemetry and source passages that support each analytic statement.
- Assign confidence separately to behavior mapping, software identification, infrastructure linkage, and actor attribution.
- Set an expiration or review date for judgments that depend on changing infrastructure or reporting.
Translate reported techniques into hypotheses
ATT&CK maps groups to techniques reported in open sources. Those relationships are examples of observed behavior, not a complete playbook and not a list that every intrusion attributed to the group must follow.
For Andariel, use the official relationship table to create testable hypotheses. For each relevant technique, identify the expected data source, the observable event, plausible benign explanations, analytic logic, and the scope in which the test is valid.
Prioritize techniques by your organization’s technology, exposure, business consequence, and intelligence requirements. Do not rank a technique simply because it appears in more reports.
Detection and coverage questions
A group profile becomes operationally useful when it produces concrete questions for engineering and security operations. The goal is not to claim coverage of a name; it is to validate coverage of relevant behaviors across the systems that matter.
- Which reported behaviors are observable in endpoint, identity, cloud, network, email, and application telemetry?
- Are the required logs enabled, retained long enough, normalized correctly, and available to analysts?
- Which analytics have been tested with representative data rather than only mapped on paper?
- What prevention, containment, and recovery controls reduce consequence when detection is late?
- Which high-impact assets require a narrower, higher-confidence monitoring baseline?
Investigation workflow
When an alert or intelligence report references Andariel, begin with the affected asset and the observed behavior. Expand the timeline, identify related identities and infrastructure, and compare the full sequence with alternative explanations before applying the group label.
Use ATT&CK relationships to broaden collection, not to force evidence into a preferred narrative. Record both matches and meaningful absences, especially when a public report describes required precursors that are not present locally.
- Confirm the alert’s raw events and collection health.
- Build a behavior-centered timeline across relevant security domains.
- Map only actions supported by evidence to ATT&CK techniques.
- Compare software and infrastructure indicators with authoritative and time-bounded sources.
- State incident scope and attribution confidence as separate conclusions.
Bias and confidence controls
Well-known group names create anchoring risk. Analysts may overvalue weak similarities, overlook commodity tooling, or interpret missing evidence as proof of stealth. Peer review and explicit alternatives reduce that risk.
Use calibrated terms such as confirmed, highly likely, likely, possible, unlikely, and unknown only when the organization has defined them. Link each confidence statement to evidence quality, source reliability, consistency, and unresolved gaps.
Safe practitioner exercise
Using a public report linked from the official Andariel record, build a one-page intelligence note. Extract three directly supported behaviors, one software or infrastructure relationship, and two uncertainties. Do not reproduce exploit instructions or sensitive indicators that are unnecessary for the learning objective.
For each behavior, propose a data source and a defensive test in a lab, tabletop, or sanitized dataset. Conclude with the collection improvements that would most increase confidence.
Version, attribution, and independence
This page was reviewed against Enterprise ATT&CK v19.2. ATT&CK content changes over time; verify the official G0138 record before using it for an operational or attribution decision.
© 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. Bare Metal Cyber is not affiliated with or endorsed by MITRE. The instructional analysis on this page is original Bare Metal Cyber content.
Certification relevance
This subject appears in or supports the following certification bodies of knowledge: