Hacking for hoodies

MISP edition

 Posted on October 23, 2025  |  22 minutes  |  4619 words  |  Jeroen Pinoy

1. Background

Photo by Alexandre Dulaunoy, as found on flickr.

1.1. Start of MISP involvement, concerns

I have been using MISP since 2019, and started contributing with minor commits in 2020. Since then I have become more and more involved with the project, both professionally and as a hobby. I absolutely love the project, and especially the people involved.

I’ve seen 3 main areas where there is room for improvement when it comes to MISP:

  1. Test coverage: Some functionality (especially if it is not mainstream) is not consistently tested, either manually or using automation. This leads to concerns with regards to operational stability and security, for example with regards to ACL.
    • That being said, there are existing automated test cases: these are available in the MISP and PyMISP repos.
  2. Documentation: Documentation is sometimes lacking in key areas, including API specification, operational procedures, best practices, and user processes. There are a lot of cool features in MISP which are tough to find, and use, because of this.
  3. User interface Needs rework to be up to modern standards -> to be Sammified.

The first two above, are the areas I personally wanted to invest more in.

Before continuing, please note I have quite a lot of knowledge of the business logic and flows of MISP. This means it is probably much easier for me to spot certain issues than for the average functional tester or pentester looking at MISP.

1.2 Motivation

Just like a lot of people, I do look for a sense of purpose in life. Personally, I decided to focus on:

  • Being as kind and helpful as I can to others, without letting myself get abused by people that take advantage.
  • If possible (I don’t want to starve), do things that I feel contribute to society.
    • Professionally
    • As a hobby
    • Make them beautiful, as easy to understand as possible, and well thought out
  • Be able to help defend my core values and way of life. In the current geopolitical landscape, this also means being able to help contribute to defend my nation / region.
  • Share knowledge by teaching

Contributing to things that have a positive impact on the world or society, and that are long-lasting, feels amazing to me. Imagine having contributed to building a castle like below for example. It would be something that gives me satisfaction for the rest of my life. Photo by Rachel Davis on Unsplash

Now while a castle like this is fancy and beautiful, I’d get as much satisfaction (if not more), from contributing to a building that is used for essential services, like a fire station. The building might not look as fancy (and it doesn’t have to), but it has to be functional, secure, and well-designed. Photo by Tomas Eidsvold on Unsplash

I get this same type of feeling when contributing to (open source) tools, like MISP! While my contributions mainly consist of testing and documentation, I believe this also improves the overall product.

Some other things about my personal motivation that I feel are noteworthy:

  • Like most people, I prefer doing stuff that leads to a “finished” product or task.
  • I like technical/intellectual challenges.
  • I want to make sure I continue to have good job opportunities, on top of being able to defend (and potentially attack) systems.
    • Gaining pentesting, vulnerability research and red teaming skills, makes sense from this perspective.
    • Same thing with improving or keeping up programming skills (Python, PHP, …) -> This is somewhat on hold because of other priorities.
  • A sense of “belonging”, while not something I’m very consciously pursuing, is still something that does affect me as well.

*Photo by Thomas Bormans on Unsplash. Ticking boxes is nice ;).

1.3 The plan

A couple years ago, I switched jobs and became responsible for multiple MISP instances and communities at a large international organisation. Since I had professional experience with web application testing, test automation, system administration and incident response, my original plan for contributing to the MISP project was to:

  1. Get familiar with my new role
  2. Gain more experience with MISP administration
  3. Review MISP code and functionality in my free time
  4. Build automated testing for MISP
  5. Update MISP documentation based on my work experience, test results, and experimentation

Things didn’t exactly go as planned, but I did continue to have a look at MISP and related products. At a high level the plan remains the same

A core benefit from this type of hacking activities, is that the knowledge I gain from my open source tool involvement helps me in my day job, and vice versa.

1.4 First “security”/tool review, getting familiar with Cerebrate - November 2024

My involvement with MISP led me to the discovery of Cerebrate. When I look at new tools, my first three questions are:

  1. Can it help me (or my organisation)?
  2. How is it built?
  3. Do the people involved wear cool hoodies? While this might be a joke, knowing the people involved in the project are “good” and have a sense of community, is definitely important to me.

I am very excited about the future of the Cerebrate project, as there are several potential use cases for my team, which would make my life a lot easier:

  • Contact management.
  • MISP sharing group management.
  • Creation of e-mail lists for specific communication flows.
  • MISP community management (approval flows for access, maintenance of organisation and user details).

