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

The team working on the ICS/SCADA honeypot Conpot, just merged in a more mature support for STIX (Structured Threat Information eXpression) formatted reporting via TAXII (Trusted Automated eXchange of Indicator Information) into the master branch on Github.

STIX allows us to represent event sessions captured by the honeypot in a structured format, which eases the integration of Conpot into existing consumer (e.g. SIEM) infrastructures.

By transforming an arbitrary honeypot event into a schema defined format, we are able to communicate an incident in a language, which is also understandable by someone not trained in interpreting industrial protocol messages.

The Conpot team recently introduced what we call the proxy module. Basically we forward the traffic from one service in Conpot to a service running on a real piece of hardware. This is a very successful technique when figuring out a unknown hardware or protocol. Next step then is to decode the messages logged in the proxy module. Most of this step is done by studying books of specifications, leaked manuals and offensive tools. This then gives us insight into the protocol, the commands sent and responses generated.