ICS – ZIRCONIC

Time for an update on my constellation of honeypots. As you may recall from my last update, I currently have four Dionaea honeypots running in NYC, Frankfurt, Bangalore and Singapore (the GRAB series) and a single Conpot running in NYC (JUMPSEAT).

grab1

I had a bit of an issue this month that caused me to lose some data from the honeypots. The issue was the same on all the GRAB honeypots, but the circumstances were different and this is what’s interesting to me. I ran out of inodes on all four honeypots. On two of them (NYC and Frankfurt), this is definitely my fault as I never backed up and removed the bistreams stored on both of them, so after almost two months of operation I simply ran out of inodes there. However, on my other two, what was pretty crazy is that I ran out of inodes shortly after bringing them online due to the high volume of traffic on both honeypots. One honeypot ran out of inodes after seven days, and the other after three days due to the sheer volume of attacks. I didn’t think I’d have to check on them that frequently, but looks like we’re doing ok now. Maybe there was some sort of campaign in that part of the world… Here are the stats.

GRAB-NYC03:
Connections: 757,521
Unique IPs: 19,192
Files Downloaded: 12

2ndmonth1

2ndmonth2

Similar results to last time I measured – though keep in mind that I did lose about 10 days of data from this one, so the full results probably would have been much higher. Romania increased its share to about 6% of the total attacks (up from about 0.71% last month).

2ndmonth3

2ndmonth4

A more varied mix of services, while UPnP remains the most popular.
Again, not a shock that the most activity also came through port 1900, the UDP port for UPnP.

2ndmonth5

Actually a new set of top 10 IPs this time, with fewer attacks per IP address than last month (which had one address responsible for about 80,000 attacks). The top IP with 14,057 attacks leads back to AWS. The next one, 45.32.222.158, leads to Choopa, LLC, a managed hosting company in Matawan, NJ. According to their Google reviews, they are known for hosting malicious actors. Good to keep in mind in case I ever need a “permissive” host someday. Number 4 on the list, 94.236.95.171, is odd because it originates at Beggars Group, Ltd, a group of record labels. Numbers 5 and 6 originate in Beijing.

Here’s a map showing the attacker locations:
2ndmonth6

2ndmonth7

Next is the Frankfurt honeypot:

GRAB-FRA01:
Connections: 745,068
Unique IPs: 13,803
Files Downloaded: 13

Again, results more or less in line with last month, keeping in mind the loss of 10 days of data. More unique IPs this time, many fewer files downloaded.

2ndmonth8

2ndmonth9

Similar to the results from the NYC honeypot.

2ndmonth10

The huge number of UPnP connections looks more like the prior month’s results (compared with NYC’s results).

2ndmonth11

Therefore, no shock here when looking at ports.

2ndmonth12

Like NYC, a new set of characters this time around. Nearly 110,000 attacks from 54.211.52.121, which leads back to AWS. In number 3, 94.236.95.171, we again see that Beggars Group, Ltd entity. Numbers 4 and 5 lead back to Beijing.

Here’s another map of the attackers, with an alternate view of the same data as well:

2ndmonth13

2ndmonth14

Now for the new honeypots!

GRAB-SIN01:
Connections: 154,834
Unique IPs: 17,750
Files Downloaded: 2,003

That’s not a mistake – I really did get just over 2,000 files collected in the Singapore honeypot. Almost all of them were Conficker variants. Out of all the unique binaries, I only found one Pepex variant and a Poebot variant, then 137 different Conficker binaries. I haven’t found Conficker in any of my other honeypots so far. Really unbelievable how many files I captured in such a small attack surface (compared with my other honeypots).

2ndmonth15 2ndmonth16

Interesting split – this makes me think that there is some sort of regional difference here, at least compared with my other honeypots. We see China higher up and also Vietnam, which so far I haven’t seen in the top 10 anywhere else.

2ndmonth17

A bit more diversity in these services, closer to what NYC looked like vs. Frankfurt.

2ndmonth18

