Tracing a Multi-Vector Malware Campaign: From VBS to Open Infrastructure 

Recently LevelBlue SpiderLabs initiated an investigation into a multi-stage malware delivery campaign initially identified from LevelBlue’s MDR SOC through a SentinelOne detection of a suspicious Visual Basic Script (VBS) file.

While the endpoint protection controls successfully prevented execution of the file, further analysis of the decoded script revealed a fileless loader leveraging Unicode obfuscation, PNG-based payload staging, and a reflectively loaded .NET execution method commonly referred to as the VAI loader .

Continued investigation of the associated artifacts exposed an open-directory attacker architecture hosting multiple similarly obfuscated VBS files, each mapping to different malware payloads, including variations of XWorm and remote access trojans such as Remcos RAT.

Further review uncovered a secondary infection vector hosted within the same infrastructure, involving a weaponized “PDF” and batch script that resulted in further malicious payload deployment and outbound network activity.

Collectively, these findings indicate the activity was not an isolated endpoint event, but part of a broader, reusable malware framework designed to support multiple payloads and delivery mechanisms.

This report outlines the initial detection, subsequent script analysis, infrastructure discovery, and the associated risks and indicators observed during the investigation.

Initial Detection and SOC Triage

The investigation created by LevelBlue’s MDR SOC originated from a SentinelOne detection identifying a suspicious VBS file, Name_File.vbs. The file was observed in the \Users\Public\Downloads\ directory. SentinelOne successfully terminated and quarantined the file under an enforced Protect/Protect policy before execution could complete.

Initial triage conducted by the SOC determined that the file hash did not have an established reputation in available OSINT sources, and no additional detections or related activity were identified within the environment’s historical telemetry. At the time of detection, the activity appeared isolated to a single endpoint.

As part of the triage process, SentinelOne telemetry captured the decoded command-line activity associated with the VBS file, revealing a Base64-encoded PowerShell command. While the initial containment prevented further execution on the affected host, the presence of encoded script content and external network references warranted additional analysis to better understand the intent and potential scope of the activity.

Based on these findings, the investigation transitioned from endpoint-level triage to a deeper analysis of the VBS script and its associated execution logic by LevelBlue’s Cyber Threat Intelligence team to determine whether the activity represented a standalone incident or part of a broader threat campaign.

Decoded VBS Analysis and Loader Behavior

Following initial containment, analysis shifted to the contents and behavior of the detected VBS file to better understand its execution flow and intent. A review of the script revealed that the VBS primarily functioned as an obfuscated launcher, responsible for decoding and executing a secondary PowerShell payload rather than containing the malicious logic directly.

Obfuscated VBS Execution

Figure 1. Name_File.vbs content

Figure 2. Name_File.vbs Unicode removal

Figure 3. Name_File.vbs encoded script after Unicode removal

The VBS script employed heavy Unicode-based obfuscation to conceal its true functionality and evade static inspection. Once decoded, the script was observed to reconstruct and execute a Base64-encoded PowerShell command. This approach allowed the attacker to minimize visible malicious content within the script itself while deferring core functionality to runtime.

Fileless PowerShell Loader Behavior

Figure 4. Name_File.vbs decoded PowerShell command

The decoded PowerShell command exhibited behavior consistent with a fileless malware loader. It explicitly enforced the use of TLS 1.2 and leveraged the Net.WebClient class to retrieve remote content over HTTP. The first URL we analyzed in this script was as follows:

hxxp://ia600606.us.archive[.]org/11/items/msi-pro-with-b-64_20251030/MSI_PRO_with_b64.png

Rather than downloading a traditional executable, the script fetches a PNG file (MSI_PRO_with_b64.png) from the first URL above and searches its contents for embedded data found by custom BaseStart and BaseEnd markers.

Figure 5. MSI_PRO_with_b64.png

Figure 6. MSI_PRO_with_b64.png BaseStart

Figure 7. MSI_PRO_with_b64.png BaseEnd

PNG-Embedded Payload Staging

Our analysis confirmed the PNG file contained a Base64-encoded .NET assembly appended to the image data. The extracted content was decoded and loaded directly into memory using the Reflection.Assembly::Load method, enabling execution without writing a payload to disk. This technique allows malicious code to bypass many traditional file-based detection mechanisms and complicates forensic recovery. The content of this is a malware loader, commonly referred to as PhantomVAI.

Payload URLs Passed to the Loader

Once loaded, the .NET assembly was provided with additional parameters that directed follow-on activity. Two notable URLs were passed into the loader at runtime:

QHe05ycvNWblJnbo9mavI3b0NWZ09mcw9ie5hnLl1GNzdXZu9yL6MHc0RHa -> hxxps://news4me[.]xyz/protector/johnremcos.txt


hxxps://news4me.xyz/uac.png

