G0036: GCMAN
Analyst context for executives and security teams
GCMAN matters because ATT&CK describes it as a financially motivated group targeting banks to transfer money to e-currency services. For security leaders, the decision value is less about the name and more about validating whether remote access paths used for lateral movement—specifically SSH and VNC in the supplied ATT&CK relationships—are governed, monitored, and reviewable in banking or payment environments where unauthorized movement can quickly become financial loss.
Executive priority
Prioritize this as a financial-fraud and operational-resilience scenario. Leaders should ask whether remote administration is tightly controlled, whether privileged and valid-account use can be reconstructed during an incident, and whether SOC/IR teams have evidence to distinguish legitimate support activity from suspicious lateral movement. This also supports audit and compliance readiness: access paths such as SSH and VNC should have ownership, approval, logging, and review evidence, especially around systems involved in money movement.
Technical view
ATT&CK does not provide a detection section for GCMAN, but the relationship context identifies use of Remote Services via SSH (T1021.004) and VNC (T1021.005). Detection and response teams should validate visibility into remote logons, session initiation, source/destination pairs, account context, and administrative activity across environments where SSH or VNC are present. Because the group object has no specified platforms, platform scope should be driven by the related techniques and local asset inventory rather than assumed globally.
Likely telemetry
- Authentication logs for SSH and VNC-accessible systems
- Remote access session logs, including source IP, destination host, username, time, and duration
- Network flow or firewall logs showing SSH/VNC connectivity between internal systems
- Endpoint logs showing remote shell or remote desktop session activity
- Privileged account use records and access management audit trails
Detection direction
- Baseline expected SSH and VNC administration paths, then alert on unusual source hosts, destinations, times, or accounts.
- Correlate remote access with valid-account use, privilege level, and subsequent administrative actions.
- Review east-west network visibility; lateral movement may be missed if monitoring focuses only on perimeter traffic.
- Tune detections to reduce false positives from legitimate administrators, jump hosts, and support tools while preserving accountability for every session.
- Use the banking money-movement context to increase scrutiny around remote access to payment, transfer, treasury, and administrative systems where applicable.
Mitigation priorities
- Inventory where SSH and VNC are enabled and remove or disable unnecessary exposure.
- Restrict remote administration to approved users, approved systems, and controlled access paths such as managed administration hosts where locally appropriate.
- Enforce strong identity controls for privileged and remote access accounts, including review of valid-account usage.
- Ensure logging is enabled and retained for remote sessions, authentication events, and administrative actions.
- Regularly review access approvals and produce evidence suitable for audit, incident response, and control validation.
Analyst notes and limits
The most useful defensive lens is not broad attribution but control validation: can the organization prove who remotely accessed critical systems, from where, and what they did? The supplied ATT&CK relationships point specifically to SSH and VNC as behaviors to validate. For financial institutions, those controls are especially material around systems that can initiate, approve, or support money transfers.
MITRE provides a short group description and no official detection text for this object. The group object itself has no specified platforms or tactics; platform references come only from the related SSH and VNC techniques. Local exposure, telemetry quality, and business-system criticality must be verified before drawing conclusions about risk or coverage.
GCMAN
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.
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 | 6c2c6572d29e… |
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]
Securelist GCMAN
Kaspersky Lab's Global Research & Analysis Team. (2016, February 8). APT-style bank robberies increase with Metel, GCMAN and Carbanak 2.0 attacks. Retrieved April 20, 2016.
Open source URL -
[2]
GCMAN
(Citation: Securelist GCMAN)
-
[3]
mitre-attack G0036Open 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.