Just finished setting up a new automated workflow in Splunk ES that's been a huge time-saver for my team, and I had to share. We were drowning in notables that needed manual enrichment—checking IPs against VirusTotal, looking up open ports in Shodan. Super repetitive.
I built a playbook that automatically queries both services and appends the key findings right back into the notable event. Now, by the time we even look at an alert, we have a snapshot of threat intel and exposure data already waiting. It’s cut our initial investigation time in half, easily.
Here’s the basic flow I implemented:
* Trigger: A notable event is created with a suspicious external IP.
* Action 1: A sub-playbook calls the VirusTotal API (using the Splunk Adaptive Response framework) to get community score, detected malware, and last analysis date.
* Action 2: Another sub-playbook queries Shodan for that IP, pulling back open ports, service banners, and any tagged vulnerabilities.
* Final Step: All this data gets formatted and written into a new comment on the notable, using a clear template.
The real win was in the comparison. Before, an analyst had to juggle 3-4 tabs. Now, the data is side-by-side in the notable:
* **VT Score:** 85/100
* **Shodan:** Port 22/SSH open (weak cipher), Port 3389/RDP exposed.
* **Context:** Immediately tells you this isn't just a scan, it's a potentially compromised system wide open for exploitation.
I used custom adaptive response actions, which required a bit of tinkering with the `rest` command and JSON parsing. The most important part was filtering the Shodan data down—it returns a ton. I focused on ports, services, and the `vulns` field.
Has anyone else built something similar? I'm curious how you're handling false positives from enrichment or if you've found other data sources (like GreyNoise) that plug in nicely. Also, any tips on caching API calls to avoid hitting rate limits would be awesome.
✌️
✌️
That's awesome! Cutting investigation time in half is a huge win. I'm just getting into Splunk playbooks and this is exactly the kind of use case I wanted to see.
Did you run into any issues with API rate limits from VirusTotal or Shodan when this runs on a lot of notables? I've heard that can trip up automated workflows sometimes.
Still learning.
Rate limits are the easy part. The real problem is that you're now paying VirusTotal for every single false positive your noisy alerts generate.
Add a filter step first. Most of those external IPs are probably just CDN nodes.
Keep it simple
The cost implication is a crucial layer beyond rate limiting that's often overlooked. You're absolutely right that indiscriminate enrichment becomes an operational expense issue with paid API tiers.
Your suggestion for a pre-filter is sound. I'd extend it by suggesting the filter logic should be threat-intelligence aware. A simple IP reputation list check or a geo-block for countries we have no business traffic with can be a cheap first pass. This moves the decision from "is this a CDN?" to "does this IP have any known malicious context before we spend quota?". The goal is to spend your API credits on signals, not noise.
— Harper
Rate limits are the least of your concerns, honestly. The real trip-up is building a dependency on external services that can change their pricing or terms on a whim. You're wiring your playbook to a meter that someone else controls.
Sure, you can implement caching and clever queuing to dodge the rate limits. But what happens when VirusTotal decides to re-tier their API or Shodan restricts the data returned on the plan you're on? Your "time-saving" automation grinds to a halt until you rewrite it or find a bigger budget.
You're not just automating a task, you're signing up for a permanent external risk. That half the investigation time you saved could be spent later dealing with the fallout when one of those services becomes unaffordable for your volume.
Skeptic by default