As I planned to use Cerebrate to help with MISP community management, I installed it to see what functionality it had at that moment. This exploratory testing led to a list of bug fixes in Cerebrate release 1.26 and Cerebrate release 1.27, including patches for 5 security issues:

1.5 Starting MISP code review - December 2024

Having gotten a taste of finding security vulnerabilities (and being challenged by Iglocska?), I decided to start reviewing MISP code, focusing more on the security aspects. My goals were to:

  • Improve my understanding of MISP
  • Help improve the software, by finding and reporting vulnerabilities
  • Improve my understanding of web application testing from a security point of view
  • Get to a point where I personally felt like I’d “deserve” to wear a MISP project hoodie :), due to the amount of effort I invested in the project.
    • I also thought this can be a nice “milestone” to think of for other projects as well. This would allow me to have a collection in the future, helping me to trigger memories of moments and social interactions in the past.

My existing knowledge of potential security issues came from:

  • Education
    • Bachelor applied informatics studies
    • Master Computer Science studies
    • Offensive Security Penetration With Kali Linux material (I had gone through most of it)
    • Hack The Box academy training material (didn’t study this much)
  • Prior work experience, including testing/attempting to bypass some security patches

2. The MISP software

2.1. A short intro to MISP

MISP is an open source threat intelligence and sharing platform. It is written in PHP using the CakePHP Model-View-Controller framework.

This means that anyone with a decent understanding of imperative programming languages and MVC frameworks, should be able to review the code to some degree.

The main goal of the application is to allow sharing of, and collaboration on, cyber threat intelligence.

I typically present MISP use cases using a slide like the one below. Giving a more “concrete” example of things you can track about an adversary, such as intent, techniques and mitigation strategies. The reasoning behind this kind of teaching approach, is that it is difficult for people to understand abstract concepts from the get go. If you can gradually move from something concrete to more abstract, it helps people understand a concept more easily.

In a second step, I then give an example of how the same thing can be tracked and share for cyber related information, such as a targeted phishing mail campaign.

2.2. MISP communities

MISP is intended to be used in a network of connected instances or “communities”. Each community can have many organisations on it. This setups allows easy integration and collaborating between different communities.

In the example above you can see a community with a focus on the private sector, for example banks, interconnected with a community run by a national computer emergency response team (for example CIRCL). This last community is then in turn connected to a community with a more military focus.

2.3. MISP architecture / interconnections

MISP has an extension mechanism called MISP modules. These are standalone additions to MISP, which can be used to extend import, export, enrichment, and other automation capabilities (workflows) of the platform. These are written in python, and hosted as a separate web service, typically only accessible through MISP.

While best practice is to have these modules installed on a separate server, by default, these were installed on the same server in the past.

As you can see in the image above, there are quite a few modules which allow a user to query internal or external services.

2.4 Specific areas of interest for a potential attacker

  • XSS vectors, especially if the exploit can be synced as part of event data and only requires passive user interaction. The reason why this is very powerful, is that you can potentially make the payload spread to MISP instances you don’t have direct access to.
  • REST Client -> potential SSRF vector (seems to be locked down though).
  • Getting unauthorized access to, or abusing “normal” access to MISP modules.
  • Configuration of interconnections (API keys, tokens). As connections to quite a few of the internally or externally accessed services also require authentication, through api keys for example, managing to access the settings of these modules in cleartext can also lead to lateral movement.
  • Logs / audit logs
  • Distribution / sharing group management. Being able to change these when you shouldn’t be, can give you access to confidential data for example.

2.5 Specific areas of interest for defenders - logging, monitoring and incident response

To be extended but you can always have a look at:

3 White box review of MISP

3.1 The approach

As MISP is very regularly pentested by people that have extensive knowledge of web application security, it made no sense to me to try to use the same approach with fuzzing etc…

As I know the code base and app quite well, I decided a white box approach would make more sense for me.

3.1.1 OWASP top 10 as initial inspiration

Image of the OWASP top 10 changes between the version of 2017 and 2021

Having a list to trigger some initial ideas can be helpful in my opinion. In this case I had a look at the OWASP top 10 again, to see what I could pay attention to while doing my review of MISP. I was somewhat surprised to see broken access control at the top. I decided to focus on these types of issues:

  • Broken access control
  • Injection
  • Insecure design
  • Security misconfiguration
  • Server-side request forgery

3.1.2 Focus on critical components

