Archive

Archive for the ‘Tool-Kit’ Category

Mercury – Live Honeypot DVD

<UPDATE>Live download mirror: carnivore.it</UPDATE>

Mercury Live DVD was initially (I believe) announced in a post to the Nepenthes Mailing list. It is a remastered Ubuntu distribution with pre-installed honeypot applications and malware analysis tools created by John Moore. From the ReadMe:

This live DVD is a remastered version of Ubuntu 10.0 Beta LTS x86_32. It was designed due to my being disappointed with another reverse engineering malware live CD that was released recently. I have decided to call my creation MERCURY, which is an acronym for Malware Enumeration, Capture, and Reverse Engineering.

The Mercury live DVD contains tools used for digital forensics, data recovery, network monitoring, and spoofing. It should primarily be used as a honeypot or network monitoring platform as well as a laboratory and teaching aid. There are three honeypots installed – honeyd, nepenthes, and dionaea. Four, if you include netcat.

The majority of the additional applications reside in /opt:

  • Dionaea (0.1.0) – Dionaea is a malware collection honeypot focusing primarily on SMB emulation, covered on InfoSanity numerous times before.
  • FFP – Fuzzy Fingerprinting is a util to aid SSH MitM attacks.
  • jsunpack-n – Is a Javascript unpacker, perfect for analysis captured or potentially malicious URLs in more depth.
  • Kippo (svn rev.169) – Kippo is an low-medium interaction SSH honeypot, Also covered
  • mitm-ssh – Unsurprisingly, a utility for aiding man in the middle attacks against SSH connections.
  • Origami & pdftools – Two frameworks for analysing malicious PDF files.
  • Volatility – an excellent memory analysis toolkit
  • Zerowine-vm – A malware behavior analysis platform. I’ve covered ZeroWine here before, and whilst I find it useful for initial analysis I found it a pain to setup and get running. The fact this works out of the box on Mercury is enough reason alone to keep the .iso handy.

Other tools are installed on the system as started, access from standard locations (/etc, /usr/bin, etc.). I won’t try to list them all, but some highlights include:

  • Nepenthes – Dionaea’s predecessor
  • Honeyd – Honeypot system, perfect for emulating multiple different systems from one platform. Covered in more depth here.
  • John – John the Ripper, password cracker
  • ircd-hybrid – irc server daemon, useful for analysis irc-based malware’s interaction with command and control systems.
  • Snort – de-facto intrusion detection system.
  • Wireshark – Packet capture and network analysis tools.

I could go on, but I’m sure you get the idea.

Setting up a honeypot, and analysing the results, has never been easier. And I’m sure the toolkit’s functionality will also be useful in other scenarios; incident response, general network administration or as a safe learning platform. So what are you waiting for?

–Andrew Waite

N.B. there have been several mirror’s and downloads established, the most reliable download source I’ve used is Markus’ mirror at carnivore.it

Advertisements

Kippo SVN build

This morning I cause myself a problem. Annoyingly it was foreseeable and avoidable, this is my excuse (not great, but I’ll stick to it). But as every problem is merely an opportunity in disguise whist I’m re-building systems I might as well document the process. The original InfoSanity guide for installing Kippo was based off of the latest stable version, but I rapidly migrated to the development SVN on learning of the MySQL logging capabilities, so this guide covers that.

Packages

As I’m using a Debian system a lot of the system pre-requisites are packaged, this aren’t all needed immediately but we might as well grab them all at once.

apt-get install subversion #for svn
apt-get install python-twisted python-mysqldb # Python and required modules
apt-get install mysql-server #

Basic Kippo setup

Grab Kippo direct from svn, at time of writing I got version 160. (latest instructions):

svn checkout http://kippo.googlecode.com/svn/trunk/ /opt/kippo-svn

Now we can start the honeypot system:

./start.sh

That’s it, all that is required to get the system running. To confirm you can ssh locally with ssh -p2222 root@127.0.0.1, unless you’ve jumped ahead and edited the config, password will be 123456.

