CyberWire Daily - Twofold snooping venture. [Research Saturday]

Episode Date: May 30, 2020

Working with many different honeypot implementations, a security researcher did an experiment expanding on that setting up a simple docker image with SSH, running a guessable root password. The catch? What happened in the next 24 hours was unexpected. Joining us in this week's Research Saturday to talk about his experiment is Larry Cashdollar of Akamai.  The research can be found here:  A Brief History of a Rootable Docker Image Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. data products platform comes in. With Domo, you can channel AI and data into innovative uses that deliver measurable impact. Secure AI agents connect, prepare, and automate your data workflows, helping you gain insights, receive alerts, and act with ease through guided apps tailored to your role. Data is hard. Domo is easy. Learn more at ai.domo.com. That's ai.domo.com. Hello, everyone, and welcome to the CyberWire's Research Saturday. I'm Dave Bittner, and this is our weekly conversation with researchers and analysts tracking down threats and vulnerabilities and solving some of the hard problems of

protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us. And now, a message from our sponsor, Zscaler, the leader in cloud security. Enterprises have spent billions of dollars on firewalls and VPNs, yet breaches continue to rise by an 18% year-over-year increase in ransomware attacks and a $75 million record payout in 2024. These traditional security tools expand your attack surface with public-facing IPs that are exploited by bad actors more easily than ever with AI tools. It's time to rethink your security.

Zscaler Zero Trust Plus AI stops attackers by hiding your attack surface, making apps and IPs invisible, eliminating lateral movement, connecting users only to specific apps, not the entire network, continuously verifying every request based on identity and context, simplifying security management with AI-powered automation, and detecting threats using AI to analyze over 500 billion daily transactions. Hackers can't attack what they can't see. Protect your organization with Zscaler Zero Trust and AI.

Learn more at zscaler.com slash security. I would really like to give them a real system to break into. And I thought the easiest way to do this would be to have a Docker image. That's Larry Kashtaller. He's a senior security response engineer at Akamai Technologies. The research we're discussing today is titled, A Brief History of a Rootable Docker Image. which we're discussing today is titled A Brief History of a Rootable Docker Image. I had been running some honeypot software in my malware lab that I run out of my home.

And, you know, I was running pretty standard stuff like Calary and some other honeypots that were out there. And I had noticed that a lot of the attacks had been dropping off after a few weeks. And what I had suspected was that the attackers had discovered that they were indeed attacking the honeypot. The honeypot had been fingerprinted. Somehow they realized that it wasn't actually a real server or a real system, and they just stopped attacking my IP addresses. And actually, they stopped leaving malware on the honeypots. So, you know, I thought to myself, well, I would really like to give them a real system to break into. And I thought the easiest way to do this would be to have a docker image where I could set up a docker image on a closed off network in my lab that would only allow ssh connections in

and then wouldn't allow any connections out except maybe perhaps for port 80 or port 443 because I I wanted these attackers to be able to download their malware, which they usually do over HTTP or FTP. And I figured through that, you know, that way I could at least collect some samples. And then I thought, you know, I probably would really want to watch their actions. And I had been interested in what sort of attacks were targeting SSH daemon enabled systems or SSHD systems that had actual SSH server running on it. So I decided to go back many years ago. I was a sysadmin. We had some modified SSH software or an SSH daemon that would log all of the um console connections or all of the session information

and logging information to a log file that that was sent over the terminal i thought to myself that i would augment that by also logging the username and passwords that that were being logged into the uh the actual system or at least be able to document the list of credentials that the attackers were using to log into the system with. So this was a two-fold snooping venture I had gone on where it would log the session information and also the credentials used to log into the system. So I had gone and found some old C code that had been archived for years that would log session information. I had modified the SSH daemon myself to log the passwords and user names that were being logged in. And I tested it on my network myself and once that was set up, I built a Docker image that would use

this SSH daemon and then I placed it on my malware network and just set it live. And after, I'd say 15 to 20 minutes, the machine had been picked up and there were already login attempts against it. And I think it took maybe 45 minutes before somebody had logged into it and started installing an IoT botnet binary. And then maybe a few hours after that, somebody had logged in and installed a crypto miner. So it didn't take long for it to get attacked. And I thought, well, I probably should take it off the network after a day because I don't want a dozen different attackers on this stalker image

