maxxlavalink.cyou: a server that handed out Mirai and coin miner files for Linux routers and IoT devices, and what to do

What maxxlavalink.cyou is, and what we know about it

maxxlavalink.cyou is not a program on your computer. It is a web address that the abuse.ch project URLhaus lists as a place where malware files were served. We found no public write-up of this one address, so what follows is what URLhaus shows, what the registration record says, what our own request returned, and what other researchers have published about the kind of malware the tags name.

1. 1

   What URLhaus lists

   Nineteen file addresses, all plain http, added between 06:59:21 and 07:15:17 UTC on 4 October 2026 by one reporter. Eighteen are program files with names such as x86_64, aarch64, armv7l, mips, mipsel and ppc64, or names in a folder called bins such as main_arm, main_mips and main_sh4. One, run.sh, is a script. Every one carries the threat label malware_download, and every one was marked offline when we read our copy of the data.

2. 2

   What the tags say

   Eleven addresses are tagged mirai, two (mips and mipsel) are tagged CoinMiner, one (run.sh) is tagged script, and five carry no tag at all. Mirai is the name of a botnet family that takes over devices running Linux, such as routers and cameras, and uses them to attack other servers. A CoinMiner is a program that uses a machine's processor to mine cryptocurrency for someone else. A tag is a label from the reporter, not a proof, and we did not download the files.

3. 3

   What we could not confirm

   We did not open any file, so we cannot tell you which Mirai build is inside, which servers it calls home to, or which attacks it can run. We do not know which exploit or weak password was used to make a device ask for the files. That first step happens on the victim's side and is not visible from the server.

4. 4

   What this means for you

   If you only saw the name in a firewall, router or DNS log, you are not infected by that alone. The risk is for a device that was already reachable and weak, and that went to fetch one of these files. People do not request files called mips or main_sh4 by hand.

Kind of threat

A server that handed out Linux program files for many processor types; 11 tagged Mirai, 2 tagged CoinMiner, 1 shell script

Where the files were

hxxp://maxxlavalink[.]cyou/ with names like x86_64, mips, aarch64 and bins/main_arm: plain http, no secure connection

Domain registered

18 September 2026 through NicNames, Inc.; the statuses server hold and client hold are set (RDAP, read 7 October 2026)

URLhaus entries

19 file addresses, all added on 4 October 2026 between 06:59 and 07:15 UTC; all 19 offline

Delivery trick

One file per processor type, so the same script works on whatever device it lands on. The entry step is not known

Platform

Linux and embedded Linux devices (routers, cameras, recorders, small servers). Nothing we read says these files run on a Windows PC, a Mac or a phone

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

Our check was a plain request from our own server on 11 October 2026. It did not reach any page: the lookup failed with the error getaddrinfo ENOTFOUND, which means the name did not resolve to an address at all. That is all it shows. It does not clear the owner of the address, and it does not say what the files did while the name worked.

What happened to maxxlavalink.cyou, from registration to our check

The domain is only a few weeks old and every report sits inside one quarter of an hour. Dates come from RDAP and from the URLhaus data we hold; times are UTC.

1. 18 September 2026

   The domain is registered

   RDAP shows maxxlavalink.cyou registered on 18 September 2026 at 12:59 UTC through NicNames, Inc. The ending .cyou is one of many cheap new endings; the ending alone says nothing about the owner.

2. 4 October 2026, 06:59 UTC

   The script and the first binaries are reported

   The script run.sh is added at 06:59:21. Within the next 25 seconds, Mirai-tagged files such as bins/main_sh4, main_arm5, main_arm6, main_arm7 and main_mips are added, then x86, aarch64 and the Mirai-tagged x86_64 files.

3. 4 October 2026, 06:59 to 07:00 UTC

   More processor types

   main_mpsl, main_arm, main_m68k, main_ppc, armv7l, ppc64 and the CoinMiner-tagged mips and mipsel files are added. A file named main_x86 with the word deleted in its name is also listed, which suggests a file that was already removed when it was reported.

