I can't tell if my IOT is hacked / nope just paranoid

EDIT: figured it out

Turned out this was benign. Saving post as a display of my own paranoia

Last week, while at a team offsite, I spotted a funny thing on my RockNSM dashboards while showing off my home network tap data to a coworker. I send my data securely up into Elastic Cloud, so I can humble-brag from anywhere in the world.

That’s right, while I’m out of the house, devices from my home network are communicating with IPs assigned to the US Department of Defense. That’s not expected, so it’s probably not good. Returning home and getting some time this weekend I punched up some whois on the IPs involved to verify my sensor is correctly identifying the IPs I’m talking to outside my network.

It’s the Navy all right! Let’s check the Bro/Zeek Conn log to see which devices those were?

Adding a filter for the responding host network organization identity shows that three devices on my home network 192.168.2.0/24 are responsible for that traffic. I use DHCP and not static IPs on that router, but devices plugged in 24/7 tend to have stable internal IPs. Lookup up .123, .206, and .219 on my router’s admin page they are my wifi-enabled Wemo Mini Smart Plugs which I use to control some non-smart lights in my house. I reset these devices to factory defaults and reinstalled them on July 13th after making some changes to the wifi in my house. I have 100% coverage of the Bro and Suricata logs from before July 13th so I do have the data to look into this. The Wemo switches don’t have passwords I can change, so they’ll accept network connections from anything on their home network, making them inherently less secure than most of the other things on my home network. Consumer IOT has a bad reputation in the news for being invovled in offensive botnets, so I’d really prefer not to be unwittingly attacking a government network.

EDIT: figured it out

About an hour after posting this … I realized that the above diagram solves the mystery. Port 123 is NTP traffic. The Wemo Devices are using public network time servers at the US Naval Observatory to sync their internal clocks. This is nothing. There rest of this blog post is me descending into paranoia.

What else have these three devices been doing?

From my high-level overview page, I can see that the main responding organizations are what is likely an AWS datacenter and a DOD Network Information Center. IPv4 is a crowded place. It’s totally within the realm of belief to believe my ISP is internally routing address range that is supposed to be DOD for their purposes as part of some kind of WAN acceleration. Jumping over to the Bro Conn logs I realize I am getting beyond my ability to diagnose what is going on.

1. I can tell that the day I installed the devices they started acting differently than the previous day of operation.
2. The Wemo devices are attempting to communicate with every device on my internal network.
3. These devices have web servers built into them and have communicated with benign command and control services from Wemo so that I can control them from outside my house using the iOS app or automation tools like IFTTT. I see a lot of HTTP traffic and some DNS that should be easy to look into given it isn’t normally encrypted.
4. These wemo devices account for 1.6 GB of network traffic to the subnet’s router and 521 MB of communication with devices 192.168.2.236 and 192.168.2.122 which are Sonos Devices. Could the IOT devices of my life be conspiring against me? Is this normal chatter for some kind of IOT mesh protocol? I don’t know. Getting paranoid now.

Looking into the traffic from the Wemo to the Sonos devices, I see that 100% of the traffic are HTTP calls to SOAP XML endpoints of the SONOS devices that don’t look Sonos specific. How do I know that? Well, check out my previous investigations into SONOS.

Looking into the DNS requests, things look pretty normal. The majority of the traffic came when I was setting them up in the first place and a week later when messing with their setup. This would be a normal time for them to re-establish communication with their Wemo command and control functions outside my house. Most of the communication is to my router looking for devices by Name.local or to xbcs.net, which from my research is the domain that Wemo uses for most normal C&C. There is one interesting thing in there though. heartbeat.lswf.net gets some traffic. That domain has a “for sale” page up over HTTP. Its domain and IP are in an AWS datacenter and it has a neutral reputation according to CISCO Talos. The rate of access matches the general trend of the rest of the DNS. Maybe it’s nothing?

I dug in a few other places that are harder to redact in screenshots, but unfortunately this is about where my skills and time run out. All of the traffic to the DOD network is UDP and I wasn’t running PCAP so I can’t look into it beyond the basic connection information. The UDP traffic started when I reinstalled the devices on the 13th, so it’s possible a firmware update changed the benign behavior. These devices weren’t working as smoothly as I’d like so I’m just going to unplug them until I can do more research. I set forum posts from others complaining about their cell phones and cable modems doing similar things. Kibana and Elasticsearch made digging around in this data very easy, but I’m no network forensic analyst. That takes a bit more domain experience than what I have.

Sigh.

EDIT: figured it out

Time to reconnect my devices.