Kippo Hiccups

Good evening folks

I thought I’d share a little something about Kippo that I didn’t know until this evening.

I’ve been tinkering with the Kippo log files in an attempt to write some code to parse out useful information. The long term goal is to be able to parse multiple log files from multiple servers and have it all dump to a database to make attack tracking and correlation a little easier. But that’s a story for another evening.

For tracking new connections to the ‘pots I’ve been using what I believe to be a unique session identifier which should be unique through the log files. It looks a little something like this:

2012-01-01 22:56:13+0200 [kippo.core.honeypot.HoneyPotSSHFactory] New connection: $ATTACKER:42702 ($ADDRESS:$PORT) [session: 32666]

The “session: 32666″ is what I’ve been using to pull all the goodies from the log file.

The problem comes in when I combine multiple log files into one big log file for easier parsing (as per my previous post here). It seems that if you restart the Kippo server (huge assumption here) it will recycle old session identifiers. When doing a little script debugging I found that session X had been “repeated” across multiple log files. Not really an issue if you work with the individual Kippo log files, a big of a pain in the butt if you do what I do and combine multiple log files into one big file :)

It’s no biggie really, it just means I’ll need to do a little error checking in my code (somehow) or work with the individual log files (which could be a little more time consuming).

I just thought I’d share this in case anyone else is doing something similar to me.

If I’m horribly mistaken, please feel free to get in touch.



Quick and dirty Kippo log parsing

To be fair I haven’t really looked into this too much so I’m sure there may be better solutions out there. Here’s a couple of quick one liners to parse out some useful information from Kippo logs. What’s frustrating me is there doesn’t seem to be a “standard” formatting to the log file so it’s proving a little difficult to parse.

Anyway…here’s the good stuff :)

First of all, I pulled all my logs into a master log file “masterlog”.


Pull hosts from the log file:

This will check the master log file for all the unique IP connections connecting to the server before they started their brute force attacks. I’ll use the ipcons.txt file in the next scripts.

grep -e “New connection” masterlog.log| awk -F” ” ‘{ print $6 }’ | awk -F”:” ‘{ print $1 }’  | sort | uniq >> ipcons.txt


Pull username attempts per host:

This will pull out a list of all the usernames used in attacks against the server.

for x in `cat ipcons.txt ` ; do echo $x >> users.txt ; grep -e “$x” masterlog.log| grep -e “login attempt” | awk -F”[" '{ print $3 }' | awk -F"/" '{ print $1 }' | sort | uniq >> users.txt ; echo " " >> users.txt ; done


Pull passwords per host:

This will pull out a list of all the passwords used against the server for each connection.

for x in `cat ipcons.txt ` ; do echo $x >> passwords.txt ; grep -e "$x" masterlog.log | grep -e "login attempt" | awk -F"[" '{ print $3 }' | awk -F"/" '{ print $2 }' | awk -F"]” ‘{ print $1 }’ | sort | uniq >> passwords.txt ; echo ” ” >> passwords.txt ; done


Ok, so it’s not the cleanest, most efficient way of doing things, but until such time as I can finish up writing the log parser I’ve been “working” on for ages it’ll have to do. If anyone has comments or suggestions please feel free to get in touch.




SSH Brute Forcing / ihatehackers

There was an interesting post on ISC from Tom Liston this morning following a tweet yesterday. We took a quick look through our servers and saw much the same thing.

What we saw was  a single connection from an IP address in an attempt to brute force the root account with the password “ihatehackers”.

The details

We started seeing connections on November 3rd at around 21:10:17. The last connection was on November 5th at 15:15:34.

Over those three days we had 12 unique IP addresses connecting.

The connections per day were as follows:

November 3rd: 4 connections (3 unique IPs)

November 4th: 23 connections (8 unique IPs)

November 5th: 19 connections (5 unique IPs)

The geolocation breakdown:

Republic of Korea – 1

China – 3

Italy – 2

United States – 2

France – 1

Brazil – 1

Canada – 1

Poland – 1

As you can see most of the IP connections were a simple connect/attempt/disconnect. The only IP that connected more than once was (CN) which connected 4 times over the space of two days. A close second was a tie between (BR) and (US).

The actual connection was done using a binary compiled with SSH-2.0-libssh2_1.2.8.

Strange that we haven’t seen anything else since.

Have you seen something similar ? Get in touch, especially if you have some kippo/kojoney logs to share.

If you’d like the Maltego OSINT report, it’s available here.


GlastopfNG Report

Before you go thinking we’ve dropped off the map completely I thought I’d put something up on some of the interesting scans I’ve been seeing on my GlastopfNG pot. It’s running on some fairly busy IP space within a large ISP’s IP space inside South Africa.

If you’re interested, you can find out more about GlastopfNG here.


w00t !

These scans are getting a little more common. The first time I saw them was when I was working for a small(ish) design firm in Durban. The scan logs look a little something like this:


which a simple Google will tell you is just a fairly “rare” scanner which leaves that footprint. More interesting is this post from the ISC. More recently I’ve been seeing a lot of these kinds of scans which I assume is a similar tool with a couple of small changes :)



