chibomaydan.devs.surf: a download server for Mirai botnet programs aimed at routers and other Linux devices

What chibomaydan.devs.surf is, and what we know about it

chibomaydan.devs.surf is not a program on your PC and not a page you are meant to visit. It is a web address that the abuse.ch project URLhaus lists as a place where malware was served. We found no public write-up of this one address, so this page rests on what URLhaus shows, what our own server saw, and what security vendors have published about Mirai botnets in general.

1. 1

   What URLhaus lists

   Thirteen file addresses on chibomaydan.devs.surf, all on plain http with no port and all in the top folder of the host. Twelve are named after a processor type (mips, mpsl, arm, arm5, arm6, arm7, x86, x86_64, ppc, sh4, m68k, spc) and one is called debug.dbg. They were added on 3 October 2026 between 17:42:18 and 17:42:27 UTC, nine seconds in all, by one reporter. Every entry carries the threat label malware_download and was marked offline when we read the data.

2. 2

   What the tags mean

   elf means the file is an ELF executable, the program format of Linux and similar systems, not of Windows. mirai names the Mirai family of botnet programs, which turn routers, cameras and other small connected devices into remote controlled machines. botnetdomain means the address is used by a botnet to hand out its files. ua-wget means the fetch that URLhaus recorded came from the command line tool wget, which is how a script on a Linux device downloads a file.

3. 3

   What the file names suggest

   A Mirai style installer usually tries several downloads in turn and keeps the one that runs on the chip it finds. Twelve names, one per chip type, fit that pattern. Our reading, not a fact from a source: mpsl is the little endian MIPS build, spc is the SPARC build, and debug.dbg is a test or debug copy. We did not download any file, so we cannot tell you what is inside them.

4. 4

   What this means for you

   If you only saw the name in a firewall, DNS or router log, you are not infected by that alone. The name does mean that some device on your network, or a server you run, asked for it, and a person does not normally do that by hand. That device is the one to find first.

Kind of threat

A host that handed out 13 Linux (ELF) programs tagged mirai and botnetdomain, one per chip type

Which devices

Linux based devices: home and office routers, IP cameras, recorders, small servers, some smart TVs. Not Windows PCs, not Mac, not iPhone

Status when we looked

All 13 entries offline in URLhaus; the host name did not resolve from our server on 13 October 2026

Registration

The registered domain devs.surf was created on 10 January 2026 at the registrar Spaceship, Inc.

Not the same as

A virus on a PC. The files are botnet programs for other kinds of devices

What we do not know

What the files contain, who runs the botnet, how many devices fetched them, and whether other hosts serve the same files

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

Our check was one plain request from our server, not a visit with a browser, and we downloaded nothing. The request failed at the first step: the name chibomaydan.devs.surf did not resolve to an address. That tells you the situation on one day, from one place, and it does not clear anything.

The reports, second by second, and what changed since

All 13 reports arrived in a burst. A burst like that is typical of a sensor or a person who found a script, read the list of files in it and submitted every address at once. It shows when the files were seen, not when the server was set up.

1. 10 January 2026

   devs.surf is registered

   The registry record for the domain devs.surf shows creation on this date at the registrar Spaceship, Inc. We cannot tell when the chibomaydan name was created under it.

2. 3 October 2026, 17:42:18

   First report: x86_64

   URLhaus adds the build for 64 bit PC type processors first. The host is tagged botnetdomain, elf, mirai and ua-wget.

3. 3 October 2026, 17:42:19

   Nine more reports in one second

   The files mpsl, spc, x86, arm, arm6, sh4, arm7, ppc and arm5 are added in the same second. They cover ARM, MIPS, SPARC, PowerPC, SuperH and 32 bit x86 chips.

4. 3 October 2026, 17:42:24

   m68k and debug.dbg

   Two more files appear: m68k, an old Motorola chip family, and debug.dbg, a name that does not match any chip.

5. 3 October 2026, 17:42:27

   Last report: mips

   The 13th file is added. All 13 entries carry the same four tags and the same reporter.

6. 13 October 2026

   Our check: no such host

   A plain request from our server fails with ENOTFOUND, and URLhaus lists all entries as offline. No new reports have been added since 3 October 2026 in the data we hold.

The 13 files and the chips they are named after

One file per chip type is the signature of a botnet that wants to run on whatever it finds. The reading of each name below is ours from common usage, except where URLhaus gives a tag. We have not opened a single file.

What Mirai variants are known to do

We found no report on the files from this host, so we cannot say which Mirai variant they belong to. What is published for other Mirai variants shows the range, and it explains why the tag matters.

From these reports the useful point is the way in: a device is taken over because it has a known, unpatched flaw, and the botnet programs are then fetched by a short script. Sources for the weak password route, which is also widely documented, are not among the pages we read for this guide, so we state it as general background and not as a finding about this host.

