Weaponizing WhatsApp: From SORVEPOTEL to Astaroth

Blackpoint’s SOC recently responded to a campaign that weaponizes authenticated WhatsApp sessions to deliver a well-known infostealer. The attackers leverage a Python based SORVEPOTEL worm that uses Selenium and ChromeDriver automation to control logged in WhatsApp Web sessions, scrape contacts, and push high trust lure messages at scale. By piggybacking on real conversations and existing browser sessions, the worm turns WhatsApp into a delivery channel that bypasses traditional email defenses and significantly boosts click rates.

When victims click on the lure, which delivers a malicious VBS file, execution shifts to the endpoint. Running that script triggers PowerShell commands that download an additional obfuscated VBS loader and an MSI installer into the user’s temporary directory, then immediately launches both artifacts in parallel. This design creates two distinct execution paths. The first path writes and executes a batch script that installs a bundled Python runtime, retrieves the SORVEPOTEL automation tooling, and enrolls the host into the worm’s WhatsApp propagation network, enabling continued lateral spread.

The second path processes the MSI, which unpacks several staging components, including a compiled AutoIt loader responsible for delivering the final payload. This AutoIt stage decrypts and decompresses an embedded PE entirely in memory using an LCG-based XOR routine and Windows-native decompression functions, then performs a manual mapping sequence to prepare the image for execution without writing it to disk. Rather than executing directly, control is transferred into a hollowed svchost.exe process, where the payload operates as a long-lived, memory-resident implant.

The final payload is Astaroth, also tracked as Guildma, a long-running Latin American banking malware family known for stealthy execution, credential and session theft, and flexible Command and Control (C2). In this campaign, Astaroth operates fully in memory and incorporates newer communication patterns, including mailbox-based IMAP C2 alongside lightweight host telemetry. Combined with the SORVEPOTEL driven social delivery on the front end, the result is a resilient, multi-stage attack chain that blends trusted communication abuse, in-memory execution, and evolving tradecraft to maintain access across compromised hosts.

Key Findings

• Delivery starts with compromised WhatsApp Web sessions, where attackers abuse previously authenticated chats to deliver malicious VBS lures directly to victims.
• When a victim downloads and executes the lure, it triggers PowerShell to pull two files into %TEMP%: an obfuscated VBS loader and an MSI installer.
• The VBS loader reconstructs its logic from over a hundred encrypted fragments, then generates and executes a hidden batch script that begins deploying the SORVEPOTEL runtime.
• The batch script builds a full Python 3.12 environment under C:\temp, installs pip and automation libraries, fetches the correct ChromeDriver version, and launches whats.py with pythonw.exe.
• Once active, the Python based SORVEPOTEL worm weaponizes authenticated WhatsApp Web sessions, scraping contacts and autonomously sending lure messages to propagate the campaign further.
• In parallel, msiexec.exe processes the downloaded MSI, unpacking PE components, helper DLLs, a batch staging script, and a semi compiled AutoIt loader disguised under a .log extension.
• The AutoIt loader retrieves a .tda or .dmp container, applies a Linear Congruential Generator (LCG) driven XOR decryption routine, then uses Windows native decompression APIs to recover an embedded PE payload.
• The recovered payload is manually mapped in memory and executed inside a hollowed svchost.exe process without ever touching disk.
• The resulting Astaroth (Guildma) implant operates as a memory-resident backdoor, using mailbox-based IMAP command and control and lightweight HTTP telemetry.
• The overall chain combines living off the land binaries, parallel execution paths, in-memory loading, and abuse of trusted user sessions to maximize stealth, resiliency, and propagation.

Observed Kill Chain

SORVEPOTEL: When the Chat Logs You Back

The campaign starts upstream on an attacker-controlled machine running a Python-based SORVEPOTEL worm. SORVEPOTEL is a WhatsApp automation tool built on Selenium that hijacks or reuses authenticated WhatsApp Web sessions, scrapes the full contact list, and pushes lure files through existing chat threads. Using ChromeDriver and a cloned browser profile, it launches WhatsApp Web, injects the WPPConnect library, and automates the entire interaction flow as if a real user were at the keyboard. This tooling sits at the core of the propagation chain, and compromised hosts are later leveraged to distribute the same worm to continue spreading the payload further.

