If You See C:\\Windows\\System32\\wbem\\wmic.exe.bak On A Host, You Have STAC6405. The 24 VENOMOUS#HELPER IOCs Just Landed In Our Feed.

May 6, 2026 · DugganUSA LLC

Securonix Threat Research published a writeup on a phishing campaign codenamed VENOMOUS#HELPER — cluster ID STAC6405 — earlier this week. The campaign has been running since April 2025 and has hit more than eighty organizations, primarily in the United States, with secondary clusters in Western Europe and Latin America. We had zero indicators in our IOC index as of this morning. As of an hour ago, all twenty-four published indicators are indexed under source securonix-venomous-helper and queryable through our STIX feed. This post is the writeup, and it leads with the single highest-confidence host artifact you can hunt for tonight.

If your endpoint detection pulls the file C:\Windows\System32\wbem\wmic.exe.bak from any host in your fleet, that host is compromised by STAC6405. The legitimate Windows wmic.exe is not normally backed up at this path. Securonix flags this file as a high-confidence static IOC. Hunt for it across every Windows endpoint you have visibility on. If it appears, the host is in scope.

The Lure

Victims receive an email impersonating the U.S. Social Security Administration, telling them a new SSA statement is available for review. The link in the email does not point to an attacker-registered domain. It points to a compromised legitimate business website in Mexico, gruta.com.mx or server.cubatiendaalimentos.com.mx, hosting the dropper at the path /~tiendazoycom/sns/statement5648.exe. The use of compromised legitimate infrastructure rather than newly-registered attacker domains is deliberate: secure email gateways and URL reputation systems treat established domains with prior clean history as low-risk, and the lure clears the filter on reputation alone.

The dropper, statement5648.exe, is a JWrapper-packaged executable. JWrapper is a legitimate Java application packager; the package itself is not the malware. The malware is the bundled customer.jar plus its supporting infrastructure that the package extracts and installs.

The Persistence

Once executed, statement5648.exe installs two independent remote-access channels on the host. The first is a customized SimpleHelp 5.0.1 instance configured to phone home to 84.200.205.233 on port 5555 over HTTP and UDP. The second is a ConnectWise ScreenConnect client configured to reach a relay endpoint at sslzeromail.run.place on port 8041. Both clients are signed binaries: SimpleHelp by Thawte, ScreenConnect by ConnectWise. Antivirus and EDR products that maintain allow-lists or trust signatures from those issuers will let both binaries execute without alarm. That is the design.

The dual-channel architecture is the key feature. Either RMM client by itself is detectable through behavioral analysis; the two together provide redundancy if a defender catches and removes one. The operator retains access through the other while the defender thinks they have remediated.

The persistence is layered. The malware installs as a Windows service named "Remote Access Service" and registers itself in the Safe Boot registry hive at HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Network\Remote Access Service. That registration causes the service to load even if the host is rebooted into Safe Boot with Networking, which is the mode an incident responder typically uses to remediate a compromised endpoint. A self-healing watchdog process restarts the service if it is killed. The malware also enumerates installed security products on a loop to detect when a defender has installed new tooling.

The high-confidence static IOC, C:\Windows\System32\wbem\wmic.exe.bak, is the file the malware drops as part of its installation routine and uses for one of its evasion mechanisms. The legitimate wmic.exe is not normally backed up at that path. Its presence is the cleanest single-file detection in the entire chain.

The Targets

Securonix attributes the campaign to a cluster designated STAC6405, with overlaps to clusters previously tracked by Red Canary and Sophos. The campaign has not yet been attributed to a named state actor or named criminal group. Securonix's read is that STAC6405 is operating as an initial access broker — establishing persistent footholds on victim networks and then either selling that access to ransomware operators or staging follow-on operations directly. Eighty-plus organizations across nine languages of regional content, hit since April 2025, is the volume profile of a broker, not a targeted state-sponsored actor.

The sector spread is broad. There is no narrow targeting pattern. The lure (SSA statement) presupposes a U.S.-resident victim audience and pre-selects for organizations whose employees would plausibly receive SSA correspondence. That is essentially every organization that employs U.S. citizens.

The Hunt Tonight

Run these in roughly this order:

One. File hunt for the static IOC across the Windows fleet. In Microsoft Defender for Endpoint advanced hunting, the KQL is: DeviceFileEvents | where Timestamp > ago(60d) | where FolderPath endswith "wmic.exe.bak" | project Timestamp, DeviceName, ActionType, FolderPath, FileName, InitiatingProcessFileName, InitiatingProcessAccountName | order by Timestamp asc. Anything that comes back is a candidate compromise. The file should not exist anywhere in your fleet.

Two. Network egress hunt for the C2 infrastructure. DeviceNetworkEvents | where Timestamp > ago(60d) | where RemoteIP in ("84.200.205.233", "213.136.71.246") or RemoteUrl has_any ("sslzeromail.run.place", "cubatiendaalimentos.com.mx", "gruta.com.mx") | project Timestamp, DeviceName, RemoteIP, RemoteUrl, RemotePort, InitiatingProcessFileName, InitiatingProcessCommandLine. Any internal host connecting outbound to those IPs or domains is compromised, full stop. The IPs are not legitimate external services that a normal corporate workload would reach.

Three. Process hunt for the dropper and the secondary tooling. DeviceProcessEvents | where Timestamp > ago(60d) | where FileName in~ ("statement5648.exe", "SimpleGatewayService.exe", "SimpleService.exe", "session_win.exe", "elev_win.exe", "winpty-agent64.exe") | project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName. These filenames are the JWrapper-packaged dropper plus the SimpleHelp and ScreenConnect components the dropper installs. SimpleHelp and ScreenConnect have legitimate enterprise uses, so before treating a hit as conclusive, confirm against your sanctioned IT software inventory. If the host is not in your inventory of authorized SimpleHelp or ScreenConnect deployments, it is in scope.

