Unmasking a Multi-Stage Loader: AutoIt Abuse Leading to Vidar Stealer Command-and-Control Communication

LevelBlue’s Security Services issues Threat Analysis reports to inform on impacting threats. The Threat Analysis reports investigate these threats and provide practical recommendations for protecting against them.

In this Threat Analysis report, we investigate a multi-stage malware execution chain identified through proactive threat hunting activities within a client environment. LevelBlue’s Endpoint telemetry and dynamic analysis revealed a sequence of processes demonstrating script masquerading, defense evasion, staged payload extraction, and command-and-control (C2) communication.

Key points

• The infection chain began with the execution of MicrosoftToolkit.exe, a commonly abused tool, which spawned a command shell to initiate the next stage of the attack.

• A disguised file (Swingers.dot) was renamed to a .bat script and executed, demonstrating file extension masquerading to bypass security controls.

• The attack included process discovery and termination attempts (tasklist, findstr), followed by payload extraction using extract32.exe and execution of an AutoIt loader (Replies.scr) with an external parameter.

• Outbound network connections from the AutoIt component to infrastructure associated with the Vidar Stealer were observed, indicating deployment of an information-stealing payload.

Introduction

AutoIt is a legitimate Windows scripting language designed to automate tasks such as system administration and application interaction. While it is widely used for benign automation, threat actors frequently abuse AutoIt to create compiled scripts that can execute malicious code, load encrypted payloads, and evade traditional security detection. Because AutoIt executables resemble normal applications, they are often used as stealthy loaders in multi-stage attacks.

In this incident, an AutoIt-compiled script (Replies.scr) was used as a loader component within the attack chain. The script processed an external payload file and subsequently initiated network communication.

Further analysis confirmed communication with infrastructure associated with Vidar, a well-known information-stealing malware capable of harvesting credentials, browser data, cryptocurrency wallets, and system information.

Vidar is a prominent information-stealing malware that first appeared in late 2018 and was developed using the source code of the Arkei stealer.

The observed behavior indicates that the AutoIt component functioned as a delivery mechanism for the Vidar stealer.

Figure 1. Vidar infection chain.

Attack Flow Breakdown

Figure 2. Attack tree observed in LevelBlue’s EDR.

Figure 3. Another instance of Replies.scr making a C2 connection.

Attack Overview

The attack chain begins with the execution of Microsoft Toolkit, a commonly abused hack tool. This initiates a sequence of commands that rename and execute a disguised script file.

The script performs environment checks and attempts to identify security-related processes before extracting additional payload components. An AutoIt-compiled executable is then executed with an external payload file, indicating a staged loader architecture.

Subsequent activity reveals outbound communication to infrastructure associated with Vidar, confirming the deployment of an information-stealing payload.

Attack Type: Loader / Dropper infection chain

Technical analysis

LevelBlue’s EDR telemetry and dynamic analysis revealed the following sequence:

• Execution of MicrosoftToolkit.exe (hack tool)

• Spawn of cmd.exe

• Renaming and execution of swingers.dot as swingers.dot.bat

• Process discovery (tasklist, findstr)

• Payload extraction via extract32.exe

• Execution of replies.scr with parameter D

• Execution delay/Synchronization via waitfor.exe

• Outbound C2 communication from a secondary instance of replies.scr consistent with Vidar infrastructure

Execution and Initial Staging

The use of a hack tool as the initial execution vector suggests user-driven execution, likely under the assumption of legitimate software activation. This technique reduces the need for traditional delivery mechanisms such as phishing or exploitation.

The malware uses .dot files as a payload container format, likely hiding encoded or segmented data inside multiple files.

Figure 4. Snippet of files created by Microsofttool.exe.

Masquerading and Script Execution

Renaming .dot file to .bat file enabled the execution of embedded commands while evading simplistic file-type controls. This reflects a reliance on user-space scripting rather than exploit-based delivery.

Figure 5. File-based staging and renaming.

Defense Evasion

The invocation of tasklist.exe and findstr.exe indicates active enumeration and potential disruption of security tooling. This behavior is consistent with attempts to weaken endpoint visibility prior to payload deployment.

Payload Staging

The subsequent execution of replies.scr (AutoIt-compiled binary) with an external argument (D) demonstrates a staged loader architecture, where the AutoIt binary functions as a loader rather than the final payload.

AutoIt provides a flexible and low-friction mechanism for executing malicious logic while blending in with legitimate administrative tooling.

Payload Reconstruction

