Threat actors compromised Ethersphere’s npm and GitHub packages to steal crypto wallet keys and deploy cross-platform backdoors
Overview
OX Security researchers identified a coordinated supply chain compromise affecting the Ethersphere ecosystem, a decentralized storage and communication protocol for Ethereum. Threat actors leveraged a suspected compromised developer access key to inject malicious code into both the @ethersphere/bee-js npm package and the official ethersphere/swarm-desktop GitHub repository.
The injected code targets local Swarm node configurations and encrypted wallet keys before establishing persistent remote access. While the tainted npm package version has since been revoked, the malicious GitHub release version remains accessible at the time of writing. Combined, the affected components exposed over 16,800 monthly downloads across direct and indirect downstream dependencies.
Key Findings
- The malicious commit adds a C2 payload download and execution logic. The C2 server contains platform specific payloads, according to which machine was infected, targeting Windows, Linux & MacOS. If the platform isn’t given to the server, or not supported by the malicious server – it returns a benign looking script as decoy.
- The malicious C2 domain framework metrics[.]xyz was registered two days before the attack happened, which indicates that threat actors already had a stolen access key and were planning the attack up ahead.
According to our research, the C2 server including all three payloads are still live, in both npm and GitHub variants.
Recommended Actions
- Check for affected versions. Review installed dependencies and lockfiles for the compromised package versions listed below. Installation alone does not necessarily mean the malicious payload executed.
- Investigate potential wallet compromise. If an affected package was loaded and the malicious code executed, treat cryptocurrency wallets and associated credentials accessible from that environment as potentially compromised.
- Restrict dependency updates. Pin dependencies to verified clean versions and consider implementing a minimum package-age policy to reduce exposure to newly published malicious releases.
Impact Analysis
- @ethersphere/bee-js Footprint: The affected npm package averages 13,378 monthly downloads.
- Direct Dependents: 7 out of 47 downstream packages were configured to resolve the compromised version range, representing an additional 3,152 monthly downloads.
- Transitive Dependents: 1 out of 8 indirect downstream packages was impacted, representing 260 monthly downloads.
- GitHub Standalone Installs: The malicious swarm-desktop GitHub release was downloaded 44 times prior to publication.
Compromised Packages
| Package | Versions | Fix Versions | Ecosystem | Status |
| @ethersphere/bee-js | 13.3.0 | 13.2.0 | npm | Reverted to 13.2.0 |
| ethersphere/swarm-desktop | 0.56.2 | 0.56.1 | GitHub | Live |
Affected Dependencies
The following dependencies can either directly or indirectly import the affected @ethersphere/bee-js package.
| Package | Versions | Ecosystem |
| @solarpunkltd/swarm-id | 0.10.5 | npm |
| @snaha/swarm-id | 0.8.0 | npm |
| @ethersphere/swarm-cli | 3.7.0 | npm |
| @ethersphere/bee-dashboard | 0.37.1 | npm |
| @solarpunkltd/file-manager-lib | 1.1.1 | npm |
| @upcoming/bee-dashboard (via @solarpunkltd/file-manager-lib) | 0.33.3 | npm |
| bee-wasm-js | 0.1.1 | npm |
Infection Analysis
The malware was committed to both Ethersphere GitHub bee-js project and the swarm-desktop, potentially through a stolen API key.
Inspecting the commits, in both we see the same pattern – a malicious C2 payload dropper that executes during install and execution phases.
- bee-js malicious commit
- https://github.com/ethersphere/bee-js/commit/de2f74e784b2eafa0d66fbb6d88b42ea11ee34cf
- swarm-desktop malicious commit
- https://github.com/ethersphere/swarm-desktop/commit/2de727046706062d38edfbbf8340f32d1eb2bdfb
After the commit was added, the worker was triggered to run a publish workflow which created both npm and GitHub releases.
Technical Analysis
The malware’s logic is simple: connect to the C2 server, download a platform specific payload, and install a backdoor.
The malicious C2 server responds to the payload download request with either a Windows, Linux, MacOS payload, and if the targeted machine isn’t in the list – it downloads a decoy non-malicious script.
Windows variant:
Linux variant:
MacOS variant:
Decoy script:
The Ethersphere Swarm saves an encrypted key and a configuration file in their data directory, the malware accesses them and uploads to /v1/swarm/report.
Uploading the data:
Each variant then continues to download a platform-specific backdoor –
- The Windows variant uses a ScreenConnect remote access, which connects to 185[.]232[.]84[.]169:8041
- The Linux & MacOS variants deploy the evjawbreaker Go-based RAT malware which connects to 193[.]57[.]9[.]155:4912.
- The C2 IP address is received remotely from the ETH contract address 0xf8a900Db50b3331be6B768bA460BB59f3E40C344 – which means the threat actor could change it on demand.
Conclusions
Following the recent Binance hack and the DPRK PolinRider malware from last week, crypto currency based attacks are a continuous and emerging threat.
That being said, this recent Ethersphere hijack can teach us a lot on how threat actors approach supply chain attacks and account compromises:
- Velocity beats complexity: Threat actors are lazy – they understand that their malware is going to be taken down quickly, so the malicious code isn’t obfuscated at all, no special memory tricks or novel zero days. The code is simple to read and any human or AI could flag it in an instant. This gives us the impression that their goal is to get as much crypto as they can and disappear quickly. Additionally, the domain registration two days before the attack implies that it took the threat actors two days to build and move their infrastructure to the newly bought domain, and trigger the GitHub build while no one was on guard.
- Crypto is the new gold: Since the creation of Bitcoin, threat actors have a way to launder money and do illegal activities while staying anonymous. Having this kind of asset proves itself highly useful, as the ROI for a successful hack is a direct conversion of the amount of effort shipped into hacking the accounts to the amount of stolen crypto currency. Think about it – why would talented hackers (or sloppy threat actors) want to invest their time and effort doing bug bounties in a highly competitive cyber era, just to get their bug assigned as a duplicate with no bounty or credit? Where the same effort can go to generating more predictable outcomes, in a much lower effort.
- Defensive systems are still too slow: Yes, I know it’s ironic coming from a defensive cyber security company, but this issue needs to be addressed directly and with honesty – GitHub and npm didn’t learn, after being compromised directly by TeamPCP this year, and after numerous promises for the npm firewall. If the npm package was removed but the malicious GitHub release is still live, it shows we have a gap in the place where decisions are being made in each platform. Additionally, it shows that there’s no direct connection between the IOCs extracted from the npm version compromise to the GitHub one. In a fully functioning system, (hey Microsoft, it’s free advice right here) any malicious IOC from npm is directly queried and blocked at GitHub and vice versa, especially when these platforms are connected and could be used to cross reference each other.
The more we invest in protecting users through npm and GitHub, threat actors will be pushed away to seek other entry points to the supply chain, while no system is perfect – npm just makes it too easy, and it needs to stop before another GitHub-level compromise apoears in the wild.
IOCs
Network Addresses
- frameworkmetrics[.]xyz
- api[.]frameworkmetrics[.]xyz
- hxxps://api[.]frameworkmetrics[.]xyz/v1/analytics
- hxxps://api[.]frameworkmetrics[.]xyz/v1/electron
- hxxps://api[.]frameworkmetrics[.]xyz/v1/assets/
- hxxps://api[.]frameworkmetrics[.]xyz/v1/swarm/report
- 185[.]232[.]84[.]169
- 185[.]232[.]84[.]169:8041
- 193[.]57[.]9[.]155
- 193[.]57[.]9[.]155:4912
Ethereum Contract
- 0xf8a900Db50b3331be6B768bA460BB59f3E40C344
Payload Hashes
- 735aba95e24f515a5cea4efea309f245952917d372b37b5fbea305986dbcd568
- 1f3a7afd2e43215f09f2a81063dc2796af556bae74aaf492fba2d66e5d65b14c
- 2496d74e6a913eba39c8537be31baeff9cf6ccdd8ee84a69475302815cfd4105
- 705b4aa2bc6fa35f8e6d448f3c6e193fac6027b9b5239e212e09732cc9fc0dba
- 37d14bff30762ca701e9c1f8bc6c57c065bb20ae3a2208cb7411a6530610f08e
- 7527e86d70e7c9493db4356f1c3775380431b310000f2602c1e993cf435d01da
- 9b73e7cd4e1425e770392549d8df46c706139ef476f4f7b9ac405165dc8d9696
- b601776817363b96295119f7221338a122d5247a35a77a64b04f286e1bbcc565
- 80d2672e2599732d3c0ae2a4cd0d1e3fe4d555a60273ce33feb99db3f34d250f
- fae61f31f00988fdc5cc9e7272b51e08af2e245d81003237875415930fd27358
Strings
- X-Ethersphere: 1
- solidity-langsupport-runner.service
- com.solidity.langsupport.runner
