This Monero cryptojacking review examined 1,018 honeypot files and recovered four valid Monero addresses associated with 64 sample hashes. The evidence shows mining configuration, persistence mechanisms, concealment, and attempts to redirect existing miners.
This review used static analysis and saved sandbox traces. During this review, no samples were rerun or destination servers contacted. Personal and operational identifiers are omitted. Full addresses and destinations follow, reproduced exactly from the captured evidence.
How the samples were collected
Our internet-facing honeypots recorded interactions with decoy services. Cowrie provided an emulated SSH and Telnet shell, recording commands and retaining files transferred during sessions. Its shell did not execute captured binaries on the sensor operating system. Downloads requested through the emulated shell could make real HTTP or HTTPS requests, preserving the returned files for analysis.
An uploader forwarded captured files and session events to a private collector over an encrypted tunnel. The collector recomputed each file's SHA-256 hash before accepting it. Identical bytes shared a sample record, while sightings retained the associated sensor, session, filename, and download URL where available.
Those session records let us connect scripts to wallet values supplied when they were launched. The review combined the collected files with previously saved analysis reports, rather than downloading fresh copies from the listed destinations.
The collection contained approximately 3.75 GB of captured material. Searching for miner names helped narrow the review, but those matches needed context. Some programs mentioned mining software while looking for competing processes. Others contained configuration templates without an immediately visible wallet. The strongest findings came from connecting file contents, executable logic, and the commands used to launch a sample.
How Monero cryptojacking persists
Fifty-six files shared this wallet, encoded with XOR using 0x5a:
89PNDJssF3RbL6m7aSydYB4tLrvjZ28Cr8n4LucmFHat8botWkWr6oDPEaSHfeZn4wfA3dC5QsE7nZV1P6tE81sK2i9heam
Disassembly confirmed decoding and pool configuration construction:
project0.cc:443
5.189.149.171:443
169.58.248.162:443
A representative binary contained cron entries and a system-helper timer for relaunching payloads. Embedded shell functions hid matching crontab entries, filtered top output, and stripped forceful signal options from kill calls. Startup hooks referenced libbase.sh.
These capabilities suggest persistence and interference with inspection. Its saved sandbox run showed hardware discovery before exiting with status 1, without recorded network attempts.
The crontab wrapper filtered selected entries when listing jobs, but retained those entries during editing or removal. An administrator could therefore receive an incomplete picture from familiar commands. This is evidence of intended deception in the supplied shell logic, without demonstrating that the wrapper was installed or used successfully on a victim.
The group accounted for 13,931 sighting records across 20 sensors. Those figures describe collection activity. They do not show how many machines an operator controlled, and repeated or incomplete transfers can produce misleading impressions of scale.
The .b0s variant
This sample embedded a plaintext wallet and encoded primary destinations:
4ALMv7Z7Vn2YoJX89ccULYCukCefUKjSyMC1rWkVCWTB8G18Grue3hkgnbiDrCgr66TkdxnitVfyrXfxU9PhjvKMLomGLAH
fvbi.cc:443
130.12.182.19:443
Cron templates launched files named snap.service.d, snapd.service.d, and .bash_history. Startup hooks invoked libutility.sh. Other commands targeted duplicate miners and selected sshd processes outside normal locations. Their presence suggests competition for resources, without proving the targeted processes were malicious.
Its sandbox run also exited with status 1. The primary configuration disabled TLS despite using port 443. XMRig documents separate address and TLS settings:
https://xmrig.com/docs/miner/config/pool
Both groups included these fallbacks:
pool-fr.supportxmr.com:5555
pool-phx.supportxmr.com:5555
pool-nyc.supportxmr.com:5555
pool-hk.supportxmr.com:5555
pool-sg.supportxmr.com:5555
pool-aus.supportxmr.com:5555
pool-ca.supportxmr.com:5555
Shared pools do not establish common ownership or pool-provider involvement.
The .b0s file appeared in 618 sighting records across 19 sensors. Its wallet was readable directly, while its primary destinations required decoding. A visible wallet can accompany hidden settings, so automated reports need careful review. Conversely, a destination string alone cannot establish that a program connected to it.
Downloaded payload
Another payload contained network-dispatch persistence templates for systemd, cron, and startup hooks. A captured command downloaded it, granted execute permission, and attempted background execution:
http://77.239.124.165:80/akbarniga.x86_64
Its compiled default wallet and pool applied when runtime values were empty:
43cLb4E2oLf3mfy9SZbKHvSxDVm3X7rxVcLCzBt4BdHjEud7YasW5f7AnQR7oBSx9s83Muo4FnyZoXs5j1opAn2yASGdLoX
pool.supportxmr.com:3333
The saved sandbox trace read /proc/self/status, then sent itself SIGKILL. The reason remains unproven. Neither persistence nor mining was demonstrated by that run.
The download address and pool address serve different purposes. One identifies where a captured command tried to obtain executable content. The other identifies a compiled mining destination. Mixing them in one server list could misidentify a download server as a mining pool.
For legitimate downloads, see our guide to verifying Monero binaries with PGP.
Redirecting existing miners
Six scripts received this wallet and pool through environment variables across fourteen captured sessions:
86dUB9nfevZBA63EEQ4bAvhpmohm6kwFXDNZu5L2HfryLbc9qjq2JRMaugzFHc62NabNLtns38a41DiFWEzuKoCnFq13nUS
pool.hashvault.pro:443
Their code inspected Monero processes, Docker containers, cron jobs, timers, and watchdogs. Conditional takeover routines disabled competing startup entries, removed a matching container, and attempted mining reconfiguration.
Other routines downloaded or built XMRig, changed local Monero settings, and installed an ensure.sh restart helper. Cron and systemd templates supported persistence. Launch settings requested TLS.
One recorded run created a working directory but found no Monero binary or Docker container. It finished without demonstrating mining.
The scripts were especially revealing because their payout setting arrived outside the uploaded file. Matching sensor and session records recovered the value supplied at launch. Reading only the script would expose the variable name but miss its contents. This illustrates why an apparently unconfigured mining script can still represent a concrete deployment attempt when its surrounding session is available.
Validation
All four addresses passed Base58 decoding and Keccak checksum checks. Address documentation:
https://www.getmonero.org/resources/moneropedia/address.html