This repository houses a collection of tools to build and run a distributed spamtrap system that is comprised of IMAP- as well as SMTP-collectors and an analysis backend. This repository builds to Python-projects, spamtrap-backend and spamtraps, and provides several Dockerfiles and Dockerized setups to run such a system.

In-depth documentation of the project can be found here: https://jgru.github.io/spamtrap-system/

• Synopsis
• Usage
  • Quick Start
  • Instructions for Single Components
• Todo

The collectors constitute the spamtraps and transfer the collected spam via AMQP or Hpfeeds to the backend. There, the (mal)spam will be automatically decomposed and analyzed with the help of a sandbox, e.g., Cuckoo or Tria.ge, and Thug. The ultimate goal of the system is to gather actionable threat intelligence regarding the infrastructure used by malware, which is accomplished by evaluating the results given by the sandbox and utilizing MalConfScan. Results are persisted a MongoDB instance. In order to assist analyses, relevant results can be pushed into an Elasticsearch instance with a Kibana frontend, a Karton analysis pipeline, or a MISP instance where threat intel analyst could query the collection.

This project aims to be modular to a large extent, so that further collectors or reporting components could be added easily.

To quickly get started with the modular system, a docker-compose.yml-file is provided which serves starts the services connected to the backend, i.e.,

• processing backend
• MongoDB
• Hpfeeds broker (without TLS protected)

To run it, just use the following command:

docker-compose up

For detailed instructions regarding the installation, deployment and usage of each component, refer to the readme-files on installation in the subdirectories.

The IMAP-collector and the fake open SMTP relay can be used right off the deck after having installed the requirements listed in the respective requirements.txt-file. To run the SMTP fake destination SMTP server, the TLS-protected Hpfeeds-broker, the Elastic stack or the MongoDB just use the docker-compose-files within periphery-directory.

The installation of Cuckoo is a bit more involved and time consuming. Therefore, an Ansible role can ease the setup of this malware analysis sandbox. See https://github.com/jgru/ansible-cuckoo-virtualbox for further information.

There are several things that could be added and improved.

• ☒ Add a reporting module to deliver the results into a MISP-instance
• ☒ Add Hatching Tria.ge API-usage as an alternative to the on-premise operation of a Cuckoo-sandbox
• ☒ Add a reporter to push malspam into a pipeline of Karton-tasks
• ☒ Make enriching optional
• ☒ Make MongoDB ingestion optional
• ☐ Add an option to ingest the decomposed malspam into mwdb
• ☐ Add lookups for threat intel services, like Shodan, URLhaus, GreyNoise v2, VT, etc.
• ☐ Conduct performance tests
• ☐ Your idea…;)