MySQL

Log into MySQL via commanline, assuming you’ve not modified the kippo.cfg database directives build the database:

create database kippo;
grant all on kippo.* to ‘kippo’@’localhost’ identified by ‘secret’;

Next edit the kippo.cfg accordingly you database/user/password and uncomment the [database] configuration directives. REMEBER to uncomment ;[database] line not just the parameters, that has now caught me out twice.

Finally, build the database structure with the script that can be found in <kippo>/doc/sql/:

doc/sql/# mysql -ukippo -psecret kippo < mysql.sql

Restart your Kippo process and you should be good; re-test access to the shell and view the database tables to confirm that logs are being written to the database.

Happy Honeypotting

–Andrew Waite

    Categories: Honeypot, Kippo, Tool-Kit

    mimic-nepstats_v1-1.py

    I’ve been a bit lax in writing this post; around a month ago Miguel Jacq got in contact to let me know about a couple of errors he encountered when running InfoSanity’s mimic-nepstats.py with a small data set. Basically if your log file did not include any submissions, or was for a period shorter than 24hours the script would crash out, not the biggest problem as most will be working with larger data sets but annoying non the less.

    Not only did Miguel let me know about the issues, he was also gracious enough to provide a fix, the updated script can be found here. An example of the script in action is below:

    cat /opt/dionaea/var/log/dionaea.log| python mimic-nepstats_v1-1.py

    Statistics engine written by Andrew Waite – http://www.infosanity.co.uk

    Number of submissions: 84
    Number of unique samples: 39
    Number of unique source IPs: 65

    First sample seen: 2010-06-08 08:25:39.569003
    Last sample seen: 2010-06-21 15:24:37.105594
    System Uptime: 13 days, 6:58:57.536591
    Average daily submissions: 6

    Most recent submissions:
    2010-06-21 15:24:37.105594, 113.37.56.28, emulate://, 56b8047f0f50238b62fa386ef109174e
    2010-06-21 15:18:08.347568, 195.205.5.71, tftp://195.205.5.71/ssms.exe, fd28c5e1c38caa35bf5e1987e6167f4c
    2010-06-21 15:17:08.391267, 195.117.74.62, tftp://195.117.74.62/ssms.exe, bb39f29fad85db12d9cf7195da0e1bfe
    2010-06-21 06:29:03.565988, 195.160.222.101, tftp://195.160.222.101/ssms.exe, fd28c5e1c38caa35bf5e1987e6167f4c
    2010-06-20 23:34:15.967299, 195.242.145.40, http://208.53.183.164/trying.exe, 094e2eae3644691711771699f4947536

    — Andrew Waite

    Amun statistics

    Amun has been running away quite happily in my lab since initial install. From a statistic perspective my wor has been made really easy as Miguel Cabrerizo has previously taken one of the InfoSanity statistic scripts written for Nepenthes and Dionaea and adapted it to parse Amun’s submission.log files.

    Results generated from the script in my environment are below, if you’re wanting to get an overview of submissions from another Amun sensor the script has been uploaded alongside the other InfoSanity resources and is available here.

    ~$ cat /opt/amun/logs/submissions.log* | ./amun_submission_stats.py

    Statistics engine written by Andrew Waite (www.infosanity.co.uk) modified by Miguel Cabrerizo (diatel.wordpress.com)

    Number of submissions      : 25
    Number of unique samples   : 25
    Number of unique source IPs: 18

    Origin of the malware:
    Ukraine :     1
    None :     7
    Poland :     2
    Romania :     1
    United States :     8
    Russian Federation :     2
    Hungary :     1
    Norway :     1
    Bulgaria :     2

    Vulnerabilities exploited:
    MS08067 :    13
    DCOM :    12

    Most recent submissions:
    2010-05-31, 11:37:22, 208.53.183.164, 63.exe, acf5c09d547417fe53c163ec09199cab, MS08067
    2010-05-30, 19:23:09, 208.53.183.162, 63.exe, 89b578839f1c39f79d48e5f9e70b5e2f, MS08067
    2010-05-28, 10:27:03, 208.53.183.162, 63.exe, f7c4f677218070ab52d422b3c018a4ba, MS08067
    2010-05-27, 16:23:14, 195.34.117.180, ssms.exe, 1f8a826b2ae94daa78f6542ad4ef173b, DCOM
    2010-05-24, 19:46:35, 208.53.183.163, 63.exe, 53979f1820886f089a75689ed15ecf6e, MS08067

    A comment on a recent post asked for a comparison between different honeypots, while this is far from conclusive and only focuses on a single aspect of the technologies one of InfoSanity’s Nepenthes sensors ‘saw’ more attacks in the last 24hrs than my Amun installation did in the almost three weeks shown above. As both are running within the same, small, IP allocation I think I’m safe in assuming that one IP isn’t actually receiving a disproportionate level of interest from the badguys and bots that are out there.

    — Andrew Waite

    Starting with Amun

    No single technology can do or handle every situation; the same holds true with honeypot sensors which is why I’m always interested in finding new systems to add to my environment. I’d had Amun on my list of potentials for a while, but after reading a short blog post by Miguel Cabrerizo that suggested install and setup was relatively quick and painless, it got moved up the to-do list.

    As suggested the install was quick and easy, with no real problems. Since being installed the system has done what it says on the tin, emulating vulnerabilities and logging interaction with attacking sources. The sensor has been active for around 5 days and has collected 14 unique malware samples to date. Whilst not immediately being indicative of any comparison, three of these samples have not also been ensnared by Nepenthes or Dionaea sensors running within the same IP space.

    The Amun log directory shows some interesting information, with logging being split between several different files. From initial results there is some interesting information collected by the system. One aspect of the logging that I’m unsure if I like is that Amun rotates it’s log files on a daily basis, so far this is resulting in my log directory getting cluttered with rotated files. For the curious available log files are:

    • amun_request_handler.log
    • amun_server.log
    • download.log
    • exploits.log
    • logging.log
    • shellcode_manager.log
    • shellemulator.log
    • submissions.log
    • successfull_downloads.log
    • unknown_downloads.log
    • vulnerabilities.log

    Going forward there are a number of installation and configurations options available from Amun that I intend to experiment with; high up this list is the ability to log to a MySQL database, I’m hoping that this will provide both a convenient and powerful way to search and analyse the information collected by the sensor. In the meantime Miguel has extended one of InfoSanity’s submission_stats to gather similar statistics from Amun sensors, Miguel’s work is available here.

    — Andrew Waite

    amun01:/opt/amun# ls -l malware/md5sum/
    total 2512
    -rw-r–r– 1 root root 155648 2010-05-13 10:53 0cc3c16497214997a9aca72e387c9d9b.bin
    -rw-r–r– 1 root root 444416 2010-05-12 15:43 146d61fca77d748f5a5ecff53afd30e4.bin
    -rw-r–r– 1 root root 158720 2010-05-11 07:43 14a09a48ad23fe0ea5a180bee8cb750a.bin
    -rw-r–r– 1 root root 159744 2010-05-11 00:29 1d419d615dbe5a238bbaa569b3829a23.bin
    -rw-r–r– 1 root root 153600 2010-05-15 13:41 53098aa3e420a1be0a5e6a992dc30f3b.bin
    -rw-r–r– 1 root root 176128 2010-05-10 23:35 5a951d625eb10b900eb7001892edfa77.bin
    -rw-r–r– 1 root root 159744 2010-05-13 19:16 6366b14ed66bf79d6ece8ed8cb116838.bin
    -rw-r–r– 1 root root 153600 2010-05-12 13:36 98eb0fdadf8a403c013a8b1882ec986d.bin
    -rw-r–r– 1 root root 172032 2010-05-13 06:22 9b1bec8e5fbc9696c60422a031147d07.bin
    -rw-r–r– 1 root root 159744 2010-05-13 19:16 a7b197e90b2c5d63b19dfb4797ef7710.bin
    -rw-r–r– 1 root root 147456 2010-05-14 07:04 b407982b9eea8c8af3ff4f52ee71c44a.bin
    -rw-r–r– 1 root root 147456 2010-05-11 07:09 b786ad96a1dfb330e05595e4657d8a61.bin
    -rw-r–r– 1 root root 160768 2010-05-12 14:46 bb39f29fad85db12d9cf7195da0e1bfe.bin
    -rw-r–r– 1 root root 152576 2010-05-11 00:00 fd28c5e1c38caa35bf5e1987e6167f4c.bin

    Categories: Honeypot, InfoSec, Tool-Kit

    Determining connection source from honeyd.log – cymruwhois version

    2010/05/03 1 comment

    InfoSanity’s honeyd-geoip.py script has been useful for analysing the initial findings from a HoneyD installation, but one of weaknesses identified in the geolocation database used by the script was that a large proportion of the source IP addresses connecting to the honeypot environment weren’t none within the database. Markus pointed me in the direction of the cymruwhois (discussed previously)python module as an alternative. I’ve re-written the initial script, below:

    #!/usr/bin/python
    from cymruwhois import Client
    import sys
    
    logfile = open('/var/log/honeypot/honeyd.log', 'r')
    source = []
    for line in logfile:
        source.append(line.split(' ')[3])
    
    src_country = []
    src_count = []
    c=Client()
    
    results=c.lookupmany_dict(set(source))
    
    for res in results:
        country = results[res].cc
        try:
            pos = src_country.index( country )
            src_count[pos] += 1
        except:
            src_country.append( country )
            src_count.append( 1 )
    
    for i in range( 0, ( len( src_country ) - 1 ) ):
        sys.stdout.write( "%s:\t%i\n" %( src_country[i], src_count[i] ) )

    So far this has resulted in far fewer unknown source locations, 249 using geoip compared to 3 using cymruwhois. The downside unfortunately is performance, the cymruwhois communicates with a remote host to gather information compared with the geolocation database that is already stored locally on the machine. Both perform some local caching of results/data however so I would expect the performane difference to decrease as larger datasets are analysed.

    Using the newer script, based on the same 24hr data set, the top ten host countries communicating with InfoSanity’s honeyd environment are:

    RU:     397
    US:     234
    TW:     179
    BR:     158
    CN:     123
    RO:     107
    DE:     101
    IT:     96
    JP:     91
    AR:     86
    

    — Andrew Waite

    Team Cymru Whois

    2010/05/03 1 comment

    Since posting my Python whois class it’s lead to a (relatively) high volume of search hits pointing people to it. So I’d like to apologise for inflicting my code on other people. After a recent post with the honey-geoip.py script I was pointed in the direction Team Cymru’s whois service and accompanying python script. If you’ve not come across the stuff released by Team-Cymru I would strongly suggest that you take a look. I always manage to find some interesting new info, three overall sections Monitoring, Services and Reading Room.

    Making my life easier, Justin Azoff has released a Python module hosted on github for the whois.cymru.com service. Using the client is incredible simple as the sample code included in the package shows:

    >>> import socket
    >>> ip = socket.gethostbyname("www.google.com")
    >>> from cymruwhois import Client
    >>> c=Client()
    >>> r=c.lookup(ip)
    >>> print r.asn
    15169
    >>> print r.owner
    GOOGLE - Google Inc.
    

    Overall Justin’s client works faster than my own attempt, especially has it has functions specifically designed for bulk lookups. If you’re working with IP, whois or geolocation data I’d suggest giving the cymruwhois utility a look. Thanks to Justin and the Team Cymru people for releasing tools and info that make my work easier.

    –Andrew Waite

    Categories: InfoSec, Python, Tool-Kit