Data is progressively:

• Extracted from .dot files

• Filtered via findstr

• Written into Replies.scr

• Executed with argument D

This indicates a builder-style loader mechanism.

This matches typical loader behavior: the initial .scr file (Replies.scr) interacts with an encrypted payload (D) and then reads it into memory for decryption and execution.

Figure 6. Replies.scr interacting with file D.

Figure 7. Replies.scr reading from file D.

Figure 8. Binary file D loaded by Replies.scr.

Vidar Analysis

As soon as we load and run the extracted executable payload into x64dbg, we get the following message.

Figure 9. Snippet from x64dbg runtime.

We observed that this executable has several anti-analysis methods. The malware employs anti-debugging techniques using ZwQueryInformationProcess to query process debug-related attributes, such as ProcessDebugPort and ProcessDebugFlags. This allows the malware to detect the presence of a debugger and alter execution accordingly.

In addition to looking for a debugger, the malware queries ProcessInstrumentationCallback (0x25) via ZwQueryInformationProcess to detect the presence of instrumentation callbacks often used by EDRs or monitoring tools. If detected, the malware may alter execution or evade analysis.

C2 Communication

The malware invoked InternetConnectA with a URL pointing to https[:]//telegram[.]me/sre22qe and https[:]//steamcommunity[.]com/profiles/76561198777118079. This indicates the use of WinINet-based communication for remote interaction.

Additionally, the presence of Sleep referenced in a preserved register suggests potential anti-analysis or execution delay behavior prior to network communication.

Figure 10. Call to InternetConnectA.

Figure 11. Sleep API pointer.

Figure 12. Call to InternetConnectA

Figure 13. Sleep API pointer.

The malware constructs an HTTP GET request using HttpOpenRequestA, targeting the path /sre22qe on the host telegram[.]me. This results in a full request to https[:]//telegram[.]me/sre22qe. The use of a GET request suggests that the malware is likely attempting to retrieve configuration data or staging information from a remote resource prior to executing further actions such as data exfiltration.

It also establishes an HTTP connection to steamcommunity[.]com using the WinINet API. It constructs a GET request targeting the following resource:

https[:]//steamcommunity[.]com/profiles/76561198777118079.

This behavior is implemented via InternetConnectA followed by HttpOpenRequestA, where the HTTP method ("GET") and object path ("/profiles/76561198777118079") are explicitly defined in memory.

Figure 14. Calls HttpOpenRequestA to construct an HTTP request.

The use of a legitimate platform such as Steam suggests potential abuse of public web content for C2 or configuration retrieval.

The malware initiates an HTTP request using HttpSendRequestA. At the time of the call, no request headers or payloads are present, and the optional data buffer is NULL with a length of zero. This suggests that the request is used as a beacon or polling mechanism rather than immediate data exfiltration.

Figure 15. Call to HttpSendRequestA

The destination endpoint was identified earlier via InternetConnectA / HttpOpenRequestA, indicating a structured C2 communication channel.

The malware also performs DNS resolution for gz[.]technicalprorj[.]xyz via public DNS (8.8.8[.]8), indicating dynamic infrastructure usage prior to establishing outbound communication.

Observed network activity aligns with known patterns associated with Vidar, confirming the final objective of the infection chain. This includes likely exfiltration of credentials, browser data, and other sensitive information.

Post-Execution Cleanup and Artifact Removal

The malware (MicrosoftToolkit.exe) was observed terminating its own processes and removing files dropped during execution. This behavior is consistent with indicator removal and operational cleanup.

This capability significantly reduces forensic artifacts and may hinder retrospective investigation.

Post-Execution Cleanup and Anti-Analysis Behavior

During dynamic analysis, the malware (MicrosoftToolkit.exe) was observed performing post-execution cleanup activities, including:

• Deletion of dropped or staged files from the disk

• Removal of execution artifacts

• Termination of its own processes

This behavior indicates an attempt to minimize forensic artifacts and reduce the detection footprint on the infected system.

The malware is walking a linked list of .dot payload files, resetting their attributes, deleting them from disk, and freeing all associated memory structures to erase traces.

Figure 16. Deletion routine for the files written on disk.

After finishing cleaning up its dropped .dot files, the malware runs an internal routine, then switches its working directory to the staging folder to continue execution using relative paths.

Figure 17. Transition in execution flow.

Afterwards, it iterates through a directory using FindNextFileA and deletes each file it finds, cleaning up other files dropped onto the disk.

Figure 18. File-enumeration and deletion.