2ndmonth19
This time, Beggars Group is the top IP address messing around with my Singapore honeypot. Coming in at number 3 is 208.78.164.135, at Valve Corporation. Number 6, 188.165.192.91, leads to OVH in France. Number 9, 54.166.233.236, shows up as AWS. The final one there, 93.174.93.136, leads to Quasi Networks, based in Seychelles. Their barely functioning website advises that they are building sites in Amsterdam, Stockholm, Frankfurt, Moscow and London and that their website will be online soon. I guess they already have the hosting up and running… Another one to keep in mind in case I need a permissive host. Interesting that this hub didn’t see any Chinese addresses in the top 10.

2ndmonth21 2ndmonth20

Bangalore:

GRAB-BAN01:
Connections: 72,685
Unique IPs: 19,299
Files Downloaded: 1

Dismal number of files collected from Bangalore. Interesting that this honeypot has the highest number of unique IPs of all the GRAB honeypots. Also interesting that this honeypot has the highest diversity of connections (the top is “Other” which encompasses individual countries that were too small to fit on the top 10 on their own, followed by China and the USA).

2ndmonth22 2ndmonth23

Nothing too out of the ordinary in terms of services and ports:

2ndmonth28 2ndmonth27 2ndmonth24

Beggars Group, Ltd, is number 1 again, at 94.236.95.171. Numbers 2 and 3 are in Beijing, number 4 is Valve Corporation again. We saw OVH again, in 8^th place, at 188.165.192.91. Otherwise, nothing too new or interesting here.

Some maps:

2ndmonth25 2ndmonth26

With JUMPSEAT, I’m running a Conpot honeypot, and I don’t have as many options as far as reporting as I do with the Dionaea honeypots. I took the raw logs and did some work with them in LibreOffice. Here are some numbers regarding the total numbers of connections that I had:

2ndmonth29

Modbus was the most popular protocol, followed by all variants of HTTP. There were a few other things scattered around in there. Looking at attacks by IP address, things get more interesting:

2ndmonth30

71.6.167.142 leads to a hosting company called CariNet out in San Diego, CA. This person scanned just about every port on JUMPSEAT. The other addresses were definitely more typical of the activity I got on this honeypot, as you can see from the numbers. 113.240.250.156 and 106.38.241.111 lead to Beijing. 91.196.50.33 and 185.25.148.240 lead back to a hosting company in Poland. 67.87.198.46 actually leads to Optimum Online in NY – is someone scanning these from home?

When I ran 71.6.167.142 through robtex.com, it actually appears that this is shodan.io. The way it scanned the honeypot makes sense now.

That’s it for this month.

Continuing on the subject of honeypots, I wanted to see if I could get something set up as an ICS/SCADA honeypot. I’ve noticed traffic on some of the GRAB series honeypots that could be Modbus connections, for instance. I’m also pretty interested in ICS/SCADA in general, so I looked into whatever I could find regarding honeypots that I might be able to set up myself. In the end I set up a single Conpot honeypot, and I thought I’d share my notes in case it helped save someone some time.

I identified several potential honeypots to try:
– Digital Bond’s SCADA Honeynet
– Cisco CIAG’s SCADA Honeynet
– Fieldbus Honeypot
– SHaPe honeypot
– Conpot

Ultimately, Conpot was the only one I got to work. Here are my notes on everything:

Digital Bond’s SCADA Honeynet
This sounded like it would be the most robust and realistic of all the honeypots that I could find, but I ran into issues during installation. First, the documentation and system is from 2006, so a lot of the instructions are really out of date (for instance, one document referred to installation on an Ubuntu 6.x system). I ran into a few issues while installing dependencies, but I was able to get past those — specifically, instead of xlibs-dev, install libx11-dev, and automake1.11 instead of automake1.9. The real issues came when I tried to install VMware server. This used to be freely available, but isn’t really available anymore from VMware (I’ll explain what I mean by this). The installation instructions from Digital Bond specifies a link to download an old version of VMware server for Linux (1.0.2) and this link still works, however with my current version of Ubuntu (16.04) I ran into too many issues with the installation and just gave up on it.