There were 4 critical components that came to my mind to look at first, since they are closely related to access control:

  • The ACLComponent. This controller contains core ACL logic, defining which permissions are required to acess certain endpoints. This also allows you to quickly check which pages are accessible to anyone, and which have very limited access.
  • The users controller. Responsible for user management actions (add, edit, delete).
  • The authkeys controller. Responsible for api key management.
  • Logs and audit logs. Logged user and system actions can be found here. This includes fairly detailed changes to data and MISP settings, meaning broken ACL can quickly lead to data leakage.

Examples of findings

3.1.3 Look for (potentially vulnerable) code patterns

While I did know some code patterns or strings that can lead to issues already, I decided to ask LLM to see if that can come with something nice, and it did. I typically combine these kind of queries with normal search engine queries as well (Kagi, Google).

This approach basically consists of looking for specific strings in the code, and then reviewing the code arround it and the code flow. In the case of potential XSS, this means verifying whether user or other type of provided input, is properly sanitized before being used in a view.

Example finding

3.1.4 Review previously disclosed vulnerabilities and their fixes

From time to time, security fixes don’t seem to be 100% complete. Sometimes it’s not easy to spot all the places in the code where there is a similar issue. Looking at historical changes for security fixes can give inspiration for things to look for or check, to see if the same issue was still present elsewhere, or was introduced somewhere else later.

Example findings

3.1.5 Just review the code line by line

This takes quite a bit of work, but leads to findings which aren’t always spotted by LLM for example, especially if the code files are big, which is the case in MISP sometimes.

Example finding

3.1.6 Review latest commits

In this case, catching an issue can help a fix get introduced fast, and hopefully reduce the risk of exploitation.

Example finding

  • Remark: This functionality was broken at the time of reporting, so it wouldn’t have been exploitable unless an administrator went through a lot of trouble to set up the functionality. It is also not advised to install/enable this module for outsiders. CIRCL feedback is to only use this internally/locally with strict access control. HTML injection in convert markdown to pdf module

3.1.7 Blog posts and articles as inspiration

The most interesting example here was work done by Mizu, which was in the “Top 10 web hacking techniques of 2024” of Portswigger.

While it took some tweaking and theorycrafting, using this blog as inspiration led to the discovery of 2 XSS vulnerabilities in MISP event reports. One of them was unrelated to the technique described, and required the attacker to have a domain name of maximum 5 characters (ab.cn for example). While this perhaps sounds impossible or very expensive, it turns out it is not. I currently have 2 such domains registered myself, and one of them only costs me 20 euro/year.

The particularly interesting part of this XSS vector in MISP, is that it was syncable, as MISP event reports get synced as part of events. This means the payload could be spread to connected instances. Combined with two other vulnerabilities I found, which could have allowed an attacker to inject the payload into other people’s events, even using a “read only” user, this vector could have been extremely powerful (config dependendant). Note that multiple threat intelligence providers have a MISP instance they use to share threat intelligence with their customers, given them at least a read only user on their instance.

3.1.8 (Online) pentesting training as inspiration

Example: Hackthebox academy injection attacks module.

Example finding (not MISP)

Shoutout to https://swisskyrepo.github.io/PayloadsAllTheThings/LaTeX%20Injection/#read-file for this as well. The examples helped to find working exploits.

3.2 Benefits of (white box) approach

  • I found things in code which wasn’t even functional at the time. A black box approach wouldn’t have caught those.
  • Spotting an issue in one area, allows you to quickly pivot and look for similar issues elsewhere in the code, for example using code pattern searches.
  • You can follow the program flow, either by reading the code, or by using a step debugger.

3.3 Disadvantages of (white box) approach

  • I made assumptions about what code is secure.
    • “limit” operation in CakePHP ORM was apparently vulnerable to SQL injection at some point, which I didn’t know. I would never have caught this issue with my approach.
  • Code review takes quite a bit of time
  • Reviewing LLM or other automated output such as the one of static code analysis tools, requires filtering out a lot of false positives

4 Recommendations based on the code review

4.1 For MISP users

  • Update MISP and your other tools frequently
  • Review AuthKey creations
  • Push for more testing, internally as well
  • Limit site admin usage.
  • Monitor site admin activity
  • Install MISP-modules on a separate server or container
  • Limit site admin page access to allowlisted IP range if possible

4.2 For the MISP project team

This includes myself and sort of everyone who is very actively using MISP for core mission functions.

4.2.1 Project management

  • Continue focusing on fostering community engagement
    • Having more contributors is always a good thing
    • Gathering of use cases and feedback
  • Look into optimizing automated testing flows
    • Something I intend to contribute to
    • Include some pentest/fuzzing automation
    • Perhaps use LLM as well as part of code review flow

4.2.2 Restock on hoodies :)

I hope I will inspire some other ethical hackers.

