Lumma Stealer Abuses Google Groups for C2 in New Campaign

Threat actors have weaponized Google Groups to distribute credential-stealing malware, exploiting the platform's trusted reputation to bypass corporate security controls. CTM360's threat intelligence team identified more than 4,000 malicious Google Groups and 3,500 Google-hosted URLs serving Lumma Stealer and a secondary payload called Ninja Browser.

The campaign is especially insidious because it targets professionals seeking legitimate technical help. Attackers infiltrate industry forums discussing network troubleshooting, software configuration, and authentication issues—topics that naturally attract IT staff and developers.

How the Attack Works

The infection chain starts with social engineering inside Google Groups. Threat actors create or join forums covering topics like network diagnostics, enterprise software, or authentication errors. Once established, they respond to genuine technical questions with posts that embed malicious download links.

These links are disguised as helpful resources: "Download [Company Name] for Windows 10" or links to supposed patches and configuration tools. Users looking for solutions trust the forum context and click without suspicion.

When victims download the payload, they receive Lumma Stealer—a well-documented infostealer that harvests credentials, browser data, cryptocurrency wallets, and session cookies. The malware then uses Google Groups infrastructure to communicate with its operators. Because the traffic flows through google.com domains, it passes through corporate firewalls that whitelist Google services.

This represents a concerning evolution from the 9,000-email phishing wave we covered in January, where attackers abused Google Cloud Application Integration for credential theft. Threat actors are systematically finding ways to weaponize Google's trusted infrastructure.

Ninja Browser: The Silent Persistence Layer

Alongside Lumma, the campaign deploys Ninja Browser—a malicious browser that installs extensions without user consent and establishes hidden persistence mechanisms. The malware operates quietly, harvesting data while maintaining footholds for future compromise.

The combination proves effective: Lumma handles immediate credential theft while Ninja Browser ensures long-term access. Victims may clean up obvious malware but miss the rogue browser silently siphoning data in the background.

Why Google Groups Works for Attackers

Corporate network security typically trusts Google domains by default. Firewall rules permit outbound HTTPS to *.google.com without inspection. DNS filtering services categorize these domains as "Productivity" or "Business"—never flagged for blocking.

This blind trust creates a perfect C2 channel. The malware contacts Google Groups to retrieve commands and upload stolen data. From the network's perspective, an employee is simply accessing Google services. No alerts fire.

The distributed nature of Google Groups compounds the problem. Blocking a single group does nothing when thousands exist. Attackers rotate through groups faster than defenders can enumerate them.

Infostealer Infections Continue Climbing

The campaign underscores the growing enterprise risk from infostealers. Research from Flare found that one in five infostealer infections now exposes corporate credentials, with Microsoft Entra ID appearing in 79% of enterprise identity logs. Session cookies captured by stealers enable immediate MFA bypass.

Lumma Stealer specifically has shown remarkable resilience. Microsoft and law enforcement disrupted its infrastructure in May 2025, but operators rebuilt within weeks. The malware-as-a-service model means multiple affiliate groups distribute Lumma independently.

Indicators and Detection

CTM360's report includes SHA-256 hashes and domains associated with the campaign. The primary C2 domains identified include healgeni[.]live and related infrastructure.

Organizations should monitor for:

• Unusual traffic patterns to Google Groups from endpoints
• Browser processes spawning PowerShell or cmd.exe
• New browser installations not deployed through IT channels
• Credential access events following Google Groups visits

Network detection is challenging because the traffic blends with legitimate Google usage. Endpoint detection focusing on behavioral indicators offers better visibility. EDR solutions should flag processes that access credential stores immediately after Google Groups connections.

Mitigation Steps

1. Review Google Groups permissions - Consider whether employees need unrestricted access. Some organizations may choose to limit posting or joining external groups.

2. Deploy application allowlisting - Prevent execution of unknown binaries, even from seemingly trusted sources.

3. Monitor browser installations - Any browser appearing outside your deployment process warrants investigation.

4. Implement session monitoring - Look for impossible travel or anomalous access patterns that suggest stolen session cookies.

5. Conduct targeted awareness training - Technical staff downloading tools from forums should verify sources through official channels.

The campaign demonstrates that legitimate platforms will continue being abused for malware delivery. Trust-based filtering alone cannot stop threats that hide behind Google's reputation. Organizations need layered detection focused on endpoint behavior rather than network reputation alone.