JS#SMUGGLER: Multi-Stage - Hidden Iframes, Obfuscated JavaScript, Silent Redirectors & NetSupport RAT Delivery
Threat Intelligence, Threat Research, Threat Security
JS#SMUGGLER: Multi-Stage – Hidden iframes, Obfuscated JavaScript, Silent Redirectors & NetSupport RAT Delivery
By Securonix Threat Research: Akshay Gaikwad, Shikha Sangwan, Aaron Beardslee
December 03, 2025
tldr:
The Securonix Threat Research team has analyzed a sophisticated web-based multi-stage malware campaign. The attack chain unfolds across three distinct stages: (1) an obfuscated JavaScript loader injected into a compromised website, (2) a stealthy HTA (HTML Application) that executes encrypted PowerShell stagers via mshta.exe, and (3) a final PowerShell payload that downloads, extracts, executes, and establishes persistence for a Windows-based remote access Trojan.
Our analysis confirms that the final malware delivered through this chain is **NetSupport RAT**, a widely abused remote-administration tool repurposed for malicious use in modern intrusion campaigns. NetSupport RAT enables full attacker control over the victim host, including remote desktop access, file operations, command execution, data theft, and proxy capabilities. Its use as the last stage highlights the actor’s objective: full, persistent remote access.
Introduction:
This blog breaks down a multi-stage web-based malware operation that uses hidden iframes, obfuscated loaders, and layered script execution to silently deploy a remote access payload. We walk through each stage to reveal how attackers achieve stealthy, persistent control over compromised systems.
Key Findings:
This threat demonstrates multiple advanced and rarely documented behaviors:
- Multi-layer obfuscation via numeric index mapping and dynamic array rotation.
- Device-based(mobile/desktop) branching and domain rotation.
First-visit persistence logic in the JavaScript loader. - HTA-based code execution via mshta.exe.
AES-256-ECB encrypted PowerShell payloads with Base64 + GZIP compression. - Downloads and deploys **NetSupport RAT**, a fully featured remote access framework.
- Achieves persistence through disguised Startup shortcuts.
These traits strongly indicate an actively maintained, modular malware framework optimized for stealth and control.
STAGE 1: Initial Execution: Obfuscated JavaScript Loader
1. Stage 1 Overview
The first stage of the attack begins with the heavily obfuscated JavaScript loader retrieved from https://boriver[.]com/call/phone.js, triggered through silent redirects embedded into compromised websites. Once executed, the script initializes a rotating array–based obfuscation scheme, activates its decoder functions, and waits for the DOM to fully load before proceeding. From there, it dynamically profiles the victim’s device to decide whether to inject a fullscreen iframe (mobile) or load a remote second-stage script (desktop). The loader also implements a subtle first-visit tracking mechanism using localStorage to ensure the malicious logic executes only once per user, reducing noise and increasing stealth. Through runtime decoding and branching logic, Stage 1 lays the groundwork for the remaining stages by stealthily constructing malicious URLs and fetching the HTA payload from attacker-controlled infrastructure.
2.Obfuscated JavaScript (phone.js)
Instead of relying solely on compacted or encrypted code, the attackers flooded the script with massive comment blocks filled with randomly generated words, inserting them between nearly every line of functional JavaScript. This technique ballooned the file into thousands of lines of meaningless filler, effectively burying the malicious logic under a mountain of harmless-looking noise.
Figure 1 Obfuscated JavaScript (phone.js)
The sheer volume of junk text made the script resemble an ordinary, human-written document rather than an active malware loader, allowing it to slip past traditional detection mechanisms. By disguising the true behavior inside pages of natural-language–style comments, the attackers ensured that initial inspection tools—and even some automated scanners—were far less likely to recognize the script’s real purpose.
3. De-Obfuscation & String Decoding:
CyberChef effectively peeled back the script’s obfuscation by decoding the rotating string tables and the numeric index lookups. This exposed the true behavior of the loader, including its URL generation routines and conditional redirection logic.
Figure 2 De-Obfuscated JavaScript using CyberChef tool.
The first stage of the attack is where the malware framework truly reveals its sophistication. Hidden behind layers of dense obfuscation, the JavaScript loader delivered from the compromised site springs into action the moment the page loads. Instead of executing immediately, the script quietly initializes a rotating array of scrambled strings, activates its decoder functions, and patiently waits for the DOM to become ready. From there, it adapts dynamically—profiling the user’s device, deciding whether to inject a full-screen iframe or pull a remote payload, and even tracking first-time visitors through a subtle localStorage flag. This silent choreography enables the loader to construct malicious URLs on the fly, avoid repeated execution, and seamlessly fetch the next stage from attacker-controlled domains like stoneandjon.com and boriver.com. What looks like a simple script tag on the surface is, in reality, a finely tuned delivery mechanism engineered for stealth and precision.
4. Obfuscation Logic:
The script uses multiple layers of nested IIFEs (Immediately Invoked Function Expressions) and numeric index-based lookup functions to hide all meaningful strings and logic. By constantly rotating the underlying arrays, it ensures that calls like _0x497e(0x83) only resolve to readable values (e.g., ‘iframe’, ‘script’, ‘body’, CSS styles, or the final malicious URL) at runtime, making static analysis and signature-based detection much harder.
At the core of the obfuscation, the code wraps its logic in several Immediately Invoked Function Expressions (IIFEs) that run as soon as the script loads. Inside these IIFEs, the malware maintains large arrays of scrambled strings and numeric constants. The “decoder” functions (such as _0x497e, _0x11e7, _0x21ac, _0x4fc5) don’t store the real strings directly; instead, they take a hex or numeric index (like 0x83), apply an offset, and then fetch the corresponding element from a rotated array.
Figure 3 IIFEs function and Numeric index-based lookup function Expressions
The while-loops you see (while (!![]) { … }) are responsible for repeatedly shifting (shift()/push()) the array elements until a calculated checksum (_0x266cb8, _0x2de05d, etc.) matches a target value. When the correct arrangement is reached, every subsequent call to _0x497e(0x83) or similar indices will return meaningful strings such as ‘iframe’, ‘script’, ‘body’, the CSS used to style the fullscreen iframe, or the dynamically constructed malicious URL. This design forces analysts and tools to actually execute or emulate the script to see the real values, significantly complicating static reverse engineering.
5. Key Decoder Functions
The _0x497e function acts as a string decoder. Instead of storing readable strings directly in the code, it uses an index and a pre-defined array to reconstruct the original values at runtime. This helps the script hide meaningful strings (like URLs, DOM element names, and keys) from static analysis.
Figure 4 Key Decoder Function
The snippet works as a lookup/decoder wrapper around the _0x19d1() array. The first call initializes _0x19d1ba with a pool of obfuscated strings, then replaces _0x497e with an inner function that:
- Adjusts the numeric argument (_0x497e66 – 0xec) to compute the correct index.
- Uses that index to fetch a value from the _0x19d1ba array.
As a result, any call like _0x497e(0x109) is not a raw constant—it’s a dynamic lookup into a rotated string pool. This indirection makes it harder to understand the script without executing or emulating the decoder.
6. Clean Versions of Decoded Functions
- generateRandomString(): This function creates a randomized alphanumeric token used to construct dynamic URLs. It selects characters from an encoded character set and assembles them into a string of a specified length.
Figure 5 Generate random string function
Inside the function, the script first retrieves an obfuscated character pool (letters, numbers, etc.) via _0x4fc5(0x7a). It then loops for the number of characters specified in _0x4815c1, and during each iteration, it uses Math.random() and Math.floor() to select a random index from that character set. The corresponding character is appended to _0x5705bc, gradually building a fully randomized string. This string is later used to generate unique, unpredictable URL paths—an effective way for the attacker to evade static URL-based detection or caching by security tools.
- checkLastVisit(): This function uses localStorage to determine whether the script has already executed on the user’s device. It sets or reads the lastVi key, enabling the malware to enforce “first-visit-only” behavior for stealth.
Figure 6 Check last visit function
The function retrieves the value of localStorage[‘lastVi’] through obfuscated lookup calls. If the key does not exist, the script writes the current timestamp into localStorage and returns false, signaling this is the first visit. If the key does exist, it returns true, meaning the script has been executed before. This mechanism prevents multiple triggers of the malicious redirection or injection logic, reducing suspicious repeated activity and helping the malware blend in by only executing once per browser profile.
- createIframe(): This function builds and injects a fullscreen, invisible iframe into the webpage, directing the victim to a malicious URL. This method enables seamless redirection without user interaction and is primarily used when the script detects a mobile device.
Figure 8 Create Iframe function
The function begins by creating a new <iframe> element through obfuscated DOM calls. It then applies a predefined CSS style string—resolved at runtime—which forces the iframe to occupy the full screen (width:100%, height:100%, position:fixed, top:0, left:0, z-index:9999, border:none). Once styled, the iframe’s src attribute is set to the malicious URL passed into the function. Finally, the iframe is appended to the document’s <body>.
This ensures that the user is silently redirected or overlaid with attacker-controlled content, making the transition appear instantaneous and minimizing any visible indicators of compromise.
- createScript(): The createScript() function dynamically generates a <script> element and loads a remote JavaScript payload from the attacker’s C2 server. This mechanism is used to deliver Stage 2 of the malware when the victim is on a desktop environment.
Figure 9 Create script function
The function first creates a new <script> element using an obfuscated call to document.createElement(). It then sets the script’s src attribute—decoded at runtime through the _0x21ac function—to the malicious URL passed in (_0x481c5b). Once configured, the script is appended to the document’s <body> via another obfuscated DOM reference.
As soon as the element is inserted, the browser automatically retrieves and executes the remote JavaScript. This allows the attacker to load additional malicious stages on demand, leverage domain rotation, and blend malicious activity into normal web scripting behavior.
isMobileDevice(): This function checks the browser’s user-agent string to determine whether the victim is using a mobile device. This allows the script to branch its behavior—typically redirecting mobile users through a fullscreen iframe while desktop users receive a different payload.
Figure 7 Mobile device check function.
The function leverages a simple regex test (/Android|iPhone/i) against navigator.userAgent, accessed through an obfuscated index lookup. If the user-agent contains indicators of an Android or iPhone device, the function returns true; otherwise, it returns false. This device-aware branching enables attackers to tailor the infection path, hide malicious activity from certain environments, and maximize their success rate by delivering platform-appropriate payloads while avoiding unnecessary exposure.
- DOMContentLoaded Handler: The DOMContentLoaded handler ensures that the malicious loader runs only after the webpage’s DOM has fully initialized, preventing errors and making the redirection or payload execution appear seamless. Once triggered, it generates a randomized URL, checks whether the user has visited before, and then launches either the iframe or script-based delivery path.
Figure 10 DOMContentLoaded handler function
When the browser fires the DOMContentLoaded event—decoded from obfuscated constants via _0x4eba19()—the callback function executes. Inside it, the script creates an 8-character randomized token with generateRandomString(), appending it to a hardcoded attacker URL to produce a unique request each time.
The loader then calls checkLastVisit() to determine whether this browser has already been targeted. If not, it inspects the device type: mobile users are redirected via a fullscreen iframe (createIframe()), while desktop users receive a remote script injection (createScript()).
By deferring execution until the DOM is ready, the attacker avoids race conditions, ensures all DOM functions exist, and blends malicious behavior into the normal lifecycle of the webpage.
7. Stage 1 Sandbox Execution Results (Node.js Safe Environment)
During controlled execution in a mocked Node.js “browser” environment, we captured the loader’s behavior step by step. The script first registered a window.addEventListener handler for the DOMContentLoaded event, then, when the event was simulated, it queried localStorage.getItem(‘lastVi’), which returned undefined (indicating a first visit). The loader then set localStorage.setItem(‘lastVi’, 1764235237460) and proceeded to create a <script> element with its src pointing to https://stoneandjon[.]com/tue/day.php?c5BDyXF8.
Figure 11 Sandbox execution results using Node.js
This runtime trace confirms three critical behaviors:
- The malicious URL is fully decoded and constructed at runtime.
- The lastVi key is assigned on first execution to enforce stealthy, one-time behavior.
- The loader chooses to inject a remote script payload (rather than an iframe) into document.body, aligning exactly with the desktop-branch logic observed in the deobfuscated code.
STAGE 2: Malicious HTA Loader (mshta.exe)
1. Stage 2 Overview
Stage 2 is delivered as a stealthy HTML Application (HTA) retrieved from the attacker-controlled URL https://stoneandjon[.]com/tue/day.php?58DyXF8, which is dynamically generated during Stage 1 execution. Leveraging mshta.exe—a trusted Microsoft-signed binary often abused for covert execution—the HTA runs completely hidden from the user. Once launched, it writes an encrypted PowerShell stager to disk, decrypts it using a layered AES-256-ECB → Base64 → GZIP workflow, and then executes the resulting payload entirely in memory to avoid detection. After execution, the script removes its temporary files, minimizing forensic visibility. This HTA stage forms the essential bridge between the obfuscated JavaScript loader and the fully weaponized PowerShell payload.
2.Malicious HTML Application (HTA) (day.php)
This script operates as a fully weaponized malicious HTML Application (HTA) that serves as the second-stage loader, activated only after the obfuscated JavaScript from Stage 1 performs its checks and redirects. Executed through mshta.exe, a trusted Windows binary commonly abused for LOLBAS evasion, the HTA immediately runs in a hidden state to avoid user awareness.
Figure 12 Malicious HTA loader script
Once triggered, the HTA quietly constructs a temporary PowerShell stager and writes an encrypted payload blob to disk. It then begins a multi-layered decryption workflow—AES-256-ECB decoding, Base64 extraction, and GZIP decompression—to reconstruct the final PowerShell payload. After preparing this decrypted payload, the script executes it entirely in memory, ensuring fileless operation and evasion of traditional security tools. This orchestration makes the HTA a crucial component in the infection chain, seamlessly bridging the JavaScript loader and the final-stage malware deployment.
3. HTA Stealth Behavior
The HTA is configured to run completely hidden from the user. By disabling all visible window elements and minimizing the application at startup, the attackers ensure that the HTA executes silently without drawing any attention.
Figure 13 HTA Stealth function
The <HTA:APPLICATION> block defines how the HTML Application behaves when launched through mshta.exe. Settings like border=”none”, caption=”no”, showintaskbar=”no”, and sysmenu=”no” strip away all UI components, preventing any visible window from appearing. Additionally, windowstate=”minimize” suppresses the application even further by minimizing it immediately upon launch. This configuration guarantees a fully hidden execution environment, allowing the malicious HTA to run its stager and decryption routines without alerting the victim.
4. Encrypted Stager File Creation
This portion of the HTA script uses Windows ActiveX components to create a temporary PowerShell stager on disk. By writing the decrypted payload into a file inside the system’s TEMP directory, the attackers prepare the next step of the infection chain while keeping all operations hidden from the user.
Figure 14 Encrypted stager file creation function
The script instantiates the Scripting.FileSystemObject ActiveX object to interact with the file system. Using GetSpecialFolder(2), it targets the TEMP directory, a common location for staging malicious files because it typically avoids permission prompts and blends into normal system activity. The script then creates a file named temp_file_to_run.ps1 and writes the decrypted PowerShell payload (params) into it. Once the content is fully written, the file handle is closed, leaving a ready-to-execute stager that will be invoked in the next step of the HTA’s execution chain. This technique provides a clean handoff to PowerShell while limiting visibility and forensic artifacts.
5. ExecutionPolicy Bypass with PowerShell
The HTA uses the Shell.Application ActiveX object to launch PowerShell with ExecutionPolicy Bypass, ensuring that the malicious stager runs without restrictions. This allows the attacker’s PowerShell payload to execute silently, even on systems where script execution is normally blocked.
Figure 15 ExecutionPolicy bypass execution function
By creating an instance of Shell.Application, the script gains access to the ShellExecute method—commonly abused in malware for stealthy process execution. It invokes powershell.exe with the arguments -ExecutionPolicy Bypass -File “<path>”, overriding Windows security policies that would typically prevent unsigned or untrusted scripts from running. The final parameter (0) ensures that PowerShell launches in a hidden window, maintaining a low profile. This step is crucial in Stage 2, as it transitions the attack from the HTA loader to a fully capable PowerShell stager while avoiding detection by system safeguards.
6. AES + Base64 + GZIP Decryption Steps
The HTA performs a multi-layered decryption routine to reconstruct the final PowerShell payload. It decrypts the embedded data using AES-256-ECB, extracts a Base64-encoded segment, and then applies GZIP decompression to produce the fully decoded script.
Figure 16 AES + Base64 + GZIP Decryption function
The payload embedded inside the HTA is deliberately wrapped in several layers of encoding and encryption to evade static detection. First, the script applies AES-256-ECB decryption to the raw binary blob, recovering a structured byte stream. The first 16 bytes of this stream function as an initialization vector or metadata marker, while the remaining bytes represent a Base64-encoded string. Once the Base64 layer is decoded, the output is still compressed—requiring a GZIP decompression step to reveal the final, human-readable PowerShell payload. This multi-stage decoding workflow significantly complicates analysis and ensures the malicious PowerShell code only becomes visible at runtime.
7. Fileless Execution of Decrypted Payload
The final decrypted PowerShell payload is executed directly in memory using a fileless technique. By piping the reconstructed script into a PowerShell instance, the malware completely avoids writing the final-stage payload to disk, significantly reducing opportunities for detection.
$final | powershell –
After the HTA finishes decrypting and decompressing the embedded payload, the script stores the resulting PowerShell command in a variable such as $final. Instead of saving this payload as a .ps1 file, the malware passes it directly to PowerShell via standard input ($final | powershell -). The hyphen (-) instructs PowerShell to read commands from the pipeline rather than a file. This technique is a hallmark of modern fileless malware: it allows attackers to run sophisticated logic entirely in memory, bypassing antivirus engines and EDR tools that rely on scanning files written to disk.
8. HTA Cleanup Routine
After executing the decrypted payload, the HTA removes the temporary PowerShell stager from disk and silently closes itself. This cleanup routine minimizes forensic traces and ensures the infection chain leaves behind as little evidence as possible.
Figure 17 HTA cleanup function
The script uses setTimeout() to trigger a deferred cleanup routine roughly one second after execution begins. Inside a try/catch block, it calls underFile.DeleteFile(fileToExecute) to remove the temporary PowerShell script it created earlier in the %TEMP% directory. The error handling ensures that even if the deletion fails, the malware continues without crashing or generating visible alerts. After attempting the cleanup, the HTA executes window.close() to terminate the application silently. This combination of delayed deletion and hidden exit reinforces the loader’s stealth, making it harder for defenders to recover artifacts or reconstruct the execution chain.
STAGE 3: Final PowerShell Payload (Downloader + NetSupport RAT Installer)
1. Stage 3 Overview
Stage 3 is the fully decrypted PowerShell payload responsible for downloading, unpacking, and installing the final malware: NetSupport RAT. Once executed in memory, the script retrieves a ZIP archive from the attacker-controlled domain, extracts its contents into a stealthy folder under ProgramData, and launches the embedded client executable using a hidden JScript wrapper. To maintain persistence, the script creates a disguised Startup shortcut that ensures NetSupport RAT runs automatically on each login. This final stage transitions the infection from a multi-layered loader chain into an active, persistent remote access foothold on the victim system.
2. Decrypted PowerShell Payload
The decrypted PowerShell payload is responsible for retrieving and deploying the final malware stage. It downloads a ZIP archive from an attacker-controlled URL, extracts a malicious executable, launches it covertly using a JScript wrapper, and then creates a disguised Startup shortcut to ensure persistence. This final-stage executable is confirmed to be a NetSupport RAT client, enabling full remote access to the compromised system.
Figure 18 Decrypted powerShell script
Stage 3 represents the final and most impactful phase of the infection chain. The decrypted PowerShell payload functions as a downloader that retrieves a ZIP archive containing the NetSupport RAT components from an attacker-controlled domain. After downloading the archive, the script silently extracts the contents into a disguised folder under ProgramData, launches the RAT executable through an indirect JScript-based execution method, and establishes persistence via a misleading Startup shortcut. This stage fully weaponizes the compromise by deploying NetSupport RAT, giving the attacker remote control, surveillance capability, and long-term persistence on the victim’s system.
3. Payload Code Behavior
- Download: The PowerShell payload retrieves an externally hosted ZIP archive from the attacker’s infrastructure, pulling down the components required for the final-stage malware.
The script initiates a network request to https://kindstki[.]com/qazx.zip, a C2-hosted archive containing the NetSupport RAT binaries. By downloading a compressed bundle, the attackers reduce detection likelihood and keep individual malicious files hidden until extraction.
- Extraction: Once downloaded, the ZIP is extracted into a benign-looking folder within ProgramData, a location commonly used by legitimate applications.
Figure 19 Unzipped NetSupport RAT components
The payload unpacks the archive into C:\ProgramData\CommunicationLayer\, a directory chosen for its inconspicuous name and permissive user-level access. Storing files here helps the malware blend into normal system activity while avoiding privileged directories that might trigger security alerts.
- Execution: The script launches the extracted NetSupport RAT binary (client32.exe) indirectly through a concealed JScript runner to mask execution flow.
Figure 20 run.js used for execution
Instead of invoking the binary directly, the malware uses a JScript file (e.g., run.js) executed via wscript.exe in silent mode. This indirection obscures the parent–child process relationship, making telemetry-based detection significantly harder for EDR systems.
- Persistence: To maintain persistence, the payload creates a deceptive Startup shortcut named WindowsUpdate.lnk, ensuring the RAT executes automatically on reboot.
Figure 21 WindowsUpdate.lnk used for persistence
The shortcut points to wscript.exe running the attacker’s hidden run.js script in background mode (//B). By placing the .lnk file in the Startup folder and naming it after a legitimate Windows component, the malware gains user-level persistence while blending in with system files to avoid suspicion.
Deep-Dive: NetSupport RAT as Final Payload
NetSupport Manager is a legitimate remote-administration tool. Attackers have repurposed it widely for unauthorized remote control, commonly referred to as **NetSupport RAT** in threat intelligence circles.
When weaponized, NetSupport RAT provides attackers with:
• Full remote desktop control
• File browse/upload/download
• Keylogging capability (if added)
• Command execution
• Proxy tunneling / lateral movement
• Persistent recon and surveillance
In this campaign, the downloaded `cli*.exe` matches known patterns of NetSupport RAT droppers: packaged inside ZIP archives, renamed with generic client identifiers, executed indirectly via JScript, and persisted via Startup folder shortcuts.
Stealth and Persistence Techniques Used
- Execution of NetSupport via hidden wscript.exe.
• Indirection layer (run.js) masks parent-child relationship.
• Persistence through fake WindowsUpdate.lnk.
• Installation under ProgramData\CommunicationLayer (benign-sounding folder).
• No Admin rights required due to user-level persistence model.
Wrapping up…
This campaign demonstrates a modern multi-stage intrusion chain engineered for stealth, modularity, and persistent remote access. Stage 1 employs advanced JavaScript obfuscation, device-aware payload branching, and first-visit logic. Stage 2 escalates to a fully hidden HTA loader that decrypts and executes encrypted PowerShell payloads filelessly. Stage 3 delivers and installs NetSupport RAT, granting full remote control capabilities while persisting silently through Startup shortcuts and indirect execution via JScript.
The sophistication and layered evasion techniques strongly indicate an actively maintained, professional-grade malware framework. Defenders should deploy strong CSP enforcement, script monitoring, PowerShell logging, mshta.exe restrictions, and behavioral analytics to detect such attacks effectively.
Victimology and attribution
This campaign appears to target general enterprise users through compromised websites and silent redirectors rather than a specific industry. The tooling and infrastructure suggest financially motivated operators or access brokers. However, there is currently insufficient evidence to attribute the activity to any known threat group or country.
- Stay alert for web-based social engineering techniques and ensure users avoid interacting with unfamiliar redirects, pop-ups, or download prompts from untrusted sites.
- Validate all software downloads and ensure they originate only from verified, official vendor domains to prevent drive-by infections via compromised websites.
- Strengthen endpoint defenses: Deploy an EDR capable of detecting suspicious script activity, HTA/mshta.exe abuse, fileless PowerShell execution, and anomalous parent-child process chains (e.g., mshta.exe → powershell.exe → wscript.exe).
- Restrict script execution: Enforce controls that block untrusted JavaScript, HTA, and PowerShell scripts from executing—especially those originating from browser caches, %TEMP%, or internet-sourced locations.
- Enable advanced logging: Turn on enhanced PowerShell logging, command-line auditing, and ScriptBlock logging to surface obfuscated commands and multi-stage fileless payloads. Monitor Startup folder shortcuts and unusual file creation in ProgramData or TEMP directories.
- Securonix users can leverage the threat hunting queries below to identify endpoints potentially impacted by this multi-stage JS#SMUGGLER/NetSupport RAT activity.
MITRE ATT&CK Matrix
| Tactics | Techniques | |
| Initial Access | T1189 – Drive-by Compromise | |
| Execution | T1059 – JavaScript Execution
T1059.001 – PowerShell T1218 – Signed Binary Proxy Execution (mshta.exe Abuse) |
|
| Persistence | T1053 – Scheduled Task / Startup Folder Persistence | |
| Defense Evasion | T1027 – Obfuscated / Encrypted Payloads | |
| Execution | T1027: Obfuscated Files or Information
T1140: Deobfuscate/Decode Files or Information T1620: Reflective Code Loading T1036.005: Match Legitimate Name or Location T1562.001: Disable or Modify Tools (Windows Defender) T1497.003: Time Based Evasion (Ping Delay) |
|
| Credential Access | T1056.001: Input Capture: Keylogging | |
| Command and Control |
|
Relevant Securonix detections
- Suspicious MSHTA.exe Child Process Creation Analytic
- Suspicious Covert Base64 PowerShell Execution Analytic
- Potential LNK Persistence File Creation Analytic
Relevant hunting Queries
(remove square brackets “[ ]” for IP addresses or URLs)
index = activity AND rg_functionality=”Next Generation Firewall” AND (requesturl CONTAINS “boriver[.]com” OR requesturl CONTAINS “stoneandjon[.]com” OR requesturl CONTAINS “kindstki[.]com” OR requesturl CONTAINS “cpajoliette[.]com” OR requesturl CONTAINS “emoteragoddess[.]com” OR requesturl CONTAINS “srimedhasoft[.]com” OR requesturl CONTAINS “byspotikfy[.]com” OR requesturl CONTAINS “frostshiledr[.]com” OR requesturl CONTAINS “centaurustermas[.]com”)
index = activity AND rg_functionality = “Web Proxy” AND (destinationaddress = “89.46.38[.]48” OR destinationaddress = “85.158.111[.]126” OR destinationaddress = “85.158.111[.]35” OR destinationaddress = “104.21.8[.]48” OR destinationaddress = “85.158.111[.]123” OR destinationaddress = “98.142.251[.]26” OR destinationaddress = “89.46.38[.]126” OR destinationaddress = “85.158.111[.]113” OR destinationaddress = “98.142.251[.]75”)
index = activity AND rg_functionality = “Microsoft Windows Powershell” AND message CONTAINS “ExecutionPolicy Bypass” AND message CONTAINS “-File” AND message CONTAINS “ShellExecute”
index = activity AND rg_functionality = “Endpoint Management Systems” AND deviceaction = “File created” AND filename IN (“client32.exe”, “run.js”, “WindowsUpdate.lnk,”)
C2 and infrastructure
| Domain | IP |
| boriver[.]com | 89.46.38[.]48 |
| stoneandjon[.]com | 85.158.111[.]126 |
| kindstki[.]com | 85.158.111[.]35 |
| cpajoliette[.]com | 104.21.8[.]48 |
| emoteragoddess[.]com | 85.158.111[.]123 |
| srimedhasoft[.]com | 98.142.251[.]26 |
| byspotikfy[.]com | 89.46.38[.]126 |
| frostshiledr[.]com | 85.158.111[.]113 |
| centaurustermas[.]com | 98.142.251[.]75 |
Indicators of Compromise (IOCs)
| File Name | SHA256 |
| phone.js (Obfuscated JavaScript) | fe8400a81be3de95807396ffa1539e6818c8c586bd8a17d833a573aa5d7b433b |
| hour.js (Obfuscated JavaScript) | 246d7d74deaa27eaad25c97fa302d128a1c8d58058ce4cc95fd6055acbc9b959 |
| bof.js (Obfuscated JavaScript) | a89b471528737b91046fc42527bf84008b067908ccc1bf4318135476c290de61
55ad68ee73fa288698cd3b885196d0d02cdfd417563d247f617bca288243bf44 15a3cd9fc6f3e89fc4901be19b15069ccef0dcdd8071b4900448bf2ab374c002 24a8660ebdf54094d8e787486f19b2823f3bc4382f5ace764429a6b7e48025ea fced9291b4339c4fe3a1abfe5878d210a500afa7e1fa4a3be8613a6791c02b8e |
| buf.js (Obfuscated JavaScript) | 4f0494cf85322d540e9cb87295af1247377bcb65b09254900b7ca29f6f46508f
fced9291b4339c4fe3a1abfe5878d210a500afa7e1fa4a3be8613a6791c02b8e |
| skype.php/ day.php/ prsty.php (HTA Loader) | 9ce88cc6fd2e3d298b97592d431c301d994f9c4ed7a7886c225e167bce29c046 |
| quarz.zip (NetSupport RAT zipped components) | 99744720b128c6ac678a1d6e0fad0e69f159c1606428e91e7d2b7695cc353a80 |
| client32.exe (NetSupport RAT executable) | 06a0a243811e9c4738a9d413597659ca8d07b00f640b74adc9cb351c179b3268 |
