Australian Honeynet Project

Current Members
Ben Reardon - Member
Chris Horsley - Member
Gerald O'Reilly - Member
David Zielezna - Member
Kayne Naughton - Member
Shaun Vlassis - Chapter Lead
Changes in the structure of your chapter
We have been very lucky to increase the number of full time members of the team this last 12 months.
Kayne, Gerald and Chris joined the ranks of the team.
Deployments
We currently have a few disparate network honeypots deployed however are in the process of redesigning how we collect/share and distribute the information we gather.
Research & Development
Both Shaun,Chris and Ben have been involved in the recent GSoC projects with Chris mentoring a project related to Splunk attack graph visualisation, Shaun mentoring a project on Network Sinkholing and Ben mentoring a project on webviz.
We are actively looking at all our existing systems, many of which require a lot of TLC, and updating/rewriting so that they are easier to maintain, use and open up to more local collaborators that historically has been difficult to bring on board.
Interactions with the security community
We have recently this year created a new security discussion mailing list for Aussies in the Incident Responder/Malware analysis space as currently there is no real community for people interested in or working in those fields to get together and discuss things that they are seeing/doing.
Our very own Ben also ran one of the Forensic Challenges, FC10 - Attack Visualisation !
How to interact with our chapter
We are able to be contacted via [email protected] as well as via our discussion list on [email protected]
Goals
Last year we grew our chapter by 3 people and in the coming year we will be looking for more people that are interested in getting involved more closely with the project.
For the coming year we will be focusing on creating and fostering a better community for Incident responder/Malware researchers here in Australia through collaborative discussion and botnet proliferation monitoring.
MISC Activities
All members of the Australian chapter are regularly chatting away on the mailing lists and IRC :)

While the quantity of submissions for FC10 was lower than usual - we had expected this because of the amount of work required to submit plus being over the Christmas break - the quality of the solutions was really inspiring.

Of course the hardest part was deciding the winners, and as expected the traditional scoring method was not ideal for this type of challenge because the challenge was about creating and developing ideas, rather than just answering a number of dry questions. Quite a few people people used the challenge not so much to win a prize, but to have fun, develop an idea they've had, practice on some real datasets, learn, and teach. This was exactly the spirit we'd hoped for, so thanks to everyone for putting in a big effort.

The Winners and their solutions:
Fabian Fischer - solution

Chris Horsley - solution

Fraser Scott - solution

Dan Gleebits - solution

Johnathan Tracz - solution

The standout theme in the submissions for me was the use of interactive and flexible tools to analyse the data. As we move further into the big data world, its going to be imperative to get inside the data interactively to understand it. Some of the solutions focused on developing brand new applications/frameworks to interactively data sets - Check out the submissions from Fabian and Chris as really good examples of this. While Fraser put forward the idea of rendering images in 3D - which is not that far-out an idea actually, why not?!.

We hope that this challenge was enjoyable for those who participated, and for those downloading the submissions for inspiration. These challenges have a long legacy, we see people downloading, attempting and referencing these challenges and the solutions for education purposes years afterwards, so they are an important program at the Honeynet Project.

It would be great to see solutions to future forensic challenges use visualization, not only to analyse and detect trends, but also to describe the problem space to the layperson. With that said - the next Forensic challenge, FC11 should be released shortly - so stay tuned.

And lastly, if anyone wants to develop their ideas further, a good way (i.e. get paid if you are accepted!) is to get involved in our upcoming Google Summer of Code program GSOC12

Head on over to the main GSOC blog to see some updates from a project that I've been mentoring through the Honeynet Project Google Summer of Code (GSOC) 2011 program. It is now half way through the program and while there is still lots of work to do, the results are starting to surface. Have a sneak peak (you'll need chrome or Firefox) at the interactive malware globe prototype while it is still on ogzy's site, and here is a snapshot of it.

Its been great working with my student Oguz Yarimtepe. We've been experimenting with some "out there" ideas, and learning lots along the way.
Also, make sure you check out the other 11 HP GSOC projects. All students passed the mid term reviews and the results so far are really encouraging. It's great to see some useful ideas like Android malware analysis and detection tools, and wireshark snort signature plugins get some rubber on the road.

