@apexacc/cli: Malicious npm Package Chains PowerShell, PyArmor and a Go Loader to Drop a Windows Infostealer

Credit up front: the findings in this post are Elastic Security Labs’ — we’re summarizing their developing investigation into a malicious npm package because it’s a pattern worth recognizing before you run npx against something unfamiliar, not because we independently verified the chain ourselves. Elastic’s own language is that this is an active investigation, so treat the details below as their current assessment, not a closed case.

What Elastic found

Elastic Security Labs is investigating @apexacc/cli, an npm package whose behavior, per their initial assessment, diverges sharply on Windows. On that platform it:

• Modifies registry settings tied to Windows Smart App Control
• Adds antivirus exclusions
• Attempts UAC elevation
• Runs Base64-encoded PowerShell

None of that is behavior a legitimate CLI tool needs. Smart App Control and AV exclusions exist specifically to stop unknown code from running unchecked — disabling them from inside an npm postinstall or CLI-invoked step is a strong signal the rest of the chain is designed to evade detection, not to ship a product feature.

The chain, end to end

Elastic’s end-to-end triage traces a multi-stage chain on the Windows path:

1. The package’s "verification" step calls out to vrf.apexaccs[.]org
2. That endpoint returns commands that trigger further encoded PowerShell execution
3. The PowerShell leads into a compiled Python binary, packaged with PyInstaller
4. That binary is obfuscated with PyArmor, a commercial Python obfuscation framework used specifically to resist decompilation and static analysis
5. Execution ultimately hands off to a Go-based shellcode loader
6. The final component dropped by that loader shows strong infostealer characteristics

The "verification" framing is worth pausing on: a step that phones home before deciding what to run next is a common way to gate the malicious payload behind an environment check — serving something benign (or nothing at all) to researchers and automated scanners who don’t match the expected profile, while serving the real payload to the intended targets. It’s the same broader idea (conditional, fingerprinted payload delivery) documented in other recent npm campaigns, even where the specific mechanics differ.

Timeline

Elastic has said they’ll update their thread as the investigation develops — this post reflects what they’d published at time of writing, not necessarily the final word. If npm removes the package or Elastic publishes a fuller writeup, treat that as the authoritative update over this summary.

Related campaigns and techniques

Elastic’s thread points to variants of this campaign and technique elsewhere. Two worth knowing about:

• SafeDep’s writeup on @copilot-mcp/apex — a related but distinct campaign from an "Apex Foundation" branded operator, targeting macOS specifically, with its own C2 infrastructure and a rebrand-after-takedown pattern (the same dropper was republished under a new package name within hours of npm removing the first one). It’s not the same technical chain as the Windows path above, but it’s the same broader "Apex"-branded cluster worth watching.
• A further related observation flagged in Elastic’s thread, documenting additional technique overlap.

We’re not asserting these are all the same threat actor — that’s a connection for Elastic, SafeDep, and npm’s own investigation to confirm or rule out. What’s clear is that "Apex"-branded packages promising Web3/AI tooling have shown up more than once this year with credential-theft payloads behind them.

What to check right now

1. Don’t install or npx @apexacc/cli "just to see what it does" — the verification step alone is enough to trigger the chain on a matching target.
2. If it’s already run on a Windows host, check Smart App Control policy state and your AV’s exclusion list for unexpected changes, and look for outbound connections to apexaccs[.]org in proxy/DNS logs.
3. Treat a hit as a compromised host, not a package to uninstall. The chain ends in an infostealer — assume credentials and browser/session data on that machine need rotating, not just that the package needs removing.
4. Review postinstall/preinstall scripts before running npm install against unfamiliar or recently-published packages — this is exactly the hook this family of attacks relies on.
5. Pin dependency versions rather than accepting floating ranges from low-reputation publishers, so a compromised or malicious later release can’t silently reach your build.

PlayCISO’s free npm package scanner checks a package's postinstall hooks, encoded payloads, and known-bad indicators before you install it. If you already have a domain or file hash from an incident and want a quick reputation check, the free reputation checker (VirusTotal-backed) covers hashes, URLs, domains and IPs.

Frequently asked questions

What is @apexacc/cli and why is it dangerous? It’s an npm package that, according to Elastic Security Labs’ ongoing investigation, behaves very differently depending on your OS. On Windows, it modifies registry settings tied to Smart App Control and antivirus exclusions, attempts to elevate privileges past UAC, and runs Base64-encoded PowerShell — none of which a CLI tool needs to do for legitimate functionality.

What does the Windows infection chain actually do? Per Elastic’s reporting: the package first calls a "verification" endpoint at vrf.apexaccs[.]org, which responds with commands that trigger further encoded PowerShell execution. That PowerShell leads into a Python binary (packaged with PyInstaller and obfuscated with PyArmor), which hands off to a Go-based shellcode loader. The final payload shows strong infostealer characteristics.

Is @apexacc/cli still available on npm? As of Elastic’s report, yes — discovered in July 2026 and still live at time of writing. Elastic says it has been reported to npm and the investigation is ongoing; this is a developing story, so check npm’s advisory database and Elastic’s thread for the latest status.

Is this the same campaign as the @copilot-mcp/apex macOS infostealer? Related but distinct. SafeDep documented @copilot-mcp/apex (and predecessor @apexfdn/apex) as a separate macOS-focused campaign from an "Apex Foundation" branded operator, with different C2 infrastructure than the Windows chain Elastic describes. Whether they share an operator isn’t confirmed by either report.

What should developers and security teams do right now? Don’t run @apexacc/cli or npx it to check. If it’s already run on a Windows host, check for Smart App Control and AV-exclusion changes, look for connections to apexaccs[.]org, and treat the host as potentially compromised, not just the package as something to remove. Review postinstall scripts before installing unfamiliar packages, and pin dependency versions.