Every day, automated bots scan the entire internet looking for servers with weak logins, exposed services, or unpatched software. Once they get in, the most common payload isn't ransomware or data theft — it's a cryptominer, silently burning your server's CPU to mine cryptocurrency for someone else. It's quiet, often goes unnoticed for weeks, and can rack up a massive cloud bill before anyone realizes the server has been compromised.
Weak or Password-Based SSH Logins
How it works: Bots constantly scan the internet for servers with SSH open on port 22 and try thousands of common username/password combinations (root/admin, root/123456, root/password). If password authentication is enabled and the password is weak, it's only a matter of time before a bot gets in.
Real-world pattern:
A fresh cloud server with root password login enabled can see thousands of brute-force attempts within hours of being switched on — long before a human ever logs in to configure it.
How to protect yourself: Disable password authentication entirely and use SSH key pairs only. Move SSH off the default port 22, and use a tool like fail2ban to automatically block IPs after repeated failed attempts.
Exposed Services Without Authentication
How it works: Services like Redis, Docker's API, Jenkins, and database admin panels are sometimes left listening on a public IP without a password, often because they were only meant for local use. Attackers scan for these specifically, since several have known techniques to achieve remote code execution — for example, writing a malicious cron job through an open, unauthenticated Redis instance.
Common targets:
Unauthenticated Redis (port 6379), exposed Docker daemon sockets, open database ports (5432, 3306, 27017) reachable from anywhere, and admin dashboards (Jenkins, Kubernetes, phpMyAdmin) with default credentials.
How to protect yourself: Bind internal services like Redis and your database to localhost or a private network only — never to 0.0.0.0 — and put a firewall in front of every port that doesn't need to be public.
Unpatched Software With Known Vulnerabilities
How it works: When a critical vulnerability is disclosed in widely-used software (web frameworks, CMS plugins, container runtimes), attackers race to write automated exploits before server operators get around to patching. Cryptomining gangs are usually the fastest to weaponize these, since the payoff doesn't require ongoing access — they just need a few seconds of code execution to drop a miner.
Why this matters:
Mass-exploitation campaigns following major CVE disclosures (Log4Shell, Confluence RCEs, Docker API exploits) have repeatedly been tied to cryptomining botnets within days of the vulnerability going public.
How to protect yourself: Enable automatic security updates where possible, and patch internet-facing software promptly — especially anything that handles untrusted input.
Leaked or Reused Credentials
How it works: API keys, database passwords, and SSH keys accidentally committed to public repositories, shared in plaintext, or reused across multiple projects give attackers a direct path in — no brute-forcing required. Automated bots specifically scan public code repositories for leaked credentials within minutes of a push.
Protection tip:
Never commit .env files, keys, or hardcoded passwords to version control. Use a unique, randomly generated password or key for every server and service — never reuse the same one across projects.
How to protect yourself: Rotate any credential the moment you suspect it might have been exposed, and use secret-scanning tools on your repositories to catch leaks before they're exploited.
Malicious Packages in the Software Supply Chain
How it works: Attackers occasionally publish malicious or hijacked packages to npm, PyPI, and other package registries. A single npm install of a compromised dependency can silently drop a cryptominer onto the build server or production host, often disguised as a "postinstall" script.
Warning signs:
Unusually high CPU usage right after a deployment, unfamiliar processes with names mimicking system tools (like kdevtmpfsi or xmrig), and outbound network connections to unfamiliar mining-pool domains.
How to protect yourself: Pin dependency versions, review what changed before upgrading packages, and run npm audit or equivalent tooling regularly.
How to Tell If Your Server Is Already Mining for Someone Else
- Constant high CPU usage with no obvious cause — check with
toporhtopfor processes consuming 90–100% CPU. - Unfamiliar process names that mimic legitimate system binaries, often running from
/tmpor hidden directories. - Unexpected cron jobs you didn't create, often used to reinstall the miner if it's killed.
- Outbound connections to unknown IPs or ports associated with mining pools — check with
ss -tnpor similar. - Sudden cloud billing spikes from sustained CPU usage you can't otherwise explain.
The Golden Rules of VPS Security
- SSH keys only, never passwords. Disable password authentication in
sshd_config. - Firewall everything by default. Only open the ports your application actually needs publicly.
- Bind internal services to localhost. Redis, databases, and admin tools should never face the public internet directly.
- Patch promptly. Enable automatic security updates for your OS and keep dependencies current.
- Never reuse credentials. Every server, database, and service gets its own unique, randomly generated secret.
- Monitor for anomalies. Unexplained CPU spikes are usually the first sign something is wrong.
Spotted a suspicious link or message claiming to be a "security alert"?
Scammers exploit security scares too. Screenshot it and scan with ScamSense before you click anything.
Download on Google Play