Archive for March, 2016

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, part II: Tree maps  

Posted at 3:58 pm in Uncategorized

In some earlier posts, I’ve written about bots bruteforcing their way into my Cowrie honeypot, and trying to establish outbound tunnels from there. While regular honeypot activity will often produce interesting logs of intrusion attempts and malware downloads, this kind of monotonous activity is less interesting from an analysis-point-of-view. However, the activity is still interesting and produces nice metrics, and metrics can be graphed and visualized. For a single day’s activity I’m using AfterGlow, which is really nice for smaller volumes of data. For larger volumes, I’ve found tree maps more informative. I tried out a few treemapping tools, but the easiest (and more web friendly) I found was available from Highcharts who provides an impressive range of graphing/visualization javascript libraries.

The tree maps can be constructed to allow you to drill down to every level of detail. For visualizing tunneling activity through the honeypot it’s sufficient with three levels, in increasing order based on the number of occurrences:

  1. The source IP address of the bot (very few)
  2. The destination port (few)
  3. The destination IP address (a lot)

On the top level this gives me a map as shown below. The different colours represent different source IP addresses, and some of the destination ports are shown where there’s room for it. As the yellow part of the tree map shows, there’s a lot of activity from the IP address, with 7121 attempts (so far) to establish outbound TCP connections. The blue part of the map represents another IP address with a higher number of connection attempts, but its activity is less varied than the yellow part. The number of attempts is shown by hovering the mouse over the general areas (not here though, since this is just a screenshot…).

By hovering the mouse over the port numbers, the map shows that of these 7121 attempts, 3763 have targeted port 25 on a lot of destination systems, each system represented by a rectangle within the yellow area. As we can see, this IP address has also attempted to connect to servers on ports 26, 80, 443, 465, 587, 777, 2525, and 25000.


Clicking on the yellow part of the map, we’re drilling down to the activity of each originating IP address. Where there’s room for it, this map shows the target IP addresses, i.e. where the bot has attempted to establish connections. The map now focuses on the yellow area only, i.e. the activity from only one IP address. The map is still divided into rectangles, representing target ports.

At this level, the destination ports are visible when hovering the mouse over the different general areas of the map. The biggest upper left area is towards port 25, lower left is port 587, upper right is port 465, and in the lower right corner we find less frequently attempted ports like 80, 25000, 2525 etc. By hovering over an IP address, the map will show the number of attempted connections against that IP address and port.


As mentioned earlier, all the outbound connections are of course being denied – even though the intruder is given the impression it’s perfectly doable. So if you find your own IP address somewhere in these screenshots, you’re not under attack – at least not via my systems…

Written by bjorn on March 10th, 2016

Threat intelligence: OTX, Bro, SiLK, BIND RPZ, OSSEC  

Posted at 8:15 am in Uncategorized

Building a toolbox around threat intelligence can be done with freely available tools. Shared information about malicious behaviour allows you to detect and sometimes prevent activity from – and to – Internet resources that could compromise your systems’ security.

I’ve already described how to use lists of malicious domain names in a BIND RPZ (Response Policy Zone). Adding an information feed like AlienVault OTX (Open Threat Exchange) to the mix further extends the awareness and detection capabilities.

AlienVault is probably most known for their SIEM (Security Information and Event Management) named Unified Security Management™, with a scaled-down open source version named Open Source Security Information and Event Management (OSSIM). They also provide a platform for sharing threat intelligence, namely Open Threat Exchange (OTX). OTX is based on registered users sharing security information, for instance domains and hostnames involved in phishing scams, IP addresses performing brute force SSH login attempts, etc. The information is divided into so-called pulses, each pulse a set of information items considered part of the same malicious activity. For example, a pulse can contain URLs to a site spreading drive-by malware, the IP addresses of their C&C, along with hashes of the files. By selecting which pulses and/or users to subscribe to, the registered information in each pulse will be available through a feed from their API.

Carefully reviewing which users/pulses to subscribe to – there’s always a risk of false positives – I’m now regularly receiving an updated feed. This feed is parsed and currently split into two files: One RPZ file containing hostnames and domains for use with BIND, and one file containing IP addresses for use with SiLK.

As explained in an earlier post, OSSEC will let me know if someone (or something) makes DNS requests for a domain or hostname registered as malicious. Extending this to include the DNS records obtained from OTX was simply a matter of defining a new RPZ in BIND. Depending on how this is used (block? redirect? alert?), a whitelist should be in place to prevent accidental blocking of known good domains. One pulse describes all the Internet resources a client infected by a certain exploit will contact, including some certificate authorities which are not necessarily considered evil.

The file with IP addresses can be used directly with a firewall, by logging or even blocking or throttling traffic to/from the IP addresses in question. For rear-view mirror analysis it can be used with SiLK, to find out if there has been any network traffic to or from any of these addresses. To do this, you will first have to create an IP set with the command rwsetbuild:

