# Cybersecurity Awareness Month - IoT and SOHO devices **URL:** \ **Category:** Tutorials, Tips & Tricks\ **Created:** [October 28, 2025, 9:27pm UTC](https://community.emergingthreats.net/t/cybersecurity-awareness-month-iot-and-soho-devices/3095 "2025-10-28T21:27:27Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![trobinson667](https://sea2.discourse-cdn.com/flex016/user_avatar/community.emergingthreats.net/trobinson667/32/544_2.png) [@trobinson667](https://community.emergingthreats.net/u/trobinson667)\ **Post date:** [October 28, 2025, 9:27pm UTC](https://community.emergingthreats.net/t/cybersecurity-awareness-month-iot-and-soho-devices/3095/1 "2025-10-28T21:27:27Z")
# Cyber Security Awareness Month - Securing IoT devices Earlier this month, I did a [write-up](https://community.emergingthreats.net/t/cyber-security-awareness-month-web-browser-security/3071/1) on browser/web browsing security controls that can be used to help keep you and your user community secure at home, and at work. This time around, I want to talk a little bit more about a subject that has been a focus for me for the past few months, and that is IoT device security. IoT stands for “Internet of Things” and is a pretty broad spectrum covering just about any device that has some form of embedded hardware and software that supports network connectivity of some sort. to me, the label includes SOHO (Small Office/Home Office) devices like routers, NAS (Network Attached Storage) devices, Access Points, Wireless repeaters and just about everything in between. In my opinion, IoT devices also encompass a lot more than that, For example, building management/monitoring suites, Multifunction printers with web management interfaces, DVRs, networked security cameras, serial to ethernet controllers to provide network access to serial-only devices, and much much more. I’m picking on these device categories in particular, since as Shodan, Censys, and other Internet Search Databases will all tell you: Their management interfaces are very often exposed to the public internet ![image](https://us1.discourse-cdn.com/flex016/uploads/emergingthreats/original/2X/4/43b689f5051e3decb16e0f72aff16e0cee8868a9.png) > There is a whole galaxy of exposed embedded/IoT devices out there. (Image credit: [shodan.io](http://shodan.io)) In some cases, this may be an intentional configuration state that is necessary for one reason or another, and in other cases, it could be an overlooked misconfiguration. ## Risks factors of unsecured IoT devices Why am I making such a big deal out of this? Here on the Emerging Threats team, we concern ourselves with a wide array of threats out there. The threat landscape is gigantic, but more and more recently, I’ve been paying attention to the deluge of vulnerabilities for IoT devices, and writing detection for those vulnerabilities. Why? because the bad guys are using them, and here’s how: 1. **Initial access** - If IoT devices are plentiful, vulnerable, barely ever managed unless they go down, and connected to the public internet, bad guys interested in internal network access – including ransomware groups, or nation-state threat actors – have no problem using them for initial access. For a real-world example of this, take a look at “Phineas Fisher” and his [account](https://gist.github.com/jaredsburrows/9e121d2e5f1147ab12a696cf548b90b0) on how he compromised the organization “Hacking Team”. While this write-up is a little bit long in the tooth, the fact remains is that out of the options available, attacking an exposed, embedded device at the network border was the chosen method for initial access because it was the path of least resistance. 2. **Bypass security controls** - In general the security of desktop and server operating systems has been getting better and better. On top that, bypassing EDR (Endpoint Detection and Response) while possible, is a complicated matter. Why bother when bad guys can abuse an embedded device with very little in the way of security controls? 3. **To build ORB (Operational Relay Box) Networks** - Many different types of threat actors are utilizing IoT devices to build ORB networks, or networks of compromised devices to act as proxies in order to obfuscate the true source behind malicious activity. Depending on the community, these “ORBs” can also be referred to as “Jump Boxes”, “Residential Proxies”, “Redirectors”, “Non-Attributable Infrastructure”, etc., but the overall idea is the same: hide the true source behind malicious activity to make attribution and attack prevention more difficult. ![image](https://us1.discourse-cdn.com/flex016/uploads/emergingthreats/original/2X/5/56b9008d678a58aad757c837969084b333dae00a.jpeg) > This image, from [this article](https://www.team-cymru.com/post/an-introduction-to-operational-relay-box-orb-networks-unpatched-forgotten-and-obscured) by Team Cymru, demonstrates how ORB networks are used to obfuscate the true source of malicious activity. 1. **DDoS Botnets, Coinmining botnets, and other such nuisances** - Aside from being used by threat actor groups, IoT devices are often exploited to participate in DDoS botnets, or exploited to mine cryptocurrencies (though, most embedded devices are not known for having access to large amounts of CPU and/or GPU power that crypto-mining typically requires). One of the most popular cases of an IoT botnet being used in a DDOS attack was the [2016 DDoS by the Mirai botnet](https://en.wikipedia.org/wiki/DDoS_attacks_on_Dyn), that targeted the Dyn network’s DNS service, resulting in wide-spread outages for a wide variety of internet services. Since then, [the](https://arstechnica.com/security/2025/01/the-internet-is-once-again-awash-with-iot-botnets-delivering-record-ddoses/) [number](https://www.trendmicro.com/en_us/research/25/j/rondodox.html) [of](https://www.akamai.com/blog/security-research/digiever-fix-that-iot-thing) [IoT botnets](https://www.cisecurity.org/insights/blog/critical-infrastructure-caught-botnet), and the exploits they utilize to build their networks has only exploded. # Recommendations for Securing IoT devices So now that we’ve established that IoT devices are vulnerable by design, and being exploited by a variety of actors for a variety of different purposes, what can you do to keep your devices at home, and in the enterprise safe? Here are my thoughts: 1. **If it uses `boa` or `goahead webs` as the web server/framework for the web interface, deeply reconsider the usage of such products or have _very robust_ mitigations in place**. Boa HTTPd has been unmaintained since 2005 and yet is still used in a significant variety of IoT devices, meanwhile GoAhead webs and `goform` are also frequently implicated in the large number of CVEs I’ve written detection coverage for. Sometimes the purchase of devices using these frameworks is unavoidable. If that’s the case, consider the other advice here to mitigate the risk they pose. Be aware that, even if you utilize devices that don’t use either framework, IoT devices in general **still** represent a significant risk that needs to be carefully monitored. 2. **Monitor vendor websites for firmware updates, patches, and End-Of-Life Announcements.** It’s never easy, and its never fun, but with many of these devices, firmware updates are not done automatically, making it necessary for customers to keep an eye on announcements from the vendor for new firmware releases or patches that are intended to mitigate major vulnerabilities. Additionally I am **not** a fan of planned obsolesce, but when a vendor decides that they will no longer support a given device, it becomes necessary to upgrade the existing device to something that _is_ supported. This is never fun to deal with, but there are a significant number of IoT botnets consisting of devices that vendors have announced as EOL (End-of-Life). This is big problem because the vulnerabilities used by those botnets will **[never get patched](https://www.techradar.com/pro/security/d-link-says-it-wont-patch-60-000-older-modems-as-theyre-not-worth-saving)**. This type of vulnerability is also referred to as a “Forever Day” and represents a serious risk to network security. Again, some networks, especially regulated IoT/SCADA networks are often tied up with regulatory red tape that requires a significant amount of time and planning to upgrade obsolete devices. The best advice I can offer in these situations is strict access control, and robust monitoring of the affected devices – network segmentation, access management, exporting logs to a central location, IDS/IPS controls, etc. 3. **Stop exposing embedded devices, especially web management interfaces over the public internet.** This is single biggest reason why there are so many exploited IoT devices today. If you can, ensure that the management/admin interface for your IoT devices are **NOT** exposed to the public internet. **If there’s no exposed surface area, there is no exploited IoT device**. ![image](https://us1.discourse-cdn.com/flex016/uploads/emergingthreats/original/2X/6/68e41331b9068a15142a93b1634d1eb1c82b33eb.png) > A screen capture of the results from [shodan.io](http://shodan.io) for my residential IP address. I run a personal blog and a minecraft server, so ports 80, 443, and 25565 are exposed. If there were other services exposed, I would definitely want to know about it! 1. Consider implementing other security controls for accessing the IoT devices over the internet - Consider implementing a VPN or another form of secure remote access. Even something like key-based SSH meets that criteria! 2. **Consider using more enterprise-quality offerings, or other alternatives** - With regards to networking equipment, Considering steering away from retail or home market solutions like D-Link, TP-Link, Linksys, etc., and selecting slightly more high-grade solutions that have a bigger ecosystem – Mikrotik, Ubiquiti, GL.iNet, etc. While some of these vendors may also be subject to their own problems and vulnerabilities, many have well-supported device ecosystems, and utilize their own custom operating systems, such as Mikrotik’s [RouterOS](https://mikrotik.com/software), or variations of [OpenWRT](https://openwrt.org/) that come pre-installed. ![image](https://us1.discourse-cdn.com/flex016/uploads/emergingthreats/original/2X/f/fabd171b6aef9fb6136ba8f1c4a7c6be6dede3f8.jpeg) > In my household, I bought a very generic 4-port miniPC, and installed pfSense on it. After discovering the hard way that support for Wi-Fi6 and beyond is very limited on the FreeBSD-based pfSense, I purchased a GL.iNet router, and configured it as a wireless bridge. A little bit complicated, but _very_ robust. So far, its been in-service for two years with no problems to report. ## Conclusions I hope you’ve found this post helpful for securing your IoT devices and SOHO equipment. If you I missed any recommendations for securing IoT devices, or if you have any preferred vendors and/or solutions of your own, feel free to comment. Until then, Happy Hunting. -Tony