What a taken over device can cost you

We found no report on the files of this host. These are the risks that follow in general for a router, camera or server that fetched a file from this host, shown by how likely they are.

• High

  Your device attacks other people

  A Mirai style bot waits for orders and can be used to flood other sites with traffic. Your connection is slower, and your address may be blocked or blamed.

• High

  A router that is not yours any more

  If the router was taken over, the person in control sits between you and the internet. We found no report that this host's files change DNS settings, so we do not claim that, but a router that fetched botnet code cannot be trusted.

• Medium

  Slowdowns and drops

  Heavy outgoing traffic, overheating and restarts are the usual signs on small devices. They also have ordinary causes.

• Medium

  The way in stays open

  The flaw or password that let the first script in is still there after you delete a file. A cleaned device that is not fixed is infected again, often within hours.

• Low

  If you only saw the name

  A blocked request in a log is the firewall doing its job. The risk is the device that sent it.

Who can meet this address, and how it shows up

People rarely meet a download host of this kind in a browser. They meet it in a log, a security alert or a notice from a provider.

The goal is to name one device. The steps below are general and need no special tools. Menu names differ by maker, so look for the closest match in your own device.

1. 1

   Write down where you saw the name

   Note the log or alert, the time and the device or address that made the request. A DNS log or firewall log normally shows the internal address of the device that asked. If the name came from a provider's notice, ask them which address and which time.

2. 2

   Map the address to a device

   In your router's page, open the list of connected devices or the DHCP lease list and match the internal address to a name or a hardware (MAC) address. If the address is the router itself, treat the router as the suspect.

3. 3

   Look for the signs on the router

   Open the router's admin page and check whether remote management from the internet is switched on, whether there are port forwards you did not make, and whether the DNS servers are ones you set. Compare the firmware version with the maker's latest.

4. 4

   Look at the device that asked

   For a camera or recorder, look for a changed password, a changed time or an unfamiliar user. For a server, run last, check crontab -l for each user, look in /tmp and /var/tmp for files you did not create, and run ss -tupn to see which programs hold network connections.

5. 5

   Check the web logs on a server

   Search the access and error logs of the website for requests around the time that contain wget, curl, sh or a long string of encoded characters. This shows the page or program flaw that was used.

6. 6

   Do not trust a quiet result

   A device can run a bot with no sign you can see. If the name was asked for and you cannot explain why, go on to the cleaning steps.

Clean the device, then close the way in

We did not run these steps against a live infection. They are general good practice for taken over routers and Linux devices and are not tested for the files of this host.

1. 1

   Take the device off the network

   Unplug the cable or switch off Wi-Fi on the suspect device. For a router, do the next steps with a computer connected by cable and the internet cable unplugged where possible.

2. 2

   Reset to factory settings

   On a router, camera or recorder the most reliable fix is a factory reset with the maker's method (usually a reset button held for several seconds). Mirai style bots normally live in memory, so a restart alone may remove them, but a restart does not close the way in.

3. 3

   Update the firmware before you connect again

   Download the newest firmware from the maker's own site and install it. If the maker no longer provides updates for the model, replace the device; a device without updates cannot be made safe.

4. 4

   Set new passwords

   Set a long, unique admin password for the device and for any Wi-Fi network. Never keep the factory login. Turn off remote management from the internet, Telnet and UPnP unless you need them.

5. 5

   Rebuild a server

   For a server or a VPS the safe way is a fresh install from a clean image, then restoring only data. Change every password and key that was on it, and patch the flaw that let the script in before it goes online.

6. 6

   Check the rest of the network

   Other devices on the same network may have been scanned or taken over. Repeat the check for every camera, recorder and smart device, and watch the router log for the name again.

7. 7

   Change passwords on your accounts

   If a router was taken over, change the passwords of your important accounts from a device on a different network, email first, and turn on two step sign in.

If your own website or server was used

A download host is often somebody's hacked site or a rented server. If this address or a link to it was found on something you run, this is what to do.

1. 1

   Find how it got there

   Look at the web server and application logs for the time of the first report, 3 October 2026. Look for a new account, a new file in the web folder, an outdated plugin or an open admin page.

2. 2

   Remove and rebuild

   Take the site offline, restore from a backup made before the first sign, update everything and change all passwords and keys. If you cannot show the backup is clean, rebuild from a fresh install.

3. 3

   Ask for a review

   When the files are gone and the flaw is closed, tell your host and the abuse team of the listing service so the entry can be reviewed. We do not know the review process of every service, so ask each one directly.

4. 4

   Report the abuse

   If you only found the files and the host is not yours, report the address to the host's abuse contact and to the security authority of your country. The contact for devs.surf at the registrar is the place to start because we do not know who runs the sub name.

What is still unknown

Saying plainly what we do not know matters more here than a long list of guesses.