mail to misp - Email in your threat intel

I receieve a lot of spam and malware via email. Sometimes I can't be bothered to do much with it, but recently I've been picking up doing things with the samples I have been sent. Ever thought about setting up your own "this is a phish button" in your email client? If so, this post may be for you.

TLDR: I made a container for Mail_to_misp, whcih you can find here: https://github.com/phpsystems/mail_to_misp_docker

MISP or the (Malware) Information Sharing Platform is custom built and designed to share samples of, well, malware and phishing with other people and systems. MISP allows peering of different instances along as well as supporting automation. It is not just limited to Malware and phishing attacks, it can also share IP addresses, urls, files, hashs and a whole lot more.

Mail_to_MISP is a program which converts emails to MISP events. It also comes with a fake SMTP Daemon to receive email directly from a server. The code base is quite old and is problematic to get working, particularly with a new version of python. For some reason, the components never seem to line up properly. At the time of writing, the code base also looks like it hasn't been touched in quite a while.

Using old software is not without it's own risks. There could be old dependency issues, bad coding, who know what could be wrong with it. And you don't get any support with it. Not to mention, the security and risk nightmare something like this could turn out to be.

From an architecture perspective, when faced with running something like this, I would look to isolate the code as best as possible. To be clear, the best way to do this would be in it's own isolated virtual machine. This does have the right level of separation that you could run a something like this without being a risk to the rest of the network.

For my purposes, however, I am going to use a docker container to run the tool. I don't want it exposed to the internet, I'm going to redirect mail from my patched main mailserver for that. Containers will provide a certain level of isolation, but it is not as complete as a vm. Also, under no circumstances expose it directly to the internet at large, if you must use a vm for that and limit it's access and consider a WAF infront of MISP.

The first main issue I ran in to with mail_to_misp is that there didn't appear to be an official docker container. This lead me in to the world of creating one, starting off by defining a Dockerfile.

So what is a Dockerfile?

A Dockerfile is a file called "Dockerfile" which describes how to build and run the container. It starts with specifying the base image of the container. I chose a python variant, since misp_to_mail is written in that language. The specific variant is Python 3.8.10. While not the latest version, this was at least found to work with the smallest amount of issues.

After the base has been specified, you can run a number of other commands to build in to your image. Each "RUN" command generates another layer in the final container. Each layer adds to the final size of the container, so it makes sense to reduce these as much as possible. In my case, I separated out the requirements between mail_to_misp itself, and a software that was installed as a pre-requiste. The advantages of using mutltiple layers, is that you can cache these layers. If you change the Dockerfile, the rebuild will start on the first layer that was modified and above.

Lastly, we have an entrypoint which is a command that is run when the container is deployed and running.

After quite a bit of playing around, I got the container working. There were some interesting quirks, such as the container must be run in interactive mode, or the fakesmtp daemon will just exit.

The final code can be found on my github here: https://github.com/phpsystems/mail_to_misp_docker and the container itself can be run via the command:

docker run \ 
  -ti 
  -v ./config:/config 
  -p 25:2525
  ghcr.io/phpsystems/mail_to_misp_docker:latest