dstats.qzz.io: a Mirai botnet download address for routers and cameras, and what to do if a device of yours may be infected

What dstats.qzz.io is, and what we know about it

dstats.qzz.io is a web address, not a program. It is a host that the malware tracker URLhaus lists as a place where Mirai files were served. Mirai targets devices that run a small Linux system, such as home routers, cameras and video recorders, not ordinary Windows or Mac computers. No public write-up of this one address exists that we could find, so this page rests on the URLhaus entries, our own lookup and what CISA and researchers have published about Mirai.

1. 1

   What URLhaus lists

   36 file addresses on dstats.qzz.io, all with the threat type malware_download, all added on 28 September 2026 by a reporter account named von. The first, http://dstats[.]qzz[.]io/ily.sh, came at 18:41:20 UTC and the last, /x64s, at 18:56:17 UTC. All 36 were offline when we read them.

2. 2

   What the tags say

   34 entries carry the tag mirai. Two files, ily.sh and payload.sh, carry no tag. Thirty-two of the tagged files have names that match processor types, such as arm, arm5, arm6, arm7, mips, mpsl, ppc, sh4 and x86. The other two tagged files are shell scripts named lel.sh and lol.sh.

3. 3

   What we could not confirm

   We did not download any file and found no analysis of these exact files. So we do not know which Mirai variant they are, which logins they try, or where they report to. The tags are the reporter's labels, not our finding.

4. 4

   What this means for you

   If you only saw the name in a log or a block list, nothing is wrong with your device because of that. If a device of yours connected to this address or ran a file from it, treat the device as infected and follow the plan below.

Kind of threat

A malware download host: 36 files, 34 tagged mirai, 2 untagged shell scripts

Malware family

