Operationalizing VMRay UniqueSignal in MISP for detection, hunting and blocking
In the previous post, we covered how to connect VMRay UniqueSignal to MISP. This follow-up looks at how to put the feed to work in a SOC or CSIRT.
The objective is straightforward: turn threat intelligence into something analysts can trust, and push indicators to the places where they can be used. Some belong in blocking controls. Others are better suited to enrichment or historical hunting.
Why this matters
The problem is rarely a lack of data. It is too much low-value data reaching analysts and controls. Stale indicators, context-free observables and indiscriminate blocking all add noise. Curation has to happen before distribution, not afterwards when your SOC analysts are left to clean up the mess.
Start with what is already curated
VMRay applies curation before publishing to UniqueSignal. The feed is built from sandbox observations and enriched with context, so the output includes malware family labels, TTPs and confidence scores rather than bare observables. That context is what makes your triage faster: instead of having to research what an indicator means, analysts can immediately focus on what to do with it.
That said, no external feed can know your environment. Whether an indicator is actionable also depends on your own infrastructure, risk tolerance and operational context. That local judgement belongs in MISP.
Before going further, it is useful to set two tags on the VMRay feed itself, in the feed configuration in MISP. They make every later step easier:
-
curation:community="VMRay" marks every event as coming from VMRay. You will lean on this tag when you filter inside MISP or in the integrations covered later in this post.
-
admiralty-scale:source-reliability="a" records that you treat VMRay as a highly reliable source. The same tag lets you filter on source reliability during day-to-day work and optionally also from the integration configs.
First quality gate: MISP warninglists
The MISP warninglists are lists of values that are usually benign, or risky to block without a closer look, such as VPN ranges, cloud infrastructure or CDN addresses. When an attribute matches a warninglist, MISP flags it so analysts can take a second look before it ends up in a detection or blocking pipeline.
Pro tip: Maintain your own warninglists covering internal IP ranges, hostnames, domains and URLs, plus known infrastructure from critical partners. It prevents a lot of self-inflicted false positives.
Correlation as a quality signal
MISP correlates attributes automatically across all events in your instance. Correlation is useful for two reasons: it can raise confidence, and it can broaden context. If a VMRay indicator also appears in events from your national CSIRT, an ISAC or open-source feeds, that overlap helps confirm prevalence and gives you more investigative context. If a VMRay indicator has no correlation yet, that does not reduce its value. In many cases, it can mean the indicator was surfaced earlier than other sources. The key point is that UniqueSignal adds rich context either way, so analysts can move faster from indicator to action.
Warninglists catch shared infrastructure, but UniqueSignal also gives you metadata to judge whether an indicator is still worth acting on. The offline status tag, mostly relevant for network indicators, tells you whether the infrastructure is still live. The first seen date hints at how far back in your logs you need to look. The VMRay confidence score lets you narrow things down further, for example by keeping only the highest-rated entries (confidence VMRay UniqueSignal - Unlimited: 100.00). You can also use vertical classification to prioritize indicators by sector relevance. This is especially useful when storage and query performance matter, because it lets you keep high-priority, high-relevance indicators in fast operational datasets while moving lower-priority data to longer-term searches.
An indicator tagged as offline, or one last seen many months ago, is often not ideal for blocking but a good candidate for a retro hunt through historical logs. That covers a few situations: reviewing older events, investigating a compromise that may have started long before it was detected, or running a routine check for activity that slipped past your controls before the indicator was known to be malicious. In short, it gives you a second chance to spot intrusions you missed the first time around.
MISP will not perform the hunt, but it is the right place to assemble the work package your SOC takes to the log sources. A bare list of indicators does not tell the full story, so MISP lets you bundle related material into collections: the VMRay events you are working from, plus threat actor profiles or attack techniques. A collection can represent a campaign, an intrusion set or ongoing research. You find them under Event Actions > Collections; events and galaxy clusters also have sidebar buttons to add items directly to a collection.
Retro hunts with MISP workflows
You still need to choose which indicators actually go into the hunt. MISP workflows handle that nicely, either on an automatic trigger or on demand from Administration > Workflows.
A lightweight workflow can look like this:
-
Confirm that an analyst has reviewed the event and add an admiralty scale rating to record how reliable the information is.
-
Tag the attributes you want included so the workflow can pick them up.
-
Use the blocklist module to append them to a list the SIEM consumes.
-
Add an analyst note for traceability and tag the event so the rest of the pipeline knows it has been dealt with.
The same building blocks fit other situations too. During a CSIRT investigation, for example, the workflow can attach the relevant attributes to a case, notify the responders and tag the event as under investigation. Only the destination and the tags change.
Pushing indicators to Sentinel and Defender
Once you trust what is in MISP, the question becomes where to send it. Microsoft Sentinel and Microsoft Defender both consume threat intelligence, but they should not be fed in the same way. Sentinel supports detection and hunting, where a wider set is acceptable because nothing is blocked and users commonly see no impact. Defender can act on what it receives, so the bar has to be much higher.
Wider reach with MISP2Sentinel
MISP2Sentinel is a practical option for continuous detection support. It synchronizes selected MISP data into Microsoft Sentinel, where SOC teams use it in analytics rules, hunting queries and investigations. A pragmatic baseline configuration is:
-
Run as a scheduled task every 12 hours.
-
Include only events updated in the last two days, with a small overlap so a missed run of the scheduled task does not create a gap.
-
Apply indicator expiry in Sentinel so stale entries age out on their own.
That keeps the dataset focused and prevents long-term build-up of outdated entries. You do not need to filter explicitly for to_ids=True; MISP2Sentinel applies that automatically. A config snippet looks like this
misp_event_filters = {
“published”: True,
“tags”: [“workflow:state=\”complete\””],
“enforceWarninglist”: True,
“publish_timestamp”: “2d”,
}
days_to_expire = 50
Tighter control with MISP2Defender
Blocking hits live traffic immediately and can disrupt the business if you get it wrong, so what is fine for Sentinel detection should not flow straight into Defender. MISP2Defender sends vetted indicators from MISP into Microsoft Defender, but with a noticeably stricter quality bar. A straightforward policy is to only forward entries with high-confidence VMRay tags, for example confidence VMRay UniqueSignal - Unlimited: 100.00 or confidence VMRay UniqueSignal - Unlimited: 80.00.
The relevant MISP2Defender settings are the event filter, the vetting tags and the action Defender should take:
“published”: True,
“tags”: [“workflow:state=\”complete\””],
“enforceWarninglist”: True,
“publish_timestamp”: “2d”,
}
limit_vetted_attributes_from_specific_events = [“curation:community=\”VMRay\””]
vetted_attribute_classifier = [“confidence VMRay UniqueSignal – Unlimited: 100.00”, “confidence VMRay UniqueSignal – Unlimited: 80.00”]
defender_severity = “Medium”
defender_action = “Block”
check_if_already_in_defender = True
The workflows covered above run on demand or on an event-driven trigger. MISP also makes its data available through scheduled exports that security controls can pull at a fixed interval without any manual intervention.
A firewall, DNS resolver or proxy can be pointed at a MISP REST API export and configured to refresh on a regular cadence. The export passes through the same warninglist checks and tag filters as the rest of the pipeline, so the device always receives a pre-filtered list rather than raw feed output. This extends the quality controls already applied in MISP to any tool that can consume a plain-text or CSV list, without requiring a dedicated connector for each one.
The example below fetches a newline-separated list of IP indicators from events published in the last two days, restricted to VMRay as the source community and limited to the highest-confidence entries:
curl -s \
-H “Authorization: YOUR_API_KEY” \
-H “Content-Type: application/json” \
-H “Accept: text/plain” \
-d ‘{
“returnFormat”: “text”,
“type”: [“ip-src”, “ip-dst”],
“tags”: [
“curation:community=\”VMRay\””,
“&&confidence VMRay UniqueSignal – Unlimited: 100.00”
],
“publish_timestamp”: “2d”,
“to_ids”: 1,
“enforceWarninglist”: true
}’ \
https://YOUR-MISP-INSTANCE/attributes/restSearch
The && prefix on the second tag enforces AND logic: both tags must be present. Schedule this as a cron job and pipe the output to your firewall’s address feed or blocklist file.
Ad hoc handling for urgent cases
Even with scheduled synchronization, urgent cases still happen. Analysts may need to move indicators from a single campaign or event quickly.
MISP supports two quick paths without adding complexity.
The first is to navigate directly to the event and use the export function to download its attributes as a CSV file. That file can be loaded straight into a detection or blocking tool, with no connector required.
The second is to trigger a workflow from within the event itself. The export_sentinel module in a MISP workflow can push selected indicators from a single event to Sentinel or Defender immediately, bypassing the next scheduled synchronization run entirely.
Either path gives analysts the flexibility to act on a single campaign event when speed matters, while leaving the regular synchronization cycle undisturbed.
Closing takeaways
For SOC and CSIRT teams, the main benefit of using UniqueSignal in MISP is not volume. It is having indicators that are timely, relevant and supported by enough context to make sensible decisions.
In practical terms, that means:
· prioritizing indicators that are still actionable;
· using context, confidence and correlation to guide response;
· and choosing the right destination for each indicator, whether that is hunting, detection or blocking.
MISP provides the operational structure for that controlled distribution. Used this way, the process is easier to prioritize, introduces less noise for analysts and supports faster, safer response decisions.