The 2011 Annual Honeynet Project workshop was hosted in Paris, France from 21-25 March 2011. For the first time, we included a open public day. We hope this becomes a permanent fixture, as the feedback from attendees was excellent. The slides for this event can be found here. As well as the presentations, there was a "Capture the Flag" exercise that was occurring throughout the day.

The Australian Chapter contributed to the workshop by presenting on VOIP security during the public day and a demonstration on creating time animated geographic heatmaps of malicious IP's.

Highlights for me were:

• Learning about the research that many chapters are doing in the mobile malware space, particularly within the Android platform. Mobile malware is one of the Honeynet project's priority research areas.
• Many ideas and feedback on data visualization techniques.
• The growing awareness of the need to mature our data analysis capability, in order to compliment our already impressive data collection technologies.
• The many break-out workshops, including some very productive sessions for our upcoming Google Summer of Code program.
• And of course the food, forging new friendships and refreshing old ones with many HP members from around the globe.

Thanks, and congratulations go to all those Honeynet project members involved in organizing this event, and thanks to the ESIEA Engineering School in Paris for providing the facility.

With the increase in popularity of VOIP telephony, attacks are becoming more prevalent. The compromise of a VOIP system can cost the victim over $100,000 in real cash. For example, an Australian based company suffered $120,000 in toll fraud as a result of a VOIP compromise.

Combining two of our interest areas (VOIP attacks and visualization), through Dataviz Australia I compiled a video which is intended to be a high level (if not stylized) visualization of the early stages of a cyber criminal compromising a VOIP system.

CLICK to see video.

Following is a brief summary of our activity and contributions during 2010:

Organisation
2010 saw the addition of David Zielezna as a contributor to the Project.
We are now:
- Shaun Vlassis, HP full member, Chapter lead.
- Ben Reardon. HP full member, member of the HP Public relations and membership committees
- David Zielezna. Contributor, and in charge of AHP infrastructure.

2010 Annual Honeynet project workshop, Mexico City
Shaun and Ben attended the 2010 Annual workshop and presented to the group on VOIP attacks and honeypots, development of malware data visualization techniques, and defacement tracking.

Forensic challenge 4
Development of Forensic challenge FC4, which dealt with VOIP attacks.

GSOC 2010
Participation as a co-admin and mentor for the Honeynet Project's Google funded GSOC 2010 initiative.

Conferences

The Australian High Tech Crime Conference, HTCC2010 8 September 2010
Presentation: VOIP Honeypots

Melbourne Branch: Australian Information Security Association (AISA) 12 August 2010
Presentation: The Honeynet project and Data Visualization for Security Purposes

Sydney Branch: Australian Information Security Association (AISA) 15 September 2010
Presentation: HiTech Crime and Honeypots

Ballarat Innovation, Communication and Technology Cluster 15 June 2010
Presentation : Honeynet Project

AusCERT Conference, Gold Coast Queensland. May 2010

References
We were pleased to see work on VOIP attack analysis referenced in academic paper delivered at the Australian Digital Forensics Conference by Craig Valli "An Analysis of Malfeasant Activity Directed at VoIP Honeypots"

Highlights of 2010

Sharing our work at the Annual workshop

Collaboration with the Norway Chapter on VOIP honeypots, and Forensic Challenge FC4

Collaboration with the many students and mentors during GSOC 2010

Developing new ways of understanding malicious activity by using data visualization tools

Collection and analysis of honeypot data indicating a substantial malicious activity against VOIP (SIP) servers.

Continued development of Honey Client system Trigona

Goals for 2011

Seek to identify and analyse NEW and less understood data sets and attack vectors

Attend and present at the first ever Public Honeynet Project workshop in March 2011

Continue development of data visualization techniques on data sets

Continue VOIP activity research

Continue development of Trigona and other tools

Crooks use any communication medium available to them, and SMS is no exception. We've seen malware and phishing attempts using SMS in the past, however it doesn't seem all that common in the last year.
Although last week, I received a couple of these spams via SMS while overseas (to my roaming Australian phone number).

This style of scam is correctly known as "Advance Fee Fraud", also unfairly known as Nigerian or 419 scam. I did some word analysis of the email version of this scam here a couple of years ago.

