25 Mar 2013

From Indicators of Compromise to Smoking Guns

0 comments Permalink Monday, March 25, 2013
In a previous post I used the intuitive visualization in Packetloop to zero in on a particular attacker that had targeted at least two systems with indicators suggesting Warez related FTP and the delivery of shellcode. The analysis at that time was interesting but hardly a smoking gun. The security analyst was presented with indicators of compromise but could not conclusively prove a breach.

Packetloop's "Threat Analysis" feature started out as a functionality story called "play by play". I wanted to be able to peer inside an attack and step through it play by play. To do this we needed to take every indicator and warning and then perform deep packet inspection on every packet from every conversation and link it into our User Interface. Packetloop's Advanced Filter experience is powerful and fast and Threat Analysis had to be able to respond in the same way. So you could zoom in and out, pan left and right through time and filter on Attacker, Victim, Attack, Port or Industry Reference (e.g. CVE). It was a pretty bold concept and initially difficult enough that we pushed the functionality back - but we didn't give up ;)

Remember this is the canonical DARPA98 data set that I am analysing here. So the attacks have that old school retro feel.

Threat Analysis

In the previous post the the source of attack 152.169.215.104 was located due to a large number of New Attacks in a very small period of time (12 new attacks in 1 minute). These attacks were related to information discovery (Finger and RPC Mapping) against 172.16.112.50. On closer inspection there was suspected FTP warez activity triggering a number of indicators. Filtering by 152.169.215.104 as the source and then zooming out to a 3 month time window we were able to view the entire attack timeline and find a second host 172.16.114.50 that was also the destination of attacks (x86 NOOP Shellcode). Despite these indicators it was difficult to conclusively prove and analyse the breach.

The attack timeline shows Finger and RPC requests being used by the Attacker to enumerate the target

An open FTP server is used to store and access Warez and Tools including the Linux Root Kit.

A vulnerability in BIND is exploited to gain root access
Threat analysis enables you to move from indicators and warnings to find the proverbial smoking gun. The initial series of attacks are mostly information discovery with finger attempts and rpcmap's to enumerate users and interfaces. The second set of attacks is linked to FTP and Warez and this is where Threat Analysis really shows it's power. If we focus on those purple bars in the centre of the main visualization, and we switch to the Analysis view in the Data Panel, we can immediately see exactly what this attacker is doing.


The attacker logs in to the ftp server as 'ftp' and idents and the changes into the "caliberX" and then the "Win98.Final-PWA" directory. At a glance we have gone from thinking that this might be suspicious activity on our network to knowing that it is. Scrolling down we can view the individual files that the attacker is accessing including the zip files and nfo files.


Later in the attack timeline the evidence becomes clearer and more damning. Looking into more FTP sessions between 152.169.215.104 and 172.16.112.50 we see the attacker download tools for exploiting Linux systems.


Again the attacker logs in as 'ftp' changes directory into 'lr2k-1.1' and then in the final row of output downloads 'lrootk.tgz'. This is a version of the Linux Rootkit.

The Shellcode attacks between 152.169.215.104 and 172.16.114.50 establish a shell that is used to initiate an X11 Window session between the attacker and the target. Using the advanced filter we can limit the search and zoom into the attack timeline. Shellcode is delivered over DNS (UDP/53) in a series of attacks at 12:33AM and then another flurry of attacks at 12:39AM.



The Shellcode targets a vulnerability in BIND 4.9 and BIND 8.0. This can be determined by highlighting the CVE in the Advanced Filter.




The timeline is important as an X11 session is established in the reverse direction (172.16.114.50 to 152.169.215.104) soon after the initial attacks with the first back channel created at 12:39AM. This is shown in the screenshot below.


Packetloop's Threat Analysis provides a full breakdown of the X11 session.


We can tell that the attacker used the DNS exploit to gain root access because they issue an 'id' command that returns 'root'.


Again we can access a detailed breakdown of the X11 sessions where the id command is executed.


Conclusion

This is a canonical example of an attacker performing reconnaissance and targeting, exploiting a vulnerability and establishing full root access. Packetloop allows you to find and analyse these incidents in minutes with full data fidelity. Every attack and attacker can be isolated, every packet in the attack can be stepped through and analysed.

With Packetloop's Threat Analysis there is no guesswork. The entire attack time line can be examined from months to minutes.