The downstream phase begins when a user downloads and runs a malicious .vbs file delivered through one of the worm’s automated WhatsApp messages. Once executed, the script issues two powershell.exe -ExecutionPolicy Bypass calls to pull down an MSI installer and a secondary VBS from varegjopeaks[.]com, then fans out into multiple parallel paths. One path hands control to msiexec.exe to process the MSI, while another path sets up the components needed to deliver SORVEPOTEL onto the host, pulling it into the same WhatsApp driven propagation loop.

Initial PowerShell commands used to fetch the MSI and VBS stages.

The VBS stage is wrapped in heavy obfuscation, storing its real logic across more than a hundred encrypted fragments. Each block is decoded through a multi-step routine that mixes subtraction and XOR operations, then appended into a final buffer. Once reconstruction is complete, the script hands the decrypted payload to ExecuteGlobal, letting it run entirely in memory without dropping any intermediate components to disk.

The decrypted logic is far simpler than the wrapping suggests. Its job is to prepare a writable workspace under C:\temp, generate a temporary batch file, write the next stage commands line by line, execute it through WScript.Shell.Run in a fully hidden window, and immediately remove the batch file once execution finishes. The loader is designed to be purely transitional, serving only to hand control over to the next phase.

Deobfuscated VBS logic showing creation and execution of the next stage.

The batch script dropped by the VBS stage acts as the bootstrapper for the SORVEPOTEL environment. It first makes sure C:\temp exists and then uses it as a dedicated workspace for everything that follows. From there it checks for python.exe, and if it’s missing, downloads the embedded Python 3.12 package directly from python[.]org, unpacks it in place, and wires up python312._pth so the runtime knows where its standard library and site packages live. It then pulls down get-pip.py, installs pip, and provisions a standalone Python runtime that lives entirely under C:\temp.

Batch bootstrapper staging the SORVEPOTEL runtime.

With a local runtime in place, the script moves on to browser automation. It checks for chromedriver.exe, and if absent, queries the installed Chrome version from the registry, fetches the corresponding ChromeDriver build via Google’s Chrome for Testing JSON feed, and falls back to a hardcoded driver URL if that fails. After unzipping the driver and cleaning up, it installs a stack of Python packages used for automation and screen interaction, including requests, Selenium, webdriver-manager, GUI and input libraries, and OCR/vision tooling.

Once the environment is ready, the batch script downloads whats.py from the attacker infrastructure and launches it using pythonw.exe, fully in the background. This is the handoff point where the host stops being just a victim and becomes an active SORVEPOTEL relay. The script initializes a Selenium driven browser session, restores or hijacks an existing WhatsApp Web login, scrapes the full contact list, and begins polling the attacker’s C2 for configuration updates. From there, the compromised machine can automatically send lure messages, upload harvested contacts, and receive new delivery instructions without any user interaction, completing its role in the propagation loop.

Initialization stage of the SORVEPOTEL Python worm.

Astaroth: The Part AutoIt Hoped You Wouldn’t Notice

While the SORVEPOTEL setup chain is spinning up in the background, the other branch of execution hands control to the MSI installer. The VBS loader calls msiexec.exe with the downloaded package, using Windows Installer as the “legitimate” host process to blend in with normal system activity. From there, the MSI unpacks its staged components into user writable locations, including helper DLLs, support files, and a compiled AutoIt stub that serves as the loader for the next stage.

Once the MSI runs, it carves a randomly named working directory under C:\Public\ and stages its next launcher inside it. In our case, the installer created a folder named S2DSystemX.S2D.90878754.4496.284. It then drops a small run.vbs that switches into that directory and silently executes a bundled executable with a .log companion. This pair forms the entry point into the AutoIt loader chain, where the next stage begins unpacking and executing its embedded logic.

Contents of the run.vbs launcher script.

The AutoIt stage was extracted from the MSI dropper and found to be semi compiled, disguised under a .log extension to appear benign. The file contained an .a3x AutoIt object, which is the compiled form of an .au3 script. While .au3 files store human-readable source code, .a3x files are binary objects that require the AutoIt interpreter to run. Because of this, the script logic couldn’t be viewed directly, since its routines and constants were embedded inside the compiled payload.

