Share this story

A fast-moving botnet that appeared over the weekend has already infected thousands of Android devices with potentially destructive malware that mines digital coins on behalf of the unknown attackers, researchers said.

The previously unseen malware driving the botnet has worm-like capabilities that allow it to spread with little or no user interaction required, researchers with Chinese security firm Netlab wrote in a blog post published Sunday. Once infected, Android phones and TV boxes scan networks for other devices that have Internet port 5555 open. Port 5555 is normally closed, but a developer tool known as the Android Debug Bridge opens the port to perform a series of diagnostic tests. Netlab's laboratory was scanned by infected devices from 2,750 unique IPs in the first 24 hours the botnet became active, a figure that led researchers to conclude that the malware is extremely fast moving.

"Overall, we think there is a new and active worm targeting Android systems' ADB debug interface spreading, and this worm has probably infected more than 5,000 devices in just 24 hours," Netlab researchers wrote. "Those infected devices are actively trying to spread malicious code."

The researchers said they were withholding some information about the devices that are getting infected, presumably to make it harder for copycat attackers to exploit the same underlying weakness or vulnerability.

Further Reading

Once infected, devices are saddled with an app that causes them to mine the digital coin known as Monero. It's not clear what precise effect this mining has on the devices. In past cases, however, Monero mining apps are so aggressive they physically damage the Android devices running them.

Information returned by Monero Hash Vault—the mining pool the malicious apps use to generate the digital coin—showed the attackers have a 24-hour average rate of 7,880 hashes per second. That's a relatively small amount. So far, the attackers have generated 0.0171757089 XMR, which at current prices is worth about $3.

It's not yet clear precisely how devices are getting infected. As noted earlier, Netlab researchers are withholding some details, but they did provide one potential clue when they said some of the infection code relies on Mirai, the malware that compromises routers and other Internet-of-Things devices by guessing default administrator passwords.

Promoted Comments

There is no device. This is malware that theoretically spreads to anything running Android: smartphones, TV boxes, smart TV, even potentially your refrigerator, if it's one of the "smart" variety.

It sounds like you'll be safe if you leave the debugging tools turned off, but it's still frustrating, because as a software developer, I tend to turn on the debug tools on my Android hardware. Now this means I'll have to use an isolated network when developing and testing software on smart devices.

There is debug tools, then adb. Now if it takes advantage of a vulnerability in adb that's one thing, but it looks like it infects something listening on port 5555.

Besides, when's the last time you just auth an adb request out off nowhere?

There is no device. This is malware that theoretically spreads to anything running Android: smartphones, TV boxes, smart TV, even potentially your refrigerator, if it's one of the "smart" variety.

It sounds like you'll be safe if you leave the debugging tools turned off, but it's still frustrating, because as a software developer, I tend to turn on the debug tools on my Android hardware. Now this means I'll have to use an isolated network when developing and testing software on smart devices.

There is debug tools, then adb. Now if it takes advantage of a vulnerability in adb that's one thing, but it looks like it infects something listening on port 5555.

Besides, when's the last time you just auth an adb request out off nowhere?

ADB is also called the "Android Debug Bridge", and is the (as the name suggests) bridge between debug tools running on the device and a desktop computer running an IDE or debug console. Turning on debug tools is generally how you enable ADB on a device; so turning debug tools off should turn off ADB on the device.

I haven't actually tried probing 5555 on any devices, however, so I suppose it's possible that some devices will respond to the port even with debugging tools turned off. However, if debugging is turned on, infecting a device is trivial - since that's ADB's job.

IDK about The Dragon Box, but it is one more strike against the "it's less prone to malware" crowd.

It seems that we're hearing about more and more malware infecting smart devices of all types. It's getting to the point where we'll need to spend as much time managing our smart devices as our computers.

There is no device. This is malware that theoretically spreads to anything running Android: smartphones, TV boxes, smart TV, even potentially your refrigerator, if it's one of the "smart" variety.

It sounds like you'll be safe if you leave the debugging tools turned off, but it's still frustrating, because as a software developer, I tend to turn on the debug tools on my Android hardware. Now this means I'll have to use an isolated network when developing and testing software on smart devices.

There is no device. This is malware that theoretically spreads to anything running Android: smartphones, TV boxes, smart TV, even potentially your refrigerator, if it's one of the "smart" variety.

It sounds like you'll be safe if you leave the debugging tools turned off, but it's still frustrating, because as a software developer, I tend to turn on the debug tools on my Android hardware. Now this means I'll have to use an isolated network when developing and testing software on smart devices.

