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.
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.
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.
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
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.
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.
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.
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.
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.