Intel Owl is an Open Source Intelligence, or OSINT solution to get threat intelligence data about a specific file, an IP or a domain from a single API at scale. It integrates a number of analyzers available online and is for everyone who needs a single point to query for info about a specific file or observable.

Born at the start of 2020 (announcement), this fresh and new tool was accepted as part of the Google Summer of Code under The Honeynet Project. Great improvements have been developed since the start of this project.

The Honeynet Project recently appointed a new Chief Research Officer, Tamas Lengyel.  We want to thank again Lukas Rist for leading and growing our research over the past years, and welcome Tamas that accepted the role.

Tamas is Chapter Lead of Malware Analytics at Scale (MAS) and has been an active GSoC mentor over several years now with Honeynet. In his day job he is Senior Security Researcher at Intel, where he is focusing on low-level system security research, primarily working with hypervisors and firmware. He is a maintainer of the Xen Project Hypervisor, LibVMI and the DRAKVUF binary analysis system. Tamas received his PhD from the University of Connecticut and regularly publishes at top-tier academic conferences. He gave talks at conferences such as BlackHat, CCC and Microsoft Digital Crime Consortium.

The Honeynet Project Workshop 2019

Hotel Grauer Bär

Universitätsstraße 5-7

6020 Innsbruck, Austria

July 1st–3rd, 2019

https://austria2019.honeynet.org/

The Infection-Monkey team for GSoC 2018 wrote this post as a project summary of their GSoC 2018 experience

Team:

Student: Vakaris Žilius

Mentor: Daniel Goldberg

Introduction

During GSOC 2018, Vakaris worked with me on the Infection Monkey.

The Infection Monkey is an open source security tool for testing a data center’s resiliency to perimeter breaches and internal server infection. The Monkey uses various methods to self propagate across a data center and reports success to a centralized Monkey Island server.

Abhinav Saxena wrote this post as a project summary of his GSoC2018 experience.

What did we achieve?

The following features and changes were implemented:

• Migration of the codebase from Python 2.7 to Python 3.5 (issue #358, code: #374)
• Implementation of FTP (RFC 959) and TFTP (RFC 1350) protocol stacks based on gevent (issue #352, code: ftp and tftp)
• Implementation of an abstract filesystem that proxies and wraps an actual file system by providing os.* wrappers (code: #375 and #382)
• Wrote 123 unit tests and refactored all existing 44 unit tests, increasing coverage from 44% to 72% at the time of this writing  (code: #374, #375 and #382)
• Bug fixes and refactoring of the existing BACnet and IPMI protocol stacks (issue #341, code #382)
• Bug fixes in auxiliary Docker files (issue: #378, code: #380 and  #392)
• Refactoring of an existing telnet library to be compatible to the Conpot codebase (issue #285, code: mushorg/telnetsrvlib)
• Wrote an internal interface implementation that introduces a decorator, allowing protocol servers to interact more deeply with each other.  (issue #259, code #375)
• Helping users with issues and pull request reviews: link

All commits can be seen here and here.

After successfully participating in GSoC between 2009 and 2017, and having created or extended many honeynet technologies that have since gone on to become industry standard tools, we are very happy to announce that The Honeynet Project has applied to be a mentoring organization once again in GSoC 2018.

While last year’s GSoC saw significant changes to the program structure, the program has not seen major adjustments this year. We are very happy that the new payment model and the added third evaluation came to stay! At Honeynet, we collected extensive feedback from mentors last year and will use that to improve our students’ experience - more on that later. Based on the very positive feedback from last year, we’ll definitely continue to use our now not-so-new-anymore GSoC Slack channel and we are excited to talk to you there!

Analysis of 24 Hours Internet Attacks: A Brief Overview of Malicious Traffic Targeting Featureless Servers on the Web.

Bots_Keep_Talking_To_Us

This is a contribute by HoneyNED chapter from the Netherlands about all their 2017 activities.

As the end of the year has come, we from HoneyNED, the Dutch Honeynet chapter, want to share what has happened during the year. We have worked on several projects in the honey space and a few members represented our chapter at the annual Honeynet workshop hosted in Australia. In this post, we will discuss what honeypots have been deployed, what projects are in the pipeline and what will be the focus in 2018. But let’s start by thanking the Honeynet community for all knowledge sharing, collaboration and code-sharing.

The Honeynet Project annual workshop is just few days away, members and security folks from all over the world will gather in Canberra, Australia November 15th-17th. Every year the Honeynet Project, with the support of Google, funds a bunch of students that were admitted to the Google Summer of Code program and successfully completed their project assignments. They will have a chance to travel to the workshop and meet face to face with honeynet members and grown up experts in the security field.

Student Mohammad Bilal contributed this post as a project summary of his GSoC2017 experience. 

Merged Pull Requests

1- Connection Timeout Added

Issues Resolved: #72, #59
Description Glutton support number of services (protocol handlers) so each service mean number of connection on that service. So It crash after some time with error: [user.tcp] accept tcp [::]:5000: accept4: too many open files, and this error was due to the allowance of limited number of open file descriptors by the operating system. There was no deadline set for opened connections so most of the connections never get closed. In result, the number of opened connections gradually cross the maximum open file descriptors limit and cause panic. So I added connection timeout = 72 second, number of opened connection will never reach the open file descriptor limit. Another reason was Freki; Glutton useses freki as a networking core so freki handler crashes because of improper error handling in Glutton. So I improved error handling of protocol handlers and glutton stops crashing.