LokiBot Campaign Uses JScript Attachment and .NET Injector to Steal Credentials

A recent LokiBot campaign is using a malicious JScript email attachment, a PowerShell loader, a .NET injector and process injection to steal credentials from Windows systems. The infection chain ends with the LokiBot infostealer running inside a legitimate Windows process.

The campaign was analyzed by LevelBlue SpiderLabs, which described it as a multi-stage LokiBot sample from a recent campaign. The malware arrives through a script attachment, loads intermediate code in memory, and injects the final LokiBot payload into aspnet_compiler.exe.

LokiBot remains dangerous because it targets credentials across many applications. It can collect passwords and account data from browsers, email clients, FTP tools, cryptocurrency wallets and other software used on infected machines.

LokiBot remains active more than a decade after first appearing

LokiBot is not a new malware family. MITRE ATT&CK lists LokiBot as a widely distributed information stealer first reported in 2015. MITRE says it steals usernames, passwords, cryptocurrency wallets and other credentials, and can also create a backdoor for additional payloads.

LevelBlue notes that LokiBot was advertised in May 2015 by vendors using the names lokistov and carter. After source code leaked in 2018, multiple variants and forks appeared, adding new features and helping the malware stay active in criminal campaigns.

The latest campaign shows why older infostealers still matter. Attackers continue to refresh delivery methods and loaders even when the final malware family has existed for years.

Stage	Component	Role in the attack
Stage 1	JScript attachment	Runs through Windows Script Host and launches the infection chain.
Stage 2	PowerShell loader	Decrypts and loads a .NET assembly directly in memory.
Stage 3	.NET injector	Injects the final payload into aspnet_compiler.exe.
Final stage	LokiBot payload	Steals credentials, contacts C2 infrastructure and attempts persistence.

The attack starts with a JScript email attachment

The first stage is a malicious JScript file attached to a phishing email. When a victim opens it on Windows, the script runs through Windows Script Host.

The Microsoft wscript documentation says Windows Script Host provides an environment for executing scripts in several languages. It also notes that Windows script files commonly use extensions such as .wsf, .vbs and .js.

In this campaign, the JScript code uses obfuscation to slow analysis. LevelBlue says the script uses decoy functions and hexadecimal variable names, then decodes a Base64 PowerShell script, writes it to C:\Temp with a random filename, and runs it.

PowerShell loads a .NET injector in memory

The PowerShell stage acts as a .NET assembly loader. It decrypts a long encoded payload with XOR and a hard-coded key, then reflectively loads the resulting assembly into memory.

This approach reduces the amount of malicious code written to disk. It also gives attackers another layer between the initial script and the final LokiBot executable.

The .NET assembly is protected with ConfuserEx, a known .NET obfuscator. After it runs, it prepares the process injection stage and passes both the target executable path and LokiBot payload data to the injector logic.

• The first stage uses an obfuscated JScript file.
• The script decodes and launches PowerShell from C:\Temp.
• PowerShell decrypts a .NET assembly using XOR.
• The .NET assembly loads in memory instead of being written as a normal executable.
• The final payload is injected into aspnet_compiler.exe.

Process injection hides LokiBot inside aspnet_compiler.exe

The injector spawns aspnet_compiler.exe, a legitimate Microsoft ASP.NET compiler process, and places the LokiBot payload inside its memory. This helps the malware run inside a trusted-looking process instead of launching as an obvious unknown executable.

According to LevelBlue’s technical analysis, the injector uses Windows API functions commonly associated with process injection, including CreateProcessA, VirtualAllocEx, WriteProcessMemory, SetThreadContext and ResumeThread.

Once injected, the final LokiBot payload runs as a 32-bit Windows PE executable. It contains encrypted command-and-control addresses and resolves many Windows API functions at runtime through a custom hashing method.

Credential theft is the main goal

After initialization, LokiBot creates a mutex based on the MD5 hash of the system’s MachineGuid registry value. This helps ensure only one copy runs on the infected host.

The malware then calls dedicated credential-harvesting functions for different applications. The LokiBot techniques page lists credential theft from password stores, web browsers, email clients, FTP clients and SFTP clients among its known behaviors.

After collecting credentials, the malware compresses the stolen data using aPLib and sends it to its command-and-control server. LevelBlue says the C2 endpoint data is stored inside the binary using 3DES encryption.

Target area	Why attackers want it
Web browsers	Can contain saved usernames, passwords, cookies and account data.
Email clients	Can expose business accounts, contacts and password reset paths.
FTP and SFTP tools	Can provide access to servers, websites and file stores.
Cryptocurrency wallets	Can lead directly to financial theft.
System details	Can help attackers profile the host for follow-up activity.

Persistence appears broken in newer LokiBot samples

LokiBot attempts to copy itself to the AppData directory and create a registry run key for persistence. However, LevelBlue says newer samples created with custom builders may contain a broken persistence routine.

The issue appears tied to a patched decryption function. Instead of returning the intended registry path for startup persistence, the malware returns a configured C2 address, which breaks the registry run key logic.

