Skip to content

Contribute

How to add your own MISP modules?

Create your module in misp_modules/modules/expansion/, misp_modules/modules/export_mod/, or misp_modules/modules/import_mod/. The module should have at minimum three functions:

  • introspection function that returns a dict of the supported attributes (input and output) by your expansion module.
  • handler function which accepts a JSON document to expand the values and return a dictionary of the expanded values.
  • version function that returns a dict with the version and the associated meta-data including potential configurations required of the module.

Don't forget to return an error key and value if an error is raised to propagate it to the MISP user-interface.

Your module's script name should also be added in the __all__ list of <module type folder>/__init__.py in order for it to be loaded.

...
    # Checking for required value
    if not request.get('ip-src'):
        # Return an error message
        return {'error': "A source IP is required"}
...

introspection

The function that returns a dict of the supported attributes (input and output) by your expansion module.

mispattributes = {'input': ['link', 'url'],
                  'output': ['attachment', 'malware-sample']}

def introspection():
    return mispattributes

version

The function that returns a dict with the version and the associated meta-data including potential configurations required of the module.

Additional Configuration Values

If your module requires additional configuration (to be exposed via the MISP user-interface), you can define those in the moduleconfig value returned by the version function.

# config fields that your code expects from the site admin
moduleconfig = ["apikey", "event_limit"]

def version():
    moduleinfo['config'] = moduleconfig
    return moduleinfo

When you do this a config array is added to the meta-data output containing all the potential configuration values:

"meta": {
      "description": "PassiveTotal expansion service to expand values with multiple Passive DNS sources",
      "config": [
        "username",
        "password"
      ],
      "module-type": [
        "expansion",
        "hover"
      ],

...

If you want to use the configuration values set in the web interface they are stored in the key config in the JSON object passed to the handler.

def handler(q=False):

    # Check if we were given a configuration
    config = q.get("config", {})

    # Find out if there is a username field
    username = config.get("username", None)

handler

The function which accepts a JSON document to expand the values and return a dictionary of the expanded values.

def handler(q=False):
    "Fully functional rot-13 encoder"
    if q is False:
        return False
    request = json.loads(q)
    src = request.get('ip-src')
    if src is None:
        # Return an error message
        return {'error': "A source IP is required"}
    else:
        return {'results':
                codecs.encode(src, "rot-13")}

Tagging and untagging attributes

A result of an expansion module can also carry tags. Next to values and types, a result entry accepts:

  • tags - tags to attach to the attribute the entry resolves to,
  • remove_tags - tags to take off the attribute the event already holds for that value.

Both accept a list or a single tag name.

return {
    "results": [
        {
            "types": ["ip-dst"],
            "values": ["198.51.100.10"],
            "tags": ["misp-module:verdict=\"benign\""],
            "remove_tags": ["false-positive"],
        }
    ]
}

remove_tags is how a module retracts a verdict - its own from an earlier run, or one another module left behind. The tags are matched against the attribute in the enriched event with the same type and value as the entry, which is usually the attribute the enrichment was triggered on, echoed back by the module:

def handler(q=False):
    if q is False:
        return False
    request = json.loads(q)
    ip = request.get("ip-dst")
    if ip is None:
        return {"error": "An ip-dst attribute is required"}
    if not is_false_positive(ip):
        return {"results": [{"types": ["ip-dst"], "values": [ip], "remove_tags": ["false-positive"]}]}
    return {"results": []}

Worth knowing about the way MISP applies this:

  • When the event already holds the attribute, the entry is a tag change only - MISP does not try to create the attribute a second time, and the tags of the same entry are attached to the attribute it found. One entry can therefore swap one verdict for another. When the event does not hold the attribute, the entry creates it as usual and there is nothing to remove.
  • Only tags that exist and are actually attached to the attribute are taken off; a removal never creates a tag, and naming a tag that is not there is not an error.
  • Galaxy clusters are tags too, so misp-galaxy:... values can be removed the same way.
  • In the Enrichment Results screen nothing is removed behind the analyst's back: the tags show up in a Tags to remove field, where they can be edited or cleared before the results are submitted. The Enrich event and Enrich attribute background jobs have no such screen and apply the tag changes directly, as they do for the attributes a module returns.
  • The user the enrichment runs as needs tagging permission. When they cannot edit the event, the results come in as proposals and tag changes are skipped.

Attribute tags travel differently in the misp_standard format, where the returned objects and attributes carry their own Tag lists; remove_tags belongs to the simple format shown above.

export module

For an export module, the request["data"] object corresponds to a list of events (dictionaries) to handle.

Iterating over events attributes is performed using their Attribute key.

...
for event in request["data"]:
        for attribute in event["Attribute"]:
          # do stuff w/ attribute['type'], attribute['value'], ...
...

object enrichment

An expansion module can also be triggered on a whole MISP object instead of a single attribute. Instead of receiving one value, the module receives the object with all of its attributes, and it returns MISP objects and/or attributes that MISP proposes to add to the event.

To make a module available for object enrichment:

  • list the object template names your module accepts in mispattributes['input'] (object names and attribute types share the same namespace),
  • declare 'output': ['MISP objects'] and 'format': 'misp_standard',
  • read the object from the object key of the request in your handler.
mispattributes = {
    "input": ["domain-ip"],          # object template name, not an attribute type
    "output": ["MISP objects"],
    "format": "misp_standard",
}

Once the module is enabled, MISP shows the Add enrichment icon on every domain-ip object of an event, and the module is listed in the enrichment choice popup.

The request

MISP posts the full object, with its attributes inlined under the Attribute key:

{
  "module": "test_domain_ip_expansion",
  "event_id": "42",
  "object": {
    "id": "1337",
    "name": "domain-ip",
    "meta-category": "network",
    "template_uuid": "43b3b146-77eb-4931-b4cc-b66c60f28734",
    "uuid": "5a2b1c3d-0000-4000-8000-000000000000",
    "Attribute": [
      {
        "type": "domain",
        "object_relation": "domain",
        "value": "example.com",
        "uuid": "b2d1a2e0-0000-4000-8000-000000000001"
      },
      {
        "type": "ip-dst",
        "object_relation": "ip",
        "value": "198.51.100.10",
        "uuid": "b2d1a2e0-0000-4000-8000-000000000002"
      }
    ]
  },
  "config": {
    "apikey": "..."
  }
}

Attributes of an attachment type (attachment, malware-sample) also carry their content base64 encoded in a data key, so a module can process files attached to the object without touching the MISP filesystem.

Since object names and attribute types share one namespace, a module whose input list contains both will be offered in both contexts. In that case branch on which key is present:

request = json.loads(q)
if "object" in request:
    return handle_object(request["object"])
return handle_attribute(request["attribute"])
The response

Build the result with PyMISP and return the Object and Attribute lists of the event under the results key:

{
  "results": {
    "Object": [...],     # MISP objects to add to the event
    "Attribute": [...]   # standalone attributes to add to the event
  }
}

EventReport, Tag and Galaxy are accepted in results as well, and an optional top-level comment key overrides the default import comment shown to the analyst.

Nothing is written to the event directly: MISP renders the returned objects and attributes in the Enrichment Results screen, where the analyst picks what to keep.

Full example

The module below enriches a domain-ip object with a whois object and a standalone comment attribute. It has no external dependency, which makes it convenient to exercise the whole object enrichment flow end to end:

# -*- coding: utf-8 -*-
"""Test expansion module: enriches a `domain-ip` MISP object."""

import json

from pymisp import MISPEvent, MISPObject

misperrors = {"error": "Error"}

mispattributes = {
    "input": ["domain-ip"],
    "output": ["MISP objects"],
    "format": "misp_standard",
}

moduleinfo = {
    "version": "0.1",
    "author": "Luciano Righetti",
    "description": "Test module that enriches a domain-ip object with static data.",
    "module-type": ["expansion"],
    "name": "Test Domain-IP Expansion",
    "logo": "",
    "requirements": [],
    "features": "Takes a domain-ip object and returns a fake whois object plus a comment attribute.",
    "references": [],
    "input": "A domain-ip object.",
    "output": "A whois object and a comment attribute.",
}


def process_domain_ip(misp_object):
    domain = None
    ip = None
    for attribute in misp_object.get("Attribute", []):
        if attribute.get("object_relation") == "domain":
            domain = attribute.get("value")
        elif attribute.get("object_relation") == "ip":
            ip = attribute.get("value")

    if domain is None and ip is None:
        return {"error": "No domain or ip attribute found in the domain-ip object."}

    event = MISPEvent()

    whois = MISPObject("whois")
    whois.add_attribute("domain", type="domain", value=domain or "example.com")
    whois.add_attribute("registrar", type="whois-registrar", value="Test Registrar Inc.")
    whois.add_attribute("creation-date", type="datetime", value="2020-01-01T00:00:00+00:00")
    if ip is not None:
        whois.add_attribute("ip-address", type="ip-src", value=ip)
    whois.comment = "Enriched by test_domain_ip_expansion"
    event.add_object(whois)

    event.add_attribute(
        type="comment",
        value="test_domain_ip_expansion enrichment of {}".format(domain or ip),
        comment="Standalone attribute returned by the test module",
    )

    event = json.loads(event.to_json())

    return {
        "results": {
            "Object": event.get("Object", []),
            "Attribute": event.get("Attribute", []),
        }
    }


def handler(q=False):
    if q is False:
        return False
    request = json.loads(q)
    misp_object = request.get("object")

    if not misp_object:
        return {"error": "No object provided."}

    if "Attribute" not in misp_object:
        return {"error": "Empty Attribute list."}

    if misp_object.get("name") != "domain-ip":
        return {"error": "Wrong object type, expected a domain-ip object."}

    return process_domain_ip(misp_object)


def introspection():
    return mispattributes


def version():
    return moduleinfo

Note the guard clauses in the handler: an object enrichment module should always verify that an object was provided, that it carries attributes, and that its template is one it understands, returning an error otherwise so the message reaches the MISP user-interface.

Testing it

Save the request shown above as body.json and post it to the module server, exactly as for an attribute based module:

curl -s http://127.0.0.1:6666/query -H "Content-Type: application/json" --data @body.json -X POST | jq .

{
  "results": {
    "Object": [
      {
        "name": "whois",
        "meta-category": "network",
        "comment": "Enriched by test_domain_ip_expansion",
        "Attribute": [
          { "type": "domain", "object_relation": "domain", "value": "example.com" },
          { "type": "whois-registrar", "object_relation": "registrar", "value": "Test Registrar Inc." },
          { "type": "datetime", "object_relation": "creation-date", "value": "2020-01-01T00:00:00+00:00" },
          { "type": "ip-src", "object_relation": "ip-address", "value": "198.51.100.10" }
        ]
      }
    ],
    "Attribute": [
      {
        "type": "comment",
        "value": "test_domain_ip_expansion enrichment of example.com",
        "comment": "Standalone attribute returned by the test module"
      }
    ]
  }
}

sigmf_expand is an object enrichment module shipped with misp-modules that follows the same structure.

Returning Binary Data

If you want to return a file or other data you need to add a data attribute.

{"results": {"values": "filename.txt",
             "types": "attachment",
             "data"  : base64.b64encode(<ByteIO>)  # base64 encode your data first
             "comment": "This is an attachment"}}

If the binary file is malware you can use 'malware-sample' as the type. If you do this the malware sample will be automatically zipped and password protected ('infected') after being uploaded.

{"results": {"values": "filename.txt",
             "types": "malware-sample",
             "data"  : base64.b64encode(<ByteIO>)  # base64 encode your data first
             "comment": "This is an attachment"}}

To learn more about how data attributes are processed you can read the processing code here.

Module type

A MISP module can be of four types:

  • expansion - service related to an attribute that can be used to extend and update an existing event.
  • hover - service related to an attribute to provide additional information to the users without updating the event.
  • import - service related to importing and parsing an external object that can be used to extend an existing event.
  • export - service related to exporting an object, event, or data.

module-type is an array where the list of supported types can be added.

Testing your modules?

MISP uses the modules function to discover the available MISP modules and their supported MISP attributes:

% curl -s http://127.0.0.1:6666/modules | jq .
[
  {
    "name": "passivetotal",
    "type": "expansion",
    "mispattributes": {
      "input": [
        "hostname",
        "domain",
        "ip-src",
        "ip-dst"
      ],
      "output": [
        "ip-src",
        "ip-dst",
        "hostname",
        "domain"
      ]
    },
    "meta": {
      "description": "PassiveTotal expansion service to expand values with multiple Passive DNS sources",
      "config": [
        "username",
        "password"
      ],
      "author": "Alexandre Dulaunoy",
      "version": "0.1"
    }
  },
  {
    "name": "sourcecache",
    "type": "expansion",
    "mispattributes": {
      "input": [
        "link"
      ],
      "output": [
        "link"
      ]
    },
    "meta": {
      "description": "Module to cache web pages of analysis reports, OSINT sources. The module returns a link of the cached page.",
      "author": "Alexandre Dulaunoy",
      "version": "0.1"
    }
  },
  {
    "name": "dns",
    "type": "expansion",
    "mispattributes": {
      "input": [
        "hostname",
        "domain"
      ],
      "output": [
        "ip-src",
        "ip-dst"
      ]
    },
    "meta": {
      "description": "Simple DNS expansion service to resolve IP address from MISP attributes",
      "author": "Alexandre Dulaunoy",
      "version": "0.1"
    }
  }
]

The MISP module service returns the available modules in a JSON array containing each module name along with their supported input attributes.

Based on this information, a query can be built in a JSON format and saved as body.json:

{
  "hostname": "www.foo.be",
  "module": "dns"
}

Then you can POST this JSON format query towards the MISP object server:

curl -s http://127.0.0.1:6666/query -H "Content-Type: application/json" --data @body.json -X POST

The module should output the following JSON:

{
  "results": [
    {
      "types": [
        "ip-src",
        "ip-dst"
      ],
      "values": [
        "188.65.217.78"
      ]
    }
  ]
}

It is also possible to restrict the category options of the resolved attributes by passing a list of categories along (optional):

{
  "results": [
    {
      "types": [
        "ip-src",
        "ip-dst"
      ],
      "values": [
        "188.65.217.78"
      ],
      "categories": [
        "Network activity",
        "Payload delivery"
      ]
    }
  ]
}

For both the type and the category lists, the first item in the list will be the default setting on the interface.

Enable your module in the web interface

For a module to be activated in the MISP web interface it must be enabled in the "Plugin Settings.

Go to "Administration > Server Settings" in the top menu - Go to "Plugin Settings" in the top "tab menu bar" - Click on the name of the type of module you have created to expand the list of plugins to show your module. - Find the name of your plugin's "enabled" value in the Setting Column. "Plugin.[MODULE NAME]_enabled" - Double click on its "Value" column

Priority        Setting                         Value   Description                             Error Message
Recommended     Plugin.Import_ocr_enabled       false   Enable or disable the ocr module.       Value not set.
  • Use the drop-down to set the enabled value to 'true'
Priority        Setting                         Value   Description                             Error Message
Recommended     Plugin.Import_ocr_enabled       true   Enable or disable the ocr module.       Value not set.

Set any other required settings for your module

In this same menu set any other plugin settings that are required for testing.

Install misp-module on an offline instance.

First, you need to grab all necessary packages for example like this :

Use pip wheel to create an archive 

mkdir misp-modules-offline
pip3 wheel -r REQUIREMENTS shodan --wheel-dir=./misp-modules-offline
tar -cjvf misp-module-bundeled.tar.bz2 ./misp-modules-offline/*
On offline machine : 
mkdir misp-modules-bundle
tar xvf misp-module-bundeled.tar.bz2 -C misp-modules-bundle
cd misp-modules-bundle
ls -1|while read line; do sudo pip3 install --force-reinstall --ignore-installed --upgrade --no-index --no-deps ${line};done
Next you can follow standard install procedure.

How to contribute your own module?

Fork the project, add your module, test it and make a pull-request. Modules can be also private as you can add a module in your own MISP installation.

Tips for developers creating modules

Download a pre-built virtual image from the MISP training materials.

  • Create a Host-Only adapter in VirtualBox
  • Set your Misp OVA to that Host-Only adapter
  • Start the virtual machine
  • Get the IP address of the virtual machine
  • SSH into the machine (Login info on training page)
  • Go into the misp-modules directory
cd /usr/local/src/misp-modules

Set the git repo to your fork and checkout your development branch. If you SSH'ed in as the misp user you will have to use sudo.

sudo git remote set-url origin https://github.com/YourRepo/misp-modules.git
sudo git pull
sudo git checkout MyModBranch

Remove the contents of the build directory and re-install misp-modules.

sudo rm -fr build/*
sudo -u www-data /var/www/MISP/venv/bin/pip install --upgrade .

SSH in with a different terminal and run misp-modules with debugging enabled.

# In case misp-modules is not a service do:
# sudo killall misp-modules
sudo systemctl disable --now misp-modules
sudo -u www-data /var/www/MISP/venv/bin/misp-modules -d

In your original terminal you can now run your tests manually and see any errors that arrive

cd tests/
curl -s http://127.0.0.1:6666/query -H "Content-Type: application/json" --data @MY_TEST_FILE.json -X POST
cd ../

Documentation

In order to provide documentation about some modules that require specific input / output / configuration, the index.md file contains detailed information about the general purpose, requirements, features, input and ouput of each of these modules:

  • description - quick description of the general purpose of the module, as the one given by the moduleinfo
  • requirements - special libraries needed to make the module work
  • features - description of the way to use the module, with the required MISP features to make the module give the intended result
  • references - link(s) giving additional information about the format concerned in the module
  • input - description of the format of data used in input
  • output - description of the format given as the result of the module execution

Licenses

For further Information see also the license file.