0

I have a large number of rooted IoT devices from an industrial supplier that are meant to run as an advertising unit. The goal was to install a standard piece of advertising software designed for android and configure it in it's housing for deployment. These devices are running a rooted Android 6.0.1 Kernel Version 4.1.17-g900299-dirty

However some of these devices are consuming insane amounts of data - over a 30 day period, 300gb of ethernet data is being used by the device, this is according to the Data Usage view within the OS Settings. However the application causing it is "Android OS"...

I used a packet sniffer to perform a couple 30 second packet captures as well as a couple longer ones. I reviewed the data and I see that across each device affected the port is random, but it's consistent that there's always 1 port transferring 80-90% of the data seen in the capture. The traffic seems mostly upload traffic (bytes sent from device to remote host), but that hasn't always been the case. Triggering a reboot seems to cause the service to pick a new port during boot.

I tried using netstat -tulpn in termux to check what process is using this, but the pid section is blank across the board. I see this port is listening, though.

I've looked at lsof -i | grep <port> but nothing comes up on any of the affected devices.

ps aux | grep <port> is not returning anything either.

Within the captures, it seems like there are a couple consistent hosts that they're reaching out to within a single device, but across devices this is not true. However I'm noticing that the remote host port we're contacting tends to be 4001... is that relevant?

I've read that it's possible it's an OS Upgrade issue where we're downloading updates that somehow fail and cause this awful cycle... but when I looked into the services running that it seems like it's already disabled (as referenced here: Google Play Services High Internet Consumption )

Does anyone have any suggestion of how I can track this down and stop it?

Improve this question
3
  • If you have multiple of those IoT devices use use and place it in a network you monitor via Wireshark (especially check for DNS requests to understand which server the devices communicate with). My guess would be that those devices are infected with a malware (e.g. crypto miner or ad fraud clicker). The only question is if they have been infected after installation or if they come "pre-infected" from the manufacturer. Regular updates are 99% of all cases delivered by a http(s) server on port 80 or 443.
    – Robert
    Commented Jun 16, 2021 at 7:07
  • @Robert yes that was my fear... I did use wireshark for this, the hosts being connected to are anonymous, reverse dns lookup hasn't yielded any information other than they are cloud hostings themselves. Good to know that google sends updates of http/https. Thanks for your feedback!
    – Djones4822
    Commented Jun 16, 2021 at 15:23
  • Just to clarify Google does not send any updates. Android updates are provided by the device manufacturer. And the device polls for them using configured update URLs. If you don't see DNS queries at all communication is done on IP level which would be really suspicious. Make sure to first start your sniffing environment and then boot the device to be checked.
    – Robert
    Commented Jun 16, 2021 at 15:37

1 Answer 1

Reset to default
0

I have found the issue. It appears that the application Apache Storm was loaded onto these machines.

It was being called by a shell script install-recovery.sh that was sitting in the /system/bin directory. This shell script was being invoked by the init.rc script, a quick search for the shell script name in the init returned it being called as the flash_recovery service. Pretty sneaky...

To address some other issues I had, I couldn't find the pid or process name in netstat because I wasn't the right user, swapping to the root user using su was wrong, I needed the tsu package so that I could retain the bash environment scripts that termux was giving me - going to root caused me to enter a different shell type that had different commands, which is why netstat was failing.

Hope that helps someone in the future.

Thanks

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .