Malware configuration usually brings a familiar set of places to mind: embedded strings, resources, registry values, or additional files stored on disk. KREMLIN is a useful example of what happens when that configuration moves outside those locations.
In research published on September 14, 2026, Elastic Security Labs documented a KREMLIN JavaScript loader that retrieves some of the addresses it needs from an Ethereum smart contract. Payload and infrastructure locations therefore do not have to remain fixed inside every deployed sample.
The interesting part is not simply that blockchain is involved. It is where the configuration lives and how the malware reaches it.
##From a JavaScript Loader to a Smart Contract
KREMLIN's second-stage NodeJS loader queries an Ethereum smart contract for parameters such as main-v2, sub-module, and sentinel. The returned values can point to locations used to retrieve later modules or payloads.
That gives the operator a useful degree of flexibility. If part of the infrastructure changes, every deployed sample does not have to be rebuilt. The malware can keep the same lookup logic while values behind the contract are updated.
Static analysis may reveal the contract address and the code responsible for querying it. The final domain or payload URL used at a later moment, however, may never appear directly inside the binary.
IMAGE PLACEHOLDER 1: Relevant section of Elastic Security Labs' KREMLIN infection-chain diagram.
##Following the Flow Instead of the Final Value
This changes the direction of the analysis. Searching the binary for the final C2 domain may be less useful than following how that value enters the program.
Which contract is queried? Which parameter is requested? What format does the response use? Where is the value stored in memory, and which download or networking function consumes it afterward?
Once that chain is understood, the analysis explains more than the infrastructure value observed at one moment. It also explains how the malware can obtain the next one.
Understanding how configuration reaches the program can be just as important as recovering the final configuration itself.
##What Is the Blockchain Doing Here?
The Ethereum smart contract in KREMLIN is not simply acting as the malware's C2 channel. It is closer to an updateable resolver. The malware knows where and how to query the contract, retrieves the address it needs, and then continues into the next stage of the operation.
This does not make the infrastructure invisible. The query logic still exists in the malware, and blockchain activity leaves its own traces. What changes is the lifetime of individual infrastructure values.
If one domain disappears, another value can be supplied through the same mechanism. For an analyst, understanding that mechanism can therefore be more useful than treating a single returned domain as the whole story.
IMAGE PLACEHOLDER 2: Source image or screenshot showing module/C2 locations being resolved through the Ethereum smart contract.
##The Rest of the Infection Chain
Elastic's infection-chain diagram also makes it clear that the smart contract is only one stage of a much larger operation. After the JavaScript and NodeJS loaders, modules are downloaded through staging domains and sources such as archive.org. Later stages include a RunPE injector, CAB/JPEG carriers, sideloading through a signed SentinelOne DLL, PULSAR/REMCOS RAT, and a malicious browser extension.
That makes KREMLIN more than a single-file problem. A URL, DLL, or script observed at one stage may only exist to reach the next component. Preserving the relationship between those stages matters if we want to understand the behavior of the whole chain.
##The Browser Extension Side
Another notable part of KREMLIN is the way its malicious Chrome and Edge extension is installed. The malware modifies Chromium's Secure Preferences and recreates the integrity values needed for the browser to accept the new state.
Simply finding a modified file does not fully explain that behavior. The analyst also needs to understand what Chromium validates and how the malware produces values that satisfy those checks.
That fits the broader structure of KREMLIN: the relationships between artifacts often reveal more than any single artifact on its own.
##Conclusion
KREMLIN does not require all of its configuration to sit inside the binary in the form we would normally expect. Its loader can retrieve addresses through an Ethereum smart contract and use those values to continue the infection chain.
So failing to find the final C2 or payload location inside the sample should not end the investigation. The next step is to determine whether the program obtains that information elsewhere and to follow where the returned value goes.
KREMLIN is a good reminder that the artifact we want may not live on the endpoint, while the code path leading to it still does.
##Source
Elastic Security Labs — KREMLIN
Stay with Malrev0x...