Author: Joker&Thinking
In early July 2025, the SlowMist security team received a request for help from a victim user, requesting assistance in analyzing the reasons for the theft of his encrypted assets. The investigation found that the incident originated from the user's use of an open source project zldp2002/solana-pumpfun-bot hosted on GitHub, which in turn triggered a covert theft of coins. For details, seeGitHub's popular Solana tool contains hidden coin theft traps.
Recently, another user used a similar open source project - audiofilter/pumpfun-pumpswap-sniper-copy-trading-bot, which led to the theft of encrypted assets and contacted the SlowMist security team. In response, the team further analyzed the attack method.
Analysis process
Static analysis
We first use static analysis to find the traps set by the attacker. After analysis, it was found that the suspicious code was located in the /src/common/config.rs configuration file, mainly concentrated in the create_coingecko_proxy() method: From the code, it can be seen that the create_coingecko_proxy() method first calls import_wallet(), which further calls import_env_var() to obtain the private key.

In the import_env_var() method, it is mainly used to obtain the environment variable configuration information in the .env file.
During the call, if the environment variable exists, it returns directly; if it does not exist, it enters the Err(e) branch and prints the error message. Due to the existence of a loop {} loop without an exit condition, resources will continue to be consumed.

PRIVATE_KEY(private key) and other sensitive information are also stored in the .envfile.

Back to the import_wallet() method, when import_env_var() is called to obtain the PRIVATE_KEY (private key), the malicious code will determine the length of the private key:
Then, the malicious code uses Arc to encapsulate the private key information to support multi-threaded sharing.

Back to the create_coingecko_proxy() method, after successfully obtaining the private key information, the malicious code then decodes the malicious URL address.

The method first obtains the hard-coded constant of the encoded HELIUS_PROXY (attacker's server address).

Then, the malicious code decodes HELIUS_PROXY (attacker's server address) using bs58, converts the decoded result into a byte array, and further converts the byte array into a UTF-8 string through from_utf8().
By writing a script, the real address of HELIUS_PROXY after decoding can be restored as follows:

After successfully decoding the URL (http://103.35.189.28:5000/api/wallets), the malicious code first creates an HTTP client and converts the obtained private key information payer into a Base58 string using to_base58_string().
Then, the malicious code constructs a JSON request body and encapsulates the converted private key information in it, and sends the private key and other data to the server pointed to by the above URL by constructing a POST request, while ignoring the response result.
No matter what result the server returns, the malicious code will continue to run to avoid user awareness.

In addition, the create_coingecko_proxy() method also contains normal functions such as obtaining prices to cover up its malicious behavior; the name of the method itself has also been disguised and is somewhat confusing.

Through analysis, it can be seen that the create_coingecko_proxy() method is called when the application starts, specifically in the configuration file initialization stage of the main() method in main.rs.

In the new() method of the configuration file src/common/config.rs, the malicious code first loads the .env file and then calls the create_coingecko_proxy() method.

According to analysis, the IP address of the server is located in the United States.

(https://www.virustotal.com/gui/ip-address/103.35.189.28)
It was observed that the project was updated on GitHub recently (July 17, 2025), and the main changes were concentrated in the configuration file config.rs in the src directory.

In the src/common/config.rs file, you can see that the original address encoding of HELIUS_PROXY (attacker's server address) has been replaced with a new encoding.

After using the script to decode the original address encoding, the original server address can be obtained.

Dynamic Analysis
In order to more intuitively observe the theft process of malicious code, we used a dynamic analysis method and wrote a Python script to generate Solana public and private key pairs for testing.

At the same time, we built an HTTP server on the server that can receive POST requests.

Write a Python script to generate the code corresponding to the test server, and replace it with the malicious server address code set by the original attacker, that is, HELIUS_PROXY (attacker server address).

Then, replace the PRIVATE_KEY (private key) in the .env file with the test private key just generated.

Next, start the malicious code and observe the response of the server-side interface.

We can see that the test server successfully received the JSON data sent by the malicious project, which contained the PRIVATE_KEY (private key) information.

Indicators of Compromise (IoCs)
IPs:
103.35.189.28
Domains:
storebackend-qpq3.onrender.com
SHA256:
Malicious warehouse:
https://github.com/audiofilter/pumpfun-pumpswap-sniper-copy-trading-bot
Similar implementation techniques:
https://github.com/BitFancy/Solana-MEV-Bot-Optimized
https://github.com/0xTan1319/solana-copytrading-bot-rust
https://github.com/blacklabelecom/SAB-4
https://github.com/FaceOFWood/SniperBot-Solana-PumpSwap
https://github.com/Alemoore/Solana-MEV-Bot-Optimized
https://github.com/TopTrenDev/Raypump-Executioner-Bot
https://github.com/deniyuda348/Solana-Arbitrage-Bot-Flash-Loan
SummaryConclusion
In the attack method shared this time, the attacker disguised himself as a legitimate open source project to trick users into downloading and executing the malicious code. The project reads sensitive information from the .env file locally and transmits the stolen private key to a server controlled by the attacker. This type of attack is usually combined with social engineering techniques, and users may fall into it if they are not careful.
We recommend that developers and users remain vigilant against unknown GitHub projects, especially when it comes to wallet or private key operations. If you really need to run or debug, it is recommended to do so in an independent environment without sensitive data to avoid executing malicious programs and commands from unknown sources.