{“lastseen”:”2026-05-06T22:07:29″,”description”:”## Introduction\\n\\nThere\u2019s an automated attack circulating right now that breaks into unprotected Redis servers, takes over the underlying machine, and then carefully puts everything back the way it found it. It restores the database filename. It deletes the tools it used. It detaches from the connections it opened. When it\u2019s done, the server looks healthy. Logs look normal. Nothing appears to be wrong.\\n\\nExcept there\u2019s a new line in \/root\/.ssh\/authorized_keys that wasn\u2019t there before.\\n\\nWe discovered this attack recently targeting a single Redis honeypot. Attacks came from 10 distinct source IPs across six countries, and over 1,200 attack attempts were recorded in a single month. Our data-driven, AI-based honeypot enabled us to detect and analyze this activity in detail.\\n\\n## The Attack\\n\\nRedis was never designed to face the internet directly. But people expose it: a misconfigured security group, a container with the wrong port mapping, a developer who needs it reachable for a quick test. The default configuration has no password. Port 6379, open to the world.\\n\\nWhen our Redis honeypot instance was exposed, the first visitors arrived within minutes. They connected, ran INFO, read the version string, and disconnected. That\u2019s it. They aren\u2019t trying to break in. They\u2019re taking a census- cataloging what\u2019s out there, how old it is, whether it\u2019s protected. Thousands of these scans happen every day across the internet, quiet and mechanical.\\n\\nThen a second wave showed up. These bots tried something: config set dbfilename backup.db. It\u2019s a test. If Redis accepts the command, it means the server will let you write files to arbitrary paths on the host machine\u2019s disk. The bot doesn\u2019t exploit this. It just records the address and leaves. It\u2019s building a list for someone else.\\n\\nThe real attack came as a single connection that tried five different methods of compromise in rapid sequence. The whole thing took a few seconds. It opened with FLUSHDB to wipe the database and clear the slate, and then worked through the following tricks:\\n\\n**Cron injection:** redirect Redis\u2019s save directory to \/var\/spool\/cron\/, write a key whose value is a cron entry. Now the host downloads and runs a binary from a C2 server every minute, with a randomly generated filename to dodge signature detection.\\n\\n**Lua sandbox escape:** a Debian\/Ubuntu packaging decision dynamically linked Redis\u2019s Lua interpreter against the system library, breaking the sandbox. One EVAL command loads io.popen, leading to full RCE. CVE-2022-0543 is four years old, yet still working.\\n\\n**SSH key planting:** same file-writing trick, pointed at \/root\/.ssh\/authorized_keys. One line, and the operator has root access forever.\\n\\n**Replication hijacking:** SLAVEOF tells Redis to sync from the attacker\u2019s server, which serves a malicious shared object disguised as a database dump. MODULE LOAD turns it into a Redis extension exposing system.exec. This trick leads to full RCE through Redis\u2019s own replication protocol.\\n\\n**Direct execution:** use that module to download and run the binary through the shell.\\n\\nFive methods, one connection, a few seconds- but attackers don\u2019t need all five to work. They just need one.\\n\\nThen the connection did something unexpected. It started cleaning up.\\n \\n \\n SLAVEOF NO ONE\\n \u00a0system.exec \\”rm -rf \/tmp\/exp.so\\”\\n \u00a0MODULE UNLOAD system\\n \u00a0config set dbfilename dump.rdb\\n\\nIt detached from the rogue replication server. It deleted the malicious shared library from the disk. It unloaded the module from Redis. It restored the original database filename. Redis is often used for ephemeral data, like sessions, queues, and rate limits, so a cleared database might not even raise an alarm. It just looks like a restart.\\n\\nThe attack was optimized for **staying hidden after breaking in**. Every forensic trace is reversed. The only artifact left behind is an SSH public key, one line in a file that most administrators never read, indistinguishable from a legitimate entry. Even if you find the malware, kill the process, and delete the cron entry, the key is still there. Root access, on demand, forever. Or until someone manually audits authorized_keys, which is rare.\\n\\n## The Botnets\\n\\n**The SSH Key Operator:** A sophisticated, single-operator attack that targets unprotected Redis servers. It attempts five different RCE methods. Over a single month, our single Redis honeypot recorded over 1,200 attack attempts from 10 distinct source IPs across six countries. The majority included RCE attempts: Lua sandbox exploits and replication hijacking aimed at arbitrary command execution on the host. Different C2 servers, different binary names, but the same sequence, the same Lua payload, the same SSH public key. One operator, rotating sources and randomizing filenames. The key is the only constant.\\n\\nThe traffic came in distinct waves. Baseline was roughly 15 to 20 attempts per day from two or three sources. Then, without warning, a wave would hit, with a single IP connecting hundreds of times in an afternoon, once every 69 seconds- in total, over 300 attempts in a few hours. We saw three to four waves per month, each lasting two to six hours, each from a different source IP. Then silence until the next wave.\\n\\n**MGLNDD Botnet:** A separate operation that periodically connects to exposed Redis servers, sending a single command format (MGLNDD_54.147.241.42_6379) to perform a \\”roll call\\” – checking whether the Redis server is already part of their botnet. It operates from Azure VMs using AWS IP addresses, never repeating the same source twice.\\n\\nThe SSH key operator and the MGLNDD botnet share the same hunting ground but ignore each other completely. Two separate operations are working in the same territory. An exposed Redis port isn\u2019t just targeted by an attacker, it\u2019s targeted by an ecosystem.\\n\\n## Takeaway\\n\\nThe attack is silent. The window between \\”I’ll fix that config later\\” and the machine is silently compromised isn’t days or hours-it’s seconds. Everything looks fine afterward: the server is up, the application works, the dashboards are green. The only artifact is an SSH key, patient and persistent, waiting to be used.\\n\\n**What You Must Do:**\\n\\n * Never expose Redis to the internet. Restrict access via security groups, firewalls, or VPCs.\\n * Set a strong Redis password. The default has none.\\n * Regularly audit \/root\/.ssh\/authorized_keys for unfamiliar keys-attackers hide persistence here.\\n * Keep Redis patched. CVE-2022-0543 still works after 4 years.\\n * Monitor for suspicious commands: CONFIG SET, MODULE LOAD, FLUSHDB, SLAVEOF.\\n * Use file integrity monitoring on \/root\/.ssh\/authorized_keys to detect tampering.\\n * Don’t trust green dashboards. Assume you’ve been breached until verified otherwise.\\n\\n\\n\\nImperva Data Security solutions provide comprehensive protection for your data against a wide range of threats. These offerings enable security teams to identify the location of sensitive information, monitor access patterns, and detect misuse promptly to facilitate timely response.\\n\\nThe post Your Redis Server Looks Fine. That\u2019s the Problem. appeared first on Blog.”,”published”:”2026-05-06T18:28:30″,”modified”:”2026-05-06T18:28:30″,”type”:”impervablog”,”title”:”Your Redis Server Looks Fine. That\u2019s the Problem.”,”source”:””,”references”:””,”id”:”IMPERVABLOG:C28DF37D7E21421E9A88966A4E0F7EA1″,”bulletinFamily”:”blog”,”cwe”:null,”cvelist”:[“CVE-2022-0543″],”sourceData”:””,”sourceHref”:””,”cvss”:{“score”:10,”severity”:”CRITICAL”,”vector”:”CVSS:3.1\/AV:N\/AC:L\/PR:N\/UI:N\/S:C\/C:H\/I:H\/A:H”,”version”:”3.1″},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:”https:\/\/www.imperva.com\/blog\/your-redis-server-looks-fine-thats-the-problem\/”,”category_name”:”News”,”post_link”:””,”product”:””,”version”:””,”vendor”:””,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:”2026-05-06T22:07:29″,”description”:”## Introduction\\n\\nThere\u2019s an automated attack circulating right now that breaks into unprotected Redis servers, takes over the underlying machine, and then carefully puts everything back…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[9,6,8,36,12,59,13,7,11,5],"class_list":["post-51831","post","type-post","status-publish","format-standard","hentry","category-category_news","tag-critical","tag-cve","tag-cvss","tag-cvss-100","tag-exploit","tag-impervablog","tag-news","tag-security","tag-tapic","tag-vulnerability"],"yoast_head":"\n