Mirai, an IoT botnet (the reporter's tag; not confirmed by us)

Registration

No registration record: our lookup found no RDAP server for the qzz.io domain, so we cannot say who set up the name or when

URLhaus entries

36 file addresses, all added on 28 September 2026; all 36 offline when we read them

Platform

Routers, cameras and other Linux-based network devices. Not an ordinary PC threat

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

We tried to open https://dstats.qzz.io/ once, from Lithuania, in an automated Chromium browser set to English. The browser reported that the name could not be found, so no page loaded. That tells you nothing good about the host and it clears nothing.

What happened to dstats.qzz.io, from the first report to our test

The visible history is a single burst of 15 minutes on one evening. We have no earlier or later reports for this host.

1. 28 September 2026, 18:41 UTC

   A script and thirty-odd binaries are reported

   URLhaus receives ily.sh at 18:41:20 and then within seconds a long run of files named after processor types, among them arm, arm5, arm6, arm7, armv5, armv7, aarch64, mips, mpsl, ppc, sh4, x86 and nshx86. Two more scripts, lel.sh and lol.sh, and payload.sh follow in the same minute. All carry the tag mirai except ily.sh and payload.sh.

   

2. 28 September 2026, 18:56 UTC

   One more file

   The last entry, /x64s, is added at 18:56:17. After this URLhaus records nothing new for the host.

3. 10 October 2026

   Our test finds no address

   Our browser visit to https://dstats.qzz.io/ ends in ERR_NAME_NOT_RESOLVED, and URLhaus shows all 36 files offline, twelve days after the reports.

We could not read the URLhaus pages themselves, because they ask for a browser check. The entries above come from the same data in our own database, which holds the URLhaus feed.

The file names: what they suggest, and what we do not know

File names are weak evidence. We list what each group could be and mark which statements are only our reading.

The number of builds is the most telling fact. One file per processor type means the operator did not know which kind of device a victim would be, so the same address was prepared for many kinds of device. That fits what CISA says about Mirai's targets, but it does not prove how these files were used.

How Mirai gets onto a device, according to CISA and researchers

We did not run or open the dstats.qzz.io files. This is the method CISA and academic researchers describe for Mirai in general, so you know what to look for.

1. 1

   It scans for devices

   CISA's alert says Mirai continuously scans the internet for vulnerable IoT devices. A device with a public address and an open login is found whether or not anyone knows it exists.

2. 2

   It tries a short list of default logins

   CISA says Mirai uses a short list of 62 common default usernames and passwords. That small dictionary was enough to reach hundreds of thousands of devices, because many owners never change the factory login.

3. 3

   Which devices fall

   The incidents CISA describes involved primarily home routers, network-enabled cameras and digital video recorders. CISA also notes a later variant that abused a flaw in broadband routers that leave port 7547 open.

4. 4

   Why the scale mattered

   A USENIX Security paper that studied the botnet over seven months found it peaked at about 600,000 infections, made mostly of embedded and IoT devices. The authors point to the simplicity of the infection as a key factor.

An infected device keeps working as before, so its owner often notices nothing. Its job is to scan for more devices and to join attacks on other targets. That is why a Mirai host such as this one matters even to people who never visited it.

What you may notice, and what you may not

Most owners notice nothing. The signs below follow from what Mirai does; none of them proves infection alone.

What this can cost you

Seeing this address in a log costs nothing. The risks below apply to a device that actually connected to it or ran one of its files.

• High

  Your device attacks other people

  An infected router or camera becomes part of a botnet that can be used to flood other targets with traffic. The harm falls on strangers, and the traffic leaves from your connection.

• High

  A way into your home network

  A router sits between your devices and the internet. Control of it gives the attacker a place to watch or redirect traffic. We found no source describing that for this host, so it is a risk, not an observation.

• Medium

  Reinfection within minutes

  CISA warns that a device reconnected before its password is changed could be quickly reinfected. The scanners are always running.

• Medium

  A notice or a block from your provider

  Providers may limit or warn a customer whose device is part of an attack. This is general practice, not something we saw here.

• Low

  Nothing, if you only saw the name

  A name in a firewall log or a blocked link is not an infection.

How a device ends up contacting an address like this

We do not know how any device reached dstats.qzz.io, and no source says. These are the routes CISA and the research describe for Mirai.

1. 1

   The device was found by a scanner

   A bot scanned the internet, found a device with an open login and tried the default passwords. No one clicked anything. This is the main route CISA describes.

2. 2

   A flaw in the device software

   CISA notes a variant that abused a flaw in routers that leave port 7547 open. An old router that no longer gets updates stays open to flaws like this.

3. 3

   A command run by someone who got in

   Once inside, the attacker has the device fetch a file that matches its processor. A shell script such as ily.sh or payload.sh could do the fetching, but we did not see the scripts.

4. 4

   A log line you found

   If you only found dstats.qzz.io in a router or DNS log, the entry means a device on your network asked for the name. Find out which device did, because that one is the suspect.

Check your router and other devices before you reset anything

Start with the question that matters: did a device of yours connect to dstats.qzz.io, or does one still use its factory login with remote access on? If yes, follow the plan on this page. If you are unsure, do these checks first. None of them changes anything.

Phones and ordinary computers are not the target of these files, so this page does not give steps for them.

1. 1

   Find out which device asked for the name

   Open your router's admin page (the address and login are on its label or in its manual) and look for a log or a list of connected devices. Search the log for dstats or qzz. If the router keeps no log, a DNS filter service you use may show the device that asked.

2. 2

   Check whether the factory login still works

   If the admin page still accepts the login printed on the router's label, or the default for your model, a bot could have used it too.

3. 3

   Look at remote access

   In the router's settings find remote management or remote administration and see if it is switched on for the internet. The FTC advises turning it off, and also advises turning off WPS and UPnP.

4. 4

   Look at the firmware

   Find the firmware version in the status or system page and compare it with the manufacturer's site. An old version, or a model the maker no longer updates, is a reason to plan a replacement.

5. 5

   Read a provider notice

   If your internet provider wrote about attack traffic from your line, the notice usually names the date and the address. Match them against the device list.

6. 6

   Remember what a clean check means

   These checks cannot see inside the device. Because the malware sits in memory, a device that looks normal may still be infected until it is restarted offline.

Clean a router, camera or recorder: the order CISA gives

CISA's removal advice is short because Mirai lives in the device's memory. We follow it here and add the settings the FTC and CISA recommend afterwards. We did not test these steps on an infected device.

1. 1

   Disconnect it from the network

   Unplug the network cable and turn off its Wi-Fi if it has one. For a router that is your only connection, do the next steps from a phone using mobile data, and expect your home internet to be down for a while.

2. 2

   Restart it while it is offline

   Turn it off and on again with no network connected. CISA says the malware resides in dynamic memory, so a restart removes it. A restart alone does not stop reinfection.

3. 3

   Change the default password before reconnecting

   Sign in to the device on its local address and set a new admin password that is strong and used nowhere else. CISA warns that if you reconnect first, the device could be quickly reinfected.

4. 4

   Update the firmware

   Download the newest firmware from the manufacturer's own site. The FTC says to check the site before setup and from time to time, to register the router for update notices, and to ask your provider about automatic updates.

5. 5

   Turn off what a bot uses

   In the settings turn off remote management and UPnP. CISA lists disabling UPnP on routers unless it is necessary, and, for infrastructure devices, turning off unencrypted remote admin such as Telnet. Check that the built-in firewall is on.

6. 6

   Reset to factory settings if you cannot be sure

   Neither CISA nor the FTC pages we read give a reset procedure, so use the manufacturer's manual for your model. Most devices have a small reset button held for some seconds. After a reset, set a new password first, then update the firmware, and only then reconnect.

7. 7

   Replace a device that no longer gets updates

   If the maker has stopped issuing fixes for the model, a new password does not close its flaws. Buy a replacement from a maker with a record of security updates, as CISA advises.

If you use a Windows PC, a Mac or a phone

These files are built for the small processors in network devices. We found nothing that says they run on an ordinary computer or a phone.