What is Trigona?
Trigona is a VirtualBox powered honey-client that was designed for high throughput with low False Positive and low False Negative rates.
It is essentially taking the best of High interaction and Low interaction honey-clients and cobbling them together with a couple of Perl scripts.
The benefits of High Interaction honey-client’s has been that since there is no emulation of software etc. you can catch everything as opposed to a low interaction honey-client where exploits will only be caught if they have been catered for. However the down side of the High Interaction honey-client is that it is a lot slower than a Low Interaction as it requires a full blown virtual machine for each URL analysed as opposed to generally a command-line tool that can pump through a lot of links in a short period of time.
Trigona takes the high throughput of LI honey-clients and the ‘catch all’ benefits of the HI honey-clients and puts it into one system.
how?
essentially it works like this:
1) load a virtual machine with all the required browser plug-ins etc etc.
2) instead of loading 1 URL for the virtual machine we load 200 for example all at once. this network traffic is packet captured for analysis at a later stage.
3) revert image and repeat.
by doing this we can achieve very high throughput but miss nothing while performing the analysis of the pcap ‘out of band’.
While this is very useful it is only part of the solution.
What do we do with this pcap now?
Well the ultimate aim for a honey-client tool is to find the following:
– Infected/hacked website, i.e. mumndadsbakery.com
– Exploit Kit
– Malware Binary
In a traditional sense this was very simple as only 1 URL would be analysed at a time and if there was a binary dropped then it was safe to assume that the first URL was infected and other content pulled was related to the exploit/binary also. Case solved.
What about when you have 1..n start links 1..n intermediary links and 1..n final links???
You can start to see the problem. How do I know which link is related to which? etc etc.
For this stage the process is rather (kinda) simple.
out of the packet capture, using HTTP::Sessionizer,
http://search.cpan.org/~edeca/HTTP-Sessioniser-0.05/lib/HTTP/Sessioniser.pm,
the pcap analysis component of the tool takes all URLS visited (and other data) and loads them into a database with the following information:
mysql> desc map;
+————+—————+
| Field | Type
+————+—————+
| stem | varchar(1000)
| url | varchar(1000)
| hostname | varchar(1000)
| referrer | varchar(1000)
| exe_flag | int(11)
| start_flag | int(11)
| md5 | varchar(32)
+————+—————+
As it loads them in it will ascertain whether or not a file is of executable type or not or if it is a start_flag, this is determined by the honey-client site visit list which is tied to the pcap, (while useful is not necessary for the tool to operate but helps with accuracy)
Once it has identified executable content + associated link it will take that link and start the following:
1) take link referrer and hop back until start link or no referrer.
2) IF no referrer check to see if other links on the same hostname, IF so group those into the case as well.
It will create zip case files such as:
http://honeynet.org.au/release/Trigona/case.tgz
(taken from the Honeynet project challenge)
http://honeynet.org/challenges/2010_2_browsers_under_attack
and also put the executables identified into a separate folder for you to then feed into whatever system you wish to use.
Set and forget 🙂
There are a number of improvements that I’m currently working on for the Packet Capture Analysis component but if I waited to release when these were all done you’d be reading this in a years time hehe.
– Addition of regex’s to aid in detection of exploit kits, as this tool will only identify them IF a successful binary is dropped
– Addition of extra detection methods to identify the malicious drop to then start the link hopping.
— i.e. kit specific content i.e. Phoenix, Mpack, other cool named exploit kits etc etc.
— Anti-virus scan
— Snort like signatures to detect drops
— ability to identify XOR’d drops designed to evade such network detection on the fly. i.e. exploit downloads data where the MZ header is obfuscated to evade detection
– self learning, IF an exploit site is identified it is saved in the database and used to flag malicious chains/infected urls/drops instead of finding the executable drop.
i.e. hacked_site –> exploit site –> binary drop
currently will only work based on the binary drop and then walk backwards.
next iteration will flag a known exploit site then walk both ways to find the hacked_site and the drop. 🙂
any other suggestions?
Where can I find the tool? (Our Tools Site)