|
| 1 | +GSoC Project Ideas in no particular order. When you've picked one, take a look at [[How-to-Apply-to-GSoC]] for how to make a proposal. |
| 2 | + |
| 3 | +Mentors: [@jheysel-r7](https://github.com/jheysel-r7) |
| 4 | +Co-mentors: [@zeroSteiner](https://github.com/zeroSteiner) [@h00die](https://github.com/h00die) |
| 5 | + |
| 6 | +Slack Contacts: @jheysel, @zeroSteiner and @h00die on [Metasploit Slack](https://metasploit.slack.com/) |
| 7 | + |
| 8 | + |
| 9 | +For any questions about these projects reach out on the Metasploit Slack in the `#gsoc` channel or DM one of the mentors |
| 10 | +using the Slack contacts listed above. Note that mentors may be busy so please don't expect an immediate response, |
| 11 | +however we will endeavor to respond as soon as possible. If you'd prefer not to join Slack, you can also email |
| 12 | +`msfdev [@] metasploit [dot] com` and we will respond to your questions there if email is preferable. |
| 13 | + |
| 14 | +## Enhance Metasploit Framework |
| 15 | +### CertificateTrace and KerberosTicketTrace Support |
| 16 | + |
| 17 | +Kerberos and certificate-based authentication mechanisms are becoming increasingly prevalent across modern environments, |
| 18 | +particularly in Active Directory and enterprise deployments. As a result, Metasploit modules that interact with these |
| 19 | +authentication flows often require operators and developers to inspect Kerberos tickets or certificate material in order |
| 20 | +to understand behavior, troubleshoot failures, or validate exploitation techniques. Today, this inspection typically |
| 21 | +requires switching to separate auxiliary modules or exporting artifacts (such as .pfx files) for analysis with external |
| 22 | +tooling, which interrupts the normal workflow. |
| 23 | + |
| 24 | +This project would introduce CertificateTrace and KerberosTicketTrace functionality to Metasploit, allowing relevant |
| 25 | +authentication artifacts to be captured and inspected as part of module execution. Similar in concept to the existing |
| 26 | +HttpTrace capability, these traces would focus specifically on certificate and Kerberos-based authentication, decoding |
| 27 | +and presenting useful metadata in a consistent, operator-friendly format. Similar to HttpTrace and HttpTraceHeadersOnly, |
| 28 | +we would expect there to be support for different levels of logging, ex: print only the Certificate Signing Request (CSR). |
| 29 | + |
| 30 | + |
| 31 | +Mentors: @jheysel-r7, @zeroSteiner |
| 32 | +Size: 175 hrs |
| 33 | +Difficulty: Medium |
| 34 | +Required Skills: Understanding of how Kerberos and certificate-based authentication work; ability to write and deliver Ruby code. |
| 35 | +Preferred Skills: Experience working with or using Kerberos and/or certificate-based authentication. |
| 36 | + |
| 37 | +### Automated Vulnerable Environment Provisioning (build_vuln) |
| 38 | + |
| 39 | +Many Metasploit modules—particularly those targeting web applications or open source software—include documentation |
| 40 | +describing how to build a vulnerable test environment, and some provide vulnerable container images to simplify this |
| 41 | +process. However, this information is typically maintained in module documentation and requires users to manually build |
| 42 | +and start the environment outside of Metasploit, making module verification more time-consuming and inconsistent. |
| 43 | + |
| 44 | +This project proposes a new Metasploit command (for example, build_vuln) that automates launching a vulnerable |
| 45 | +environment for a given exploit module. Vulnerable environments would be defined using Open Container Initiative |
| 46 | +(OCI)–compliant configurations and designed to work with both Podman and Docker, with rootless execution. |
| 47 | + |
| 48 | +The goal of this project is to automate setup steps that are already documented today, making it easier for users to |
| 49 | +test exploits locally and for contributors and Rapid7 engineers to verify module behavior in a repeatable, |
| 50 | +well-defined environment. This project would include refactoring existing modules to leverage the new functionality |
| 51 | +where possible (docker-compose files already exist), as well as creating new vulnerable environment definitions for |
| 52 | +popular modules that lack them today. |
| 53 | + |
| 54 | + |
| 55 | +Mentors: @jheysel-r7, @h00die |
| 56 | +Size: 360 hrs |
| 57 | +Difficulty: Medium |
| 58 | +Required Skills: Understanding of how containers work in the context of the Open Container Initiative; ability to write and deliver Ruby code. |
| 59 | +Preferred Skills: Experience using containers; understanding of container definitions and best practices. |
| 60 | + |
| 61 | +## Submit your own |
| 62 | + |
| 63 | +If you want to suggest your own idea, please discuss it with us first on [Slack](https://metasploit.com/slack) in the |
| 64 | +`#gsoc` channel to make sure it is a reasonable amount of work for a summer and that it fits the goals of the project. |
0 commit comments