Every week the AT&T Chief Security Office produces a series called ThreatTraq with helpful information and news commentary for InfoSec practitioners and researchers. I really enjoy them; you can subscribe to the Youtube channel to stay updated. This is a transcript of a recent feature on ThreatTraq. The video features Mike Klepper, Principal Architect, AT&T Cybersecurity Services, Ganesh Kasina, Principal Technology Security, AT&T and George Graziano, Senior Cybersecurity, Security Platforms, AT&T.
Interviewer: Hey, Mike, you have a really interesting story about a fake honeynet, honeypot kind of thing for ICS-based systems. Can you elaborate more about that one?
Mike: Sure. There's a lot of concern and a lot of press about internet-connected Internet of Things, and particularly as this intersects with manufacturing sector and various smart plants and smart manufacturing environments. What’s always interesting is that you don't see much data around what the actual threats are, compared with more traditional networks.
Some researchers decided that they were going to set up a hyper-realistic honeypot emulating a smart factory. They actually modeled all of the components inside of a smart factory. Everything from programmable logic controllers to human-machine interface instances, and even went so far as to create an actual company website for the fake company complete with anonymized customer profiles as well as employee stories and so on. They really pushed the envelope, if you will, from a realism perspective. It’s effectively a very advanced honey pot, specifically looking to see what types of attacks exist against this smart manufacturing infrastructure.
The results were really intriguing. The first thing that stood out to me was that after they put this thing online in March of last year, it took two months for them to start to see attacks against it. This is interesting because usually when you see data about vulnerable Windows systems connected to the internet, you start to see attacks on those types of platforms within minutes. The fact that it took two months for someone to start identifying this and attacking this was interesting. And it wasn't because they didn't have the attack surface, the researchers actually made all of the mistakes you would expect an under-resourced, understaffed, IT shop to make. They have many common ports open to the internet that were associated with various IoT devices as well as remote administration capabilities.
After 2 months, they started to see those systems being used to facilitate fraudulent activities against other third parties. These were things like obfuscating, purchasing of phones, or trying to do number port out schemes, or things like gift card fraud and payment fraud. Then shortly after that, they started to see crypto mining-related activity. So people would log in, identify the systems, start to deploy crypto miners, and then would continue to come back and restart the crypto miners every so often in the event that they stopped producing for them.
What I thought was particularly intriguing was the ransomware instances that eventually made their way into the system. Over about a nine-month period, they had three "instances of ransomware" that popped up while they were doing this study. First was Crisis and the next variant was Phobos, delivered by different threat actors.
The interesting part was that in both cases, the threat actors logged in, identified the systems and gained access, and then manually deployed the ransomware. Some sort of bot or other types of automated process didn’t compromise them. It was people, the threat actor, logged in, looking around, determining what needed to be deployed, downloading packages, manually taking the action to encrypt the environment and then moving forward from there.
In the case of the Crisis malware, they asked the victim for a $10,000 ransom and they eventually negotiated them down to $6K before they just reset the environment. Which was interesting because of the number associated with that. Usually, you hear numbers that are a bit larger. The third ransomware attempt seemed to be by someone who was really a very inept threat actor because they didn't deploy a cryptovirus. What they did was upload some tools that it didn't seem like they knew how to use and then managed to rename everything and open up some tabs in an internet browser that pointed to some adult content in Germany. They made people aware they were there and asked them for $750 in Bitcoin. That was one of those I would personally chalk up to a script kitty - really unsophisticated threat actor, which shows the continuum of risks that these organizations are going to face.
Interviewer: Mike, do you think maybe they had an idea this was a honeypot-style setup? Like maybe it was too good to be true so the attackers thought, "You know what, maybe we'll stay away from this one. We'll let the little guys go in and see what happens." Maybe it seemed like a setup?
Mike: It's tough to say because when you start looking at like Riot and other types of more advanced ransomware, those programs know when they're running in a virtualized environment. They know when they're running in an analyst workbench or something like that and they'll take action to shut themselves down. This environment did use VirtualBox quite a bit as part of the platform, so there may have been something along those lines. But I think that what this shows us is the infection vector may be a bit different because with Riot and other types of ransomware you traditionally see, such as phishing attacks or convincing a user to click on something, are an initial infection vector. In this case, they're compromising poorly secured VNC connections or other weakly secured IoT devices and there isn’t a human interaction component. So then it's forcing the attackers to be more manual about things.
Interviewer: I'll say it's possible maybe these industrial control systems are part of the Innerspace Vector detectors.
George: Okay.
Interviewer: As Mike is alluding to, I think this is a worrying trend. But in near future, we may see lots of attacks or vulnerabilities targeting these devices. And also, I like the point that threat actors need to interact manually. So it may not be the top, high up on their list.
George: Right.
Interviewer: Yes. If they're looking for more value for less time.
George: Right, automating...
Interviewer: They’d try to go for the automation rather than doing manual attacks most of the time. That doesn't mean the threats are not there. The threat vectors are there, experts are there. Because when I read the report, they went to great lengths to use different PLCs and programs to create the real environment.
George: I read in there that they said nobody actually took over any control systems during this honeypot setup? They just rather looked around.
Mike: Yes, they were attacked. But beyond that, I didn't see they actually took the actions to try and reset things. But this does go to a point where just because you can do something, like connect your IoT environment to the internet doesn't necessarily mean you should.
It really is one of those things where you have to weigh the benefit versus the risks. And if you are going to do this, take the kinds of controls and steps that we see today Require people to access the environment remotely via VPN. Require two-factor authentication. Follow best practices of hardening your devices. Reset default passwords and credentials. And any other hardening that is available to you. These simple kinds of things would really help prevent these types of opportunistic attacks.
George: So you want to lock everything down and only unlock as you need, so you want to deny all...zero trust, right? And then as people in your company need access, you want to analyze that access. You want to vet that person, that user, and give them the privilege if they need and then open the port if necessary.