The first is an obfuscated string that is set to the variable “$hydrotherophyte” where it is later passed into the VAI method to be reversed and Base64 decoded where we see the “news4me[.]xyz/protector/johnremcos.txt” link. This text document also contains obfuscated text that is reversed and Base64 decoded to output a version of Remcos RAT.

The last URL shown in the script is also being passed into the VAI method and contains similar methods of embedding malicious code between “BaseStart” and “BaseEnd” markers. Once decoded, the embedded file is a UAC Bypass DLL used to facilitate privilege escalation.

Execution Flow Summary

Once the assembly was loaded, the script dynamically resolved a specific class and invoked a method (VAI) responsible for orchestrating subsequent execution steps including additional payloads and persistence through scheduled tasks. At this stage, execution control was fully transferred from the initial VBS and PowerShell components to the in-memory .NET loader, showing how it went from script-based delivery to modular payload execution.

This execution pattern shows a separation of responsibilities:

• VBS file acts as an obfuscated launcher
• PowerShell serves as a fileless delivery mechanism
• Embedded .NET assembly provides a framework for executing additional payloads and persistence mechanisms.

This modular design enables attackers to reuse the same loader logic across multiple campaigns, while varying payloads and delivery vectors as needed.

Attacker Infrastructure and Open Directory Architecture

Analysis of the decoded loader behavior and embedded network artifacts led to further examination of the external infrastructure used to support payload delivery. This infrastructure was hosted on an attacker-controlled domain configured with openly accessible directories, enabling direct browsing and retrieval of hosted content. Notably the following:

news4me[.]xyz/coupon/

news4me[.]xyz/protector/

news4me[.]xyz/invoice/

Review of the exposed directories revealed a structured layout supporting multiple stages of infection, with /coupon/ and /protector/ being directly related to one another, and /invoice/ containing a separate attack chain altogether.

Exposed Directory Structure

The presence of multiple openly accessible directories indicates a deliberate infrastructure design rather than accidental exposure. Each directory served a distinct role in the overall infection workflow, allowing the attacker to stage delivery scripts, payloads, and alternate infection vectors from a single domain.

VBS-to-Payload Mapping (/coupon/ and /protector/)

Figure 8. /coupon/ open directory

The /coupon/ directory contained numerous VBS files that were heavily obfuscated using Unicode characters as we previously mentioned. While the scripts differed in appearance, deobfuscation showed that they followed a consistent execution pattern, reconstructing and launching fileless PowerShell loaders similar to the one observed in the initial detection. The different VBS files each mapped to different types of malware stored in text files in the /protector/ directory.

Figure 9. /protector/ open directory

Further inspection of the associated payload directories revealed multiple configuration and staging files corresponding to different malware families. Each obfuscated VBS script appeared to map to a distinct payload hosted within the same infrastructure, indicating a modular delivery model in which the attacker could reuse the same loader framework while selectively deploying different malware depending on the campaign or target.

Alternate Attack Chain via /invoice/

Figure 10. /invoice/ open directory

The /invoice/ directory hosted a separate attack chain with a malicious batch script and a ZIP folder containing a fake PDF internet shortcut file. This delivery path was independent of the VBS-based loaders but relied on the same attacker-controlled infrastructure.

The presence of multiple payloads hosted under a single domain suggests that this infrastructure was designed for scalability and reuse rather than for a single opportunistic intrusion. By maintaining openly accessible directories, the threat actor reduced operational complexity, while enabling rapid modification or expansion of available payloads without altering the initial delivery mechanism.

Examination of the open directories showed that the initial VBS detection was only one entry point into a much larger delivery system. The same infrastructure was being used to host multiple scripts and payloads, enabling different attack vectors without changing the underlying loader.

Secondary Infection Vector via Weaponized ‘PDF’

In addition to the VBS-based delivery mechanisms, further analysis of the attacker-controlled infrastructure revealed a secondary infection vector hosted under an /invoice/ directory. This vector relied on a weaponized “PDF” and showed an entry point separate from the original VBS execution chain.

Weaponized Document and Batch Script Delivery

Artifacts within this directory included a batch script (44rrr.bat) and a compressed archive masquerading as a PDF (Invoice-JL1852586778.pdf.zip) as shown previously. The ZIP file did not contain a legitimate document, but an Internet Shortcut file disguised as a PDF.

Figure 11. Contents of Invoice-JL1852586778.pdf.zip

Figure 12. Invoice-JL1852586778.pdf.zip properties showing a URL address

Figure 13. Full URL for Invoice-JL1852586778.pdf.zip

When executed, the shortcut redirected the system to attacker-controlled, Cloudflare domains such as the decoded URL from the properties section of the file “file://bacteria-spent-endless-grammar.trycloudflare[.]com@SSL/DavWWWRoot/okl” and initiated additional command execution and payload retrieval.