There is debug tools, then adb. Now if it takes advantage of a vulnerability in adb that's one thing, but it looks like it infects something listening on port 5555.

Besides, when's the last time you just auth an adb request out off nowhere?

There is no device. This is malware that theoretically spreads to anything running Android: smartphones, TV boxes, smart TV, even potentially your refrigerator, if it's one of the "smart" variety.

It sounds like you'll be safe if you leave the debugging tools turned off, but it's still frustrating, because as a software developer, I tend to turn on the debug tools on my Android hardware. Now this means I'll have to use an isolated network when developing and testing software on smart devices.

There is debug tools, then adb. Now if it takes advantage of a vulnerability in adb that's one thing, but it looks like it infects something listening on port 5555.

Besides, when's the last time you just auth an adb request out off nowhere?

There is no device. This is malware that theoretically spreads to anything running Android: smartphones, TV boxes, smart TV, even potentially your refrigerator, if it's one of the "smart" variety.

It sounds like you'll be safe if you leave the debugging tools turned off, but it's still frustrating, because as a software developer, I tend to turn on the debug tools on my Android hardware. Now this means I'll have to use an isolated network when developing and testing software on smart devices.

There is debug tools, then adb. Now if it takes advantage of a vulnerability in adb that's one thing, but it looks like it infects something listening on port 5555.

Besides, when's the last time you just auth an adb request out off nowhere?

ADB is also called the "Android Debug Bridge", and is the (as the name suggests) bridge between debug tools running on the device and a desktop computer running an IDE or debug console. Turning on debug tools is generally how you enable ADB on a device; so turning debug tools off should turn off ADB on the device.

I haven't actually tried probing 5555 on any devices, however, so I suppose it's possible that some devices will respond to the port even with debugging tools turned off. However, if debugging is turned on, infecting a device is trivial - since that's ADB's job.

Isn't ADB disabled by default on most (since i haven't used all Android devices i will not say "all" but that is what i mean) Android devices?

Normally, yes. However, there are apps out there that interact with a PC through the USB port, and so they use ADB as a communications channel. Also, it's possible that there's a listening process on that port, even if the switch in the control panel is toggled off.

Isn't ADB disabled by default on most (since i haven't used all Android devices i will not say "all" but that is what i mean) Android devices?

Normally, yes. However, there are apps out there that interact with a PC through the USB port, and so they use ADB as a communications channel. Also, it's possible that there's a listening process on that port, even if the switch in the control panel is toggled off.

I'm guessing poor default configuration by OEMs could be part of the problem, e.g. leaving adb open on production devices. Wouldn't be the first time an OEM sent out unsecurely configured hardware.

IDK about The Dragon Box, but it is one more strike against the "it's less prone to malware" crowd.

It seems that we're hearing about more and more malware infecting smart devices of all types. It's getting to the point where we'll need to spend as much time managing our smart devices as our computers.

"Viruses, they aren't just for computers any more."

You just wrote this: we’ll need to spend as much time managing our computers as our computers.

I'm assuming (hoping) that as long as port 5555 isn't open to the internet I should be okay? I have Fire TVs at home that I have installed Kodi on and left debug mode on the devices. So, port 5555 is available on my local network, but there's no way to get to those devices from the internet. As long as there isn't some other way for these devices to get infected (streaming site?) I should be okay.

However, it sounds like I should start turning on developer mode while I'm sideloading Kodi and other apps, and turning developer mode back off when I'm done.

I'm assuming (hoping) that as long as port 5555 isn't open to the internet I should be okay? I have Fire TVs at home that I have installed Kodi on and left debug mode on the devices. So, port 5555 is available on my local network, but there's no way to get to those devices from the internet. As long as there isn't some other way for these devices to get infected (streaming site?) I should be okay.

However, it sounds like I should start turning on developer mode while I'm sideloading Kodi and other apps, and turning developer mode back off when I'm done.

Developer mode is too slutty to leave on.

I just hope my Ubiquity Security Appliance is earning its keep as the sole device attached to the cable modem.

Isn't ADB disabled by default on most (since i haven't used all Android devices i will not say "all" but that is what i mean) Android devices?

Normally, yes. However, there are apps out there that interact with a PC through the USB port, and so they use ADB as a communications channel. Also, it's possible that there's a listening process on that port, even if the switch in the control panel is toggled off.

