Cybersecurity In-Depth: Feature articles on security strategy, latest trends, and people to know.

Learning from the Honeypot: A Researcher and a Duplicitous Docker Image

When Larry Cashdollar set up a honeypot in a Docker image, he found behavior that was more enlightening than he had imagined.

(image by jag_cz, via Adobe Stock)

Sometimes you don't swat the flies that buzz around your table. Sometimes you study them so that you can better swat the next round of flies. That's what Larry Cashdollar, senior researcher at Akamai, did when hackers swarmed a honeypot he deployed earlier this year. And what he saw were trends in hacking that might make life just a little more difficult for future cyber flies.

"I had set up a honeypot that was pretty much just a Docker image that I just made to look like an SSH Web server," Cashdollar says. More than that, though, he tried to make the image look as much like a full-fledged Linux server as possible. It was important for this bit of research that the attackers not realize they had successfully attacked a honeypot.

"What I wanted them to do was log in, think that it's either a compromised Linux host or a compromised Docker system, then stay there and drop their warez and do whatever it is that they're gonna do with with a system once they compromised it," he explains.

What Cashdollar discovered was the attackers had patterns in how they attacked the honeypot, as well as patterns in what they did with the compromised system once they were inside.

One of the patterns Cashdollar noticed was that certain username/password combinations were associated with specific malicious actions. In a blog post on his research, he wrote, "Log-in combinations of root:admin, root:root, oracle:oracle would invariably use the docker image as a SOCKS5 proxy through SSHd."

That SOCKS5 proxy would stream content from Twitch, Google, Netflix, and other content providers. He wrote that a colleague informed him that the reason for at least one of these, the Twitch stream, was probably to pad the stream view count for one or more players.

Before the platforms started acting as a proxy for streaming content, however, a number of steps took place.

First, he says, the malicious code tried to add a handful of new users. Then it sought to change the root password and install a cron job to rerun the infection script on a regular basis and therefore establish persistence.

One of the novel things Cashdollar saw the infection code do was to try to make a specific directory immutable by modifying the change attribute so that not even the legitimate root user could make changes to users and passwords. He says this will work (and require a specific utility program to change), but it's not a tactic he has seen in other attacks.

After establishing control and persistence, the attach code checks to see how many CPUs the system has and, based on that, may load a cryptominer package.

As he watched the automated routines of the malicious payload do their jobs, Cashdollar noticed a repeating behavior: The malware would make an outbound query using port 3309 (commonly used for peer-to-peer communications between Oracle databases) using a specific Google DNS server (at to resolve a single, specific address. Most malware, he says, works much harder to obfuscate the address of its command-and-control (C&C) server.

It's important to note, Cashdollar says, that more than one malicious actor was at work on the honeypot. In another bit of unusual behavior, he says, the two primary actors didn't go out of their way to look for other malicious activity — something many pieces of malware do as one of their first activities. Instead, each piece of malware concentrated on its own activity, seeming not to care what anyone else was doing on the targeted system.

Asked how long it took for the attack to succeed, Cashdollar said that initial contact to persistence took a handful of seconds. The next set of questions to be answered involve the timing of the attacks. Cashdollar says the attacks appeared to come in waves.

"It seems to me like there's a higher activity at certain hours of the day, and I haven't figured out when that is yet," he says.

Related Content:

A listing of free products and services compiled for Dark Reading by Omdia analysts to help meet the challenges of COVID-19. 

About the Author(s)

Curtis Franklin, Principal Analyst, Omdia

Curtis Franklin Jr. is Principal Analyst at Omdia, focusing on enterprise security management. Previously, he was senior editor of Dark Reading, editor of Light Reading's Security Now, and executive editor, technology, at InformationWeek, where he was also executive producer of InformationWeek's online radio and podcast episodes

Curtis has been writing about technologies and products in computing and networking since the early 1980s. He has been on staff and contributed to technology-industry publications including BYTE, ComputerWorld, CEO, Enterprise Efficiency, ChannelWeb, Network Computing, InfoWorld, PCWorld, Dark Reading, and on subjects ranging from mobile enterprise computing to enterprise security and wireless networking.

Curtis is the author of thousands of articles, the co-author of five books, and has been a frequent speaker at computer and networking industry conferences across North America and Europe. His most recent books, Cloud Computing: Technologies and Strategies of the Ubiquitous Data Center, and Securing the Cloud: Security Strategies for the Ubiquitous Data Center, with co-author Brian Chee, are published by Taylor and Francis.

When he's not writing, Curtis is a painter, photographer, cook, and multi-instrumentalist musician. He is active in running, amateur radio (KG4GWA), the MakerFX maker space in Orlando, FL, and is a certified Florida Master Naturalist.

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like

More Insights