Cisco CIAG’s SCADA Honeypot
This system requires Scientific Linux 3 and a formatted, empty floppy disk. Next…

Fieldbus Honeynet
This system came up during searches for these types of honeypots. The info sheet indicates that it handles Modbus and also lists some contact info for creators, however trying to reach out to them resulted in bounced email. Not sure if this is publicly available, and searching didn’t turn up any other email addresses to use to contact them. The overall project page can be found here.

SHaPe Honeypot
I found this one through an interesting academic paper about electric power substation honeypots. They have the source up here. I liked the idea that this would be a module for Dionaea, which meant that I could either add this module to an existing honeypot, or quickly set up a new honeypot running Dionaea (which is very easy) and just use it to run this module. I ultimately ran into various issues during setup, and at this point I was pretty burned out and not interested in pursuing this anymore. If you have more luck, please let me know and maybe I’ll give it another try if you can send me some ideas on what to try.

Conpot
This was the first such honeypot I had heard of, and ended up being the one I installed. They have a great website for the honeypot, and installation was pretty easy. Instructions were sparse but clear. I installed from the git repository, not using pip. I did have issues during installation, but nothing out of the ordinary. One issue was that I needed to install libmysqlclient-dev (apt-get install libmysqlclient-dev), no big deal. The other issue I had, though, appears to be a known issue but again the fix was pretty simple. Basically, I had to downgrade stix and cybox to lower versions and then I was fine:

sudo pip install 'stix>=1.1.1.5,<1.2.0.1'

sudo pip install "cybox==2.1.0.12"

I copied both of those right out of the issue logged on the github page and then I was no longer getting errors. To keep Conpot running in the background after logging out, I used setsid in case you’re wondering how to do that. Finally, to test the honeypot, I went ahead and tried connecting to it:

2016-08-03 15:42:07,581 New Modbus connection from x.x.x.x:38816. (x-x-x-x-x)
2016-08-03 15:54:31,643 New Modbus connection from x.x.x.x:38828. (x-x-x-x-x)

Seems to be working (the xs are in place of my connection info).

I found a great article by Darren Martyn over at xrl about OPSEC for honeypots. There’s a lot of great points there, but overall — DON’T leave the default Conpot settings in place when you run your honeypot. Go to the /conpot/templates/default directory (or the directory for whatever template you are using) and look in the .xml file for that template. Here is my default Conpot template before editing:

jumpseat1

You should see the issues right away. Darren’s post highlights some of these, but to recreate his quick check on this, I did a search on shodan.io and look what I found:

jumpseat2

Don’t be these people. Change your default settings. I found dozens of these honeypots all over the world this way. One note — you might go to change the template settings in the /opt/conpot/templates directory. Per this post, go to /usr/local/lib/python2.7/dist-packages/Conpot-0.5.1-py2.7.egg/conpot/templates [you may have a different version number than I do] and change your templates there. You can test it quickly to be sure by just pulling up your site in your web browser.

Digital Ocean is not great as a host for this type of honeypot because it’ll show up as such in a search — putting it another way, why would an ICS/SCADA system be on a Digital Ocean VPS, or AWS, or GoDaddy.com? Doesn’t really make sense, but for now that’s what I have so I went with another droplet there. Ideally I’d put this new honeypot somewhere that it might actually make sense to have such a system, but I don’t have access to any such facility. I did, however, look around the area and do a little research on some ICS/SCADA sites, and entered values that should be plausible enough to collect some attacks in the honeypot. I’m not going to post any of that info here as that would potentially ruin the honeypot I set up, but what I’d say is look around the area where your honeypot is hosted and try to create a plausible “identity” for your system. Try to also pick a system that 1) uses Modbus and 2) might actually be in use at your choice of cover story. We’ll see how successful I was at setting this up, and hopefully at some point soon I’ll have some interesting info to share about this new system.

I’ve decided to place ICS/SCADA honeypots under the series JUMPSEAT.

Tag: ICS

August Honeypot Statistics

JUMPSEAT