Figure 19. Snippet of all the files/folder dropped on disk and later deleted.

The malware performs final cleanup and then terminates itself using RtlExitUserProcess, indicating the end of a single execution cycle after completing its file-based payload operations.

Figure 20. Termination of the current process.

Such cleanup routines are commonly used by malware for:

• Defense evasion, by removing indicators of compromise (IOCs)

• Operational security (OPSEC), reducing the likelihood of detection by security tools

• Anti-analysis, limiting the ability of analysts to recover payloads

Observed behavior is consistent with anti-analysis or OPSEC techniques.

Threat Assessment

The observed activity reflects a commodity stealer infection chain with moderate-to-high sophistication in execution flow and evasion. While individual techniques are not novel, their combined use demonstrates:

• Effective blending with legitimate tools

• Reduced on-disk footprint

• Rapid transition from execution to data exfiltration

Vidar is known to target:

• Browser-stored credentials

• Session cookies

• Cryptocurrency wallets

• System and user data

• The presence of C2 communication indicates a high risk of data compromise.

Conclusion

This intrusion highlights the continued effectiveness of script-based, multi-stage loaders in delivering commodity information stealers such as Vidar. A sophisticated multi-stage loader infection leveraging Windows-native tools and file-masquerading techniques. The attacker avoids dropping a single identifiable malware binary and instead reconstructs and executes payloads dynamically through staged file manipulation.

The use of AV enumeration, LOLBin chaining, and script-based execution strongly indicates a preparatory stage for deeper compromise.

The incorporation of defense evasion and artifact cleanup techniques underscores the need for behavioral detection and proactive threat hunting to identify such activity before data exfiltration occurs.

The observed self-cleanup behavior further complicates forensic analysis and may hinder traditional incident response efforts.

Remediation and Mitigation

• Affected systems should be immediately isolated from the network to prevent further data exfiltration and lateral movement.

• Given the capability to download additional malware, full system reimaging is strongly recommended to ensure complete eradication.

• As Vidar primarily targets credential theft, all potentially compromised credentials including browser, email, VPN, and administrative accounts must be reset, and active sessions invalidated.

• Multi-factor authentication (MFA) should be enforced across critical services to reduce the risk of unauthorized access.

• Network defenses should be strengthened by monitoring DNS and outbound traffic for suspicious connections, including communication with newly registered or uncommon domains.

• To prevent recurrence, organizations should restrict the execution of unauthorized or untrusted tools.

Hunting Query

Note that the query is already run by LevelBlue’s Global SOC in the environments of MDR Complete customers to ensure that possible infections are detected and notified as soon as possible.

1. To detect the execution of renamed AutoIt execution, we recommend running the following hunting query in LevelBlue’s Defense Platform.

• File Element -> add the filters “File Display Name doesn’t contain autoit or au3check” and “File Product Name contains autoit”

We provided the following hunting query to obtain the same result:

https://[yourenvironment]/#/s/search?queryString=0<-File"elementDisplayName:!autoit%7Cau3check,productName:@autoit"->Process.imageFile&sorting=creationTime&sortingDirection=-1

2. To detect communication to domains and IPs associated with this infection, we recommend running the following hunting query in LevelBlue’s Defense Platform:

• Domain name Element -> add the filters “Domain Display Name contains gz.technicalprorj[.]xyz or telegram[.]me” and select the “DNS query resolved Domain to IP (Source Domain)” Element.

We provide the following hunting query to obtain the same result:

https://[yourenvironment]/#/s/search?queryString=0<-DomainName"elementDisplayName:@gz.technicalprorj.xyz%7Ctelegram.me"->DnsQueryResolvedDomainToIp.sourceDomain

LevelBlue’s Security Recommendations

We recommend the following actions in LevelBlue’s Defense Platform:

• Enable Application Control to block the execution of malicious files.

• Enable Anti-Ransomware in your environment’s policies, set the Anti-Ransomware mode to Prevent, and enable Shadow Copy detection to ensure maximum protection against ransomware.

• Enable Variant Payload Prevention with prevent mode on LevelBlue’s Behavioral Execution Prevention tool.

LevelBlue is dedicated to teaming with defenders to end cyberattacks from endpoints to the enterprise to everywhere. Learn more about LevelBlue’s XDR, check out our Extended Detection and Response (XDR) Toolkit, or schedule a demo today to learn how your organization can benefit from an operation-centric approach to security.

IOCs

MITRE ATT&CK Mapping