If you have debugging turned on for an android phone, doesn't it prevent the typical media transfer\backup behavior from working normally with most peoples PC\USB? That may prevent some phone infections since it would be off most of the time, but considering industry track record, it wouldn't shock me at all if most non-phone Android devices keep the ADB port open just out of technical convenience (or laziness).

Maybe I missed it in the article, but is the targeting of the ADB tool\port something new? It seems like it wouldn't be but I don't recall hearing about it before.

IDK about The Dragon Box, but it is one more strike against the "it's less prone to malware" crowd.

It seems that we're hearing about more and more malware infecting smart devices of all types. It's getting to the point where we'll need to spend as much time managing our smart devices as our computers.

So, you can confirm that Kodi will still function with ADB debugging disabled on the Fire TV? I haven't tested myself, yet, and I can't find anything online (all the search results are just instructions on how to install Kodi...)

The problem is lots of these IoT devices are just cheap Linux boxes put together as quickly as possible without much care for security. I hate to suggest this, but perhaps we should have something akin to Underwriters Lab to certify web connected devices for digital safety.

In my opinion, things like this will be detrimental for the cryptocurrency world.

While cryptocurrency it is already not seen with very good eyes by the population at large, attacks like this will only make it worse. Instead of it possibly becoming in some years "mainstream" it will end up being used strictly for illegal stuff but even then it might have a really low value.

It's just sad how much damage will be caused to the owners of these smart devices (I'm sure some will stop working or working well) just so some thief can make $3.00.

It's like how assholes used to break your car window/door and steal your car stereo causing a few hundred in damage just for their $20 of drugs.

No kidding. The last time my stereo was stolen, it cost more to replace the in-dash hardware than the actual stereo. I also had to do a lot of work to extend the wiring back out to where it was useful, since the jerk cut the harness off when he stole the radio.

There is no device. This is malware that theoretically spreads to anything running Android: smartphones, TV boxes, smart TV, even potentially your refrigerator, if it's one of the "smart" variety.

It sounds like you'll be safe if you leave the debugging tools turned off, but it's still frustrating, because as a software developer, I tend to turn on the debug tools on my Android hardware. Now this means I'll have to use an isolated network when developing and testing software on smart devices.

There is debug tools, then adb. Now if it takes advantage of a vulnerability in adb that's one thing, but it looks like it infects something listening on port 5555.

Besides, when's the last time you just auth an adb request out off nowhere?

So, you can confirm that Kodi will still function with ADB debugging disabled on the Fire TV? I haven't tested myself, yet, and I can't find anything online (all the search results are just instructions on how to install Kodi...)

No I am merely stating that developer mode takes a device from a more locked down state to a less locked down state. So for instance you may disable strict signature checks and permission requests to make the life of a developer easier. Typing in your complex password 10 times just to launch a new build gets old super fast. Developer mode avoids that, but your security is best served not being in developer mode.

To be more specific to your question, if Kodi requires developer mode i would view it as inferior to competing software that does not. I do not use Kodi though, and the trade off may be worthwhile nevertheless for someone else.

I'm the the developer of adbLink, ( http://www.jocala.com ) a GPL utility for Android devices, which allows side-loading Kodi, among other things. adbLink is a front-end for Android's adb.

