[Bug] MineMeld_1_0 Obesrvable not reaching destination. #773
Comments
|
Can you share your config, redacting as necessary? Have you checked TheHive/Cortex logs for clues? |
|
Thank you for responding so quickly Wes. I am confident it has something to do on the Cortex-side, as the action to run the job from TheHive to Cortex, does successfully kick off the Responder. When tailing the Cortex application log (/var/log/cortex/application.log) in the container, during execution, the following is observed:
It is showing as successful, but giving warnings about SSL. After invoking the job from TheHive case, I did confirm calls were made over 443 from the Cortex Server to the MineMeld server via tcpdump and that the IPv4 list is in-place. This was validated via the Job History on Cortex as well: Cortex-Responder Configuration: MineMeld IPv4 Node Configuration:
I'm not sure if I'm missing anything. I am running MineMeld VERSION: 0.9.68. Currently, our work-flow workaround is to use this script to manually update indicators to MineMeld: https://live.paloaltonetworks.com/t5/minemeld-articles/uploading-list-of-indicators-to-minemeld/ta-p/162242 We're looking to replace that with your responder! Really appreciate your help in looking into this issue. |
|
A quick addition to my previous response, it does seem that the responder is trying to submit an update to the list, and the behavior is repeatable: See below tail on /opt/minemeld/log/minemeld-engine.log IP Submissions sent from TheHive start at each Polling cycle: Next thing I did was manually add an indicator to that list and sure enough, the behavior is identical to TheHive calls.
Definitely a head scratcher. |
|
Hi Wes, Wanted to pass an update. We can close this issue out. The issue was that the list in MineMeld needs to use the class: stdlib.localDB I would highly reccomend updating the documentation to ensure that when a user configures a list, they use this class within MineMeld. Best Regards, mparis1 |
|
Hi @mparis1, I can't recall if this information was already in the documentation for an example Minemeld node, but we'll certainly consider calling this out, if needed. Glad to hear your issue is resolved, and you are able to use the responder as intended! |
Describe the bug
Submitting observable (ip) from TheHive to the responder MineMeld_1_0 successfully runs, however the indicator does not get added to the target indicator_list. (no errors returned).
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Currently, when performing this operation, the observable gets submitted to the job queue in Cortex, however the observable does not get posted to the MineMeld list.
It is expected that the indicator once submitted by TheHive, will get posted to the defined list.
Complementary information
Work environment
Possible solutions
If applicable, indicate possible solutions to the problem.
Additional context
This is the docker compose of my deployment:
version: "3.2"
services:
elasticsearch:
image: elasticsearch:6.8.9
environment:
- http.host=0.0.0.0
- discovery.type=single-node
- thread_pool.index.queue_size=100000
- thread_pool.search.queue_size=100000
- thread_pool.bulk.queue_size=100000
ulimits:
nofile:
soft: 65536
hard: 65536
cortex:
image: thehiveproject/cortex:3.0.0-RC3
depends_on:
- elasticsearch
ports:
- "0.0.0.0:9001:9001"
volumes:
- "/home/ubuntu/cortex/Cortex-Analyzers/responders:/opt/Cortex-Analyzers/responders"
thehive:
image: thehiveproject/thehive:latest
depends_on:
- elasticsearch
- cortex
ports:
- "0.0.0.0:9000:9000"
#volumes:
#- "/home/ubuntu/thehive/application.conf:/etc/thehive/application.conf"
command: --cortex-port 9001 --cortex-key [key]
The text was updated successfully, but these errors were encountered: