S0666: Gelsemium
Analyst context for executives and security teams
Gelsemium matters because ATT&CK describes it as a Windows modular malware family with separate dropper, loader, and plug-in components. That modularity can complicate incident scoping: responders may find only one stage while other components, registry artifacts, command-and-control paths, or collected local data remain undiscovered. For leaders, the decision value is whether Windows endpoint, registry, process, file, and network evidence is sufficient to reconstruct a multi-stage intrusion rather than only remove an obvious binary.
Executive priority
Prioritize validation of Windows endpoint visibility, incident response collection depth, and C2 monitoring. The linked ATT&CK behaviors include discovery, registry interaction, obfuscation, DLL injection, file deletion, timestomping, local data collection, tool transfer, and multiple command-and-control options including web, DNS, fallback channels, and non-application-layer protocols. This makes the business question less about one malware name and more about resilience: can the organization prove what ran, what data was accessed locally, what changed in the registry, and whether outbound communications persisted through alternate channels?
Technical view
SOC and IR teams should treat Gelsemium as a Windows malware object with no official ATT&CK detection text, then map coverage from its relationships. Validate collection and analytics for registry query/modify activity, command shell execution, native API/process behaviors, DLL injection indicators, access token manipulation, process/user/system/file discovery, local data access, file deletion, timestomp anomalies, invalid or misleading code-signing/resource-name traits, and deobfuscation/compression-related artifacts. Network validation should include HTTP/S-like traffic, DNS-based C2 patterns, fallback communications, ingress tool transfer, and non-application-layer protocol visibility. Because the object is modular, triage should not assume a single artifact represents the full intrusion chain.
Likely telemetry
- Windows endpoint process creation and command-line telemetry, especially cmd.exe and child process activity
- Windows Registry query and modification events
- File creation, deletion, rename, path, metadata, and timestamp evidence, including MFT or equivalent forensic artifacts where available
- Module load, DLL injection, memory, and cross-process access telemetry
- Code-signing validation results and file metadata/resource-name observations
Detection direction
- Start with behavior-based coverage because ATT&CK provides no official detection guidance for this malware object.
- Correlate registry activity, suspicious process execution, fileless storage possibilities, and native API/process-injection signals rather than relying only on static malware signatures.
- Tune for sequences: discovery followed by local data access, staging/compression/deobfuscation, outbound C2, tool transfer, and cleanup such as file deletion or timestomping.
- Review false positives for administrative scripts, software installers, endpoint management tools, and legitimate compressed archives before escalating alerts based only on one technique.
- Validate egress monitoring for web, DNS, fallback, and non-application-layer channels; a single blocked protocol should not be treated as proof of containment.
Mitigation priorities
- Ensure Windows endpoint logging and retention can support incident reconstruction across process, registry, file, module, and network activity.
- Harden and monitor registry locations and execution paths commonly abused for persistence, defense evasion, or fileless storage, consistent with local baselines.
- Apply least privilege and monitor privileged token or process-context changes that could support access token manipulation or injection behaviors.
- Restrict and monitor unnecessary outbound protocols while maintaining visibility into allowed web and DNS traffic.
- Use application control, code-signing validation, and file reputation controls where operationally feasible, while recognizing ATT&CK lists invalid signatures and masquerading-like resource naming as relevant behaviors.
Analyst notes and limits
ATT&CK identifies Gelsemium as modular malware composed of Gelsemine, Gelsenicine, and Gelsevirine plug-ins written using the Microsoft Foundation Class framework, and states it has been used by the Gelsemium group since at least 2014. The ATT&CK malware platform is Windows. Relationship context expands the defensive focus across collection, discovery, execution, command-and-control, persistence, privilege escalation, defense impairment, and stealth behaviors, even though the malware object itself does not list tactics.
Official detection text is not provided, and the supplied fields do not include indicators of compromise, specific registry keys, filenames, domains, hashes, prevalence, active exploitation status, victimology, or confirmed customer exposure. Defensive conclusions should therefore be validated against local Windows architecture, logging coverage, egress design, and incident evidence.
Gelsemium
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.2 | Current bundle | 1bcc5a4a4b2e… |
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 Gelsemium June 2021
Dupuy, T. and Faou, M. (2021, June). Gelsemium. Retrieved November 30, 2021.
Open source URL -
[2]
Gelsemine
(Citation: ESET Gelsemium June 2021)
-
[3]
Gelsenicine
(Citation: ESET Gelsemium June 2021)
-
[4]
Gelsevirine
(Citation: ESET Gelsemium June 2021)
-
[5]
mitre-attack S0666Open 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.