all muddling up the forensics that I need to do later. So after 24 hours had passed, I had taken the image off and saw what sort of damage had done and then began to document everything I saw. Yeah. And it's a remarkable thing that in 24 hours, you logged this variety of attacks on this system. Can we go through them together, one at a time? What did it look like? The first thing that I really noticed was it seemed like different groups used a different collection of known credentials. So typically what was happening with the Docker image was that the attackers

were using a list of either known default passwords or logins or ones that they had collected from other systems and they would try and brute force their way into the system by guessing the root password or a login to the system. The usernames ranged between Root to Oracle to Mary to Jason to Root with zeros. It was all sorts of different usernames. The passwords were wildly all over the place. Some of them looked pretty complex. So they looked like they had been picked up by a previously compromised system. I noticed that while the groups use different

login credentials, each group would use the system for a different criminal activity. So the first group that had logged in, they had installed an IoT botnet binary on there. Yeah, I think that one was, I think the first one was a Mirai botnet variant, if I can remember correctly. And that one had been modified from the original Mirai botnet. This one not only would scan for SSH connections and telnet connections, but it had built-in exploits for things like ThinkPHP and the TP-Link GPON router vulnerabilities that were also compiled into this IoT botnet that first infected the Docker image. And then shortly after that, there was an interesting piece of crypto mining malware

that had been installed on the system. That one had actually added other users to the system and it actually attempted to change the root password. I think it was, was it Haiku? I'm trying to remember the password that they used to try and change. And that one was trying to mine, I think it was XMR or Monero. The other interesting thing about that one was that you could almost determine what the criminals were going to do depending on which login credentials they used to log in. The crypto mining malware, they were using credentials. I think RootRoot was one of the ones that they were using a lot to try and guess.

There was Oracle, Oracle, RootOracle, www, www. It was Oracle, Oracle, Group Oracle, www, www. And if the person logged in with that login credential, they would most likely use it as a crypto mining system. And if you think about the actual logins, Oracle, Oracle, and www, www, those would be more like some sort of login you would find on a more enterprise level system versus you know a system that's an iot device that had the default mirai logins of you know root root or root um one two three four five six seven um and that system would be used for either an iot botnet or some sort of sH proxy, because that system was a low-level IoT system that didn't have the performance you'd use for mining cryptoware. Whereas the one that was using the credentials that had to do with Oracle or a web server would be more likely an

enterprise-level system, and that system was used for crypto mining. So you could sort of determine what the system would be used for based on the credentials they were using to try and log in with it. One of the other interesting things that had come up was there was a SOX proxy that somebody had used the SSH daemon for. They didn't use the system as a shell or do anything on the system besides relay mail through the SSH server into a Dovecot mail relay. And that turned out to be a criminal activity where it wasn't just relaying spam mail. It was relaying email that had to do with a work from home scam. So, you know, I noticed the mail was correspondence between multiple people using a credit card to buy

high-end devices from brick and mortar stores. So one was talking about buying three or four random things with a credit card at one place was Apple store. One place was at Best Buy. The other place was at like micro center. And they were buying things like, you know, the latest Apple watch. And then they bought a MacBook Air. And then, you know, and they did that at Apple. And then at Best Buy, And then, you know, and they did that at Apple and then at Best Buy, they bought a Lenovo notebook and then they went to Staples and they bought another laptop or like a tablet. And then talking about sending receipts back to this other person and then talking about, you know, using the credit card and then getting their money in return and we realized that that it was a work from home scam where somebody says you know hey you can work from home make these purchases and then mail me the items that you purchased and then i'll send you money through paypal you know based on the person purchase you bought and then the

person who actually receives the items that were mailed to them, go and sell it on the underground or black market or dark web for a fraction of what they cost. They never send the person that purchased the devices any money at all. So that person ends up getting in trouble for fraud. The victim, they actually end up getting tracked down. They're criminally charged with fraud by buying, you know, items on a stolen or fake credit card. And then the scammer who actually convinced that person to be their mule and actually go out and buy this stuff, sells it for a fraction of the price and makes an easy, you know, four or five, $600 on an item that they bought for 800 because, you know, to them it's easy money.

