{
  "family": "jscriptwrap",
  "sample_count": 1,
  "category": "ransomware",
  "description": "<h3>Executive Summary</h3>\nJScriptWrap is not a specific malware family, but rather a detection signature for a specific malicious obfuscation and evasion technique. It identifies scripts or executables that utilize JScript (Microsoft's dialect of JavaScript) encapsulation to hide their true payload. Threat actors use JScriptWrap to bypass static antivirus signatures by dynamically unpacking and executing malicious code directly in memory using the native Windows Script Host (WSH).\n\n<h3>Technical Architecture and Exploitation</h3>\nJScriptWrap is typically used as the delivery mechanism (the initial dropper) within a phishing campaign.\n\nThe attack chain utilizing JScriptWrap usually follows this pattern:\n<ul>\n<li><strong>Delivery:</strong> The user receives a `.js`, `.jse`, `.wsf`, or `.hta` file, often zipped or embedded within a weaponized Office document.</li>\n<li><strong>Obfuscation:</strong> The script content is heavily obfuscated, often appearing as an unreadable block of encoded characters (e.g., Base64 or custom XOR encoding) combined with legitimate-looking \"junk\" code to throw off heuristic analysis.</li>\n<li><strong>In-Memory Execution:</strong> When executed by the native `wscript.exe` or `cscript.exe` engines, the JScriptWrap code decodes the primary payload (often a PowerShell script or an embedded PE file). It then utilizes techniques like `Eval()` or COM object instantiation (e.g., `WScript.Shell`) to execute the decoded payload directly in memory, leaving no executable file on the hard drive for the AV to scan.</li>\n</ul>\n\n<h3>Threat Impact</h3>\nThe use of JScriptWrap indicates a deliberate attempt to bypass endpoint security controls. Because the initial script is often small and utilizes native OS tools (Living off the Land), it frequently succeeds in executing its payload, which is often a robust info-stealer, a RAT, or a ransomware stager.\n\n<h3>Defense and Resilience Strategies</h3>\n<ul>\n<li><strong>Script Host Restriction:</strong> The most effective defense against JScriptWrap is to disable or strictly control the Windows Script Host (WSH). Use Group Policy to change the default file association for `.js` and `.vbs` files to open in Notepad rather than `wscript.exe`.</li>\n<li><strong>AMSI and EDR:</strong> Ensure that the Anti-Malware Scan Interface (AMSI) is fully functional and integrated with your EDR solution. AMSI can intercept and scan the script content *after* it has been de-obfuscated by the script engine, just before execution.</li>\n<li><strong>Behavioral Monitoring:</strong> Monitor for suspicious parent-child process relationships, such as `wscript.exe` spawning `powershell.exe` or initiating unexpected outbound network connections.</li>\n</ul>",
  "cta": "Published by the SystemHelpdesk team.",
  "aliases": [
    "Trojan.JScriptWrap",
    "Dropper.JScript",
    "Script.Obfuscated"
  ],
  "enrichment_level": "insufficient_information",
  "faq": [],
  "faq_count": 0,
  "mitre_attack": [
    "T1059.007",
    "T1027",
    "T1218.011"
  ],
  "cisa_advisory": null,
  "last_updated": "2026-07-01T16:44:41Z",
  "type": "HackTool / Obfuscator",
  "target_industries": [
    "Global / Opportunistic"
  ],
  "motivation": "Opportunistic",
  "threat_actors": [
    "Unknown / Cybercriminal"
  ],
  "target_geographies": [
    "Global"
  ]
}