Do you get much SMS spam ? What do you do with it ?
In Australia, you can report SMS spam to ACMA by simply forwarding the SMS to their number. They automatically acknowledge receipt and action them as appropriate. You can find more about this service at the ACMA website.

As an aside I'm wondering if the fact that I was in another country adds to the usual jurisdictional issues that arise in the cybercrime world, i.e assuming that some sort of crime(s) has occurred, where did it occur? Whose law prevails? This normally matters a lot in terms of which jurisdiction should action. Who should investigate?
- The country of the relay (Australia)?
- The country where I received the spam (in Asia) ?
- The country where the sending phone number/email reside (Ghana)?
- The country where the advertised phone number is (UK)?
- The country of the email supplier (AOL) ?

@benreardon

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?
@ http://honeynet.org.au/release/Trigona/TRIGONA-v1.0.zip

It's time for another quick analysis of a prevalent SIP scanner that has been active for the last 4-5 months. It is particularly interesting because it is spreading like a worm, seems to use multiple scanning techniques (ssh and SIP) and acts like a botnet.

This scanner likely responsible for the uptick in port 5060 (SIP) scanning noted on this SANS Internet Storm Center diary entry. We noticed this scanner first hit our honeypots on July 8, at the same time SANS posted the note about significant increase in UDP port 5060 (SIP) scanning.

First of all, here is a redacted version of the contents of a typical scan:

Source: 124.89.88.18:5060
Datetime: 2010-07-09 hh.mm.ss
Message:
OPTIONS sip:100@honeypot_IP_removed SIP/2.0
Via: SIP/2.0/UDP 192.168.1.9:5060;branch=zqwehwebK-0523432245;rport
Content-Length: 0
From: "sipsscuser"<sip:[email protected]>; tag=removed
Accept: application/sdp
User-Agent: sundayddr
To: "sipssc"<sip:[email protected]>
Contact: sip:[email protected]:5060
CSeq: 1 OPTIONS
Call-ID: removed...
Max-Forwards: 70

Note the order and layout of the SIP headers is very similar to that of the sipvicious tool, which I described in an earlier blog entry. This suggests that a modified version of sipvicious is being used. It is trivial to modify sipvicious in this way, just by changing the python script.
- "sundayddr" replaces the usual "friendly-scanner" in the User-Agent header
- "sipsscuser" replaces the usual "sipvicious" in the From header
- The source extension is now set to [email protected], changed from [email protected] in original sipvicious tool.

Up till today (this analysis and graphics were done in early in August) we now detected these scans coming from hundreds more IP addresses. This indicates we are dealing with a botnet, not the opportunistic scans from single IP's that we more often see. Of course it is technically possible that UDP spoofing could be the cause of these multiple IP's, but it is reasonable to rule this out in this case, as it would not make any sense to spoof the UDP messages because the attacker would not get a response to the SIP scan.

Note there are a lot of scans coming from IP addresses in China. I feel it is important to point out here that this is *not* attribution of anyone in China necessarily, rather it just means that seemingly a lot of these Chinese IP addresses may be compromised and are taking part in this scanning activity.
The geographic heatmap of IP's that have been conducting scanning against out honeypots, also shows a large amount of activity from Chinese IP space. We have results from 4 honeypots located in vastly separate countries, including Australia. There is nothing special about the IP's of the honeypots, thus the extent of scanning on the wider internet is likely be vastly more than the 4 honeypots have recorded.

Note the prevalence of Unix-like machines. Apparently there are even a couple of compromised Printers that are scanning. Makes me wonder when we will see our first Internet enabled fridge, coffee machine, or garden watering system attacking our sensors (yes its entirely likely...).

Note that the vast majority are running ssh on port 22. Also note the filtered ports, and port 4444 (Metasploit?). There are a lot of explanations for ports being open,filtered and closed, including port forward/NAT, load balancing, however it is interesting to note the number of ssh servers involved in the sample set.

Although we haven't located the kit responsible for this, here is a theory put forward by a security colleague, and which is fairly strongly supported by our results: The scanning network most likely consists of Unix-like systems that offer ssh login, and that have weak passwords that can easily be brute forced, and the sequence of events may be as follows.