4. 4 October 2026, 07:15 UTC

   The last report

   The file x86_64 in the top folder is added at 07:15:17 UTC. All nineteen entries are marked offline when we read the data, and no later report is in our copy.

5. 7 October 2026

   We read the registration

   RDAP, fetched on 7 October 2026, shows the statuses server hold, client hold, server transfer prohibited and client transfer prohibited.

6. 11 October 2026

   Our request finds nothing

   A plain request from our server fails with ENOTFOUND: the name does not resolve.

   

What the pattern suggests, and what it does not: the whole set was reported in one burst, with one file per processor type. That looks like a person or tool that collected a prepared set from an open folder in one go, which is our reading of the times. No report says so.

How a set of files like this is used

We did not see the script on this server, so this is the usual pattern for this kind of file set as researchers describe it, and our reading of the names. Treat it as a map, not as a description of what happened on any one device.

1. 1

   A weak device is reached first

   Mirai-style malware does not arrive by a click. It is pushed onto a device that can be reached from the internet and has a weak or default login, or an old unpatched hole. SANS describes router malware, including Mirai variants, as typically entering through the same weakness that stays open afterwards.

2. 2

   A script picks the right file

   A small shell script such as run.sh is a common way to do this. Because routers, cameras and servers use different processors, the script tries the download that fits: arm, mips, x86 and so on. That is why a server like this holds one file per type. Our reading is that run.sh did this here; we did not read it.

3. 3

   The file runs and the device joins a botnet or mines

   A Mirai file turns the device into a bot that waits for orders. Krebs reported in November 2016 that a Mirai worm knocked about 900,000 Deutsche Telekom customers offline, because their routers were taken over and crashed. A CoinMiner file uses the processor for mining instead; Akamai described in 2019 a botnet that installed the XMRig miner on devices and added entries to crontab so the miner started again after a restart.

4. 4

   It looks for the next victim

   Mirai family malware is known for scanning the internet for more devices with weak logins. The infected device then both attacks others and spreads the infection. A device on your network can therefore be part of attacks on strangers without showing any sign to you.

What the 19 file names tell you

The names are mostly processor types. The table is our reading of the names plus the tags from URLhaus; we did not open the files, so we do not know which processors each really targets.

What this kind of malware can do, and what only other reports show

Nothing on this page comes from analysing the files on this server. The behaviours below are what published reports say about Mirai and miner botnets in general.

What an infected device can cost you

The cost depends on the device. A bot on a camera may be invisible; a bot on a router sits between your whole home and the internet.

• High

  A taken-over router or gateway

  A router sees everything that goes in and out. If its settings were changed, such as the DNS servers, other devices can be sent to wrong pages even after the malware is gone.

• High

  You become part of an attack

  A bot can be used to flood strangers' servers. Your internet address can then be blocked, and the provider can cut or warn you.

• Medium

  Slow device, hot device, slow internet

  A miner uses the processor all the time. Small devices become slow, hot or unstable, and a router may drop connections.

• Medium

  More malware later

  A device that was reachable once with a weak login is likely reachable by others. Several botnets can sit on the same device.

• Medium

  A server owner's bill and reputation

  On a small cloud server, a miner can raise the bill and the provider can suspend the account for abuse.

• Low

  Nothing at all

  If you only saw the name in a log of blocked requests, no harm may have happened. The danger is the case you cannot tell apart yet.

Who can meet this, and who cannot

These are Linux files for devices with certain processors. Most readers of this page found the name in a log, an alert or a router message, not on a screen.

Check your router or device before you reset it

Write down what you see before you change anything: the log line, the time and the device's address. That tells you which device asked for the name.

1. 1

   Find which device asked

   Open the router's log or your DNS filter's log and look for maxxlavalink.cyou and the time. The entry shows the local address of the device. Match that address to a device in the router's list of connected devices (the names vary by brand).

