Sep 2004 to Mar 2005

1.0 DEPLOYMENTS

1.1 Current technologies deployed

We currently have three active honeynets deployed in the UK, all using the current Honeywall bootable CDROM:

UKA – UK ISP ADSL

  • Data Control and Capture
    • Honeywall v0.69 – Partial Class C
    • Sebek 2.1.7 or 2.5.3
  • Data Analysis
    • ACID console
    • Sebek web interface
    • Honeywall upload script
    • Honeywall daily analysis script + email alerting
    • Honeysnap daily analysis script
  • Honeypots:
    • Fedora Core 1 unpatched
    • Windows XP Professional SP2
    • Solaris 9 on Sun U10 unpatched

UKB – UK ISP Data Centre

  • Data Control and Capture
    • Honeywall v0.69 – Partial Class C
    • Sebek 2.1.7 or 2.5.3
  • Data Analysis
    • ACID console
    • Sebek web interface
    • Honeywall upload script
    • Honeywall daily analysis script + email alerting
    • Honeysnap daily analysis script
  • Honeypots:
    • Redhat 7.3 unpatched
    • Fedora Core 2 unpatched
    • Solaris 9 on Sun U10 unpatched
    • Solaris 8 on Sun U5 unpatched

UKC – UK University

  • Data Control and Capture
    • Honeywall v0.69 – Partial Class C
    • Sebek 2.1.7
  • Data Analysis
    • ACID console
    • Sebek web interface
    • Honeywall upload script
    • Honeywall daily analysis script + email alerting
    • Homebrew scripts
  • Honeypots
    • Redhat 7.3 unpatched

During this reporting period we have routinely upgraded each of these three honeynet deployments and tested revised first generation “eeyore” honeywall CDROM releases, up to and including the public v0.69 release. Currently first generation “eeyore” deployments UKA (roo-002a) and UKB (roo-002b) are actively submitting obfuscated data to the Honeynet Project’s centralised database on Kanga on a daily basis. We have also been beta testing the new second generation “roo” bootable honeywall CDROM and expect to deploy an initial system in a live environment using UKA over the Easter holidays. Honeynets UKB and UKC have recently been taken down for forensic data recovery and will be redeployed using “eeyore” in the next few weeks.

1.2 Lessons learned from the technology, what you like about it

The Honeywall CDROM continues to make honeynet deployment of multiple honeynets much quicker and easier, and we are looking forward to using the new HFlow and Walleye functionality available in “roo” in the wild – particularly the attack process visualisation capabilities.

Our own honeysnap tool is proving very useful for daily activity monitoring and rapid initial forensic analysis, particularly when IRC traffic is involved. Analyst time that would previously have been spent wading through historical pcap logs can now be focused on key network events, and it has served as a good starting point for ideas for future analysis tools.

1.3 Lessons learned from the technology, what is lacking, what you would like to see improved

Data analysis still remains our main concern. We are good at building and operating honeynets, but analysis of captured data is still very time consuming and requires too much human analyst time. Better data analysis and reporting tools, with greater cross group communication and incident response are essential. Near real time alerting and responses are also highly desirable, which again require more powerful automated analysis tools and techniques.

2.0 FINDINGS

2.1 Number and type of systems compromised during six month period

A number of our honeypot systems were compromised on one or more occasions during this period, including honeypots running: Redhat 7.3, Fedora Core 1, Solaris on Sparc.

2.2 Highlight any unique findings, attacks, tools, or methods

We have a large amount of black hat IRC activity logged, including a number of distinct types of underground or criminal activity, and we hope to produce a KYE white paper on IRC trends during the next period. We continue to work on analysis of a phishing incident captured last August, and we are also studying the activities of an Italian group who recently compromised one of our Solaris honeypots. This incident may have included the use of a previously unseen root kit, but further analysis is required.

2.3 Any trends seen in the past six months

We seem to experience regular compromises on unpatched Solaris systems, usually by Romanian or Italian groups. Installation of IRC servers (usually psyBNC) continues to be the #1 activity of our attackers. Captured conversations can be a rich vein of material to help in understanding blackhat activity in the wild, but on a number of occaisions we have felt the need to disconnect the system after the content of the conversation was clearly illegal.

Windows XP2 service pack two so far appears to have prevented any compromises on our Windows XP Professional honeypot, which bodes well for Internet safety if it finally makes it through to being deployed on home systems (or becomes standard on new PCs).

2.4 Document data analysis tools and methods being used

Standard forensic tools: TCPdump, Ethereal, tcprelay, ACID, etc plus Sebek, Chaosreader and Privmsg. We have also developed and alpha tested our own tool for initial analysis of pcap data called honeysnap, a copy of which has been supplied to some members of the Research Alliance and Honeynet Project. A potential port to python is planned soon, but we will release the initial shell version to the Alliance for beta testing in the interim.

2.5 For data analysis what tools work well, and what still needs to be developed

