This blog post is the first of a two-part series in response to the Wired article of Oct 14, 2014, “How Microsoft Appointed Itself Sheriff of the Internet.” [McM14] I find some problems with this article that raise questions about the depth of research into some elements of the story, and an appearance of bias in how “unintended consequences” are presented.

[McM14] Robert McMillan. How Microsoft Appointed Itself Sheriff of the Internet. http://www.wired.com/2014/10/microsoft-pinkerton/, October 2014.

A few months ago I read the paper “Technical analysis of client identification mechanisms” [1]. The paper is really interesting and it is really worth investing your time and reading. Just a brief excerpt from the abstract:

“In common use, the term “web tracking” refers to the process of calculating or assigning unique and reasonably stable identifiers to each browser that visits a website. In most cases, this is done for the purpose of correlating future visits from the same person or machine with historical data. Some uses of such tracking techniques are well established and commonplace. For example, they are frequently employed to tell real users from malicious bots, to make it harder for attackers to gain access to compromised accounts, or to store user preferences on a website. In the same vein, the online advertising industry has used cookies as the primary client identification technology since the mid-1990s. Other practices may be less known, may not necessarily map to existing browser controls, and may be impossible or difficult to detect. Many of them - in particular, various methods of client fingerprinting - have garnered concerns from software vendors, standards bodies, and the media.”

Thug 0.6 was released just a few hours ago. The most important change introduced during the 0.5 branch was a complete redesign of the logging infrastructure which is now completely modular. This makes adding (or removing) new logging modules extremely easy.

I did this change for a couple of reasons. The first one is that the logging code before Thug 0.5 was developed without a proper design but just adding the modules as soon as I needed them. I usually hate this approach so it would be enough to justify a complete redesign. But there was one more reason. I was aware that a few persons out there were implementing their own logging modules and binding them in some really awful ways to the main code (someone said plugins?). I spent a lot of time in documenting such changes. For these reason I will not dive into details in this post. But trust me. Extending Thug logging with your own modules should be an easy task now. Hopefully. Let me add that additional logging modules would be really appreciated so if you think your cool module should be included in the source tree please feel free to contact me.

Angelo, you have been HNP CEO for more than over a year now. What were your goals when you started and did you achieve them?

First of all let me confess that it seems really incredible to me that a year has already gone by. I took over the CEO position for the Honeynet Project from Christian Seifert more than a year ago and at times the role appeared quite intimidating to me. Christian and Honeynet Project founder Lance Spitzner did an awesome job of driving the organization
during the past few years and I used to think that walking in their footsteps would have not been that simple. Fortunately I receive a great amount of support from both of them to this day, as well great support from the Project Board of Directors, Officers and by all our members. I have to say that I am really proud to hold this role.

Join us! http://stavanger2015.honeynet.org/

Hello,

last week I published kippo fork https://gitlab.labs.nic.cz/honeynet/kippo
which contains commits from https://github.com/micheloosterhof/kippo-mo
(Michel Oosterhof brought awesome SFTP, and exec support)
and original kippo https://github.com/desaster/kippo
(I am very pleased is now on github. was on google code before).

On top of that are my changes:
- use shasum to store binaries from wget and SFTP (less disk space is used)
- store records about SFTP downloads in db
- log client IP and port in textlog
- log only info about downloads in textlog
- config file supports hpfeeds settings (more info in README)
- terminal doesn’t reset when user logs out (no clear screen in ttylog)
- accept port other than 80 in wget (difference from original kippo)

Howdy all,
The Italian Chapter is proud to release the latest version of dorothy2 (our ruby-based malware analysis framework) :).
The new features introduced by this versions are severals. A lot of work has been done on the core system, by making the whole system even more modular and customisable. A dummy webgui written in Sinatra has been also introduced, in order to let the analyst able to browse within the results. Binaries can now also be directly uploaded from the web.
A particular attention has been dedicated on the network part: on the sample’s resume page the analyst will now able to download the pcap of every single network flow in order to manually analyse it whenever needed.
This version also introduces the use of the “analysis profiles” which give the researcher the possibility to run analyses on a set of binaries by using different environments (OS versions, sandbox timeout, number of screens, etc). As it is known, some malwares might run only in specific environment and this feature could guarantee the successful execution of those. A CSIRT might also use this feature to test suspicious malwares only against an environment that reflects the one of its customers. Sources can also be configured to be automatically analysed by certain profiles (e.g. use Profile_Windows_30sc for all the binaries retrieved by Kippo_source).
Lastly, Dorothy is now able to fetch binaries also from a mailbox (also if an email is forwarded “As Attachment”). This could be useful for everyone who wants to setup an analysis email sinkhole, and redirects all the incoming SPAM there.

A few days ago I was contacted by our CPRO, Leon van der Eijk, and asked to write a blog post about my own project called Bifrozt; something which I was more than happy to do. :) This post will explain what Bifrozt is, how this got started, the overall status of the project and what will happen further down the road.

What is Bifrozt? Generally speaking, Bifrozt is a NAT device with a DHCP server that is usually deployed with one NIC connected directly to the Internet and one NIC connected to the internal network. What differentiates Bifrozt from other standard NAT devices is its ability to work as a transparent SSHv2 proxy between an attacker and your honeypot. If you deployed a SSH server on Bifrozt’s internal network it would log all the interaction to a TTY file in plain text that could be viewed later and capture a copy of any files that were downloaded. You would not have to install any additional software, compile any kernel modules or use a specific version or type of operating system on the internal SSH server for this to work. It will limit outbound traffic to a set number of ports and will start to drop outbound packets on these ports when certain limits are exceeded.

Finally we can announce with great pleasure the first public beta of the Beeswarm project. Beeswarm is an active IDS project that provides easy configuration, deployment and management of honeypots and clients. The project differentiates itself by two key items:

• • Active deceptions
• • Simplicity and ease of use

Active deceptions Normal honeypot deployments are passive - which means that if an attacker eavesdrop on the network he will never see any actual traffic to the honeypot, and therefore most likely ignore it making the honeypot virtually worthless. In contrast to others, Beeswarm operates by deploying fake end-user systems, called beeswarm clients, which simulates real users communicating with the honeypots using what we call bait sessions. These bait sessions are so fine grained that for interactive protocols like ssh and telnet the traffic patterns will match the typing speed of humans. The whole purpose of this scheme is to make the bait session traffic look legit and interesting to the hacker and lure him out of the shadows.

During the month of June the following information was obtained from Glastopf installations worldwide

Geographical spread

10 most popular injected files during the period

Short introduction to RFI:

“Remote File Inclusion (RFI) is a type of vulnerability most often found on websites. It allows an attacker to include a remote file, usually through a script on the web server. The vulnerability occurs due to the use of user-supplied input without proper validation. This can lead to something as minimal as outputting the contents of the file or more serious events such as: Code execution on the web server .. “ source: Wikipedia