Tagging and Timelines: Part 2

Posted by Bagpuss on February 27, 2011
Tags: honeynet, digital forensics, data visualisation, timeline

During a recent attempt at answering the Honeynet Log Mysteries Challenge, I wrote a series of reasoned analyses for the supplied Honeynet logging data. Unfortunately, teaching workloads stopped me from submitting any realistic challenge answer.

Inspired by the idea of applying the Scientific Method to Digital Forensics (see Casey2009 and Carrier2006) and using data visualisation (see Conti2007 and Marty2008), I set about attempting to apply the same principles to analysing the Log Mysteries data sets.

In Tagging and Timelines: Part 1 we had introduced a tagging algorithm that utilised Debian's package tags (ie. debtags). This blog post explores how we may use these tagging relationships, along with an interactive timeline (implemented using Protovis), to explore and analyse the auth.log sudo events.

As this article focuses primarily on techniques for exploring data, we shall not present any rigorous arguments here. Instead we shall focus on using timelines to visualise and correlate events. In doing this, we wish to document any questions or observations that may arise during this phase of analysis. At a latter investigation phase, we shall use these questions and observations to fuel the creation of supporting rigorous models and arguments.

Tag Choice Rationale:

When investigating or monitoring systems, we clearly need to ensure all our security boundaries are adequately covered or monitored.

With this in mind, we can identify the following Debian tag-based security boundaries:

  • any security related event needs further investigation (ie. security::* and admin::* tagged events)
  • all networking events should be monitored (ie. network::* tagged events).

By focusing on all admin::*, security::* and network::* tagged events, we are able to produce the following timeline (click to view and explore the timeline data - warning: page is approx. 750KB):

We leave it to the reader to explore and analyse this timeline further.

Now, in Tagging and Timelines: Part 1, we defined the threats tag by noticing that there was an association between psybnc (a keyword flagged by the Snort alerting rules) and eggdrop (reference: An Introduction to psyBNC 2.3.1; and Know your Enemy: Web Application Threats).

In looking at the threats tagged events, we want to first utilise tagging to define individual sessions. Then, for each session, we will perform a secondary analysis to identify context change boundaries (again implemented with tagging). A latter analysis (which will not be performed here), can then use this information to define behavioural models for each of our sessions (and so all the tagged events).

Click to view and explore the following threats based timeline data:

In working with this threats timeline, we choose to use TTY (ie. the current terminal device) to define our session related tags - this leads us to define two separate sessions. To define our context change boundaries, we use the following criteria for boundary selection:

  • PWD (current working directory for event) - a change in the current working directory will signify a change in command line behaviour here
  • UFW restart, status, enable and disable events will be used to separate UFW port opening (or allow) events here.

Based on these context change boundaries, we may now make the following observations about our attacker's behaviour (times are UTC):

DateSessionTime PeriodObserved Activity Overview
20/Apr/10pts/106:25:00-06:29:44Build/installing within /home/dhg/psybnc-linux/psybnc (attempt at building psyBNC that fails?)
06:34:35-06:38:18Build/installing within /home/dhg/eggdrop1.6.19 (attempt at building version 1.6.19 of Eggdrop that succeeds?)
pts/213:51:38Attacker reconnects to server via Eggdrop?
13:51:38-13:52:26Firewall modified to allow traffic through ports 53 (DNS) and 113 (ident)
13:54:56-13:57:22Firewall restarted, enabled and its status is checked (period of testing?)
13:58:19-13:59:02Firewall modified to allow traffic through ports 22 (SSH), 53 (DNS), 113 (ident) and 303 (telnet backdoor?)
13:59:40-14:00:30Firewall restarted, status is checked and it is disabled (period of testing ends?)
14:06:11-14:06:22Firewall modified to allow traffic through port 2685 (telnet backdoor?)
In addition, we also question why root needs to execute sudo?

In our next blog article we shall look at how we can accurately determine a version for Wordpress and its plugins.

Tools Used

Rails 3 used to model our data (see GitHub project for Rails application used in analysis)
JGR to initially explore and visualise data
Protovis 3.2 used to plot graphs in Rails application.