2. 2

   Look at the device's sign-in

   Try to sign in to the device with the password you set. If the old password no longer works, or the device asks for a new one, someone may have changed it. Note that.

3. 3

   Check what is open from the internet

   Open the router's admin page and look for remote management, port forwarding, UPnP entries and exposed services such as Telnet or SSH. Remove forwards you did not make.

4. 4

   Check the DNS settings

   Look at the DNS servers in the router's internet settings. If they are addresses you did not set and your provider does not use, write them down. SANS warns that DNS changes can survive a reset and can be done without any malware at all.

5. 5

   Look at the load

   If the device offers a status page, check processor use and the list of running processes. A small device that runs flat out while idle fits a miner. A quiet page clears nothing.

6. 6

   Check the firmware version

   Compare the firmware number with the newest on the maker's support page. A very old version is a sign that known holes are open.

Detection names, and why we give no Microsoft name

We did not open the files, so we do not know the detection names that security products use for them. A tag on URLhaus is not a detection name.

Clean a router or IoT device

Do the steps in order. We did not run them against an infected device; they follow SANS Internet Storm Center advice on resetting a router and the general advice in the other sources. Exact menu names differ by maker, so use your device's manual for the button names.

1. 1

   Disconnect it from the internet

   Unplug the cable that goes to the internet, or take the device off the network. This stops it from attacking others and from fetching more files. Leave the power on only if you need to see settings.

2. 2

   Do not rely on a restart

   SANS says router malware, including Mirai variants, generally does not survive a simple power cycle. That is why a restart can make it look fixed. The hole that let it in usually stays open, so it can be back within minutes of being online.

3. 3

   Back up only what you need

   Write down your internet provider's settings (user name, VLAN, any special values). Do not restore a saved configuration file from the infected device, because settings such as DNS can be part of the problem.

4. 4

   Factory reset the device

   Use the reset button or the factory reset item in the menu, as the maker describes. A factory reset puts the software back to the maker's default. SANS recommends going further than a button press for the paranoid case: reinstall the firmware from the maker's file.

5. 5

   Update the firmware before reconnecting

   Download the newest firmware from the maker's support page on another device, check that the file name matches your exact model, and install it while the device is still cut off from the internet.

6. 6

   Set a new admin password and close the doors

   Choose a long, unique password. Turn off remote management, UPnP and any Telnet or SSH access from the internet unless you need it. Turn on automatic updates if the device offers it.

7. 7

   Reconnect and watch

   Reconnect and watch the device's log for a few days for requests to unknown names. If you cannot get a firmware update because the maker stopped supporting the model, replace the device.

8. 8

   Change passwords for what passed through it

   Change your Wi-Fi password and the passwords of accounts used on the network, from another device, starting with email. Turn on two step sign in.

If you run a Linux server or a website

The same file names can turn up on a server that was hacked and used as a host, or on a small server that was taken over and set to mine. We cannot say which case this is. These steps are general good practice, not taken from a report on this address.

1. 1

   Look for what you did not install

   List running processes sorted by processor use, and check crontab entries for every user, the files in the folders used for temporary files, and the start-up scripts. Files named like system tools but in odd folders deserve a closer look.

2. 2

   Search your web folders for these names

   If you run a website, search for files called run.sh, main_arm, main_mips or x86_64 that you did not upload. If you find them, the site was probably used to host malware, which is what a reporter may have seen.

3. 3

   Rebuild rather than clean

   The safest answer is a fresh server from a known image, with data restored from a backup made before the incident. Cleaning by hand can miss a backdoor. Akamai and the Microsoft campaign reports both describe attackers who add persistence.

4. 4

   Close the way in

   Turn off password login for SSH and use keys, update the software that was exposed, restrict which addresses can reach admin ports, and change every password and API key that was on the server.

5. 5

   Ask your host

   Tell your hosting provider what you found. Many providers have a process for abuse reports and will help prove that the server was cleaned.