NullReceiver: the tactic that the C2 IP hides in Etheum's destination directions

Cybersecurity researchers have detected a sharp variation of the technique known as EtherHering: a method that takes advantage of the public nature of blockchains such as Etherium to transfer command and control instructions (C2) without resorting to traditional servers. The new tactic, baptized as NullReceiver by the group OpenSourceMalware, completely dispenses with smart contracts or data fields in transactions and, instead, code the IP address of the C2 within the bytes of the destination address of an Etheum value transfer and null data. This reduces the cost of gas, eliminates obvious fields where you search for payloads and makes it difficult to create static prints that defenders can monitor.

In the chain of events described by analysts, malicious JavaScript libraries published in npm - identified as bianira-ui and fluid-type-ui - carried code capable of locating a fixed attacker wallet in the lockchain, reading its latest outgoing transaction and extract the IP address from the first four hexadecimal bytes of the "To" address of that transaction. This address does not exist to receive funds; its only function is to serve as a binary container that encodes, for example, "a658863e" → 166.88.134.62 and, in the rest of bytes, to include a legible label ("helloipbot!!") for the author. The bookstores were removed from the register, but had already been downloaded hundreds of times after their publication in late July 2026.

NullReceiver represents a tactical escalation with respect to EtherHering, publicly documented in 2023, because it eliminates the component that allowed response teams to mark and pursue a known public destination. While EtherHering could host URLs or complete scripts in calldata or contracts, NullReceiver only transport a few useful bytes but does so so that there is no "field" to track; each transaction uses a different and disposable destination address, which complicates the lock rules based on transaction patterns.

The use of lockchain as a C2 channel is not new in sophisticated campaigns and has been associated by intelligence teams with State-sponsored actors - in this case, public signals link the activity to North Korean campaigns that have used subterfuges in professional networks and malicious packages to achieve remote execution. The technical novelty is in the refinement: minimum, cheap and apparently harmless transactions that only make sense when a committed client applies the reverse logic and converts direction bytes into an IP address.

For defenders and development leaders, the main lesson is double: the attack area in the code supply chain has evolved, and conventional signals in the lockchain (reusable contracts, suspicious calldata, public domains) are no longer a guarantee of detection. Conventional static audits can overlook code that only performs simple cryptographic operations and consultations to public nodes therefore it is necessary to complement the integrity control of the code with performance and network controls in the endpoint.

I recommend that corporate development and security teams implement practical and prioritized measures: require approval and review policies for new units, paint versions in lockfiles and publish only signed packages or from internal records; enable multi-factor authentication for publication accounts in public repositories; use software composition analysis tools (SCA) and static scanning to detect suspicious patterns such as calls to Ethereum nodes, use of web bookstores 3 or address decoding; and also implement egress controls in endpoints that prevent unauthorised outgoing connections from Node.js. processes In critical environments, consider the use of private proxy repositories (e.g. on-premises solutions) to filter and validate packages before consumption.

From the perspective of detection and response, the tactic forces to change attention to behavioural signals: to monitor and alert processes that consult public blockchain APIs, unexpected connections to newly created IP addresses or address resolution patterns, and any attempt to convert hexadecimal data into IP addresses within third-party code. The capabilities of EDR and network rules must be adjusted to capture these anomalies, and threat intelligence teams should track known attackers and their transactions, even if that task is now more laborious and less conclusive.

The community benefits when this kind of tactics is documented and shared, because it allows anticipating counter-attacks and tightening controls before large-scale campaigns achieve greater impact. For those who want to deepen how transactions work and why the blockchain allows such technical abuse, the official Etheum documentation provides a solid basis on transaction and coding structures: https: / / ethereum.org / en / developers / docs /. To understand best practices in software supply chain security and concrete mitigation measures, the resources of the OWASP Supply Chain Security project are very useful: https: / / owasp.org / www-project-supply-chain-security /.

In short, NullReceiver is a reminder that the attackers take advantage of the transparency of blockchains for greater operational resilience and tactical anonymity. The defense can no longer rely only on static black lists: it requires controls in the development phase, validation of the software entering the organization, and a behavior-based detection layer that blocks unusual connections and processes before a committed dependence pivot into a greater intrusion.