S0389: JCry
Analyst context for executives and security teams
JCry is an ATT&CK-listed ransomware family written in Go and identified in reporting associated with the 2019 #OpJerusalem campaign. The business issue is not the name itself, but the combination of user-driven execution, script/command interpreters, persistence, and recovery inhibition tied to ransomware outcomes. Leaders should treat this as a validation case for whether the organization can prevent, detect, contain, and recover from a ransomware execution chain before data encryption affects operations.
Executive priority
Use JCry as a ransomware readiness checkpoint: are user-executed files controlled, are PowerShell/cmd/VB execution paths monitored, are startup persistence changes visible, and are recovery mechanisms protected from tampering? Because ATT&CK provides no official detection text and no malware platform field, priority should be on proving local coverage with evidence rather than assuming tooling detects this family by name.
Technical view
ATT&CK relationships show JCry using PowerShell, Windows Command Shell, Visual Basic, Malicious File execution, Data Encrypted for Impact, Inhibit System Recovery, and Registry Run Keys / Startup Folder. SOC and IR teams should validate telemetry and detections around script and shell execution, suspicious user-launched files, registry or startup-folder persistence, abnormal file encryption activity, and attempts to disable or remove recovery capabilities. Treat technique-level behavior as more durable than malware-family naming because the object has sparse detection guidance.
Likely telemetry
- Endpoint process creation for PowerShell, cmd, VB-related interpreters, and user-launched executables or scripts
- Command-line arguments, parent/child process lineage, and script block or interpreter logging where available
- File creation, rename, modification, and high-volume encryption-like activity on local or reachable storage
- Registry Run key and startup folder modification events
- Events showing backup, recovery, restore, or system-recovery controls being disabled, deleted, or altered
Detection direction
- Prioritize behavior detections mapped to the related ATT&CK techniques rather than relying only on JCry signatures.
- Tune for suspicious combinations: user-opened file followed by PowerShell/cmd/VB execution, persistence modification, recovery inhibition, and rapid file changes.
- Baseline legitimate administrative use of PowerShell, command shell, Visual Basic, and startup entries to reduce false positives while preserving visibility into unusual parent processes and user contexts.
- Validate that recovery-inhibition activity is logged and escalated quickly, since ransomware impact often becomes a business-continuity issue before full malware classification is complete.
- Confirm coverage gaps created by missing or disabled endpoint logging, lack of command-line capture, unmonitored startup locations, and storage areas outside normal EDR visibility.
Mitigation priorities
- Harden user-executed file paths with attachment/download controls, application control, and user awareness where appropriate.
- Restrict and monitor script and command interpreters, especially PowerShell, Windows command shell, and Visual Basic execution paths identified in the relationships.
- Protect persistence locations such as Registry Run keys and startup folders with least privilege, monitoring, and change control.
- Strengthen ransomware resilience through protected backups, tested restoration, and controls that prevent or alert on recovery-mechanism tampering.
- Run tabletop or technical validation exercises to confirm incident response can move from detection to containment and recovery without depending on malware-family attribution.
Analyst notes and limits
The ATT&CK object identifies JCry as ransomware written in Go and cites Carbon Black reporting from May 2019. The most useful defensive context comes from the listed relationships to execution, persistence, and impact techniques. This supports a ransomware-readiness and detection-engineering interpretation, but not claims about current activity, prevalence, victimology, or guaranteed detection.
Official ATT&CK detection guidance is not provided, and the malware object itself lists no platforms, aliases, tactics, or labels. Platform and tactic discussion is therefore limited to the related techniques supplied in the relationship context. Local telemetry, asset architecture, backup design, and endpoint control coverage are required to determine actual exposure and detection readiness.
JCry
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 | T1486 | Data Encrypted for Impact | JCry has encrypted files and demanded Bitcoin to decrypt those files. CitationCarbon Black JCry May 2019 |
| Enterprise | T1547.001 | Registry Run Keys / Startup Folder Sub-technique | JCry has created payloads in the Startup directory to maintain persistence. CitationCarbon Black JCry May 2019 |
| Enterprise | T1059.001 | PowerShell Sub-technique | JCry has used PowerShell to execute payloads.CitationCarbon Black JCry May 2019 |
| Enterprise | T1059.005 | Visual Basic Sub-technique | JCry has used VBS scripts. CitationCarbon Black JCry May 2019 |
| Enterprise | T1204.002 | Malicious File Sub-technique | JCry has achieved execution by luring users to click on a file that appeared to be an Adobe Flash Player update installer. CitationCarbon Black JCry May 2019 |
| Enterprise | T1059.003 | Windows Command Shell Sub-technique | JCry has used |
| Enterprise | T1490 | Inhibit System Recovery | JCry has been observed deleting shadow copies to ensure that data cannot be restored easily.CitationCarbon Black JCry May 2019 |
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 | 6c8fb10d72ec… |
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]
Carbon Black JCry May 2019
Lee, S.. (2019, May 14). JCry Ransomware. Retrieved June 18, 2019.
Open source URL -
[2]
JCry
(Citation: Carbon Black JCry May 2019)
-
[3]
mitre-attack S0389Open 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.