Honeysnap is still proving surprisingly useful, and we seem to spend a lot of time using privmsg to quickly isolate blackhat IRC traffic. Ethereal continues to be an essential item in the analyst’s toolkit, but we have moved away from Chaosreader for quick data analysis and application data extraction (for performance reasons). TCPflow has proved useful for us as a less fully featured but faster replacement. We would like produce an improved version of honeysnap, to include features beyond IRC keyword summaries, such as:

  • number of messages
  • number of unique talker
  • number of unique hosts
  • number of unique channels
  • count of messages per channel
  • count of talkers per channel
  • new channels seen today
  • new talkers seen today per channel
  • new hosts seen today per channel
  • sysops names for each channel
  • splits/joins
  • average rate of messages per channel
  • average rate of messages per talker
  • alerts when these rates significantly alter from historical averages
  • number of unique key words
  • number of unique key words per channel
  • top 10 key words per channel
  • new words seen per day per channel

We have also discussed building an ethereal-like GUI for IRC analysis – something that lets you rapidly and intuitively filter privmsg logs by host/sender/channel/keyword, build groups, follow threads, etc, report on the items above against an applied filter, etc. This would probably be quiet useful for IRC heavy log analysis.

3.0 MISC ACTIVITIES

3.1 Presenting at conferences

Attended Annual Honeynet conference in Chicago in September 2004.

3.2 Developing, testing or releasing code

  • Next-gen Honeywall CDROM Proof of Concept platform (demonstrated in Chicago)
  • Eeyore beta testing
  • Honeysnap – initial pcap analysis to spot the low hanging fruit in an unknown dataset

3.3 Publication of papers

Papers on phishing and IRC stil under development. Assisted with KYE paper review for releases during this reporting period.

3.4 Involvement in SotM challenges

None in this period.

3.5 Other

Set up and administrated Wiki for Chicago 2004 workshop (plus two attendees), which was apparently well received and continues to be used (and administrated) within the project for communication within project streams.

4.0 ORGANIZATIONAL

4.1 Changes in your structure of your organization

This has been a reasonably low key period in which we have concentrated on capturing blackhat activity from multiple honeynets and establishing a solid data set, building tools to improve our initial data analysis and improving our internal proceedures. One additional member from the UK Foreign Office has joined, and another alumni member from private industry has become active again. Otherwise no changes except for a move towards using our internal Wiki for inter-team communication.

5.0 LESSONS LEARNED

5.1 What positive things can you share with the community, so they can replicate your success.

  • Our internal group Wiki is proving very useful for group communication and collaboration, especially at a time when people are geographically separated.
  • Tools like honeysnap can take out a lot of the manual labour in operating honeynets, allowing us to easily focus our (fairly limited) resources on incidents worthy of further investigation.
  • Data captured from IRC sessions has provided us with a much richer data set than IDS and firewall logs, exploits or sebek keystroke logs. Much of what we have learned during of blackhat activity during this period has been from IRC
  • Building relationships with speakers of other languages can be very useful when attempting to understand blackhat IRC traffic.

5.2 What mistakes can you share with the community, so they don’t make the same mistakes?

  • When a deploying a new honeypot, always log in and echo a standard phrase such as “Honeypot XXX deployed on site YYY at date/time” from the command line, so that you can easily determine at a later date when a particular honeypot was deployed.
  • Don`t mistakenly re-use the same passwords on later honeypot deployments, otherwise attackers may return after many months and just log in by somehow knowing a user and root password. This can cause a lot of confusion and waste a lot of man hours trying to understand how they somehow knew this information!
  • Beware of logging IRC traffic when you might not be able to respond to events quickly. Relatively benign IRC communication can rapidly turn into obviously illegal activity with the addition of a new channel, and the potential for legal exposure could potentially be high. Consider how you will handle the capture of stolen credit cards, identity theft, EBay or PayPal accounts, etc before the event happens and have a well prepared and rehearsed response (such as immediate disconnection).

6.0 FUTURE GOALS

6.1 Plans/Goals for next six months

  • Make more time for honeynet research and other activity
  • Improve timeliness of incident response and data analysis
  • Re-activate our public web site
  • Start publishing basic attack statistics
  • Release a small number of useful tools and papers
  • Bring in a couple of additional core team members
  • Design and begin deploying a much larger distributed honeynet system in the UK (“Honeynet Central”), if possible with funding
  • Begin fundraising and seeking external sponsorship
  • Work on platform development and testing of next-gen Honeywall CDROM, plus QA process
  • Produce a bootable LiveCD version of the next generation “roo” platform
  • Participate in Honeynet conferences in Europe (Aachen May 2005) and American (Chicago Autumn 2005)
  • Help to organise logistics for another UK Honeynet conference with the Network Defence team at GCHQ (September 2005)
  • Form connections with legal experts in the UK and assess legal position of honeynet data capture – particularly IRC