Sign Up for a Free account today and explore the 50GB of Public Datasets available on the Packetloop platform using Packetloop Threat Analysis.



23 Mar 2013

What's New?! - Threat Analysis with Deep Packet Inspection

0 comments Permalink Saturday, March 23, 2013

Introduction

Context is King when it comes to understanding and analysing attacks and attackers. Today we are releasing the analysis feature for the Threats module. Internally we call this feature "play by play" and it does exactly that. It allows you to peer inside every attack and step through it so you can rule the attack in or out of your analysis.

What do you need to do to enable it? - nothing. We are processing all datasets on Packetloop today to enable this new functionality.

MySQL Login and a Drop Database shown in Analysis view
In the screenshot above the full context of a MySQL root login is shown. Stepping through the attack you can see the successful connection, authentication and then a "drop database" command is issued and executed successfully on the database server.

Packet Level Detail and Protocol Context

For every Attack each packet is analysed using deep packet inspection to identify and parse the protocol used in the attack. Relevant information from each layer of the TCP/IP stack is easily accessed and presented in a tree structure so you can drill down to specific information you are looking for.

If you want to know who dropped your database tables - it's right there. The specific HTTP URI used as part of an attack - it's right there.

Clicking on the attack in the Analysis view allows you to explore and find evidence and details that can aid your analysis.

How does it work?

Every packet capture you upload is passed through multiple detection engines and are analysed for attacks. At the same time we pass every packet and conversation through deep packet inspection - for every attack we record the specific protocol information related to the attack.

Rule in or Rule Instantly

The analysis information combined with Packetloop's Advanced Search allows you to access the context you need incredibly fast. Click on a Country, City, IP or Attack type and you can immediately filter all analysis to that data type. Using your scroll wheel or mouse pad you can zoom in and out from years to minutes or pan left and right to go forward and back in time. 

No detection system is perfect and context is king for analysts. Allowing you to inspect any attack and be able to rule it in or out of your analysis almost instantly saves you precious time. Time that can be spent finding other complex attacks.

Availability

This feature is now available for all new uploads and any packet captures stored in Packetloop. We have more functionality to add to it. As always if you have any feedback let us know.



3 Mar 2013

What's New?! - Amazon S3 Bucket Processing + More

0 comments Permalink Sunday, March 03, 2013
Our current focus is the Cloud but that won't always be our only delivery model. Packetloop will be available on premise but we have a lot to deliver and the Cloud allows us to demonstrate what the product is capable of - fast and iteratively.

In the last week we added some cool new features and we will continue to add cool new things every week. Obviously the ones that Customers need go in first. Here is a summary of the 1.0 releases.

Amazon S3 Bucket Processing

Our Customers are pretty equally split between people who are producing captures from their corporate network and performing analysis in Packetloop and those that have applications that operate 100% in the Cloud. For Customers already in the Cloud copying full packet captures down to their computer and then re-uploading to Packetloop is classic double handling. It would be much easier if they could just push their full packet captures to an S3 bucket and give Packetloop the ability to process their bucket.

We built this functionality directly into the application. All the Customer has to do is make sure they have granted the ability for Packetloop to access their bucket via a bucket policy. The following screenshots show how simple it is to process large captures from an S3 bucket.

Select Upload Files and then S3 Bucket
Select a Capture Point and specify your Bucket Name
Select the files you want to process and submit
The packet captures are copied directly from bucket to bucket avoiding the requirement to download and re-upload the data. It's simple and fast! After the files are copied they are processed as normal by Packetloop.

In the future we will add scheduling capabilities so we can scan the bucket periodically, find new capture files and seamlessly process them (stay tuned!).

Command Line Upload

Some customers roll their full packet captures over based on time (e.g. 1 hour) or based on size (e.g. 100Mb) and wanted an easy way of getting these captures into Packetloop. We brought forward enough of our API functionality to allow you to login, list/create capture points and upload files. Here's an example of how to do this using cURL. So now when Customers roll their captures they can fire the script and upload to Packetloop and the next time they login the data will have been processed.

Compression and Archive Support

Packet captures compress extremely well to often 1/2 or 2/3's of their original size. Packetloop shipped with support for xzip, bzip2, gzip and tar archives but strangely enough no zip support ;( This was addressed in a recent release.