# rwsetbuild /some/path/ip-otx.txt /some/path/ip-otx.set


Now we can use this set file in our queries. For this query I’ve manually selected just a few inbound matches:

# rwfilter --proto=0-255 --start-date=2016/01/01 \
  --sipset=/some/path/ip-otx.set --type=all \
  --pass=stdout | rwcut -f 1-5
            sIP|            dIP|sPort|dPort|pro|||60264|   53| 17|||33091|   80|  6|||63604|  993|  6|||60633|  993|  6|||60888|  993|  6|||32985|  993|  6|||33060|  993|  6|||33089|  993|  6|||33103|  993|  6|||33165|  993|  6|||33185|  993|  6|||33614|  993|  6|||33750|  993|  6|||60330|  993|  6|||60000|   80|  6|||60000|   80|  6|||    0|    0|  1|||43176|   53| 17|||    0|    0|  1|||60000|   80|  6|||60000|   80|  6|


When you need more details about the listed address or other indicators, OTX provides a search form to find the pulse(s) in which the indicator was registered.

OTX can be used with Bro as well, and there are at least two Bro scripts for updating the feeds from the OTX API. The one that works for me is The script will make Bro register activity that matches indicators from an OTX pulse.

Sample log entries, modified for readability: 59541 some.dns.ip    53 - - -
                                            Intel::DOMAIN DNS::IN_REQUEST 40453 80 - - -
                                            Intel::DOMAIN HTTP::IN_HOST_HEADER   47235  80 - - -


This article mentions just a few components that can be combined. Obviously there’s a lot of possibilities for integrating and interfacing between different systems. There are several companies that provide threat intelligence feeds, some for free and some for paying customers. Depending on the product(s), a SIEM would be able to combine and correlate the different kinds of threat intelligence to detected events.

Written by bjorn on March 9th, 2016

Tagged with , , , , , , , , , ,

ClamAV client/server setup  

Posted at 8:37 pm in Uncategorized

Note: This may very well be well-known information, but I found it difficult to get exact answers from the official ClamAV documentation, available man pages, and other kinds of documentation. The most useful hint originated from a mailing list thread considering ClamAV version 0.70, which is getting rather outdated.

My original issue was getting antivirus functionality with mod_security and Apache on a Raspberry Pi server. Due to memory constraints it seems Apache and ClamAV (my version at the time of writing: 0.99) do not coexist happily on the same RPi unit. The obvious solution: Run the ClamAV daemon on a separate device, and set up mod_security with client-side scanning.

The command-line client for antivirus scanning with the ClamAV daemon is named clamdscan. In older Debian releases like Squeeze and Wheezy, clamdscan is included in Debian’s clamav-daemon package, so the daemon will be installed even though you only need the client. This has been fixed in Debian Jessie and above, where clamdscan has become a separate package.

Both the ClamAV daemon (clamd) and the scanner client (clamdscan) have the same configuration file, unless otherwise specified. In Debian this is /etc/clamav/clamd.conf. Getting the client/server relationship configured is a matter of defining the socket on which they communicate. If the client and daemon (server) is running on the same system, the most efficient communication happens over a Unix socket (clamd.conf setting: LocalSocket). On different systems, however, you will need to use the settings TCPAddr and TCPSocket:

TCPAddr defines the IP address (and not TCP address, which would be a port number) on which the server should listen and/or which the client should make contact. Note that the documentation states that TCPAddr is used to define the IP address(es) clamd should listen on, and that it’s by default disabled. However, when setting TCPSocket and leaving TCPAddr unconfigured, clamd will listen on all IP addresses ( The documentation also makes no mention that the setting is used by clamdscan.

TCPSocket is the TCP port on which the communication takes place.

The following diagram illustrates the relationship:


Note: On a Squeeze/Wheezy Debian system, setting TCPAddr to a non-local IP address in clamd.conf will naturally make clamd (clamav-daemon) complain. You should disable clamav-daemon and clamav-freshclam on a client-only system:

# update-rc.d -f clamav-daemon remove
update-rc.d: using dependency based boot sequencing
# update-rc.d -f clamav-freshclam remove
update-rc.d: using dependency based boot sequencing


After configuring as specified above, antivirus functionality should be tested with clamdscan. On the client node:

# clamdscan -v klez.exe 
klez.exe: W32.Elkern.C FOUND
----------- SCAN SUMMARY -----------
Infected files: 1


On the server node, from the ClamAV log:

Sat Mar 5 20:31:59 2016 -> instream(local):
W32.Elkern.C(16bc8fcec023b05b38af3580607bb728:92499) FOUND


Finally, I reconfigured the “” file in mod_security by changing from clamscan to clamdscan.


Written by bjorn on March 5th, 2016

Tagged with , , , , ,