Confirming the .log file is a compiled AutoIt script via the AU3!EA06 magic bytes.

To obtain a readable version of the script, it was decompiled using the open source autoit-ripper script, which reconstructs a readable .au3 script from the .a3x object. Once decompiled, the recovered source exposed the script’s real functions, constants, and control flow, making it possible to analyze how the loader operates.

The decompiled script functions as a staged loader. It searches the working directory for a .tda file, and if none exists, it falls back to a .dmp file. Once found, the file is opened in binary mode, and its contents are read into memory for processing. This container holds the next stage payload that the script will decrypt, decompress, and execute in memory.

The function loads a .tda or .dmp file, decrypts, and executes it in memory.

The decryption logic relies on a Linear Congruential Generator (LCG) combined with XOR operations. An LCG is a simple pseudo random number generator that produces a sequence of values using a predictable multiply and add formula seeded with an initial state. While typically used for low complexity RNG tasks, here it’s used deterministically to generate a stream of one-byte masks that drive the XOR decryption routine.

The decryption function which uses an LCG to generate XOR masks.

The mask sequence is driven by three constants embedded in the decompiled .au3 script: a multiplier (A = 3333), an increment (B = 3434), and an initial seed (state = 1000). These feed the LCG formula, updating a 16-bit internal state on every iteration to produce a new value after each loop. The high byte of that state, calculated as (state >> 8) & 0xFF, becomes the one-byte mask applied to each encrypted byte, with the result XORed to produce the decrypted output.

Because the same constants and seed are reused on every run, the process is fully deterministic. Given the same input, the mask sequence will always unfold the same way, producing identical decrypted output. This lets the loader reliably recover its payload while still making the encryption appear random to anyone who doesn’t know the constants. With those values in hand, the payload can be decrypted and analyzed as a normal binary.

Once the script finishes decrypting the file, the output still is not usable; it remains a compressed blob rather than a ready-to-run payload. Instead of relying on common libraries like gzip or zlib, the AutoIt script uses Windows built-in compression routines. These functions live in ntdll.dll and are normally used by the operating system for handling compressed data structures and memory segments.

The decompression function which uses Windows native routines from ntdll.dll.

The decompression process happens in two steps. First, the script calls RtlGetCompressionWorkSpaceSize to determine how much temporary memory Windows needs to decompress the data. This function does not decompress anything itself; it only reports the workspace size required by the selected algorithm. After allocating that workspace, the script calls RtlDecompressFragment, which takes the decrypted byte stream, the workspace, and a guessed output buffer size, then attempts to expand the data.

If the initial attempt fails, the script increases the output buffer size or switches to another compression format, such as LZNT1 or XPRESS. This retry loop continues until one combination works, or all options are exhausted. When the call finally succeeds, Windows returns a STATUS_SUCCESS code, and the output buffer contains the decompressed payload.

Now that both decryption and decompression are understood, the same operations can be reproduced with a small Python pipeline. The script applies the LCG based XOR using the recovered constants, then performs the Windows style decompression step to mirror what the AutoIt loader does. Running this sequence against the captured .dmp blob produces the decompressed byte stream, a PE payload that can be inspected and analyzed further.

A Python script replicating the AutoIt decryption and decompression pipeline.

Confirming successful decryption and decompression.

The AutoIt wrapper hands the decompressed PE to an in-memory loader that prepares it for execution by performing a manual map. This loader allocates memory, reconstructs the DOS and NT headers, maps all sections, resolves imports, applies relocations, and sets appropriate memory protections. Rather than executing the payload directly, this mapped image is then used as the source for process hollowing, where execution is transferred into a newly created or existing svchost.exe process.

The loader function which maps and executes the decrypted PE payload.

Once execution is established inside the hollowed svchost.exe process, the implant begins operating as a fully featured Astaroth backdoor. From this trusted system context, it initializes its command channel using hardcoded IMAP configuration embedded within the payload, including the mailbox leonardomilitao1998[@]terra[.]com[.]br. The implant authenticates to this account, periodically polls for new messages, executes received tasking, and returns results through the same mailbox. Using a legitimate email service for Command and Control (C2) allows activity to blend into normal encrypted traffic while avoiding reliance on attacker-owned infrastructure.