Four. Service inventory check. Get-Service | Where-Object { $_.Name -eq "Remote Access Service" -or $_.DisplayName -like "Remote Access" } across the fleet. The service name is generic and may exist legitimately in some environments (Windows includes a built-in RRAS), so cross-reference with the registry persistence path: presence of HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Network\Remote Access Service combined with an installed "Remote Access Service" outside your authorized RRAS deployments is conclusive.

Five. Email gateway retrospective hunt. If you have email logs going back to April 2025, search for inbound messages with subject lines or body content referencing SSA, Social Security Administration, statement, or your-statement-is-ready, sent from addresses outside your normal correspondence patterns, with links to gruta.com.mx, cubatiendaalimentos.com.mx, or run.place subdomains. The hit set tells you who clicked the lure and how far back you have potential exposure.

SHA256 Hashes

The eleven file hashes published by Securonix are in our index and queryable. If you are running YARA, ClamAV, or any AV with custom hash matching, the indicators to load are:

810a99a7d6696a36491530e286476b4cf8a819a47fb5e3801fdfecfdb2dc6193 641230a9f3091bdd38d04c6df96062bfc82dfc4ff6f663ceb522d3881d6af53a dbdddea03c3fc4c2574ce4221450ec86221ebc615c4915c4c4eb3f2a5e3f5b25 9369d7194ab03362e9e7af022a48bc6d4e7d91a6ab7c4b5cf5d90abbcd8c7012 97f801e750cfc2d4558020fb246782e034fd6101d75a59d8915b4f2b2b50ebd9 11914d10b51b5a96606ae606b5ab70d79550e36c1cce94a86134107c59075e0c 76d85124db2778baecee24cc5ad56c9a3060c41c5b3c1b5cdc7f0435e0f77cac d953dfbe8d91dc9fafad0a6117e1276fa636d4ae1b6a4d81616ff2446cf09234 3e4b3559fdbe584e19a1ff9b3142b429c6fb91aaa63b5c922c8c5b32c38e426a bce1222fc9e64aba4dd6f963dfd3377afa1844a1df9d5026e06990c8dc524645 3b15e61c4f2e0349702a1940c71716e3d327e5224ac6d6e6a7b6c233c15f10f3

Why The Signed-Binary Bypass Matters

There is a structural defense problem in the VENOMOUS#HELPER design that every enterprise security stack inherits. SimpleHelp's binaries are validly signed by Thawte. ScreenConnect's binaries are validly signed by ConnectWise. Both companies are legitimate vendors with large customer bases. Allow-listing software based on code signing certificate is a widely-deployed defense, and both of these signatures are in the trusted set on essentially every commercial AV/EDR product.

When the dropper deploys SimpleHelp and ScreenConnect on a victim host, the AV sees a signed binary from a known vendor and lets it run. The behavioral analysis that would catch the activity is partially defeated because the activity (RMM phoning home to a configured server) is exactly what RMM software is supposed to do. The detection has to live in the layers that AV does not own: the network egress identifying the specific C2 endpoints, the process tree identifying that the RMM was dropped by an unsanctioned executable, and the inventory layer identifying that the RMM was not authorized in the first place.

This is the same dual-use signed-binary problem that has bitten the industry repeatedly with PsExec, Sysinternals tools, AnyDesk, TeamViewer, and other legitimately-signed remote-access utilities. The defense answer is not "block signed Thawte binaries"; that breaks legitimate SimpleHelp customers. The defense answer is sanctioned-software inventory plus network egress detection on the specific operator infrastructure that VENOMOUS#HELPER is using.

Why We Indexed Today

We pull from public threat intelligence aggregators (OTX, ThreatFox, abuse.ch, others) on automated cycles, but vendor-blog indicators tend to land in our index a few days after the vendor publishes, not the same hour. For a campaign at the 80-plus-organization scale, a few days of latency is meaningful. The Securonix writeup published this week was already in the news cycle by the time we noticed our own coverage gap; the manual ingest closes the gap and feeds the BDE scorer for the existing hosts in our index, plus makes the indicators queryable through our STIX feed for downstream consumers.

If your security stack pulls from our STIX feed at analytics.dugganusa.com/api/v1/stix-feed, the VENOMOUS#HELPER set is already there as of approximately 14:55 UTC today. Twenty-four indicators tagged with source securonix-venomous-helper, malware family VENOMOUS-HELPER, threat type initial-access, severity high, confidence 88.

Receipts

• Securonix Threat Research: securonix.com/blog/venomous-helper-phishing-campaign

• The Hacker News coverage: thehackernews.com/2026/05/phishing-campaign-hits-80-orgs-using.html

• Infosecurity Magazine coverage: infosecurity-magazine.com/news/ssa-emails-venomous-helper-phishing

• TechNadu coverage: technadu.com/phishing-campaign-impersonating-the-u-s-social-security-administration-targets-80-organizations/627279

• Cluster overlap (Sophos STAC6405, Red Canary prior coverage): vendor advisories

• Our STIX feed (24 indicators tagged source securonix-venomous-helper): analytics.dugganusa.com/api/v1/stix-feed

— Patrick Duggan DugganUSA LLC, Minneapolis

Aye.

---

How do AI models see YOUR brand?

AIPM has audited 250+ domains. 15 seconds. Free while still in beta.

Audit your site now → aipmsec.com