My Honeypot Wrote Down Every Word the Bots Typed

Summary

Steve from Bru-Cru Studios examines what automated visitors typed into an internet-facing honeypot—a fake server designed to imitate devices and record activity. Unlike his previous video, which focused on port scans, this one covers the payloads: the commands and requests bots made after reaching the simulated services. Steve and Jarvis review several examples from the logs.

Notable honeypot encounters

• Fuel-tank gauge: Three visitors connected to the fake gas-station tank gauge but did not issue commands. Steve says the activity is notable because government agencies have warned that exposed real-world tank gauges can be altered—for example, to conceal fuel levels or disable alarms. He also cites earlier research in which visitors changed settings on similar bait devices.
• Factory controller: Five visitors queried a simulated Siemens Simatic S7-300 industrial controller but did not send commands. Steve puts this in context with Stuxnet, which targeted Siemens controllers, and Industroyer, which used the IEC 104 protocol. Some scanners were identified as legitimate security organizations mapping exposed devices rather than attackers. Steve says he checks flagged IP addresses against multiple threat-intelligence sources to distinguish benign scanners from malicious activity.
• Smart electricity meter: A visitor used web encryption when connecting to a simulated Kamstrup meter—a mismatch that suggested broad, automated scanning. Steve discusses risks to real meters, including tampering for financial gain and research demonstrating that some models could potentially be used to cut power.
• Fake router login: Visitors tried passwords associated with Mirai-era default-password attacks. After getting into the simulated interface, they repeatedly tried commands to reach a shell, but the honeypot returned “Command not found.” They also placed files in writable locations and prompted the device to return code, which Steve interprets as a possible check to determine whether the device is worth targeting further.
• Other probes: The logs included an Nmap-related request for a file named niceportstrinity.txt.back, a visitor using the greeting “Fox hello” associated with building-control systems, attempts to use the server as a relay, requests to list Docker containers, and a request matching a known Hikvision camera vulnerability. One visitor repeatedly tried common file names such as backup, password, and .htpassword.
• Rotating identities: Steve describes activity across ten IP addresses and ports, with different operating-system identities and intervals of roughly 20 minutes. He suspects the activity may be one operation rotating addresses to make its scanning less obvious.

Main analysis and advice

The visitors generally were not targeting Steve personally. Automated bots scan the broader internet, test exposed services, and may record responsive devices for later activity. Steve recommends:

1. Change factory-default passwords on anything with a login.
2. Avoid exposing internet-connected systems that control physical equipment—such as tanks, machinery, or building systems—to the open internet.
3. Assume that any device with a public IP address has already been scanned.

The video is an analysis of honeypot logs, not a product review or step-by-step technical tutorial. It references a previous honeypot video for more detail about the simulated router service.

Main speakers and sources

• Steve Wer (Bru-Cru Studios): Narrator and analyst who reviews the honeypot findings with Jarvis.
• Jarvis: Helps review the logs.
• Organizations and research cited: CISA, FBI, NSA, Trend Micro, Shadowserver Foundation, Palo Alto Networks, and researchers studying smart meters. Steve also references The New York Times reporting on Stuxnet.