Ethersphere Hijacked With Crypto Stealing Malware Via Github & npm

Threat actors compromised Ethersphere’s npm and GitHub packages to steal crypto wallet keys and deploy cross-platform backdoors

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.

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.

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.

@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.

Affected Dependencies

The following dependencies can either directly or indirectly import the affected @ethersphere/bee-js package.

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

swarm-desktop malicious commit

After the commit was added, the worker was triggered to run a publish workflow which created both npm and GitHub releases.

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.

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.

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.

The C2 IP address is received remotely from the ETH contract address 0xf8a900Db50b3331be6B768bA460BB59f3E40C344 – which means the threat actor could change it on demand.

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 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.

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:8041

193[.]57[.]9[.]155:4912

0xf8a900Db50b3331be6B768bA460BB59f3E40C344

735aba95e24f515a5cea4efea309f245952917d372b37b5fbea305986dbcd568

1f3a7afd2e43215f09f2a81063dc2796af556bae74aaf492fba2d66e5d65b14c

2496d74e6a913eba39c8537be31baeff9cf6ccdd8ee84a69475302815cfd4105

705b4aa2bc6fa35f8e6d448f3c6e193fac6027b9b5239e212e09732cc9fc0dba

37d14bff30762ca701e9c1f8bc6c57c065bb20ae3a2208cb7411a6530610f08e

7527e86d70e7c9493db4356f1c3775380431b310000f2602c1e993cf435d01da

9b73e7cd4e1425e770392549d8df46c706139ef476f4f7b9ac405165dc8d9696

b601776817363b96295119f7221338a122d5247a35a77a64b04f286e1bbcc565

80d2672e2599732d3c0ae2a4cd0d1e3fe4d555a60273ce33feb99db3f34d250f

fae61f31f00988fdc5cc9e7272b51e08af2e245d81003237875415930fd27358

solidity-langsupport-runner.service

com.solidity.langsupport.runner