scribblebubblebibi.top: a server that handed out Linux botnet programs for routers and cameras, and what to do about it

What scribblebubblebibi.top is, and what we know about it

scribblebubblebibi.top is not a program on your computer. It is a web address that the abuse.ch project URLhaus lists as a place where malware was served: one shell script and thirteen Linux programs, one for each kind of processor. We found no public write-up of this exact address, so what follows is what URLhaus shows, what our own check found, and what other researchers have published about the same pattern.

1. 1

   What URLhaus lists

   Fourteen file addresses on the domain, all on plain http. Thirteen sit in a folder called hiddenbin and are named Space followed by a processor name: arm, arm5, arm6, arm7, arc, i686, m68k, mips, mpsl, ppc, sh4, x86 and x86_64. The fourteenth is a shell script, 1.sh, in the top folder. The 13 programs were added within 22 seconds on 15 October 2026 around 18:52 UTC, and the script at 19:07 UTC. All 14 are marked offline.

2. 2

   What the tags mean

   elf marks a Linux program file (not a Windows .exe). sh marks a shell script. ua-wget means the file was requested by the download tool wget, which is what a script on a router or a server uses, not a person with a browser. botnetdomain means the reporter sees the domain as part of a botnet's infrastructure. The reporter is listed as NDA0E; we know nothing more about them.

3. 3

   What we could not confirm

   We did not download any of the files, so we cannot tell you which malware family they are, what they do or where they report to. The folder name hiddenbin and the file names Space.arm7 and Space.mpsl match files that researchers on other servers have labelled Mirai in public sandbox reports (see the next chapters). That matches the pattern; it does not prove the files here are the same.

4. 4

   What this means for you

   If you only saw the name in a firewall log or a blocked request, you are not infected by that alone. The risk is for a device that already ran a command that went to fetch these files. Ordinary people have no reason to ask for them.

Kind of threat

A server that hands out a shell script and 13 Linux programs for different processors, tagged botnetdomain

Where the files are

hxxp://scribblebubblebibi[.]top/1.sh and hxxp://scribblebubblebibi[.]top/hiddenbin/Space.<processor>

Domain registered

9 August 2026 through Global Domain Group LLC; status client transfer prohibited (RDAP, read 15 October 2026)

URLhaus entries

14 file addresses, all added on 15 October 2026; none online when we last read the data on 17 October 2026

Platform

Linux on routers, cameras, recorders and servers. Files are ELF programs, which do not run on Windows or macOS

Our request

17 October 2026: the name did not resolve from our server (getaddrinfo ENOTFOUND)

What we checked on 17 October 2026, and what we could not

We sent one plain request from our server to scribblebubblebibi.top. It failed before any page could load: the name no longer resolves. That tells you the address is not answering today. It does not tell you the devices that fetched these files are clean.

What happened to scribblebubblebibi.top, from registration to our check

The domain is about ten weeks old. All reports fall in one evening. The dates come from RDAP and the URLhaus data we hold; times are UTC.

1. 9 August 2026

   The domain is registered

   RDAP shows scribblebubblebibi.top registered on 9 August 2026 at 17:58 UTC through Global Domain Group LLC. The only status listed is client transfer prohibited, which is a common lock and says nothing about use.

2. 15 October 2026, 18:52 UTC

   Thirteen program files are reported

   Between 18:52:11 and 18:52:33 UTC, URLhaus receives the Space files for m68k, arc, arm6, i686, ppc, mips, arm5, arm7, x86, mpsl, x86_64, sh4 and arm. All are tagged botnetdomain, elf and ua-wget. Reporting 13 files in 22 seconds looks like a tool reading a folder listing; that is our reading, not something a report says.

3. 15 October 2026, 19:07 UTC

   The script 1.sh is reported

   Fifteen minutes later the shell script 1.sh is added with the tags botnetdomain, sh and ua-wget. It is the last report we hold.

   

4. 17 October 2026

   Our request finds no address

   Our server asks for the site and gets ENOTFOUND. URLhaus marks all 14 files offline. The /check tool on this site had been asked about the address 16 times by then, which is why this guide exists.

What the pattern suggests, and what it does not: a young domain, a hidden-sounding folder, one file per processor type and a script reported together is the usual shape of a loader for devices that run Linux. It does not tell us who runs it or whether it is still active on another name.

How a Linux botnet loader like this works

The reports show a script plus one program per processor type. Researchers describe the same arrangement for Mirai-family malware. We did not see this server's files, so this chapter is the pattern, not a finding about the files.

1. 1

   Something is already running a command

   A SANS Internet Storm Center report from February 2024 shows the usual start: a command injected into the web interface of a router, which runs wget to fetch a .sh script. The same pattern is described for devices with a weak or default Telnet password, where the attacker simply logs in and types the command.

2. 2

   The script asks for one file per processor

   SANS describes the script then fetching programs for several architectures, among them mips and mpsl. A router might use ARM, a camera MIPS, an old set top box SuperH (sh4) or PowerPC (ppc). The script does not know which, so it tries them all. The 13 names on this server fit that: arm, arm5, arm6, arm7, mips, mpsl, ppc, sh4, m68k, x86, x86_64, i686 and arc.

3. 3

   Only the matching file starts

   A program built for the wrong processor simply fails to run, so most of the 13 files do nothing on any one device. Public sandbox reports on files named Space.arm7 from a hiddenbin folder on other servers describe them as UPX-packed Mirai samples (Joe Sandbox). Packing makes the file small and harder to read.

4. 4

   The device becomes a bot

   Mirai, whose source code was published in 2016, turns a device into a bot that can flood a target with traffic and scan the internet for more devices with weak passwords. The Singapore Cyber Security Agency describes a hijacked router in a botnet used for denial of service attacks. What the files on this server do was not tested by us.

