Blog Post

The IoT Crowd

Recently, Microsoft released a brief report on how IoT devices were used by a nation state actor to gain an initial foothold in a network. IoT devices causing a major risk to networks is nothing new; in fact “IoT” and “IoT Security” have certainly earned their place on the industry buzzword bingo cards – just try to find a security vendor who doesn’t mention it in their marketing material. Despite the fact that this seems like a somewhat played out topic, like many of the successful attack vectors, it remains a largely unaddressed security concern.

Since we are a security vendor, we of course spend time and resources on identifying IoT devices (to great success, in my experience), their flaws, and TTPs that include them. It shouldn’t be surprising that their presence is ubiquitous across every vertical and every shape and size of the networks we monitor. It also shouldn’t come as a shock that they are entirely unmanaged – no one is installing host-based agents on these things and would likely be hard pressed to do so even if they wanted to. Default passwords (another “played out” topic) appear to be the rule, not the exception. How do I know this? Because there’s often plaintext traffic on these networks targeting the devices that include said credentials.

This leads me to another interesting anecdote from the report: “After gaining access to each of the IoT devices, the actor ran tcpdump to sniff network traffic on local subnets.” There are many examples of interesting and useful (to an attacker) information someone can glean from local network traffic. After that they “enumerated admin accounts” potentially over SMB in order to move laterally.

What’s interesting is that none of the methods described in the report were complex or novel – they got in using default passwords, maintained persistence with a shell script, and moved laterally over SMB. These are all things that are easy to imagine, but in practice, they’re historically difficult to detect.

I recently talked about our use of functional programming for adversarial modeling in order to implement novel detection techniques. If we break down the above threats into their individual parts, we can see how we can easily employ a few basic functions to detect a difficult-to-detect threat.

Process List

Process List

Without getting too much into the nuts and bolts of how we can get this to work:

  • We identify IoT devices using analytics, and filter by only that type of device
  • We identify brute force/password guessing, followed by a success using a function
  • We identify the shell script by filtering only by non-browser traffic (made possible partly due to this research)
  • We identify characteristic SMB traffic that is unique to the original device

All of these things are impressive feats in their own right, but the icing on the cake is that we then use a function to tie all of those things together. This means that we will only see occurrences where there is an IoT device that was successfully accessed after unsuccessful attempts followed by a non-browser, encrypted shell script, followed by SMB traffic that is interesting for the network.

If it’s not entirely clear, the massive advantage that this kind of approach to detection gives you is that the above is specific enough that the probability of a False Positive is ridiculously low. With currently available detection techniques, an analyst would often have to correlate all of those separate events on their own. And they would receive alerts when any one of them occurs. That means that they’re inundated with alerts and unable to be as effective as they could (and likely want) to be all because their tools are simply not up to the task.

 

Troy Kent
Troy Kent

Threat Researcher