adb connections require an authorization ( http://www.jocala.com/usbauth.html ) that the end user must perform. Once you authorize a key is stored on your connecting PC/Mac and on the actual device at /data/misc/adb/adb_keys.

You can bypass the authorization dialog, but it requires root and a USB connection to overwrite the key on the Android device. Additionally, as far as Android set-top boxes go (Fire TV - Nvidia Shield TV, etc), I suspect that the majority don't expose 5555 to the Internet. YMMV, of course.

And yes, you can turn developer settings on, side-load Kodi, then turn developer settings off and Kodi will function perfectly.

I'm assuming (hoping) that as long as port 5555 isn't open to the internet I should be okay?

As long as you never take any ADB open devices outside your network (use your Android smartphone at the coffee shop on WiFi?) and bring it back inside the network.

There is still a concern that some other device on your internal network could get hacked, then probes all of your computers/devices/IoTs and looks for open port 5555 on them.

Most of those devices are likely to be able to reach out to the internet, so it would be worth their trouble to install cryptomalware on them, especially since it may not be evident that these devices have been hacked unless they overheat or malfunction from the load.

According to the docs(and my limited but nonzero experience) Android devices of 4.2.2 or newer will refuse to do anything useful over ADB unless you respond affirmatively to a confirmation prompt(on the device) that you do indeed wish to trust the RSA key provided by the device on the other end of the ADB connection.

Are these things running an ancient version? Is there a vulnerability in ADB, or at least some flavors of it, that allows you to bypass the keypair auth step? Did the bottom-feeding OEM stub that out because they basically want ADB to be smartphone telnet?

I certainly wouldn't take the extra risk, since it carries little benefit; but [/i]if the design is actually working as intended[/i] exploiting ADB is not substantially dissimilar in difficulty from exploiting SSH set for keypair auth only.

Given that it is clearly getting exploited; my question is "Social engineering, bug; or deliberate misconfiguration?"

There is no device. This is malware that theoretically spreads to anything running Android: smartphones, TV boxes, smart TV, even potentially your refrigerator, if it's one of the "smart" variety.

It sounds like you'll be safe if you leave the debugging tools turned off, but it's still frustrating, because as a software developer, I tend to turn on the debug tools on my Android hardware. Now this means I'll have to use an isolated network when developing and testing software on smart devices.

There is debug tools, then adb. Now if it takes advantage of a vulnerability in adb that's one thing, but it looks like it infects something listening on port 5555.

Besides, when's the last time you just auth an adb request out off nowhere?

There is no device. This is malware that theoretically spreads to anything running Android: smartphones, TV boxes, smart TV, even potentially your refrigerator, if it's one of the "smart" variety.

It sounds like you'll be safe if you leave the debugging tools turned off, but it's still frustrating, because as a software developer, I tend to turn on the debug tools on my Android hardware. Now this means I'll have to use an isolated network when developing and testing software on smart devices.

There is debug tools, then adb. Now if it takes advantage of a vulnerability in adb that's one thing, but it looks like it infects something listening on port 5555.

Besides, when's the last time you just auth an adb request out off nowhere?

IDK about The Dragon Box, but it is one more strike against the "it's less prone to malware" crowd.

It seems that we're hearing about more and more malware infecting smart devices of all types. It's getting to the point where we'll need to spend as much time managing our smart devices as our computers.

"Viruses, they aren't just for computers any more."

<chuckles>

It's good to know that all IoT devices can be managed to the point where they can be secure.

Isn't ADB disabled by default on most (since i haven't used all Android devices i will not say "all" but that is what i mean) Android devices?

Normally, yes. However, there are apps out there that interact with a PC through the USB port, and so they use ADB as a communications channel. Also, it's possible that there's a listening process on that port, even if the switch in the control panel is toggled off.

Right, but the point is you need to physically connector to the phone to run ADB. Or at least that is the only way I know how to use ADB.

I'm the the developer of adbLink, ( http://www.jocala.com ) a GPL utility for Android devices, which allows side-loading Kodi, among other things. adbLink is a front-end for Android's adb.

adb connections require an authorization ( http://www.jocala.com/usbauth.html ) that the end user must perform. Once you authorize a key is stored on your connecting PC/Mac and on the actual device at /data/misc/adb/adb_keys.

You can bypass the authorization dialog, but it requires root and a USB connection to overwrite the key on the Android device. Additionally, as far as Android set-top boxes go (Fire TV - Nvidia Shield TV, etc), I suspect that the majority don't expose 5555 to the Internet. YMMV, of course.

And yes, you can turn developer settings on, side-load Kodi, then turn developer settings off and Kodi will function perfectly.

For those that never ran ADB, it is all CLI. At least on Linux. I can see the need for adblink for the general public.

I'm assuming (hoping) that as long as port 5555 isn't open to the internet I should be okay? I have Fire TVs at home that I have installed Kodi on and left debug mode on the devices. So, port 5555 is available on my local network, but there's no way to get to those devices from the internet. As long as there isn't some other way for these devices to get infected (streaming site?) I should be okay.

However, it sounds like I should start turning on developer mode while I'm sideloading Kodi and other apps, and turning developer mode back off when I'm done.

This is horrible, especially since a lot of devices don’t document how to change the default passwords, or straight up disable it for regular users specifically, and having physical damage on top of the hack is worrisome on several levels, especially if they have batteries that might catch fire due to excessive heat (worst case).

If nobody has brought the answer yet, this malware uses port 5555 "most probably" because most, if not all Monero pools accept low-end hardware connections on ports 3333 and 5555.

If I'm correct, blocking those two ports on your router will prevent any infected device on your network from effectively communicating with almost all Monero pools. They'll still be infected, but won't drain their CPU mining. They'll keep trying to ping the pool address set in the miner's config file.