From within svchost.exe, the implant maintains a low profile and does not execute continuously. Observed strings indicate passive monitoring for access to Brazilian financial portals and applications through common browsers such as Chrome, Firefox, Edge, Opera, and region-specific banking clients. Referenced targets include major Brazilian institutions such as Banco do Brasil, Bradesco, Santander, Itaú, Banrisul, Sicredi, Sicoob, BMG, and BTG Pactual, along with payment platforms and cryptocurrency services such as Mercado Pago, RecargaPay, and major exchanges and wallets including Binance, Coinbase, Mercado Bitcoin, OKX, Crypto.com, MetaMask, and Trust Wallet, reflecting a broad financial targeting scope consistent with modern Astaroth campaigns.

In addition to mailbox-based control, the implant performs basic host profiling to establish environment awareness. It collects operating system details, processor information, available system memory, and information about installed endpoint protection products using WMI queries. This information is formatted into form-encoded HTTP POST requests and transmitted to an external endpoint at serverseistemasatu[.]com/data.php?recebe, functioning as an initial host registration or telemetry mechanism that provides operators with situational awareness of infected systems.

Taken together, the final stage functions as a stealthy, state driven Astaroth implant built for persistence and selective activation. Execution is anchored within a hollowed svchost.exe process, with mailbox-based IMAP C2 providing a resilient control channel and lightweight HTTP telemetry supporting host registration and environment awareness. Rather than operating continuously, the implant remains idle until activity consistent with Brazilian banking or financial use is observed, at which point it is positioned to act under the context of a trusted system process. This execution model aligns closely with established Astaroth tradecraft and reinforces attribution to this family.

Methodology & Attribution

Attribution for the front end of this operation is assessed as nearly certain to be SORVEPOTEL, based on multiple corroborating indicators. The Python based WhatsApp automation workflow, the Selenium and ChromeDriver session hijack, the WA-JS injection logic, and the attacker-controlled PHP API endpoints all match the tooling and delivery patterns associated with prior SORVEPOTEL activity. These behaviors align with campaigns previously observed across Brazil and Latin America, where SORVEPOTEL has been used to harvest contacts, automate lure delivery, and spread laterally by abusing authenticated WhatsApp Web sessions.

Attribution for the payload side of the chain is assessed as highly probable to be Astaroth, also known as Guildma. The infection flow follows the group’s long-standing pattern, beginning with a lightweight VBS bootstrapper that launches an MSI responsible for staging a compiled AutoIt loader. The extracted AutoIt stage mirrors historical Astaroth loader design, including an LCG-based XOR routine, Windows-native decompression, and a manual mapping sequence used to prepare the final payload for execution. Execution is ultimately transferred into a hollowed svchost.exe process, where the implant operates as a long-lived, memory-resident backdoor.

While the core loader design and execution model align with established Astaroth tradecraft, the Command and Control (C2) implementation reflects a more recent evolution. In this sample, the decrypted payload leverages mailbox-based IMAP communication to receive tasking and return execution output through a legitimate email service, rather than relying exclusively on the web-based C2 channels historically associated with Astaroth. This shift mirrors patterns observed in newer campaigns, where operators increasingly blend control traffic into trusted third-party services to improve resilience and reduce visibility.

Linguistic and environmental artifacts also align with known Astaroth activity. Portions of the staged code and configuration reference Portuguese language strings, a recurring characteristic across Latin American campaigns. The choice to weaponize WhatsApp Web through ChromeDriver reflects a broader pattern of abusing regionally trusted communication platforms to increase lure credibility. The campaign further reuses familiar techniques such as in-memory execution, dynamic component retrieval, and execution within trusted system processes.

Taken together, the technical and behavioral evidence supports attribution to the Astaroth (Guildma) family while highlighting continued evolution in how C2 is implemented. When combined with the SORVEPOTEL driven social delivery mechanism on the front end, the overall chain reflects an adaptation of established Astaroth tradecraft, with newer communication patterns layered onto a familiar execution model.

Final Thoughts