Even with broken persistence, the infection remains serious. A single successful run can still steal stored credentials and send them to the attacker before the host is cleaned.

How defenders can detect this LokiBot campaign

Security teams should focus on both file indicators and behavior. Hashes and domains help with immediate hunting, but process chains often provide stronger detection over time.

Unexpected execution of .js attachments, PowerShell launched from script hosts, temporary PowerShell files in C:\Temp, and aspnet_compiler.exe appearing in unusual process trees should all trigger review. Defenders should also watch for outbound HTTP traffic to known LokiBot C2 paths.

The Windows Script Host execution path matters because this campaign starts with script-based delivery. Organizations that do not need users to open script attachments should restrict or block them through email and endpoint controls.

Detection area	Suspicious behavior
Email security	JScript attachments, especially random or long filenames.
Endpoint telemetry	wscript.exe launching powershell.exe.
File system	Random PowerShell files written to C:\Temp.
Process behavior	aspnet_compiler.exe spawned outside normal development or build activity.
Network traffic	HTTP requests to known LokiBot C2 endpoints.

Microsoft Defender controls can reduce script-based risk

Microsoft Defender for Endpoint includes attack surface reduction rules that can help block behavior used in campaigns like this. The Microsoft Defender ASR reference includes rules for blocking obfuscated scripts and blocking JavaScript or VBScript from launching downloaded executable content.

Microsoft says the obfuscated script rule detects suspicious properties inside obfuscated scripts. It also says the JavaScript or VBScript rule prevents scripts from launching potentially malicious downloaded content.

These controls should not replace email filtering, endpoint detection and user training. However, they can add an important layer against script-based malware chains that move from a file attachment to PowerShell and process injection.

Indicators of compromise

The following indicators were published with the campaign analysis. Defenders should use them for hunting, but should also combine them with behavioral detections because LokiBot infrastructure can change quickly.

Type	Indicator	Description
Filename	gruijvdsdbcmcvbtryedfhpoibbedflokjqnb.js	Malicious JScript attachment
SHA256	c099f965144bccd0b590f946659fc3c0747c54aef505b6caaca9078712f455fb	JScript attachment hash
SHA256	64c7dd0a3a3ae49977ac05913d3878000cce14e5d8c1ee05b782bdfd648bde91	.NET injector or intermediate stage hash
SHA256	ad10ff9043d6f327045943635fcbd0c5918acb79dc998db92ee4c7dee5224710	Payload stage hash
SHA256	4c9f271242f61f1a31b8146305e9a7ed512c521445d4f7a7a901e301307add3d	LokiBot PE executable hash
SHA256	5864a697bd7b339f56b05405f29a097cd027cafdcc4e63c2aaeccccbf930605f	Additional LokiBot sample hash
IP address	158.94.211.95	LokiBot C2 server IP address
Domain	kbfvzoboss.bid	LokiBot C2 domain
Domain	alphastand.trade	LokiBot C2 domain
Domain	alphastand.win	LokiBot C2 domain
Domain	alphastand.top	LokiBot C2 domain
URL	hxxp://158.94.211.95/kelly/five/fre.php	LokiBot C2 endpoint
URL	hxxp://kbfvzoboss.bid/alien/fre.php	LokiBot C2 endpoint
URL	hxxp://alphastand.trade/alien/fre.php	LokiBot C2 endpoint
URL	hxxp://alphastand.win/alien/fre.php	LokiBot C2 endpoint
URL	hxxp://alphastand.top/alien/fre.php	LokiBot C2 endpoint

Recommended response steps

Organizations should block script attachments at the mail gateway wherever possible. If business processes require scripts, teams should restrict which users can receive or run them and monitor all script-host activity closely.

Endpoint teams should review alerts involving wscript.exe, powershell.exe and aspnet_compiler.exe. A process chain that starts with a user-opened script and ends in PowerShell or a compiler process should be treated as suspicious.

The ASR rules reference gives administrators specific controls that can help block obfuscated scripts and script-driven payload launches. Security teams should test those rules in audit mode where needed, then move to block mode once compatibility is confirmed.

• Block or quarantine .js attachments from external senders.
• Monitor wscript.exe launching PowerShell.
• Investigate aspnet_compiler.exe when it appears outside expected developer workflows.
• Search hosts for the listed hashes and C2 indicators.
• Reset credentials used on infected systems.
• Review browser, email, FTP, VPN and financial account activity after infection.
• Use behavior-based detection for reflective loading and process injection.

Bottom line

This LokiBot campaign shows how an old infostealer can remain effective when attackers wrap it in a newer loader chain. The JScript attachment starts the infection, PowerShell loads the intermediate stage, and the .NET injector places LokiBot inside aspnet_compiler.exe.

The final goal stays the same: steal credentials and send them to attacker-controlled infrastructure. That makes fast detection, credential rotation and script attachment controls essential.

Organizations should treat LokiBot infections as credential exposure events, not simple malware cleanup cases. Any system that ran the payload may have leaked passwords, browser secrets and application credentials before defenders saw the alert.

FAQ