MISP-maltego
MISP-maltego copied to clipboard
Support multiple MISP Servers
A potentially easier way would be when generating the mtz file, to also have a parameter in the configuration file to have the name of the MISP instance (ex.: superSecretServer), and also use that name in the transform folder within Maltego from MISP_maltego to MISP_maltego (superSecretServert).
This would allow users to create access for as many MISP instances as they want, and they could also easily select from which MISP instances that they can query.
This is a challenging task.
Config wise we could allow misp_url
, misp1_url
, misp2_url
, ... The code could multithread to do the background requests in parallel to speed up things.
We would also need to keep track from which MISP server the MISPEvent
and MISPObject
come from, otherwise we would not be able to pivot from there. Attributes don't need a reference, nor do Galaxy items (for now) as they use te public Galaxy repo.
Visually we'd also need to have a way to show where it comes from. Idea's on doing so are welcome.
When implemented feature request #18 From Maltego to MISP will also have a considerable impact.
A few years ago as I've detected canari I started nearly the same work as this project but I never get that far. Once upon that time my code was able to work with different MISP URLs.
While searching with pymisp against your mentionend misp
---------------------------------
| MISPEvent <entity> |
---------------------------------
| misp_url: <source url> |
| EventID: 4711 |
| .... |
For further pivoting based on a entity I did a lookup if misp_url was set in the entity and used that url for the next pymisp requests (getting objects, attributes, etc). I have to admit that I've ended up somewhere around here and I guess the challenges starts here since I never minded about where I need references and where not. IIRC I also saved the source misp url in attributes and objects and this broke the maltego correlation since I wasn't able to query a misp url attribute against other misp instances to see of other knows more about it. Yeah - challenging but I would like this feature too. If it would be interesting I could search my attic for the old (and maybe dirty) code.
Visually we'd also need to have a way to show where it comes from. Idea's on doing so are welcome.
Is this that mandatory? As long as I may have different external links right to the relevant MISP Events/Attributes in form of their misp urls I may find the information source in my browser. But one may create different colored iconsets for misp event entites and do s.th. in the config like:
misp1_url: https:....
misp1_key: 12345asdf....
misp1_color: blue
...
After that it may be possible to use the misp_event_icon_{{color}}.png
in the graph to have different colored Items?!
In regards to visual: yes, your idea is an option. I was also thinking about http://maltego.blogspot.com/2019/02/fun-with-flags.html?m=1
In regards to the URL: indeed, this is an option on MISPEvent
level, might also need to happen on MISPObject
level.
On the other hand, the same event (uuid) could be on two distinct MISP Servers. So we might not need to store the URL at all. The MISPEvent
display name should definitely change to something more human friendly and not instance specific.
It would still be interesting to be able to track where it came from, to support the analyst.
The config file (and remote server) will indeed need to be changed to support such a list of multiple servers. Let's not forget those that use remote transforms.
Requests to each MISP server (when searching for attributes, ...) should happen in parallel (multithreaded) to prevent unneeded slowdowns.
I believe Maltego's limitations will prevent us to have separate transforms for a specific MISP instance. (so one Search in MISP X
and one Search in MISP Y
)
But we could consider adding an optional parameter to the transforms to allow people to manually create their own transform configuration manually (in Maltego) and specify a specific MISP server in the transform settings.
Pull Requests are definitely welcome if you're able to work on this!