This campaign illustrates how quickly a trusted communication channel can become an initial access vector when social engineering, weak controls, and misconfigured endpoints intersect. A single WhatsApp message delivered through a hijacked SORVEPOTEL session was sufficient to draw a victim into a multi-stage chain that ultimately resulted in an Astaroth implant running fully in memory. The combination of local automation tooling, unsupervised browser drivers, and user-writable runtimes created an unusually permissive environment, allowing both the worm and the final payload to establish themselves with minimal friction. 

Defenders should prioritize application allowlisting, restrict unauthorized scripting and automation environments, and monitor for behavioral patterns consistent with in-memory execution, ChromeDriver abuse, and unexpected WhatsApp Web automation. Just as importantly, user awareness around social delivery remains critical, even when messages originate from known contacts. As this campaign demonstrates, a single trusted click is often all that is required to deploy both a propagation mechanism and a persistent financial implant in the same stroke.

Recommendations

• Block all related domains, URLs, and file hashes across DNS, proxy, and endpoint protection layers.
• Monitor for python.exe, chromedriver.exe, and renamed AutoIt binaries executing from user writable or otherwise anomalous directories.
• Limit MSI installation to administrative users and investigate any msiexec activity writing to or executing from temporary paths.
• Enable PowerShell Script Block and Module Logging for visibility into download and file write behavior and alert on suspicious use of Invoke-WebRequest or similar transfer commands.
• Hunt for process chains involving python.exe launching chromedriver.exe, PowerShell writing to %TEMP%, or renamed AutoIt binaries executing payloads.
• Enforce MFA for all remote and privileged accounts and revoke active browser or WhatsApp Web sessions when compromise is suspected.
• Require all software installations to originate from approved vendor URLs and maintain logs of installation activity for auditing and threat correlation.

Indicators of Compromise (IOCs)

Network 

Type	Indicator	Context / Notes
Domain	varegjopeaks[.]com	Primary staging host
Domain	manoelimoveiscaioba[.]com	SORVEPOTEL Infrastructure
Domain	serverseistemasatu[.]com	Astaroth C2
URL	hxxps[://]varegjopeaks[.]com/altor/teste_obscado.vbs	SORVEPOTEL VBS stage
URL	hxxps[://]manoelimoveiscaioba[.]com/tadeu/receptor.php	SORVEPOTEL Infrastructure
URL	hxxps[://]varegjopeaks[.]com/altor/installer.msi	Astaroth MSI package
URL	hxxp[://]serverseistemasatu[.]com/data.php?recebe	Astaroth C2
User	leonardomilitao1998[@]terra[.]com[.]br	Astaroth C2 (IMAP Mailbox)

Files & Hashes 

Item	File name / Path	SHA256	Context / Notes
VBS bootstrap	teste_obscado.vbs	2c885d1709e2ebfcaa81e998d199b29e982a7559b9d72e5db0e70bf31b183a5f	Starts SORVEPOTEL setup
Hidden batch file	instalar.bat	5e41ab0d45b7046d6fef9ac01d1fc0df8bdeb60227edf40f8e351c60b09b8b7d	Installs Python + SORVEPOTEL
SORVEPOTEL worm	whats.py	6168d63fad22a4e5e45547ca6116ef68bb5173e17e25fd1714f7cc1e4f7b41e1	SORVEPOTEL worm
MSI package	installer.msi	5d929876190a0bab69aea3f87988b9d73713960969b193386ff50c1b5ffeadd6	Astaroth staging
VBS loader	run.vbs	4ebc9d233e0b1344740ea366843afa50d3616607d9f76533b388c046e9a9e421	Executes AutoIt script and payload
AutoIt interpreter	ahsCyKAF.exe	bdd2b7236a110b04c288380ad56e8d7909411da93eed2921301206de0cb0dda1	Renamed AutoIt interpreter
AutoIt script	WdbbaQjj.log	160cbd2743ca98c22dca31b723d5ad085f4ae1903c66df9013c28372cb7d4707	Malicious AutoIt script
Encrypted payload	aHBNvZ.tda	495697717be4a80c9db9fe2dbb40c57d4811ffe5ebceb9375666066b3dda73c3	Encrypted Astaroth payload
Encrypted payload	nUmBmX.dmp	d08c76cfe92afda9d63b6ff67036d8168cbf5ab8cfb8fce203d1739578fe5108	Encrypted Astaroth payload