The last time Hackerfall tried to access this page, it returned a not found error. A cached version of the page is below, or click here to continue anyway

Xiphos Research Labs | Information Security

OPSEC for Honeypots

Posted by: Darren Martyn | Posted on: 2015-12-09 00:00:00 +0000

So, like many security companies, we at Xiphos run a fair few honeypots in order to have a look at what is going on out there on the scary internet. I, myself, also have ran honeypots of my own for a good while, mostly so I can laugh at script kiddies flailing around inside Kippo and the likes. In this post, I am going to point out some glaring OPSEC fails that I have seen in the wild recently with regard to running honeypots, and then suggest why OPSEC is kind of important when running honeypots, using ICS/SCADA ones as a nice example.

Recently, I became aware of a nice tool called ConPot, a honeypot for emulating ICS (Industrial Control Systems) to see what the evil SCADA hackers out there are playing at. One of the first things I noticed while reviewing the code, was that it had some pretty glaringly obvious default-information available that allowed trivially identifying it as a honeypot. Take a look, if you will, at the default information displayed when you send it some S7 requests

Location designation of a module: Copyright: Original Siemens Equipment Module type: IM151-8 PN/DP CPU PLC name: Technodrome Plant identification: Mouser Factory OEM ID of a module: Module name: Siemens, SIMATIC, S7-200 Serial number of module: 88111222

Pretty much all of those fields are static. Most noticeably, the Serial Number field, which when queried in Shodan shows 104 honeypots at time of checking. Now, if we query again for the Module Name field, we get a mixed bag of both real, and honeypot, ICS systems. If we diff the two, we can filter out all the most obvious honeypots in one go, leaving us with real, live ICS systems. Doing some googling around, a good deal of these are probably legitimate systems. Now, given it took us only a couple of minutes to filter out all the chaff based on a quick look at the existing honeypot code out there, we can safely assume that actual, malicious actors can do the same

Well, what I found immediately suspicious when Shodanning for the honeypot fingerprint was that basically all of them were on cloud hosting providers, which is probably the last place I would expect a real PLC to live (caveat: someone probably has virtualized some PLC crap in the cloud, because people are stupid like that). Hold on though! We can filter out some more!

Buggy honeypot code - now you are definately gonna have a bad time. Check out this honeypot which has failed, or, well, any of these ones which are displaying a bit of an error message, as can be seen in the screenshot below

Even worse, some of these systems are blatantly advertising themselves as honeypots to the entire internet. Quickly looking for relationships between hosts here, we can quickly identify entire ranges of honeypots to ignore or laugh at. Further to this, as attackers, we can determine that, for example, Someone in Poland really likes ICS honeypots. Admittedly, these took me a few more minutes to identify as some looked slightly more legitimate than others. However, as can be seen below, a quick look at just one of them made me cast the entire range into doubt A honeypot is not much good if it says HoneyTrap in the banner!

I could go on, finding more honeypot fingerprints and whittling down our collection of hosts to the real ICS systems out there, but as-is, we have identified a whole bunch of these ICS honeypots in a short amount of time, and even identified entire ranges to avoid as honeypots, due to bad defaults, bad OPSEC, and generally a need on the behalf of these so-called defenders to try a hell of a lot harder.

For interest, a sample of the honeypot fingerprints gathered is below. Note the last one in the list - this is the honeypot actually failing and instead printing an error instead of the random number it was meant to generate.

Serial number of module: 88111222 Plant identification: Mouser Factory PLC name: Technodrome PLC name: Czajka-STUOS Serial number of module: 6ES7 216-2AD23-0XB0 Plant identification: MPWiK-ZOS-Czajka Serial number of module: 8675309 Plant identification: Power Generation One PLC name: PG[random.randint(0,1) f

Also note the serial numbers in the above sample of fingerprints. Usually, a manufacturer sticks with one serial numbering system instead of having numerous serial numbering systems for one product-line. If you are going to display a serial number, have it not only be randomly generated (as opposed to hardcoded) on initialization of the honeypot software, but also have it conform to whatever the spec is for the product you are masquerading as.

Anyway, why all this is important, is because threat intelligence, and signal to noise ratios.

If you are attempting to gather intelligence on attacker behaviour using honeypots, you will only get good information if your attackers do not know that they are attacking a honeypot. When an attacker figures out it is a honeypot, they might just get out, or they might change their patterns to feed you noise deliberately. Given that the threat model for ICS attackers is supposedly skilled intruders doing nasty things to critical national infrastructure, and OMGZ!!1! CYBERWARZ!, you can rest assured that your attacker probably has enough of a clue to avoid the glaringly obvious honeypots you are using.

What this means, is that the only attackers you are actually gathering threat intelligence on, are idiots. The script kiddies. Low hanging fruit who most likely wont be doing anything interesting anyway to your boxes if they do get in (besides accidentally hose them trying to install dogecoin miners on them, or use them for DDoS). You will gather precisely no valuable intelligence whatsoever on any attacker that is remotely relavent to your interests. All the intel you do get, is useless noise and chaff, which simply makes seeing the important stuff going on out there a hell of a lot harder. If all you are gathering is chaff

Our apologies to anyone whose ICS honeypots are now rendered useless thanks to this bit of researching, however, you really should try a lot harder.

About the Author

Darren Martyn is an Irish ex-pat, presently employed by Xiphos Research to break things and research how to break things, and has yet to learn the refined skill of referring to himself in the third person (like the queen).

Continue reading on