As for the IP to geo-location break down, here is it:



PHP Badness

As you would expect there are still a significant amount of scans going on for the various PHP frameworks and their vulnerabilities. Most popular is still PHPMyAdmin. The guys are usually looking for something along these lines:






Although we did have a scan from Korea that checked for ALL available versions of PHPMyAdmin. Clearly low and slow was not something they’d heard of.

Also interesting was a few requests within a fairly large time frame for a simple RFI check on a server in Argentina. The request looks like this:



Here’s what the PHP badness map looks like:




Overall ?

Overall there were some fairly interesting calls to our “web server” but nothing you wouldn’t really expect. And the usual players are all there: United States, Russia, China. Japan was strangely the second highest offender in our list.

This is what the heat map looks like for all connections:



That about covers it for the web stuff.



Connection Maps

Good evening all

I thought I’d put together a little “heat” map of connections by country. This is taken from the logs on one of our servers in South Africa.

SMBD connections (Port 445)

Most of these connections are conficker. Interesting that South Africa features very little.



Sip connections (Port 5060)

Of all the SIP connections to our machine, all of them were using sipvicious. A great little tool.




Web Connections (Port 80)

Port 80 has been fairly busy as well. Lots of scans for PHPMyAdmin amongst others.


MSSQL Connections (Port 1443)

Good to see that SQL Slammer is on the decrease.





SSH Connections (Port 22)

SSH has been fairly quiet. We’ve only really had a couple of proper connections. Most of the others are just a scan and move on.


It’s been a very interesting first week in the trenches.



Breakdown / 16-03/2011

We’ve been up and running for a while now and have seen some very interesting traffic. I thought I’d spend a little time summarizing the traffic we’ve seen. Silly me forgot the clear the database so there are a couple “attacks” that shouldn’t be there. Never the less the information is still interesting. In total we’ve seen around 1600 attacks in the last 24 hours.


Other than the 900+ attempts from Conficker infected hosts we’ve seen 11 other submissions from 4 unique sources which gave us 3 unique samples. The most popular submission was aada169a1cbd822e1402991e6a9c9238 with 6 of the 11 submissions. Next up with 4 submissions was b8076e37aef1105d045fc39f780da5a2

Port Preferences

Port 445 was by far the most popular attack vector with 969 attacks recorded. Next up was port 80. Strangely, port 80 wasn’t seeing anything too interesting, mostly generic scans. Interestingly there were even some SIP scans from attackers using the sipvicious tool.

Busy Times

Being in Africa it seems the busy hours aren’t quite in line with our “off peak hours”. Most of the attacks occurred from 13h00 to 16h00. After 19h00 it seems to quiet off until the next day. Very rarely do the attacks reach triple figures during these quiet times. This does seem to fall in line with where the attacks are coming from.

That’s about it for now. I’ll be posting some interesting information around SSH in the near future so stay tuned.


[Repost] Official Honeynet Chapter

*** Update: Just migrating our old content over from the old blog ***

*** New content coming soon I swear ***


It’s with great pleasure and more than a little chest puffing that I can announce we’re now an official chapter of the HoneyNet Project. Barry and myself will be running various HoneyNet projects within the South African IP space.

We are currently setting up our own domain name and hosting. This should be completed within the next couple of weeks.

To anyone interested in getting involved within South Africa, please feel free to get in touch.

And I’d also like to extend my greatest thanks to everyone involved in getting us on board. You know who you all are.




Welcome to our new home in cyberspace. We’re still busy migrating the various bits and pieces but please go ahead and bookmark this page.

A huge thank you to everyone involved in getting us our new home.

South African HoneyNet Chapter