Batch Script Execution and Network Activity

Figure 14. Contents of 44rrr.bat

Figure 15. Sample of 44rrr.bat once changed to UTF-16LE

The batch script was encoded in UTF-16LE, which aligns with typical Windows script handling rather than intentional obfuscation. Upon execution, it ran in a hidden context and established outbound connections to external URLs hosting additional ZIP, BAT, and TXT-based payloads.

Figure 16. Additional sample of 44rrr.bat decoded with encoded URLs inside

Execution resulted in extensive follow-on activity, including the creation of numerous malicious files and the initiation of connections to remote network shares such as the following:

css-direct-excel-highlights.trycloudflare[.]com/1Nov20MA.zip

tammhdka[.]cloud:5790/PHNovSU.bat

Python Payload Deployment and MainRingtones Staging

Sandbox detonation of these files confirmed that this delivery chain facilitated the deployment of Python-based payloads in addition to script-based components. Multiple Python files were written to disk alongside batch scripts and compressed archives, with several staged within a directory named /Contacts/MainRingtones. While the directory name itself appears benign, its contents and observed behavior indicate it was used as a temporary working location for malicious scripts.

Behavioral telemetry associated with the Python components included indicators of memory injection, shellcode execution, and outbound network activity, consistent with loader-style Python frameworks used to support post-execution payload handling. VirusTotal detections further classified these artifacts as Python-based trojans under the Kramer malware family. Although full reverse engineering of each Python script was outside the scope of this investigation, the observed behaviors align with a modular post-compromise workflow.

Cloudflare Infrastructure and Payload Rotation

Figure 17. Malicious Cloudflare open directory

Subsequent inspection of the different associated Cloudflare domains revealed openly accessible directories containing numerous text files that, when decoded, functioned as executable batch logic. Several of these files shared identical hashes while referencing different external resources, reinforcing a pattern of infrastructure reuse and payload rotation.

This mirrors the modular approach observed in the VBS-based delivery chain and supports the assessment that the attacker infrastructure was designed to enable multiple infection vectors using shared hosting and tooling.

Risk, Impact, and Key Takeaways

The activity observed in this investigation presents a moderate to high risk due to the flexibility and reuse of the attacker infrastructure rather than the impact of any single payload. While the initial VBS execution was successfully prevented, the broader campaign demonstrates multiple viable entry points capable of delivering different malware types using the same hosting and delivery framework.

The use of fileless loaders, obfuscated scripts, and payloads embedded within non-executable file formats significantly increases the likelihood of evasion against traditional signature-based defenses. By staging malicious content within PNG files, ZIP archives, and Internet Shortcut files, the attacker reduced reliance on direct executable downloads while maintaining the ability to rapidly modify or rotate payloads.

Open directory configurations played a central role in enabling this campaign. The exposed infrastructure allowed the attacker to host multiple scripts, configuration files, and payloads in parallel, supporting distinct infection vectors such as VBS-based loaders and weaponized document delivery. This approach lowers operational overhead for the threat actor while increasing the potential reach and longevity of the campaign.

The presence of Python-based tooling further amplifies risk, as it introduces an additional execution layer capable of handling post-compromise activity such as payload staging, memory injection, and follow-on command execution. Combined with batch scripting and PowerShell, this multi-language approach provides resilience against partial detection or containment.

Key takeaways from this investigation include:

• A single detection can mask a much broader campaign when modular loaders and shared infrastructure are in use.
• Open directories and cloud-backed hosting can enable rapid payload rotation and support multiple attack vectors from the same domain.
• Non-traditional file formats and scripting languages continue to be effective delivery mechanisms for modern malware campaigns.
• Early containment is critical, but deeper analysis is necessary to assess campaign scope and infrastructure reuse.

Defensive Considerations

Restricting execution of high-risk script types such as .vbs and .bat, particularly from user-writable directories, can help reduce initial access. Constraining PowerShell usage and monitoring in-memory execution techniques further limits attacker flexibility. At the network level, blocking or tightly controlling WebDAV traffic would disrupt Internet Shortcut–based delivery methods, while TLD-based filtering such as restricting “.xyz” domains where possible can reduce exposure to commonly abused infrastructure. Although endpoint protection successfully prevented execution in this case, layered controls remain critical to disrupting multi-vector malware campaigns.

Based on the findings from this investigation, the team implemented custom detections to identify related VBS loaders, PNG-embedded payload staging, and associated infrastructure, improving coverage for similar activity across the environment.

Overall, this activity underscores the importance of investigating beyond the initial alert to identify supporting infrastructure and alternate delivery paths. While endpoint protections successfully mitigated the immediate threat, the findings indicate a reusable malware framework capable of adapting delivery techniques and payloads with minimal changes to its underlying architecture.

Indicators of Compromise