It was first observed targeting a North America-based multinational software and SaaS provider, suggesting that similarly large enterprises could be at risk.
Attackers deliver the first-stage Windows Script Host JScript file in a TAR archive disguised as a purchase order.
Once opened, the script launches a hidden PowerShell process. It prepares an in-memory .NET payload without writing the final executable to disk.
This approach can make conventional antivirus scans and disk-based forensic investigations less effective.
A successful compromise could enable credential theft, data exfiltration, further malware delivery, ransomware activity, and operational disruption.
Malware Hides in Environment Variables
The initial JScript sample contains decoy code, randomized variable names, and strings rebuilt character by character during execution. These techniques obscure its real purpose and hinder static analysis.
The script then decrypts a concealed command that launches PowerShell through conhost.exe –headless. The command uses PowerShell options, including -NoProfile, -NonInteractive, and -EncodedCommand, to help the malware run with minimal visible user interaction.
A separate encrypted array holds the PowerShell loader. After decoding it, the JScript stores the loader in an environment variable named z6ti4ttoCGD1. It also places a script-path value in another environment variable, kYcT4A1u9jXwA.
The most notable evasion step occurs inside PowerShell. Rather than storing the payload in one large command or file, the loader splits it into 364364364 separate process environment variables. It later concatenates these fragments at runtime.
The malware also breaks up sensitive .NET method names, such as Load, into multiple strings. This is intended to evade AMSI, endpoint inspection, and signature-based detections that look for obvious malicious PowerShell terms.
Finally, the payload is encoded using CJK or Hanzi characters instead of common formats such as Base64 or hexadecimal.
The loader converts each character back into a byte by subtracting 0x4E000x4E000x4E00, then uses .NET reflection to load the reconstructed assembly in memory and invoke its entry point.
FIRE said the loader architecture is the key concern because it may be reusable with different malware families. The final-stage .NET payload has been associated with Agent Tesla. However, the researchers have not yet recovered and directly analyzed that assembly.
Researchers said there is insufficient evidence to attribute the activity to a specific advanced persistent threat group or to determine whether the loader is part of a crypter-as-a-service offering. The layered design could indicate tailored tooling, but that remains a hypothesis, Fortra said.
The activity highlights a broader fileless malware trend, attackers are shifting payloads into volatile process memory, scripts, and environment variables where traditional dropped-file detection has fewer chances to stop them.
Maintaining PowerShell script-block logging, AMSI visibility, command-line monitoring, process-tree telemetry, and memory-focused endpoint detection is increasingly essential.
Prevent critical incidents and financial loss with stronger proactive defense. Integrate a live threat feed from 15K SOCs