So, you know, that was something that we believed was going on. And I actually had sent what I had logged to law enforcement so that they can investigate and, you know, sent them all the everything that I had collected. So in a lot of ways, this surprised me because I didn't expect to see mail being relayed through a proxy server that was set up through my SSH daemon. And I didn't expect to see certain clusters of user credentials that had been harvested by specific groups used for specific targeted attacks. I half expected that there were large swaths of collected username and login credentials that had been stolen or pulled through SQL dumps and things like that that the criminals sort of shared.

And it seemed like each criminal entity had their own collection of credentials to use and try in a brute force attack. So I thought that was kind of an interesting glimpse into how these groups operate. Yeah, I agree. And I wonder, was there any sense that after the initial scan happened, in other words, the folks who are looking for this open system or this available system, this connected system, after they find that it's there, was there any sense, like an increase in activity? In other words, did they put the word out? Hey, folks, we've got a hot one here. Let's start pounding on this one.

Yeah, that's what I kind of, that's the next thing I'd kind of like to investigate because that's what I was wondering myself. kind of that's the next thing I'd kind of like to investigate because that's what I was wondering myself you know I noticed that I don't see I'll see a little bit of traffic coming in for a specific port and then suddenly once that port is is open a lot more traffic eventually starts coming in pretty quickly from other IP addresses from around the world so I'm not sure if groups are communicating with each other or which doesn't seem to make any sense world. So I'm not sure if groups are communicating with each other, which doesn't seem to make any sense to me, but I'm not sure how the information is distributed among teams. Yeah, because I suppose on the other hand,

they would want to keep this resource to themselves. Right, and that's what I don't understand, is why after only a few minutes does my system suddenly start to get a lot more traffic from various ip addresses perhaps it's one actor who is you know using other ip addresses to do their scanning and they you know those ip addresses are notified i'm thinking it's other actors when it might be one but it's it's an interesting thing you you know, and I'm working now to try and just look at traffic showing up on my network that never actually had any, you know, business being there. Like if I had, say I had Microsoft's, you know, a packet show up to try and connect to Microsoft's RDP server,

a SYNC packet. I've never had Microsoft RDP on my network before. So I'm curious to see how long after I perhaps, you know, open that port up, how long after that do I start seeing malicious attempts against that port? So that's something else that I'm starting to investigate in my lab. So what are your recommendations here? What can folks do to best protect themselves? If you were going to put an SSH daemon out on the internet, I would recommend only allowing key SSH RSA key access to that system. I would disable password logins and perhaps stick it on a different port. 22 is highly scanned for, so you might want to be more obscure. is highly scanned for, so you might want to be more obscure. Maybe put it on a different non-standard port, like 552 or some other odd port.

Even port 222 and 2222 are scanned now for SSH daemon, so those hiding spots are kind of known. And then make sure whatever service you're running on the internet is patched regularly. Just keep an eye on that vendor and their updates to make sure that if there's a vulnerability discovered, that you're quick to patch your systems. Our thanks to Larry Cashdaller from Akamai for joining us. The research is titled A Brief History of a Rootable Docker Image. We'll have links in the show notes. Cyber threats are evolving every second and staying ahead is more than just a challenge.

It's a necessity. That's why we're thrilled to partner with ThreatLocker, a cybersecurity solution trusted by businesses worldwide. ThreatLocker is a full suite of solutions designed to give you total control, stopping unauthorized applications, securing sensitive data, and ensuring your organization runs smoothly and securely.

Visit ThreatLocker.com today to see how a default-deny approach can keep your company safe and compliant. The CyberWire Research Saturday is proudly produced in Maryland out of the startup studios of DataTribe, where they're co-building the next generation of cybersecurity teams and technologies. Our amazing CyberWire team is Elliot Peltzman, Puru Prakash, Stefan Vaziri, Kelsey Bond, Tim Nodar, Joe Kerrigan, Carol Terrio, Ben Yellen, Nick Vilecki, Gina Johnson,

Bennett Moe, Chris Russell, John Petrick, Jennifer Iben, Rick Howard, Peter Kilpie, and I'm Dave Bittner. Thanks for listening.