A new WhatsApp worm is turning one of the world’s most popular messaging apps into an automated malware delivery system. The campaign hijacks active WhatsApp Web sessions, steals complete contact lists, and then uses the victim’s own account to send malicious files to everyone they know. Behind the scenes, a second payload quietly installs a fully featured banking trojan called Eternidade Stealer on Windows systems, giving attackers access to banking portals, payment services, and cryptocurrency wallets.
For regular WhatsApp users, the danger is brutally simple. You can receive a message that looks like it came from a trusted contact, open an attached file that claims to be an invoice or document, and within seconds your own WhatsApp account can begin sending that same file to your friends, family, coworkers, and clients. At the same time, malicious code on your computer watches for banking or crypto windows to open and prepares to intercept credentials and financial data.
In this article we break down how the campaign works, why Brazil continues to be a focal point for WhatsApp based attacks, and what makes Eternidade Stealer stand out from earlier banking trojans. We also provide practical guidance for both everyday users and defenders on how to detect, respond to, and contain infections linked to this WhatsApp worm.
WhatsApp As a Prime Target in Brazil’s Cybercrime Ecosystem
WhatsApp has become the backbone of digital communication in Brazil. It is used for personal messages, business coordination, informal support channels, and even unofficial interaction with government or financial services. This ubiquity has turned WhatsApp into a natural target for cybercriminals who want reach and trust in a single package. If malware can ride on top of WhatsApp conversations, it automatically inherits the built in credibility of the sender.
SpiderLabs notes that this is not an isolated case. Over the last two years, Brazilian threat actors have steadily evolved from simple WhatsApp phishing attempts to complex, multi stage campaigns. Earlier operations such as Water Saci used a worm known as SORVEPOTEL to spread via WhatsApp Web and then deploy a banking trojan called Maverick, itself linked to earlier .NET based malware referred to as Coyote. Each generation adds more automation, better social engineering, and more resilient command and control.
The current campaign builds on that lineage but goes even further. Instead of relying primarily on PowerShell for automation, the operators have shifted to a large Python script that drives the WhatsApp worm component. The payload is tightly integrated with a Delphi based trojan, Eternidade Stealer, that uses a clever IMAP trick to keep its command servers updated. All of this is wrapped in familiar Brazilian social engineering lures written in Portuguese, which makes the messages appear even more legitimate to local users.
High Level View of the Attack Chain
At a high level, the WhatsApp worm campaign follows a multi stage attack chain that looks straightforward on the surface but hides a significant amount of complexity and engineering effort underneath.
The attack typically begins with a malicious Visual Basic Script (VBScript) sent through WhatsApp messages that pretend to be invoices, contracts, delivery receipts, or other everyday documents. The file extension is chosen to look innocuous enough that a user might click it without thinking. Once executed, the script drops and runs a batch file that connects back to the attacker’s infrastructure.
From there, the batch file retrieves two main payloads. The first is a Python based worm responsible for hijacking WhatsApp Web and sending malware to the victim’s contacts. The second is a Windows Installer (MSI) package that contains an AutoIt loader and the components needed to deploy Eternidade Stealer. While the WhatsApp worm focuses on rapid social spread, the MSI installer quietly lays the groundwork for long term credential theft and remote control.
This separation of roles matters. The worm gives operators viral distribution through trusted social circles. Eternidade Stealer, once installed, gives them access to money. Together they create an attack that is both loud in terms of propagation and quiet in terms of what happens on the endpoint after the initial infection.
Stage One: Social Engineering and Malicious VBScript
The first stage of the campaign relies on traditional social engineering with local flavor. SpiderLabs researchers observed lures written in Portuguese presented as legitimate messages that might be forwarded in a family group, a neighborhood chat, or a small business channel. For the victim, the context feels routine. For the attacker, it is a way to ride the natural trust that exists between WhatsApp contacts.
The VBScript itself is heavily obfuscated and includes comments in Portuguese, which hints at a Brazilian origin and developer base. Once executed, the script does not perform the malicious logic directly. Instead, it drops a batch file that knows how to reach out to the command server, download additional content, and orchestrate the next stages. This pattern separates the initial lure from the actual heavy lifting and makes static detection more difficult.
By using a script that blends into the Windows environment and disguises its true purpose, the attackers lower the barrier for execution. Many users are still accustomed to double clicking files delivered in chat or email if the surrounding message appears trustworthy. In a WhatsApp context, a VBScript that arrives as a forwarded file from a known contact will often be treated with more trust than a random email attachment.
Stage Two: Python Based WhatsApp Worm in Action
Once the dropped batch file runs, it downloads a large Python script that forms the core of the WhatsApp worm component. SpiderLabs identifies this script as a more than 1,300 line file named whats.py, designed specifically to automate WhatsApp Web, steal contact lists, and distribute malware at scale.
The script links to an open source project called WPPConnect, which provides a JavaScript based API wrapper around WhatsApp Web. By loading the wppconnect-w.js library into the browser session, the malware gains programmatic access to WhatsApp functions that are normally only available through the user interface. This includes the ability to read contacts, open chats, and send messages on behalf of the logged in user.
One of the most important internal functions described by SpiderLabs is obter_contatos(). To understand what the WhatsApp worm is doing, it is helpful to look at this function in plain language. The function executes JavaScript inside the victim’s WhatsApp Web browser context and calls the WPP API to fetch a full list of contacts associated with the account. The code then iterates over those contacts and applies several filters.
Groups, broadcast lists, and business entities identifiable by suffixes such as @g.us or @lid are removed. The operators are not interested in noise. They want individual people. For each remaining contact, the script extracts the WhatsApp ID, display name, any available short name or push name, and the clean phone number. It also notes whether the person is stored as a saved contact in the address book.
This information is then passed back to the Python layer, which immediately invokes another function responsible for exfiltration. There is no user prompt or delay. The stolen contact data, along with identifiers for the victim machine and the active session, is sent to the attacker’s server over HTTP POST. Even though the requests may travel over HTTPS, the payload is not encrypted beyond the transport layer, which is sufficient for the operators and simplifies their logging and processing on the back end.
How the WhatsApp Worm Uses Your Own Account to Spread Malware
Contact theft is only one part of the story. The WhatsApp worm is engineered to move quickly from data collection to active propagation. Once the operators have a list of valid contacts, the script looks for instructions from its command server that define how the outgoing messages should look and what file should be attached.
SpiderLabs describes a template system that can be updated remotely. The template controls the greeting, the language, the tone, and the call to action in the message body. One of the more subtle features is a time based greeting mechanism that chooses different phrases for morning, afternoon, and evening. Messages may include phrases like “bom dia”, “boa tarde”, or “boa noite”, which align with how real Brazilian users communicate during different parts of the day. Contact names are injected directly into the text, which makes the message look hand typed and personal rather than automated.
The malicious file itself is fetched from the command server as a Base64 encoded blob. The Python code decodes it, writes it to disk, and instructs WhatsApp Web to attach it to the outgoing messages. The script then sends the template message and file to each harvested contact. A follow up message can also be sent to nudge recipients who might ignore the first notification. The option to send messages with waitForAck: false shows that the operators are willing to prioritize speed and volume over delivery feedback in order to keep the worm moving.
From the victim’s point of view, there may be no obvious sign that anything is wrong until contacts start responding. The WhatsApp interface might briefly flash as messages are sent, but a user who is not actively watching the screen or who left WhatsApp Web open on a secondary monitor may not notice it at all. Meanwhile, friends, family members, and colleagues receive what appears to be a personal file from a trusted contact and are encouraged to open it.
Stage Three: MSI Dropper and AutoIt Loader
While the WhatsApp worm focuses on lateral movement across social graphs, the MSI installer delivered alongside it is responsible for infecting the underlying system. According to SpiderLabs, the installer drops multiple components, including a large AutoIt script stored in a file with a misleading extension. This script serves as a loader and environment reconnaissance tool that prepares the host for the banking trojan.
The AutoIt code is packed with hex encoded blobs that represent additional payloads or shellcode segments. When executed, it carries out a series of checks before it is willing to deploy the final trojan. One of the most important checks is a locale test. The script inspects the operating system language and only proceeds if the system is configured for Brazilian Portuguese. If the language does not match, the malware displays a generic error message and terminates. This geofencing behavior keeps the campaign focused on Brazil while reducing exposure in other regions where security researchers may be more active.
Once the language check passes, the script enumerates installed security products by examining running processes, registry uninstall keys, and Windows Management Instrumentation (WMI) data. It collects human readable names of antivirus, firewall, and anti spyware tools such as Kaspersky, Malwarebytes, Avast, and Windows Defender. This information can be used later to tailor evasion strategies or simply to give the operator a detailed profile of each infected machine.
The script also gathers system telemetry. It uses online services like api.ipify.org to retrieve the external IP address and collects local network information to understand where the host sits on the network. An internal function named OBTERINFOADICIONAL() queries the Windows registry for the operating system name, reads the processor model from hardware description keys, and calculates total RAM in gigabytes using WMI. It also identifies the current logon domain to determine whether the machine is joined to a corporate network or a standalone environment.
This collection of hardware and software details, combined with network identifiers, is packaged into a single report and sent to a command endpoint such as https://itrexmssl[.]com/jasmin/altor/receptor[.]php. At that point, the operators know exactly what kind of machine they have compromised and whether it is worth further attention.
Stage Four: Eternidade Stealer on the Endpoint
Once the preparatory steps are complete, the final payload is deployed. Eternidade Stealer is a Delphi compiled banking and credential stealing trojan built to survive on the system and stay tightly integrated with financial activity. Delphi has a long history in Latin American malware, and its continued popularity is not an accident. It produces compact native Windows executables, integrates well with the Windows API, and benefits from decades of shared code, tutorials, and underground tooling in Portuguese.
When Eternidade runs for the first time, it checks a registry key under HKEY_CURRENT_USER\Software\MeuApp for a value named Inicio. If the value does not exist, the malware knows this is a fresh infection. It then collects baseline system information, including computer name and processor details, and transmits this to a server such as serverseistemasatu[.]com/data.php?recebe. Afterward, it sets the Inicio flag to mark the host as already processed, which prevents redundant initialization steps in the future.
The trojan then enumerates open windows on the desktop using the Windows EnumWindows API. For each window, Eternidade records the title, class name, and executable path. It formats these as strings in a consistent way, for example:
Titulo: Banco Online | Class: Chrome_WidgetWin_1 | Exe: C:\Program Files\Google\Chrome\Application\chrome.exe
This list is analyzed to find matches with targeted banking portals, payment platforms, and cryptocurrency services. The targeting matrix is extensive. Banks such as Santander, Banco do Brasil, Bradesco, Itaú, Caixa Econômica Federal, and many regional institutions are included. On the fintech side, services like MercadoPago and RecargaPay are monitored. For cryptocurrency, major exchanges including Binance, OKX, Crypto.com, Coinbase, and several Brazilian platforms are in scope, along with wallet software like Electrum, Exodus, MetaMask, Ledger Live, Trust Wallet, and others.
When Eternidade detects that the victim is interacting with one of these high value applications, it can activate additional capabilities. These include keylogging, screen capture, and most notably, the deployment of overlay windows that mimic legitimate login prompts. Overlays can be tailored per bank, with parameters that define where password fields and buttons should appear so they sit precisely on top of the real interface. Victims believe they are entering credentials into the bank’s own website, while in reality those credentials are captured and sent to the trojan’s command server.
Dynamic Command and Control Over IMAP
One of the more interesting design choices in Eternidade Stealer is its command and control mechanism. Instead of relying solely on hardcoded C2 domains, the trojan can connect to a legitimate email provider over IMAP and use an inbox as a makeshift configuration channel. The sample analyzed by SpiderLabs used hardcoded credentials for a mail account hosted at a Brazilian provider domain, with IMAP access over port 993.
The trojan logs in to the mail account, selects a specific mailbox, and reads the most recent message. It then concatenates the email subject, sender, and recipient into a single string using labels in Portuguese such as “Assunto”, “De”, and “Para”. Within this combined text, it searches for a pattern like “ip:” and extracts the value that follows. That value is treated as the current C2 address. If no suitable value is found in the header, Eternidade repeats the same search in the email body. Only if both attempts fail does it fall back to a secondary hardcoded C2 domain, for example domimoveis1[.]com[.]br.
During analysis, SpiderLabs discovered that in at least some cases the threat actor had not enabled multi factor authentication on the mailbox. This allowed researchers to log in with the same hardcoded credentials, observe the structure of the messages being used to convey C2 information, and confirm that the IMAP based mechanism worked as described. It is a simple but effective way to change C2 endpoints without pushing new binaries to infected hosts.
Backdoor Commands, Encryption, and Operator Control
Communication between Eternidade and the C2 is built around an internal command syntax wrapped in markers such as <|OK|> or <|PING|>. To make static analysis and detection harder, many of the strings involved in these commands are encrypted. SpiderLabs documented a decryption routine that uses a hardcoded key, edit1, and a salt string, MeuSaltPessoal#2024. Encrypted data is stored as hex, converted to bytes, adjusted by subtracting a fixed value, and then passed through a rotating XOR that uses both the salt and the key.
Once decrypted, the command list reveals a diverse set of remote capabilities. Some commands instruct the trojan to collect updated system information, including which bank is currently being accessed, which security tools are installed, and how much RAM the machine has. Others such as <|PING|> act like heartbeats. When Eternidade receives this command, it responds with a <|PONG|> marker and reports the title of the currently active window. This gives the operator a near real time view of what the victim is doing and helps decide when to trigger overlays or credential prompts.
More specialized commands such as <|PedidoSenhas|> carry parameters that define the position, style, and text of fake password windows. Still others control keylogging, screenshot capture, file download and upload, and even chat style interactions where the operator can open a hidden window and interact with the victim’s desktop or inject messages. Together, these functions turn Eternidade into a blend of banking trojan, remote access tool, and espionage platform.
Infrastructure and Redirector Panel
On the infrastructure side, SpiderLabs traced connections from the initial domains used in the campaign, such as serverseistemasatu[.]com, to a broader cluster of IP addresses. Additional domains hosted on the same IPs suggested that the operators were running several related projects or components. Among the most interesting discoveries was a web based panel labeled as a Redirector System.
The Redirector System appears to sit in front of one or more C2 endpoints and make access decisions based on geolocation and other criteria. Its configuration page includes options to define which countries are allowed to reach the actual target domain and which should be blocked or redirected. For unwanted traffic, such as visitors from outside Brazil and Argentina or suspected scanners and bots, the panel can redirect clients to benign sites like https://google.com/error. Checkboxes allow the operators to block VPN and proxy traffic, hosting providers, suspicious IP ranges, and user agents that do not look like real browsers.
Logs from this panel show 454 communication records, but only a tiny fraction were allowed through to the final campaign domain. Of those entries, the highest volume came from the United States, followed by the Netherlands, Germany, the United Kingdom, and France. Only three entries were traced to Brazilian IP addresses, although 451 of the total attempts were blocked. The combination of geofencing and redirection suggests that a large portion of the observed traffic may have come from scanners, researchers, or compromised machines outside the intended target region.
Operating system statistics collected by the panel show that the majority of contacts came from desktop platforms. Windows and macOS together accounted for a significant percentage of the recorded traffic, with a smaller number of connections attributed to Linux and Android. A large block of entries were marked as unknown, likely due to stripped or obfuscated user agent strings from tools and automated probes.
The log data reinforces two points. First, the operators are deliberately trying to confine active exploitation to Brazilian and Argentinian hosts, which aligns with the language checks and local banking focus. Second, the campaign’s infrastructure is visible on the wider internet and attracts attention from around the world, which is why geofencing and redirector logic are necessary to keep it under control.
Evidence of an Evolving Codebase
By pivoting on shared infrastructure and code characteristics, SpiderLabs and independent researchers found earlier samples related to this family that date back to January 2025. One of these was highlighted by security researcher Dodo on Security, who posted on X about a banking trojan with similar functions, but a more limited feature set. In those earlier builds, the IMAP based C2 retrieval mechanism was absent, and the trojan relied on a fixed command server address.
Comparing the older and newer samples shows consistent patterns in the way data is formatted for exfiltration, how encrypted strings are handled, and how Windows processes are enumerated. The similarities are strong enough that researchers believe the same developer or small team is responsible, iterating on the codebase, adding new tricks, and adapting to defenses. The shift from PowerShell to Python for the WhatsApp worm component and the introduction of IMAP based C2 both point to an active project rather than a one off tool.
Why This Matters for Everyday WhatsApp Users
For people who simply use WhatsApp to talk to friends, coordinate work, or share documents, the technical details can feel distant. The practical risk is not. This campaign shows how quickly a normal WhatsApp account can become a weapon used against everyone in a person’s contact list. Once the WhatsApp worm is in place, it is the victim’s own identity and history that sell the malicious message.
If you use WhatsApp on a computer through WhatsApp Web, the risk is even higher. The worm does not need to compromise your phone directly. It only needs access to the browser session that is already authorized. As long as that session remains running, automated scripts can send messages, read contact data, and push files without any new prompts on your phone. The infection can start from a single careless click on a forwarded file and escalate into a broad compromise of both your social network and your financial data.
There is also a reputational angle. When an infected account sends malware to colleagues or clients, it is the user who will be blamed. For small businesses that run much of their operations through WhatsApp groups and chats, such an incident can undermine trust, lead to data exposure, and create real financial and legal consequences if customer information is mishandled or stolen as part of the wider compromise.
Practical Steps for WhatsApp Users
There are concrete steps that WhatsApp users can take to reduce their exposure to this kind of attack and detect early signs of trouble. One of the simplest is to regularly review which devices are linked to your WhatsApp account. In the mobile app, open the menu, choose the Linked Devices option, and verify that every listed computer or browser is one you recognize. If anything looks unfamiliar, log it out immediately. As a precaution, some users may prefer to log out of all devices and re link only their current machine.
It is also wise to treat unexpected files and scripts with suspicion, even if they arrive from people you know well. Ask yourself whether the context makes sense. If a contact sends what claims to be a contract or invoice, but you were not expecting one from them, confirm through another channel before opening it. A quick voice note or phone call can prevent an infection chain that would otherwise ripple through large parts of your social and professional life.
If contacts begin reporting that you sent them strange files, or if you see evidence that messages were sent from your WhatsApp account without your knowledge, treat it as a strong sign of compromise. In that case, you should immediately log out of all linked devices, change your main device’s screen lock and any associated account passwords, and perform a full malware scan on the computer you use with WhatsApp Web. Tools like Malwarebytes can help identify and remove droppers, AutoIt loaders, and banking trojans on Windows.
Additionally, enabling two step verification in WhatsApp itself provides another barrier against account takeover attempts by requiring a PIN in addition to SMS based registration. While this does not stop a worm that abuses an already authenticated session, it does make it harder for attackers to re register your number on another device or lock you out of your own account.
Detection and Response Guidance for Defenders
For defenders, incident responders, and SOC teams, the WhatsApp worm and Eternidade Stealer present a blend of web automation, script based loaders, and native trojan behavior that requires monitoring at several layers. Network telemetry can reveal outbound connections to suspicious domains and IP addresses associated with the campaign, including the URLs used to retrieve VBScript droppers, Python payloads, MSI installers, and telemetry submissions.
Endpoint protection platforms should watch closely for the execution of obfuscated VBScript files, unexpected use of cscript.exe or wscript.exe, and MSI installers launched from temporary or user directories. AutoIt processes that load large hex encoded blobs and interact with system locale, WMI, and installed security products may also be strong indicators. On the browser side, defenders should be aware that automation frameworks such as WPPConnect can be abused. While not malicious by themselves, their presence in conjunction with unknown Python processes and unusually high WhatsApp Web activity is a red flag.
At the network and email layers, security teams can look for IMAP connections to the specific provider domains and accounts associated with this campaign. Persistent IMAP sessions from endpoints that do not normally use standalone mail clients, especially those that follow the pattern documented by SpiderLabs, may warrant deeper investigation. TLS inspection or proxy logging can sometimes reveal hostnames and access patterns that point directly to the infrastructure described in public reports.
Finally, defenders should maintain and distribute detection rules and indicators that reflect both the worm and the stealer components. It is not enough to block the malware file alone. Organizations should also watch for anomalous WhatsApp Web usage, unusual outgoing file sharing patterns, and user reports about unsolicited messages being sent from internal accounts.
Indicators of Compromise
The following indicators are associated with this WhatsApp worm campaign and the Eternidade Stealer payload. They should be treated as high risk and incorporated into security controls where appropriate.
Malicious Scripts
- VBS droppers:
- e1779d9810ad39a45759c856cc85f1148a8f6601
- e3e24d57163e04ac16a93a698d4c8051473bccb4
- Python WhatsApp worm (whats.py):
- 8f3b5a0cecd4d50fc6eb52a627fe6a9179e71736
- 167cc2d716bfebc440f14ff1affe7f99b8556f2e
Eternidade Payloads
- db5545b6136f1197fd5234695cdeff285a99208e
- 03944933d662f4e96d43750aa29bd287685c6007
Domains
- varegjopeaks[.]com
- centrogauchodabahia123[.]com
- itrexmssl[.]com
- serverseistemasatu[.]com
- domimoveis1[.]com[.]br
- mazdafinancialsevrices[.]com
- adilsonralfadvocaciad[.]com
IP Addresses
- 103.84.176[.]107
- 104.21.48[.]41
- 162.120.71[.]56
- 185.169.234[.]139
- 83.229.17[.]71
- 140.99.164[.]172
- 174.138.187[.]2
For more in depth analysis of current threats and active malware families, visit our Cybersecurity and Malware sections.
