Lumma Stealer HTA Loader Analysis

Static analysis of a Lumma Stealer HTA loader that self-reads, decodes embedded hex payload data, and executes it via eval.

1/12/20263 min read

Overview

Lumma Stealer is an information stealer distributed via malware-as-a-service channels since at least August 2022. This sample represents an HTA-based loader responsible for reconstructing and executing a second-stage payload at runtime. The loader does not contain readable malicious logic prior to execution.


Sample Metadata

Source
MalwareBazaar
SHA256
802150a8445988b00785f115a8ccb6c2c8afa48fe2efebf61cb31e3cf5362d6b
File Type
HTA ASCII text
Archive
Password-protected ZIP

Static Characteristics

File length
Approximately 10,070 lines
Total <script> tags
63
eval calls
1
String.fromCharCode usage
1
parseInt(..., 16) usage
1
replace calls
1
substring calls
1

The first and only eval call does not appear until approximately line 7960.


Loader Logic Summary

The loader follows a self-reading execution model:

  1. Full document contents are read using document.documentElement.outerHTML
  2. A fixed substring is extracted from the document contents
  3. Extracted data is treated as encoded payload material
  4. Payload is decoded from hexadecimal to character data
  5. Decoded script is executed via eval

The payload does not exist as JavaScript until step four completes.

Control flow note: The variable containing the encoded payload is declared around line 4162, but execution is triggered earlier in the file around line 826. This fragmented control flow forces backward tracing and complicates static analysis.


Self-Read Mechanism

The loader reads its own contents into memory:

RewCt = document.documentElement.outerHTML

This allows the file to store encoded payload data inside itself without defining a visible script variable.


Payload Extraction

A fixed region of the file is selected:

iFxUIw = RewCt.substring(27, 187197)

This substring contains only encoded payload data and no executable logic.


Decode Routine

The decode function operates on two-character hex pairs:

  • Regex pairing using global match
  • Hex conversion using parseInt(..., 16)
  • Character reconstruction using String.fromCharCode

This transforms encoded text into executable JavaScript at runtime.


Execution Sink

A single eval call is used as the execution sink. The decoded string is passed directly into eval without intermediate storage. This is the only point at which malicious behavior is introduced.


Payload Storage Strategy

The payload is not stored as a literal script or variable. Instead, the loader embeds encoded data inside the HTA itself and retrieves it via self-read. Only a predetermined slice of the file is meaningful.

This prevents reliable extraction without manual decoding or dynamic execution.


Analysis Limitations

Static analysis cannot recover final network indicators, filesystem actions, or registry modifications. Behavioral analysis is required to observe second-stage activity.


Assessment

This HTA is confidently assessed as a loader.

The decode-to-eval execution chain combined with self-referential payload storage indicates deliberate obfuscation and staged delivery. Severity is high due to its role in deploying Lumma Stealer payloads while evading static inspection.


Detection Notes

  • HTA attachments should be blocked at the email gateway
  • Password-protected archives containing HTA files should be treated as high risk
  • Endpoint monitoring should alert on mshta.exe execution combined with eval usage
  • Content inspection can flag HTA files that read outerHTML, extract large substrings, and reconstruct code using parseInt(..., 16) and String.fromCharCode

References