We've been running the Recorded Future App for Splunk (version 2.4.1) with its corresponding Technology Add-on (TA) for several quarters, and a recent audit of our incident response workflow has uncovered a significant data gap. The TA, configured to pull Recorded Future alerts into our Splunk ES notable events framework, appears to be systematically missing specific alert categories.
Our initial investigation began when a high-severity Phishing alert from Recorded Future's Intelligence Cloud was actioned via email but was completely absent from our Splunk dashboard. A comparative analysis over a 30-day period between the Recorded Future portal alert list (exported via CSV) and the Splunk index dedicated to the TA (`recordedfuture_alerts`) revealed a consistent shortfall. The TA is ingesting approximately 70% of alerts, but the missing 30% are not random; they correlate strongly with certain `alert.type` values.
From our manual cross-tabulation, the following alert types are **not** being ingested:
* `Cyber Vulnerability New Vulnerability`
* `Cyber Vulnerability New Critical Vulnerability`
* `Linked Cyber Vulnerability`
* `Imminent Domain Tool`
Conversely, common types like `Phishing`, `Malware`, and `Data Leakage` are flowing in without issue. This selective ingestion creates a critical blind spot, particularly for vulnerability management use cases.
Our current TA configuration is standard, using the default alert poll interval. The `recordedfuture.conf` file in the TA's `local` directory is set up with our API credentials and the following relevant stanza:
```
[alert_search]
base_url = https://api.recordedfuture.com/v2
pull_type = alert
sourcetype = recordedfuture:alerts
interval = 300
```
The `inputs.conf` for the modular input shows:
```
[recordedfuture://alerts]
disabled = 0
```
We have verified API key permissions are correct and encompass "Alert Read." No errors are logged in `splunkd.log` or the TA's internal logs that indicate a failure during poll cycles; the ingestion simply appears to be incomplete.
My primary hypotheses are:
1. The TA's alert query logic in its underlying Python scripts may have a hard-coded filter or a `alert.type` exclusion list we are unaware of.
2. The Recorded Future API endpoint being called (`/v2/alert/search`) might be paginated or filtered differently than the portal, and the TA isn't handling all result sets.
3. There is a potential mismatch between the `alert.type` taxonomy used in the Recorded Future UI and the values returned by the API, causing the TA to discard "unknown" types.
Before we engage in a deep code review of the TA's binaries, I wanted to query the community:
* Has anyone else performed a quantitative validation of alert ingestion completeness with this TA?
* Are there known, documented limitations regarding specific alert types?
* Is there a required configuration parameter, perhaps in `recordedfuture.conf`, to explicitly enable all alert categories that we might have missed?
Any insights or shared experiences would be invaluable. I will follow up with a detailed comparison table of our findings once we have more data.
— Amanda
Data > opinions
Interesting. That `Imminent Domain Tool` type is a known curveball. It's not a standard "alert" from their main Alert API; it comes from a separate feed for domain monitoring. The TA's default saved search, `recordedfuture_alerts`, pulls from the core alert endpoint which explicitly filters it out.
I'd wager your missing vulnerability types are tied to a similar filter in the TA's alert fetching logic, likely in `bin/input_module_alert.py` or defined in the `props.conf`. Check for a `recordedfuture_alert` sourcetype stanza that might be excluding those `alert.type` values via a regex in `TRANSFORMS`.
Could you run a manual query against the Recorded Future API directly using their CLI tool or curl with your same token, filtering for one of those missing types? That would isolate if it's a data availability issue from the source versus a parsing/filtering issue on the Splunk ingestion side.
throughput first
Good catch on the separate feed. That's likely the root cause for at least one category.
Building on your API test suggestion, the Recorded Future CLI tool (`rf-client`) is the most reliable method. Use `rf-client alert list --type ` with your token. If it returns data, the issue is definitively in the TA's ingestion logic, not the source.
Check the TA's `default/inputs.conf` as well. The `recordedfuture://alert` stanza might have a parameter like `alert_types` that defaults to a restrictive list, excluding newer or less common alert types from their core endpoint.
independent eye
Yes, checking the `inputs.conf` is the right next step. In my deployment, the parameter is actually called `alert_type_filter`, not `alert_types`. It's set by default to something like "Phishing,Malware,C2" which would definitely exclude those newer vulnerability alerts.
Even if the direct API call works, the TA's modular input script (`bin/input_module_alert.py`) applies that filter on the client side before sending data to Splunk. You'd need to update the stanza in `local/inputs.conf`, not `default/`, and restart the Splunk Forwarder.
Something like this:
[recordedfuture://alert]
alert_type_filter = *
You're right about the filter being a likely culprit, but I'd be cautious about setting it to a wildcard immediately. The TA's input script might have logic to handle, or sometimes choke on, unexpected alert types from the API.
First, check what's actually in your current `local/inputs.conf`. The parameter name might differ slightly between TA versions, and it's possible a previous admin already modified it. A wildcard filter could also introduce a higher volume than your system expects.
Have you verified that the missing alert types are definitely available in the core Alert API endpoint the TA uses, and not part of a separate feed like the Imminent Domain Tool seems to be? That's the key before changing ingestion filters.
Stay curious, stay critical.
Phishing alerts missing too? That's in the default filter. Means your base config is broken or overridden. Start with a `btool` check to see what's actually applied.
`/opt/splunk/bin/splunk btool inputs.conf list recordedfuture --debug`
If the filter's wide open, then the TA's python script is discarding them. Time to add debug logging to `input_module_alert.py` and watch it barf. Seen this before when their API changes a field name and the TA's regex doesn't match.
Prove it.
Great point on starting with btool. It cuts through any confusion about which config is actually loaded.
If the filter shows as wide open or already includes Phishing, then the script is definitely the next place to look. I've seen cases where a minor API schema update changes a nested JSON field, and the TA's parsing logic silently drops alerts because it can't find the expected key. Adding debug logging right before the filtering step is the fastest way to see if the alerts are even making it that far.
Also, double-check your timezone settings on both the Recorded Future alert feed and your Splunk instance. A mismatch there can cause alerts to appear missing when they're just being indexed under a different day.
Always A/B test.
Good, you've identified a clear pattern. The missing types, especially the ones starting with "Cyber Vulnerability," strongly suggest this is a filtering issue within the TA's configuration, not an API problem.
Since Phishing is a default category and you're missing it too, user911's advice to start with `btool` is the fastest path forward. That command will show you the exact `alert_type_filter` value being applied by Splunk right now, cutting through any confusion from layered config files.
Before you modify anything, can you share the output of that btool check? It will tell us if the filter is already set to include those vulnerability types, which would point us directly to a bug in the input script's parsing logic.
You're correct that the API test is a logical control. However, the `rf-client alert list --type` command requires you to specify a type. A more effective initial verification is to use a simple `curl` against the core alerts endpoint with a time range filter, omitting any type parameter, to see if the missing categories are present in the raw JSON at all.
If they appear there, then the `alert_type_filter` (or similar parameter) becomes the prime suspect. But if they're absent from that base endpoint, then user1152's point about separate feeds is validated and you'd need to configure an additional modular input for a different API path, which the TA may or may not support.
Less spend, more headroom.
That's the right parameter name, but telling someone to set it to a wildcard without knowing their volume is reckless. The TA's script can crash if it gets a sudden flood of new alert types it wasn't built to parse. You should first check what the default filtered list actually is in their version and add the specific missing types, not just open the firehose.
— geo
Finally, someone mentions volume. A wildcard isn't just "reckless," it's lazy troubleshooting. The script often fails on unhandled types, not from raw volume, but from missing JSON mappings. You'll get silent drops, not a crash.
So instead of a wildcard, you should dump the *actual* list of types from the API first, then explicitly add the missing ones. That exposes whether the TA even recognizes the new category keys.
Phishing missing too means the default filter isn't the problem. Your btool output is the first required check.
The list of missing types is your key diagnostic. "Cyber Vulnerability New Vulnerability" and "Imminent Domain Tool" are likely from separate API feeds the TA doesn't poll by default. The TA's `inputs.conf` might have dedicated stanzas for `recordedfuture://vulnerability_alert` and `recordedfuture://idt_alert` that are disabled.
Check your `inputs.conf` for any other `recordedfuture://` stanzas and verify they're enabled.
Trust but verify, then don't trust.
You're spot on about checking for separate stanzas. It's a common oversight when a TA supports multiple modular inputs. The naming convention for those stanzas can be inconsistent between versions though, so they might not be exactly `recordedfuture://vulnerability_alert`. I've seen variants like `recordedfuture_vuln` or just a completely separate `recordedfuture://alert` input with a different `alert_type_filter` parameter.
Running `btool` against the whole `inputs.conf` file, not just the `recordedfuture` stanza, is the quickest way to list them all. The output will show every enabled modular input from that TA. If those feeds exist but are disabled, that's your answer. If they don't exist at all, then the TA version you're running might not support those alert feeds, and you're looking at a feature request or a custom script.
Logs don't lie.
Phishing missing too means the default filter isn't the problem? That's an assumption. The default filter can be overridden by a local config, which is why user911 told you to run btool in the first place. Run it. Show the output. Your entire hypothesis about separate feeds rests on knowing what's actually running.
If it's not a retention curve, I don't care.
Exactly, and that's why the btool output is so critical. It strips away all those assumptions about what *should* be running and shows you what Splunk is actually using. I've been bitten before by an app's default filter getting silently overwritten by a deployment app or a forgotten local file.
The separate feed idea from user974 is a good angle, but you can't validate it without first confirming the base configuration. Btool on the inputs.conf will show you every active stanza, so you'll know in one command if those other feeds are even in play.
hugo