Astaroth has always been more than a simple banking trojan. CrowdStrike’s latest analysis shows the LATAM-focused malware ecosystem adding a capability that should make defenders uncomfortable: a WhatsApp Web spambot that uses hidden browser automation to turn an infected endpoint into a malware distribution node.

The core lesson is bigger than one malware family or one region. Attackers are treating trusted browser sessions, messaging platforms, and automation frameworks as operational infrastructure. If an endpoint is compromised and the user is already logged into WhatsApp Web, the attacker may not need to steal the account first. They can automate the session that is already there.

What CrowdStrike reported

According to CrowdStrike’s technical analysis, Astaroth operators began distributing a previously unidentified WhatsApp Web spambot component in late 2025. The component is delivered by Astaroth’s command-and-control infrastructure and is designed to automatically message contacts from the victim’s WhatsApp Web session.

The spambot uses legitimate browser automation components in an attacker-controlled way. It downloads a WebDriver for Chrome or Edge, copies the victim’s browser profile into a temporary location, launches a hidden browser instance, and opens WhatsApp Web with the victim’s existing session context. From there, it uses WhatsApp Web automation libraries to enumerate contacts, filter them, and send malware-themed messages and ZIP attachments.

CrowdStrike also found overlap with Vareg, another WhatsApp Web spambot used in campaigns distributing LATAM banking trojans. That overlap suggests this capability is not a one-off experiment. It is part of a maturing criminal ecosystem where browser automation, messaging trust, and malware delivery are being combined into repeatable tradecraft.

Why this matters

Most organizations still think about messaging abuse as a user-awareness problem: suspicious links, fake invoices, social engineering, and phishing lures. This case is different. The attacker is not only sending a lure to a victim; the attacker is using the victim’s own trusted account to send lures onward.

That makes the message more believable. It also shifts the defensive question from “Did an employee click a bad link?” to “Can we detect when a compromised endpoint silently automates a logged-in browser session?”

For SMBs and government contractors, this matters because browser sessions often bridge personal communication, business collaboration, cloud apps, file-sharing portals, and identity workflows. Once malware can reuse those sessions, the browser becomes both a data source and a delivery platform.

Defensive takeaways

  • Monitor unexpected WebDriver activity. ChromeDriver, Edge WebDriver, Selenium-style automation, random local WebDriver ports, and headless browser launches should be rare on non-developer endpoints.
  • Watch browser profile cloning. Alert on browser profile directories copied into public, temp, or unusual working paths. Session theft and session reuse often begin with profile access.
  • Treat headless browser execution as high-signal. A hidden browser launched with automation-suppression flags is not normal office behavior for most users.
  • Add messaging platforms to incident scope. If malware is found on a workstation, check whether WhatsApp Web, Teams, Slack, Discord, Telegram, or browser-based email sessions were active and potentially abused.
  • Restrict risky archive delivery paths. Block or inspect ZIP attachments delivered through messaging apps where possible, especially when they originate from newly unusual user behavior.
  • Hunt for automation libraries and script injection. Legitimate JavaScript automation libraries can become attacker tooling when executed inside a victim’s live web session.
  • Reset sessions after compromise. Password rotation alone may not be enough. Revoke browser sessions, invalidate tokens, clear trusted devices, and force re-authentication across key SaaS and messaging platforms.

What to look for in logs

Useful telemetry includes process creation for browser drivers, command lines containing --headless or automation-suppression flags, browser profile access from non-browser processes, PowerShell or downloader activity retrieving WebDriver binaries, unusual browser child processes, and outbound connections from automation-spawned browsers.

On the network side, defenders should look for endpoints that suddenly connect to messaging web apps in unusual patterns, send repetitive outbound traffic, or retrieve ZIP payloads shortly before messaging activity increases. EDR and proxy logs together are stronger than either source alone.

Bulwark Black assessment

Astaroth’s WhatsApp Web spambot is a clean example of where commodity malware is heading: less reliance on noisy credential theft first, more abuse of the trusted sessions already present on the machine. That is bad news for organizations that only monitor malware hashes or block known phishing domains.

The practical defense is to build detections around behavior: hidden browser automation, browser profile cloning, WebDriver execution, messaging-session abuse, and suspicious archive staging. Those signals are useful beyond Astaroth because they map to a broader attacker pattern: hijack trust, automate the browser, and use the victim’s normal communication channels to move the campaign forward.

Source: CrowdStrike — Inside Astaroth’s New Spambot Component.