What the 13 file names tell you about the target devices

The suffix of each Space file is a processor family. Together they cover almost every small Linux device sold in the last twenty years, which is the point of the kit. The device guesses below are our reading, not facts from a report.

Two points follow. First, a normal desktop is not the target: these are Linux files, and a Windows PC or a Mac cannot run them. Second, a Linux server is a target as much as a router, so a cloud server with a weak password or an out of date web application is in the same position as a cheap camera.

What this kind of malware can do, and what is not confirmed here

We did not run the files. The table shows what Mirai-family bots are known to do, as the sources describe it, and how far that carries over to this server.

What it can cost you

The owner of an infected device rarely sees a pop-up. The costs are slower connections, a blocked internet account and, for a server, being used to attack others.

• High

  A router under someone else's control

  A bot on your router sits between every device at home and the internet. It can slow your connection and, according to CSA, attackers can also intercept traffic that is not encrypted.

• High

  Your address used to attack others

  Denial of service traffic comes from your internet address. Your provider may warn you or cut the line, and the target's logs name you.

• Medium

  A server taken over through a weak password

  If the device is a Linux server, the same weak login can lead to other programs being installed. Treat the whole server as untrusted until it is rebuilt.

• Medium

  Other devices on the same network

  Bots scan for more devices with default passwords. A camera or recorder on your home network may be next.

• Low

  Nothing at all

  If the name only appeared in a blocked request or a threat feed, nothing ran on your side. The danger is the case you cannot tell apart yet.

What you may notice, and what is not a sign

Many infected devices show nothing. These are the signs people report for botnet bots on routers and servers, with the limits of each.

Start with the logs, because they tell you which device asked for the files. Write down the device, the date and the time.

1. 1

   Search your logs for the name

   If you saw the name in a security tool, open that tool's log and note the source address of the request. On a home network, the router's own log or your DNS filter shows which device asked. A request that was blocked means the file did not arrive; a request that went through means you must treat the device as possibly infected.

2. 2

   Find the device behind the address

   The source address is usually a private one such as 192.168.1.x. The router's list of connected devices shows the name and the hardware address of each. Look for a camera, a recorder, a set top box or an old network device you forgot.

3. 3

   On a Linux server, look at what runs

   Run ps aux and ss -tunp and look for unknown programs with open connections, especially from /tmp, /var/tmp or /dev/shm. List crontab -l for each user and /etc/cron* for entries you did not add. Look for files named Space.* or 1.sh with find / -name 'Space.*' -o -name '1.sh' 2>/dev/null. A match is a strong sign; no match does not clear the server.

4. 4

   Check the login history

   On a server, last and /var/log/auth.log (or journalctl -u ssh) show who signed in and from where. On a router, check the admin page for users you did not create and for remote management switched on.

5. 5

   Check what is open to the internet

   CISA's home Wi-Fi guidance says default router login details may be public, so changing them is essential. Look in the router for remote administration, port forwarding rules and UPnP, and note any you did not set up.

Clean a router, camera or Linux server

There is no program to uninstall. The safe way is to take the device offline, wipe it, update it and lock it down. We did not run these steps against a live infection; they follow CISA and CSA advice and the SANS description of how these devices are taken.

1. 1

   Take the device off the internet

   Unplug the cable that goes to the internet, or switch the device off, so it cannot be controlled or attack others while you work. For a server, remove its public address in your hosting panel or block it with the provider's firewall.

2. 2

   Save only what you need

   For a router or camera there is little to save: write down the settings you need (the internet account details from your provider's letter). For a server, copy data, not programs, to a clean place. Do not copy scripts or binaries from the server.

3. 3

   Do a factory reset

   Hold the reset button as your device's manual says, or use the reset option in its admin page. A power cycle alone is not enough: the weak login or flaw that let the program in is still there. For a server, the safest path is to rebuild from a fresh image.

4. 4

   Install the newest firmware before going online

   Download the update from the maker's own support page on another device and install it from the admin page. CISA's home Wi-Fi guidance recommends checking for firmware updates. If the maker no longer sells updates for the model, plan to replace it.

5. 5

   Set a new, long and unique admin password

   Use a password or phrase that is long, random and used nowhere else, as CISA recommends. Change the default network name too. On a server, turn off password sign in over SSH and use keys.

6. 6

   Turn off what you do not need

   Switch off remote management on the internet side, UPnP, Telnet and any old file sharing. CISA and CSA both list these among the usual causes of hijacked routers. Put cameras and smart devices on a guest network so one bad device cannot reach the rest.

7. 7

   Connect again and watch

   Reconnect and look at the router's device list and log over the next days. If the same request to scribblebubblebibi.top or a similar name appears, another device is also infected. A provider notice that continues after all this means a device is still missed.

If you run a website or a server

The address scribblebubblebibi.top is the attacker's, not a site that was hacked, as far as the evidence shows. But your server can be the device that fetched the files, and a hacked web server can also serve such files.

Only saw the name in a log or an alert?

Then you are probably fine, but check one thing: which device asked, and whether the request was answered.

1. 1

   Blocked request

   A security product that says it blocked the request stopped the file. Note the device and move on, but keep the entry for a week.

2. 2

   Request with a reply

   If your router or firewall shows a completed connection (for example, bytes received), treat the device as possibly infected and use the cleaning chapter.

3. 3

   Request from a PC browser

   A PC cannot run these files. But a link that took you to this address came from somewhere: a message, an ad or an infected site. Treat that source with care and scan the PC with Microsoft Defender or your own security tool.