In my last blog I introduce the genome visualization tool called Circos created by Martin Krzywinski. In this post I am going to try provide an overview of the Circos tool in such a way that you can safely concentrate on what the genome terminology represents in the configuration files without being concerned about the specific meaning.

On the Circos webpage you will find excellent tutorials that Martin has already created and I have no intention of trying to reinvite the wheel. Instead, I hope to provide you with a type of Rosetta stone that you can reference when reading the tutorials so that you can more easily translate your requirements into the specific configuration changes you need.

At the core of Circos is the karyotype file. This file includes the total data set that you are basing your visualization on. For genetics, the file normally contains all data on the chromosomes, for my email investigation visualization, the karyotype file held the complete data for the 27 users being represented. An alternative data abstract for IT related visualizations may be the results of a traffic capture on a Class C network. In that case, the karyotype would hold each individual IP address and corresponding traffic type (e.g. Web, mail, P2P, FTP …). Do not be worried about having to filter and include only the data that you may want to use while you are still designing the visualization. Circos gives you plenty of flexibility in its configuration files to draw all the data, or only part of the data represented in the karyotype file.


The karyotype configuration file holds the chromosome data;
- Chromosomes would be equivalent to “email Users” in my investigation visualization
- Chromosomes would be equivalent to “IP addresses” in my network traffic example.


The next central term to understand is the ideogram. For Circos, and ideogram is the graphical representation of a chromosome, and potentially its sub-parts (bands). For my inappropriate investigation graph each “User” was represented by an ideogram. Each users ideogram was a different color, and was broken into segments/bands that represented individual emails of interest. In relation to the network traffic example, an ideogram for an IP address (network traffics chromosome) may be represented with different a color for different UDP/TCP ports, or could be shown as all 65535 ports with a single line for active ports.


An ideogram is a graphical representation for a chromosome;
- The ideograms in my investigation visualization were colored different and had bands for individual emails
- In a network traffic visualization the ideogram for an IP address may only represent active ports, or may show all ports with a line showing those with active traffic.



These are the key concepts you need to understand to work get started and work through the tutorials that Martin has already provided on the Circos hompage. In my next posting I will explain the configurations I used to generate the image I presented in my first blog on Circos.

Some time ago I wrote a blog explaining the visualization techniques I had developed to help non-technical HR personal interpret the overall scope of a particular investigation. While the specific evidence was perfectly fine to determine if there was a breach of policy, the depth of complicity of the end users actions can sometimes be hard to determine with just assorted evidence. An end user that only sends inappropriate content to one person a number times may be considered different to an end user that forwards one specific piece of inappropriate content to multiple people.

When the latest investigation of this nature appeared on my radar, I had a quick browse to see if there was a better way to automatically generate similar linking diagrams that I had previously created manually in Visio. While looking at secviz.org I notice the posted by Ben from the Honeynet project in Australia that used the graphic tool Circos.

The Circos tool was created by Martin Krzywinski for visualizing links in genomes. While the Circos seemed to be very flexible in the amount of information that could be visualized, it was very industry specific and the configuration terminology is specific to genetics. While it took a bit of time to reverse engineer the terminology in my head and really start to understand how Circos works, I believe this tool could be of great value in the IT space for all sorts of visualizations of large data sets where you want to show relationships. Because of this, I am planning to follow up this blog with a more detailed explanation of the Circos configuration files I produced in the hope that it helps others make use of this tool.

For my first attempt at using Circos I ended up to mapping 26 different internal users, and grouping all external users as another entity. This produce the following graphic.

While at first glance, the graphic looks impressive and seems to be very complicated, once you understand how to read it, it quickly becomes very useful for showing the overall relationships between who was sending and receiving inappropriate content, and how many “networks” of people were involved.

If we look at the inner band first, you will note that the circumference is broken up into 27 different colored parts. Each part for this visualization represents a different internal end user; or in the case of the light blue where “User 4″ would be, all external users to the company. Each colored arc is then broken into smaller segments. Each of these segments represents a specific email (or emails of similar content if the end user also forwarded it on after receipt) that was sent or received. The lines that link different users is colored the same color as the arc that represents the end user that sent the email.

One of the benefits of the Circos tool is that you can add multiple bands of data in the visualization. Using this ability, I added around the outside of my final graphic a histogram that also shows the age of the email for each segment. As explained in my original post on this topic, adding a time period can be important for HR to determine the appropriate discipline. In my graphic, the histogram for the Y axis is broken into 6 monthly segments. For each email represented, a bar is drawn to show how old (from the date of analysis) the original email in question was received. To make it easier to see trends in time I also used a red bar to represent any emails with in 3 months, orange for 3-9 months and green for any emails from 9-18 months old.