1. Server 1 scans a range of IP's and looks for ssh servers
2. It finds that Server 2 is running ssh, and attempts to brute force logins. It succeeds and thus compromises Server 2
3. While logged in to Server 2 via ssh , Server 1 runs a simple shell script on Server 2.
4. The shell script pulls down a "kit" from some location onto Server 2. The kit contains the modified sipvicious scanner, and an ssh brute force scanner from a remote site. It most likely uses common tools that are pre-installed on many ssh servers, for example 'wget'. This kit is that unpacked and run on Server 2.
5. When run, the script causes Server 2 to scan a set of networks for SIP servers, some of which include our SIP honeypots.
6. Server 2 then scans a set of networks for ssh servers, finds and compromises Server 3, and the whole cycle repeats in an automated, worm-like fashion.

This scanner is still very active today. An IP from China scanned one of our Australian honeypots as I was writing this, on 27 October 2010.

Using a self propogating/botnet-like infrastructure is just another evolution of malicious SIP scanning, and it is evident that more and more development is being put into systems that can automate the discovery of vulnerable SIP servers, for subsequent nefarious use.

Security professionals and system administrators are aware of the well known problems associated with "open mail relays". Spammers actively seek out these poorly configured email servers, and then take advantage by getting the relays to send out vast amounts of SPAM.

However, probably not many know that in the world of VOIP, a very similar concept exists.. Here, crooks scan for VOIP servers that are so poorly configured to accept and re-route (relay) incoming calls without carrying out proper checks on the source, blindly relaying these calls through either the victim's ISP, or through the PSTN (non VOIP) network. The concept is also similar to a "default route", in that if the VOIP server doesn't know the number being called, it will just re-route the call. The crooks then simply sell time/calls on this system on the underground market, and the victim picks up the bill at the next monthly billing cycle, whereupon the amount can be staggering. For example in 2009, a Perth business was left with a phone bill of $120,000 after 11,000 calls were made through their compromised VOIP system, read the story here.

In 2008, open SIP relay scanning activity was noted in Germany, and an excellent write up can be found here.

In the last 4 days, our Australian based SIP honeypot has detected this same activity. It seems that this group(s) are currently scanning Australian IP space in an attempt to find these open relays, to use at a later stage.

The following is an example of activity of a open relay scanner currently doing the rounds in the Australian IP space.
_____________________________________________________________

Source: 202.71.111.5:2452
Datetime: 2010-09-16 22:02:52.041018

Message:
INVITE sip:001133155xxxxxx@honeypot_ip_removed;transport=udp SIP/2.0
Via: SIP/2.0/UDP 202.71.111.5:2452;branch=1010110111000011111110101111011
202.71.111.5honeypot_ip_removed2107160275;rport
Max-Forwards: 70
From: ;tag=33632504215-229557263363250421533632504215202.71.111.5
To:
Call-ID: 787774ee110111100110101010001000100011011010110111000011111110101111011
202.71.111.5honeypot_ip_removed2107160275149dc6a001133155xxxxxx33632504215-229557263363250421533632504215202.71.111.51027572984
CSeq: 1 INVITE
Contact: [email protected]:2452;transport=udp>
Content-Type: application/sdp
Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, REFER,
REGISTER, SUBSCRIBE, UPDATE, PUBLISH
User-Agent: eyeBeam release 1003s stamp 31159
Content-Length: 212[email protected]:2452;transport=udp>

v=0
o=- 16264 18299 IN IP4 honeypot_ip_removed
s=CounterPath eyeBeam 1.5
c=IN IP4 honeypot_ip_removed
t=0 0
m=audio 33478 RTP/AVP 18 0 8 101
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/80

_____________________________________________________________

Note the following:

• The scan came from 202.71.111.5, in Malaysia
• The user agent says "User-Agent: eyeBeam release 1003s stamp 31159", which is a popular soft phone, but this is faked in an attempt to appear legitimate.
• The Call-ID contains all sorts of encoded data, including the IP of the scanner and honeypot, phone number etc. This is not a properly formatted SIP field.
• The telephone number that the relay attack is trying to dial, is a number in France 001133155xxxxxx (obfuscated here). Note the 0011, which is to get an overseas trunk out of Australia, followed by France's Country Code of 33.

This is just another sign that the crooks are actively scanning for vulnerable VOIP servers, and Australia is certainly not escaping their attention. Now may be a good time to conduct a review and/or pentest VOIP systems.

@benreardon