Five-Layer Fileless Malware Uses JScript and PowerShell to Evade AMSI and Load .NET Payload

An active phishing campaign using a five-layer, fileless malware loader to evade Microsoft’s Antimalware Scan Interface (AMSI), static detection controls, and disk-based forensic analysis.

The campaign delivers a Windows Script Host JScript payload inside a TAR archive disguised as a purchase order, ultimately loading a .NET assembly directly into memory.

The activity was first observed against a North America-based multinational software-as-a-service provider. FIRE said the engineering and staging complexity indicate that similarly sized enterprises are likely the intended targets, although attribution remains unresolved.

Researchers cautioned that the loader could reflect either a bespoke operation by an advanced threat actor or an emerging crypter-as-a-service capability that generates uniquely obfuscated samples.

The infection chain begins when a victim executes a malicious JScript file extracted from the purchase-order-themed TAR archive.

Rather than exposing its intent through readable strings or a conventional PowerShell command, the script reconstructs code at runtime, includes decoy content, and relies on randomized variable names to obstruct static scanners and analyst review.

The first layer establishes a WScript.Shell.Environment(“Process”) handle, which the malware later uses to stage code in process environment variables.

A second layer hides its PowerShell launch command through a reversed offset cipher. Once decoded, the command launches a hidden PowerShell instance via conhost.exe –headless, with obfuscated flags and an -EncodedCommand argument.

A third obfuscation layer decrypts the PowerShell loader using a 161616-byte cyclic key. The recovered Base64-encoded loader is placed in an environment variable identified as z6ti4ttoCGD1, while the script path is stored in kYcT4A1u9jXwA.

These identifiers provide defenders with immediate hunting pivots, though future variants could easily rotate them.

The most distinctive component appears in the fourth layer. Instead of placing a complete payload in a file, command line, or a single encoded string, the PowerShell script splits the next stage into 364364364 environment variables.

Fortra Intelligence and Research Experts (FIRE) has identified an active phishing campaign delivering fileless malware that uses five distinct layers of obfuscation.

It later reassembles the fragments at runtime and invokes them using [scriptblock]::Create(). The technique reduces the effectiveness of conventional string matching and can complicate AMSI inspection, particularly when combined with split method names such as (‘Lo’+’ad’).

Fileless Malware Uses JScript

In the final layer, the malware stores the .NET payload as CJK or Hanzi characters rather than familiar Base64 or hexadecimal data. The loader converts each character to a byte by subtracting 0x4E000x4E000x4E00, or 199681996819968, from its code point.

It then reflectively loads the reconstructed assembly through Reflection.Assembly::Load and runs it using EntryPoint.Invoke, leaving no executable payload on disk.

FIRE associated the final-stage payload with Agent Tesla, although direct recovery and full analysis of the .NET assembly remain pending.

Regardless of the final payload, the loader itself represents the central risk: it can be repurposed to deploy credential stealers, ransomware precursors, remote-access tooling, or data-exfiltration modules while minimizing traditional endpoint artifacts.

The campaign maps to several MITRE ATT&CK techniques, including JScript execution (T1059.005), PowerShell (T1059.001), Obfuscated Files or Information (T1027), Deobfuscate/Decode Files or Information (T1140), and Reflective Code Loading (T1620).

Defenders should prioritize telemetry that captures process lineage, PowerShell script blocks, command lines, AMSI events, and process-environment activity.

High-confidence hunting opportunities include wscript.exe spawning conhost.exe –headless powershell.exe, PowerShell executing [scriptblock]::Create() from environment variables, unusually large sets of randomly named environment variables, and reflective .NET loading shortly afterward.

Because the technique removes the need to write the final executable to disk, organizations should treat suspicious script execution and in-memory assembly loading as critical behavioral signals rather than relying solely on file hashes or antivirus signatures.

𝗔𝗜 𝗦𝗢𝗖 𝘃𝘀 𝗠𝗗𝗥 𝘃𝘀 𝗠𝗦𝗦𝗣 Which is Best in 2026? Compare costs, Automation, and response: Download Free Guide