Circos is a wonderful tool, and I definitely plan to expand my use of it in the future. One of the next projects I want to use it for is to visualize internal WAN traffic (probably netflow data) to better understand the internal traffic inter-relationships.

I have recently been working my way through the SANS (http://www.sans.org) coarse on Reverse Engineering Malware, which has been an extremely enjoyable experience. Anyway, while reading the sections on advance JavaScript obfuscation which explain how malware authors use the capabilities of the JavaScript argument.callee function to make analysis and debugging a lot harder, it struck me that there may be an opportunity to actually to turn this capability on its head and use it to protect against such malicious JavaScript.

If a JavaScript malware author uses the arguement.callee function to either check for script modification, by change in script length or by implementation of a checksum, or the arguement.callee function is used in more advance methods like as the source key for decoding the main JavaScript. Then why can’t we implement protective measures that add random blank lines and random length “canary comments” before any JavaScript is processed by the end browser.

This might be able to be implemented as a browser plug-in (e.g. NoScript capability??), in Anti-Virus/HIPS agents or even on a proxy server that does content scanning at the perimeter.

Will wide spread use of adding such “canary values” on pre-processed JavaScript diminish the threat from malicious code? No. But if it reduces the execution effectiveness of a tool that is currently used to mainly make decoding and analysing malicious JavaScript difficult, then it has to be a positive. Plus in the short term, it would gives some people better protection against the malicious JavaScript that are dependent on arguement.callee protections, and make reverse engineering malicious JavaScript’s a bit simpler.

In my last post, I used the regtime.pl and mactime tools to help determine the potential time a malware infection occurred. In this post, which is very similar to the previous post, I will follow the same steps, however this time I will use the Sleuthkit tools and mactime to analyse the file system changes to determine potential infection time. Normally, you would start with either the registry or the file system mactime, and then move to the alternative based on your findings. However, I thought it would be beneficial to show how the timeline generation and analysis is the same no matter which you start with.

This time using the SANS Forensics SIFT Workstation VM image, I will use the SleuthKits fls and ils commands to produce file system information that can be used by the mactime utility to produce a timeline.

After starting the SIFT workstation I mounted the suspect hard drive to a read-only mount point.

Using the command format of “fls –r –m C: <filepath> > /tmp/fls.log” the file system on the suspect drive was processed for to retrieve any information on allocated or unallocated files in the file system.

The options used were:-

Using the command format of “ils –m <filepath> > /tmp/ils.log” the filesystem on the suspect drive was processed to retrieve any unallocated inodes on the partition being analysed.

The options used were:-

Once I had the separate output files I then ran “cat” to join them all together. This was done by using the command:

cat <filename> >> /tmp/mactime-body

Then I ran the Sleuthkit mactime program across the mactime body file in 3 ways.

1. 1. Mactime -b /tmp/mactime-body > /tmp/mactime-body.log
   2. Mactime -b /tmp/mactime-body -d -m > /tmp/mactime-body.csv
   3. Mactime -b /tmp/mactime-body -d -m 2009-01-01 > /tmp/mactime-body2009.csv

The first one will give a full dump in standard Sleuthkit mactime default output. The second one will output a full mactime file in a comma delimited format where each line has its own timestamp. The last one is the same as the second except I am only outputting any information that changed after the 1st Jan 2009.

From there I copied the processed mactime files from the SIFT virtual workstation onto a machine with Excel2007 on it. You really want to be using Office2007 to get around the row limit in previous versions of excel. The benefit of using Excel is that it can be quick and easy to sort, search and filter information that may be of interest in the mactime output files. For example, loading up the mactime-body2009.csv file I can do a find all on .exe files that are modified (including created and deleted) in the C:\Windows\system32 directory. The main reason any  .exe should be modified here is if there is a Microsoft patch installed. However, since this directory is included normally in the execution search path, malware likes to be dropped in here to avoid execution issues.

Attached is a copy of the the output of the find all command in Excel 2007. When reviewing the timeline we can locate the same time period that was determine in the previous blog as a point in time of interest.

The following is an overview of how I used the SANS Forensics SIFT Workstation VM image to investigate a laptop that was infected with malware. The goal of the investigation was to determine if possible how the machine got infected, and when it was infected. To this end I used the regtime.pl utility that is supplied with the image.

The regtime.pl utility will process the timestamps in each key of a registry HIVE and produce output that is compliant to the SleuthKit’s mactime format.

After starting the SIFT workstation I mounted the suspect hard drive to a read-only mount point. The regtime.pl utility can be found in the the “/usr/local/src/windows-perl/” directory.

cd /usr/local/src/windows-perl/

Using the command format of “perl regtime.pl -m <HIVENAME> -r <filepath> > /tmp/regtime-<HIVENAME>” the regtime.pl each HIVE on the suspect drive was processed.

The options used were:-

Once I had the separate output files I then ran “cat” to join them all together. This was done by using the command:

cat <filename> >> /tmp/regtime-body

Then I ran the Sleuthkit mactime program across the mactime body file in 3 ways.

1. 1. Mactime -b /tmp/regtime-body > /tmp/regtime-mactime
   2. Mactime -b /tmp/regtime-body -d -m > /tmp/regtime-mactime.csv
   3. Mactime -b /tmp/regtime-body -d -m 2009-01-01 > /tmp/regtime-mactime2009.csv

The first one will give a full dump in standard Sleuthkit mactime default output. The second one will output a full mactime file in a comma delimited format where each line has its own timestamp. The last one is the same as the second except I am only outputting any information that changed after the 1st Jan 2009.

From there I copied the processed mactime files from the SIFT virtual workstation onto a machine with Excel2007 on it. You really want to be using Office2007 to get around the row limit in previous versions of excel. The benefit of using Excel is that it can be quick and easy to sort, search and filter information that may be of interest in the mactime output files. For example, loading up the regtime-mactime2009.csv file I can do a find all on common registry keys that malware play with.

Attached is a copy of the first item found in the registry and the items around it. When reviewing the timeline there is a 3 minute interval where a number of registry keys are modified, however there is no other activity for hours on either side of this activity. This would be a good indication that we may want to look at exactly what changes were made in the registry (if they still exist) to see if this was malware activity.

In the next blog post, I will use the same process using the Sleuthkit tools.

Sometimes it’s the small things that makes a conference more enjoyable:-

• Full-time vendor sponsored barrister for good caffeine injections at anytime – nice
• Full-time vendor sponsored drinks fridge for your cold drink alternative – nice
• Full-time vendor sponsored ice creams – nice
• Vendor sponsored Wireless LAN – would have been handy if I wanted to use it

Sometimes it’s the big things that makes a conference more memorable:-

• Insane storm that hit on third day – impressive distraction
• Decent lunch time food and seating – nice
• Gala dinner, MC choice and entertainment (sans bonny and clive) – nice

Its always good to be amused:-

• Hotel staff running through vendor stand at an IT conference asking for electrical equipment to be powered off because of power failure in storm
• Watching a TV entertainer as MC trying to control 8 security experts having a debate – and he probably thought it would be a boring, dry gig.
• Gala event – 100s of men + one toilet block with 3 urinals

The other stuff:-

• Networking was excellent
• As with any conference, you have your mix of good and bad talks
• Use of wireless voting tech was quick and painless. After all, who really fills in the paper surveys at the end of talks.
• David Rice – finally got to see him talk – impressive, entertaining and thought provoking
• Patrick Gray – nice talk on the social media. And kudos for not bowing to pressure for the opinion you wouldn’t give on one of the panel debate questions. It says a lot for your character and journalistic integrity. If anyone disagrees, would you trust Pat with off the record comments, or on the records comments to be kept in context if he had given in to pressure so easy. It doesn’t really matter the reasons why he wouldn’t offer an opinion.
• Peter Gutmann – to talk so fast, concisely and in-depth is impressive.

Will I be back in 2010. Hopefully.

In the past, when my frustration with the time it took to boot up my Windows XP laptop finally got the better of me, I would track down a copy of the old Microsoft Bootvis utility. This provides a nice graphical view of what is happening as a machine is booting. However like many things, a little bit of knowledge can be dangerous. Therefore, unless you really have a deep understanding of the Operating System’s architecture, there is a good chance that you will end up using such tools incorrectly. This is part of the reason why I have read Microsoft removed the support for the Bootvis utility. I will happy put myself in the category of “a little bit of knowledge” when it comes to the internal architecture of Microsoft’s kernel. However, because I recognise my limitations I am careful to use such tools to only find obvious potential problems.

The other day, the long boot time for my Vista laptop finally got to me and I went looking for a replacement for bootvis that would work in Vista. I wanted to see if I could find any obvious culprits that were causing such a long boot up time. I came across the Microsoft Performance Analysis Tools (http://msdn.microsoft.com/en-us/performance/default.aspx). This is a much better set of tools than then old Bootvis utility, and the performance hooks are built into the Vista and Server 2008 operating system. At its most basic, you can use the tools to provide you with a similar graphical display of boot performance which was provided by Bootvis.

In the end I found a problem hardware driver that wasnt loading properly and was fixed with an update. The Logitech webcam services seem to have a known conflict with cygwin, so I disabled those (dont use the webcam all that much and I can always turn them back on when I need to), and an update of the VPN software. These were very obvious candidates to research for problems, or do basic testing (e.g. disable and see if there is a boot time difference), when comparing them against the other drivers and services load times that were being undertaken. Given the power of the tools, I am sure there is a wealth of information that can be gathered to find less obvious issues, but it would require me to find some time to really learn how to use these tools as they were intended. So I am happy to fix the obvious problems to provide just enough improvement to satisfy my boot time frustrations.

For those of you who came here hoping to see some visually inappropriate content I am sorry to disappoint you. What I am writing about to day is a technique that I have developed over a number of internal Enterprise HR investigations that I supported involving the emailing of inappropriate material.

Historically when I have supported HR in their inappropriate content investigations (our company takes a strong stand on such unprofessional behaviour in the work place), I would produce for them a standard FTK (Forensic Tool Kit) HTML report. This would have each email (based on sender) bookmarked and the original email and attachments linked in the report. This was great from an detailed evidence point of view, however it did lack a lot of detail to give an over all view of the scope of the problem. The biggest issue was, there was no easy way (especially as the number of people involved grew) to show how each individual was linked in the email/forwarding behaviour with others with-in the company.

In the later half of last year I started to work on providing HR with an overview of email communications between employees using a linking visualization technique that I had seen used in a vendors product. I have also seen this a similar example is Raffael Marty’s (http://secviz.org/content/applied-security-visualization) book as shown in the Facebook application “Friend Wheel”.

The visualization technique involves mapping all the internal senders of inappropriate material around a circle, and then linking a sender and recipient by a line that crosses the inside of the circle. Arrow heads on the lines were used to represent who was sending the inappropriate email and each sender was represented by a different colour line. If the email had originated from external to the company, then a small line from the outside to the internal employee was used, and the colour was selected as if the recipient had sent the email (this would make it easier to see if employees were getting external emails and then forwarding them on). If during the analysis of an email, only one email was found after it had been forwarded a couple of times (with other sending details still forwarded), then an appropriate line would still be added based on who sent the email to whom during the chain of emails. This would allow me to show how emails were passed from one person to another, even if I didn’t have copies of the original emails from the each of the senders mailboxes.

Mapping of Emails Sent

I manually mapped this out using Microsoft Visio, and also used the layering capability to give each sender their own Visio layer. This would allow me to later select just a single sender layer to provide HR with employee specific visualizations of their inappropriate email usage. Using the custom properties of each Visio line, some of the FTK data was recorded. This allowed for double checking all the linking later. The format I used was generally the title set as the mailbox of the specific email evidence was found, and the value set to the subject of the email and the date sent. This would enough details to search the FTK evidence quickly to find the original evidence.

Emails From User 46

From User 28

Often during the investigations using FTK I would come across the same inappropriate content numerous times as being sent or received. If this was the case then I created a dedicated layer for such attachments. This allowed me to easily show how the specific inappropriate material entered the Enterprise, and how it got forwarded around to different employees.

Inappropriate Attachment Flow

Using this visualization technique has served to give HR greater confidence when interviewing employees based on their behaviour. They are able to structure the interview and council/discipline an employee knowing if they had only received inappropriate content once but had not deleted it, had received inappropriate material multiple times but may not have requested for such material to be sent to them, or were participating in forwarding such content around the Enterprise. The visualizations were also a good tool to show those employees who were “network hubs” the extent of what the investigation had found with out needing to walk through a large pile of email evidence.

Since then I have also added an Excel chart to the individual senders diagrams to show the time period that each emails were sent. This was to overcome the problem with a natural assumption when first viewing a visualization that a lot of emails were sent by a person. It may instead have been the case that they had only been a couple of specific emails sent out to two different groups of people with the incident being separated by months of time.

New Email Flow

Any improvements that can be suggested to help non-technical HR personal understand investigation evidence would be greater appreciated.

While I was drafting this blog I noticed Raffy twit that he was playing with the MooWheel (http://www.unwieldy.net/projects/moowheel/) code to do similar wheel visulisations with network data (http://raffy.ch/moo/moowheel.html). This code could have the potential to embed a dynamic visualization for HR along with the FTK report. I have have not had a chance to look at the MooWheel, but the potential at this stage does intrigue me.

Update 4th April 2009 I have uploaded the full size images to http://secviz.org

The growing market of eBook readers has started to get my wallet itching. However being from “the land Down Under”, I am limited as to what I can buy directly. Or more importantly, what I can walk into a store and play with first before coughing up all the money and buying it online.

Even so, from a Enterprise perspective, which is what most of my e-reading would be for, I believe the most appropriate viewing format would be the full size A4 or 8″x11″ screen. As I would be viewing work related documents, I believe this size format would be better for reading PDF’s, Word documents etc etc. Along those lines, I like the look of the I-Rex models, but the price does hurt.

Wearing my corporate hat, one thing that does worry me if I were to allow the use of eBook readers by others in the Enterprise, is how the company information stored on the readers is protected. The readers suffer the same data leakage risks as other mobile storage media (which includes laptop hard drives and USB sticks). Therefore, some level of encryption is needed. The question is, what is the most appropriate type of encryption . Especially as encryption is a CPU intensive operation, I am sure the eBook vendors are scared off at the potential impact of the battery life drain when encryption is thrown in the mix.

Maybe in this case, where one of the main goals and benefits of eBook readers is to have extremely long battery life, is to look at file level encryption support. This way only those files that need to be protected are, while the rest (i.e. magazines, whitepapers, novels, manuals, technical books) are left unprotected.

And now we come to a common problem for the vendors and the Enterprise. How do we make the encryption process convenient enough that end users will make use of it. To that end, I think any such encryption should be designed to protect the majority of Enterprise information in an acceptable fashion, and leave the more sensitive information to utilise other solutions (i.e. full disk encryption on a laptop). When we talk about the majority of Enterprise information we are talking about classifications such as X-In-Confidence , where X can be Commercial, Security, HR, Legal or any other Enterprise body. To define it more clearly, I will make use of the definition from SRMBok (Security Risk Management Body of Knowledge) which is:

“Private, security or commercial information prepared with an expectation it may be shared with external parties with a legitimate need to know, subject to relevant restrictions.

If the information were released to the media or competitors organisation XYZ could expect: minimal damage to corporate interests, including reputation; minor potential for financial loss; minor embarrassment to the company or its business partners and minor detriment to employees or customers.”

A solution that may protect against material that falls into this category, while maintaining ease of use, would be to introduce the fingerprint technology that you see a numerous laptops these days to authorized the decryption processes. If the fingerprint technology were combined with well designed eBook synchronization software, the protection process may become easy enough that people wont avoid the “hassle” of having to encrypt sensitive information.

To protect sensitive information, the synchronization software needs to have a very simple way to encrypt data that is to be transferred. This may simply mean having a special “Protected” container for users to copy Enterprise information into. Given that encryption/decryption functions are CPU intensive, we don’t want to encrypt all files if there is no need. This should minimize the impact on battery usage/CPU to only when “Protected” files are decrypted and displayed.

A fingerprint scanner would be used to protect a random password key that is generation during the eBook reader initiation. Then “Protected” files can be encrypted as they are passed from the synchronization software to the eBook reader. If this method is followed, then the random key never needs to leave eBook reader. This suggests that a tamper resistant/TPM like chip might be important to protect the key from general access if the reader is lost. As long as the person using the eBook reader has their fingerprint authorized, they will be able to display the protected Enterprise material.

Another option for encryption is for the eBook reader to pass the key securely to the synchronization software. This would allow the PC to encrypt the files on its faster CPU first before passing them to the eBook reader. However, once the key is removed from the eBook reader, it opens another source where the key may be found by an attacker to be able to view the eBook readers contents. But lets be realistic, if someone is able to pull the encryption key from the computers eBook synchronization software, then they its very likely that the attacker already has access to all the information stored on the eBook reader anyway.

Of note, Hoff also recently wrote about the same need for a password on the Amazon Kindle2 for Enterprise use.

For those interested in a new spin on biometric authentication using the finger, you may want to have a look at VeinID from Hitachi. The marketing hype is certainly working on overdrive with impressive technical terms like “vascular pattern recognition” and LED’s that penetrate the bodies tissues with near infrared light which is sure to get some excited.

Not to take away from the technology, but reading the website (http://www.hitachi.co.jp/products/it/veinid/global/index.html ) did make me chuckle. If you want to see Hitachi’s opinion on how this technology compares to other biometrics they provide a nice table at:http://www.hitachi.co.jp/products/it/veinid/global/introduction/comparison.html

While I am not sure how successful they will be with the USB reader due to its clunky design, I can appreciate the use of such a technology as an alternative biometric reader for physical access control.  As it is unlikely that I will be rushing out to buy a USB reader to play with, I guess time will tell how successful Hitatchi will be.