5 Personal lessons learned

  • You don’t have to have crazy in depth security knowledge to find real issues
  • It’s fun to do this kind of research
  • Sometimes, all it takes is a 5 minute look at a recent commit, to spot a potential issue and report it

5.1 Bug bounty and implications of income linked to reports

While I didn’t get any bounties (except for hack.lu admittance and a hoodie, which are awesome enough), and didn’t actively participate in any bug bounty programs, I did end up having some thoughts on ethical and financial dilemmas.

  • Bug bounty programs often pay out per vulnerability. My approach meant that I regularly found a similar vulnerability in multiple endpoints. To maximize pay-out in a bug bounty scenario, reporting these as separate issues could have been a strategy.
  • Bug bounty programs (likely) don’t pay out for things that can’t be currently exploited in default configuration. In the example of the HTML injection vulnerability I found, it might have paid off to wait until the code was “patched”, before reporting the vulnerability.
  • If there is truly a way to get a lot of money for some vulnerabilities through “shady” companies, this could be tempting for people, especially if they have very low income otherwise.
  • Re-testing/confirmation of a “fix” is important, and should be paid as well.

5.2 Developer interactions

Interacting and socializing with developers can be really cool. I can only say positive things about the people involved in MISP (and other CIRCL tools).

5.2.1 Reporting issues

Every developer is different, some people take it more personally than others when you report an issue. I do try to keep the personality of the developers in mind when I reach out, and I would advise others to do the same.

That being said, I still don’t know what the “best” approach is. I am currently trying to:

  • Stick to the facts, just provide a good description of the issue
  • Confirm the issue is an actual issue is possible, and report as soon as I am confident there might be a problem
    • Sometimes I can’t get a working version of the app, so there’s no way, but in 95% of the cases I managed to give a working reproduction scenario
  • Provide as much info as possible
    • I can often point to the exact point in the code where there seems to be a problem. When doing black box testing, having knowledge of programming also helps me to give a description of how the logic might be broken.

5.3 Personal motivation

While at times I questioned whether it made sense to spend as much time as I did, I realized I love this kind of research / work.

One thing to note is that even when an app doesn’t have any issues, I still find it valuable to “confirm” that. It’s the “assurance” part of product assurance which I believe is very important. I want the tools I use to be reliable and secure, and to always feel confident that they are. This requires proper procedures and testing. Contributing to that, is also rewarding to me, even if it that effort might not be noticed by others. A specific example here is my effort to check if there were XSS vulnerabilities in Cerebrate. I couldn’t find any, despite spending quite a lot of time on that. While this doesn’t guarantee there aren’t any, it does increase my trust in the product and the framework used.

6 Next steps

  • Similar work -> continue on this path
  • MISP sync review
  • Work on documentation
  • Set up personal MISP automated testing project / strategy

7 Fun tidbit

Before I started this research, I had no idea SVG images existed, or that there are image formats which can contain executable Javascript. I never expected that clicking like below can lead to a javascript redirection to a youtube video for example (this example is not particularly malicious but still odd to me):

Note: there are also more serious issues with SVG, so be careful when allowing users to upload or use these in your web app!

8 Acknowledgements

8.1 CIRCL

Thanks to all the team members at CIRCL. You guys do so much good for the world, and I truly appreciate that! You are all super nice to interact with, and these interactions honestly help keep me going, even in tough times.

Apologies for the perhaps spammy reports at times :).

8.2 Nerdy friends

  • Thank you Matthew for always being awesome, and for being available for technical discussions! You definitely helped sorting out the short domain thing. Also, get the dogs snipped!
  • Lawrence, thanks for the help with XSS payloads and the fun discussions about pentesting / bounty hunting.

9 Security related commits as result of my reports - Up to 20251022

As extension to my code review of MISP, I also had a look at some other CIRCL tools. I am including a list of security related commits which were the result of my reports below. Most of these are from the period of November 2024 until October 2025.

I’ll add the amount of time I estimate I spent on reviews of these projects between brackets.

9.1 MISP (200-300 hours)

9.1.1 Tagged with name (32)

9.1.2 Not tagged with name (1) - silent patch

9.2 MISP-Modules (1) - (2-3 days)

9.3 Cerebrate (5) - (80 hours, a lot of time went into understanding part of the code and looking for potential XSS)

9.4 Vulnerability-lookup (7) - (60 hours)

9.5 Lookyloo (1) - (20 hours)

9.6 Flowintel (1) - (20 hours, mainly looking into Latex injection possibilities)

9.7 Rulezet (2) - (10 hours)

MISP  security research