S0458: Ramsay
Analyst context for executives and security teams
Ramsay matters because MITRE describes it as a Windows information-stealing framework designed to collect and exfiltrate sensitive documents, including from air-gapped systems. For leaders, the key issue is not only malware removal; it is whether controls around document repositories, removable media, network shares, and isolated environments can prove that sensitive data was not silently collected, staged, or moved.
Executive priority
Prioritize Ramsay as a resilience and data-protection scenario for high-value Windows environments, especially where removable media, shared drives, or air-gapped workflows are used to protect sensitive operations. Executives should ask whether the organization can evidence control over USB use, file-share access, scheduled task abuse, stealthy execution, local data staging, and outbound web traffic. This is also relevant to audit readiness because the material question after a suspected event will be: what documents were accessible, copied, staged, or potentially transferred?
Technical view
SOC and IR teams should validate coverage across the behaviors linked to Ramsay: local, removable-media, and network-share data collection; file and directory discovery; process, network configuration, network connection, service, and peripheral discovery; local data staging; scheduled task persistence or execution; Visual Basic and Native API execution; DLL injection; masquerading; obfuscation, steganography, and rootkit-style stealth; removable-media replication; tainted shared content; screen capture; and web-protocol command-and-control. Because MITRE provides no official detection text for Ramsay, detection engineering should be behavior-led rather than signature-led, with special attention to Windows hosts that bridge isolated networks and removable media workflows.
Likely telemetry
- Windows endpoint process creation and command-line telemetry, including scripting and Visual Basic-related execution where available
- File creation, modification, rename, copy, and delete events on local disks, removable media, and network shared drives
- Removable media insertion, mount, file access, and policy enforcement logs
- Windows Scheduled Task creation, modification, and execution evidence
- Endpoint telemetry for DLL loading, process injection indicators, native API-heavy execution, and suspicious child-process patterns
Detection direction
- Build detections around behavior chains: discovery followed by broad document access, local staging, removable-media interaction, or web-protocol communication is more meaningful than any single event.
- Tune monitoring for sensitive document locations and shared drives, focusing on unusual enumeration, bulk access, copying, or staging from Windows endpoints and accounts that do not normally perform those actions.
- Validate controls and alerts for removable media use, especially on systems that connect to isolated or air-gapped environments; absence of telemetry here is a major blind spot for this malware family description.
- Review scheduled task creation and modification for unusual names, paths, or execution of scripts/binaries from user-writable, removable, or shared locations.
- Correlate masquerading and obfuscation signals with execution context: legitimate-looking names in unusual paths, unexpected DLL loads, and suspicious script execution can reduce false positives compared with simple filename matching.
Mitigation priorities
- Identify Windows systems that handle sensitive documents, removable media, network shares, or air-gapped transfer workflows and treat them as priority control points.
- Restrict and monitor removable media use; disable autorun-style behavior where applicable and require approved transfer procedures for isolated environments.
- Apply least-privilege access to document repositories and network shares, with auditing sufficient to reconstruct file access and copying during an investigation.
- Harden execution paths with application control, script controls, and scheduled task governance to reduce abuse of Visual Basic, native execution, DLL injection, and persistence mechanisms.
- Improve endpoint hardening and monitoring for stealth techniques such as masquerading, obfuscated files, suspicious DLL activity, and rootkit-like attempts to hide artifacts.
Analyst notes and limits
MITRE lists Ramsay as malware S0458 in enterprise ATT&CK, platform Windows, with an official description focused on information stealing and sensitive document collection/exfiltration, including from air-gapped systems. MITRE also notes researcher-identified overlaps with Darkhotel-associated Retro malware; this should be treated as research context, not as a claim of current attribution or active exploitation. The relationship set is rich and should drive defensive validation across collection, discovery, execution, persistence, lateral movement, command-and-control, and stealth behaviors.
The supplied ATT&CK object does not provide official detection guidance, aliases, labels, or object-level tactics. Several related techniques list broader platforms, but the Ramsay object itself is supplied as Windows, so local validation should focus on Windows unless separate evidence expands scope. Any assessment of exposure, compromise, or detection coverage requires environment-specific telemetry, asset context, and investigation evidence.
Ramsay
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 | 3c913892d2b7… |
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 Ramsay May 2020
Sanmillan, I.. (2020, May 13). Ramsay: A cyber‑espionage toolkit tailored for air‑gapped networks. Retrieved May 27, 2020.
Open source URL -
[2]
Antiy CERT Ramsay April 2020
Antiy CERT. (2020, April 20). Analysis of Ramsay components of Darkhotel's infiltration and isolation network. Retrieved March 24, 2021.
Open source URL -
[3]
Ramsay
(Citation: Eset Ramsay May 2020)
-
[4]
mitre-attack S0458Open 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.