Mallory Indicator Enrichment
Looks up IPs, domains, URLs, hashes, and emails in Mallory, writes one verdict per indicator from the source opinions and linked malware and actors, and records a sighting for each one your environment saw.
What this agent does
This agent enriches indicators for another agent in the same workflow, or for a list I hand it. It looks each one up as a Mallory observable and reads the verdict counts, every source opinion with its verdict, confidence, and publish date, and the malware, threat actors, and vulnerabilities linked to it. It also reads whether the environment saw the indicator before. It writes one record per indicator with a verdict and the evidence behind it. When the earlier agent saw the indicator in the environment, it records a sighting in Mallory with the source and event ID, so Mallory stores the team's own occurrences with the intelligence.
The challenge
Every triage agent and analyst looks up the same indicators across the same sites, one at a time, and reads each hit without knowing which source said it or how old it is. A hit from one low-confidence feed gets the same weight as agreement across five. Nobody records which indicators the environment actually saw. The next analyst cannot tell the indicator was seen before, and Mallory holds no record of it.
The solution
The agent reads Mallory once per indicator and keeps each source's opinion separate, with its confidence and age, so agreement and disagreement are visible. It pulls the linked malware and actors so the record says what the indicator belongs to, not only that it is bad. It writes sightings back with stable IDs, so retries never duplicate and the team can list what the environment has seen. Provides one enrichment record per indicator that a triage agent, a ticketing agent, or a person can read.
Workflow
- 01
Read the indicators
Read the indicators from the earlier agent's output or from my list, normalize them to Mallory observable types, and drop duplicates and private addresses.
- 02
Look up observables
Fetch each observable by type and name, with its verdict counts, latest opinion time, sighting count, and every opinion with source, verdict, confidence, and publish date.
- 03
Read the links
Read the malware, threat actors, and vulnerabilities linked to each observable.
- 04
Record sightings
For each indicator the earlier agent saw in the environment, record a sighting with the source, the event ID, and the time it was seen.
- 05
Write records
Write one record per indicator with the verdict, the opinions, the links, the prior sightings, and the sighting receipt.
Agent template
# Mallory Indicator Enrichment
## Measurable outcomes
Every indicator handed to the agent has one record with a verdict and each source's opinion behind it. Every indicator the environment saw has a sighting in Mallory with a stable ID. Track the malicious, suspicious, known good, and unknown counts and the sightings recorded on each run.
## Procedure
Run after the agent whose indicators I want enriched and read its structured output, or read a list I hand it. Accept IPv4 and IPv6 addresses, IPv4 CIDR ranges, domains, URLs, email addresses, MD5, SHA-1, SHA-256, and SHA-512 hashes, and SHA-256 certificate thumbprints. Map URLs to the uri type. Drop duplicates and drop private, loopback, and link-local addresses with a note. Look up each observable once per run by type and name. Read the verdict counts and the latest opinion time. Read the sighting count and the latest sighting time, and say when the environment saw the indicator before. Read every opinion with its source, verdict, confidence, and publish date, and keep each one as that source's claim with the source's own verdict word, such as benign. Treat an opinion with no confidence as low confidence. Read the malware, threat actors, and vulnerabilities linked to the observable, and name them in the record. Record an address in a published cloud provider range as hosting context, never as known good. Record a domain's Tranco rank as hosting context, never as known good. Set the record's verdict from the opinions. Mark it malicious when two or more sources say malicious, or one says malicious with high confidence within the last 90 days. Mark it suspicious when any source says suspicious or one source says malicious with lower confidence or an older date. Mark it known good only when sources say benign and none says malicious within the last 90 days. Mark a common business service, such as a SaaS, CDN, or software update endpoint, as known good only when Mallory has a benign opinion for it. Mark it unknown when Mallory has no observable or no opinions, and write "not seen", never "clean". Say when the latest opinion is older than 90 days. Start in a report-only mode that prints every sighting it would record before it writes anything. For each indicator the earlier agent reports as seen in the environment, record a sighting with the observable type and name, a source name I set for that agent, the earlier agent's stable event ID, prefixed with its alert ID, as the external ID, and the time it was seen. Write the source name in lowercase letters, digits, dots, hyphens, and underscores. Retry a sighting unchanged after a timeout, a lost response, a 429, or a 5xx, and honor Retry-After. Report a 409 or 422 as a failed sighting and never retry it. Never invent a new external ID or replace the time with the retry time. Back off on a throttled lookup and honor Retry-After. Never create an opinion, because a verdict is Mallory's and its sources' to give. Keep the records in a structured form the next agent can read. In reports, replace internal hostnames with stable pseudonyms.
## Requirements
It needs a Mallory API key for a tenant owner to record sightings. That role can also invite members and manage billing, so issue the key to a dedicated service user. Select the tenant by tenant_uuid on every request. It needs read access to the earlier agent's output, and nothing more. It never creates opinions, never applies tags, never deletes observables or sightings, and changes nothing in the earlier agent's system. Related templates
-
CVE Enrichment
Builds one record per CVE from KEV, EPSS, NVD, and OSV, and, when asked, reads the upstream fix to state the exact conditions under which the vulnerability applies.
Featured Threat Intelligence / Vulnerability Management 6 tools -
Datadog Detection Posture Report
Delivers a weekly report on Datadog Cloud SIEM log ingestion gaps, detection rules that are disabled, erroring, or blind, and anything in the organization that needs an admin, from Security Filter exclusions to silent Agents.
Reporting and Compliance / Security Operations 1 tools -
Datadog Detection Tuning
Finds the Datadog Cloud SIEM detection rules that produce the most noise, reads each one against the signals it raised, and proposes a specific tuning change with the evidence and what it would have missed.
Security Operations 1 tools -
Elastic Security Detection Posture Report
Delivers a weekly report on Elastic Security data stream gaps, detection rules that are failing, warning, or blind, and anything in the deployment that needs an admin, from offline Elastic Agents to lifecycle errors.
Reporting and Compliance / Security Operations 1 tools