n8n SOAR: Alert Enrichment Automation

Why Enrichment Is the Right First Automation

When a SOC team first adopts SOAR, the instinct is to automate response: block the IP, isolate the host, disable the account. That instinct is dangerous, because response actions are disruptive and an over-eager automation can take down legitimate traffic or lock out real users. Enrichment is the opposite. It only reads and adds context, never changes anything, so it cannot break production. That makes it the ideal place to build SOAR confidence and skills.

The value is immediate and measurable. A large share of analyst triage time is spent manually copying an IP into a reputation site, pasting a hash into VirusTotal, checking whether a source is internal or external, and figuring out what the affected asset actually is. Every one of those lookups is a deterministic API call that a workflow can do in parallel in seconds. Automating them collapses the time from alert to decision and removes the tedium that causes analyst fatigue and missed signals.

Enrichment also raises the floor on quality. A tired analyst at 3am might skip a reputation check; an n8n workflow never does. Consistent, complete context on every single alert means severity decisions are made on the same information every time, which is exactly the consistency that auditors and incident reviews reward. This is why Codesecure builds the enrichment workflow before any response workflow on every managed-SOC engagement.

Anatomy of an n8n Enrichment Workflow

An enrichment workflow has a consistent shape regardless of which sources you query. It begins with a trigger, runs an extraction step, fans out to multiple enrichment lookups in parallel, merges the results, and writes the enriched object to its destination. Understanding this skeleton makes building and maintaining workflows straightforward.

The trigger is a Wazuh alert. The cleanest integration is to configure Wazuh's integrator to POST alerts matching a rule level or group to an n8n webhook node. The workflow receives the full alert JSON: rule ID and description, source and destination IPs, the agent and host, the user, file paths and hashes where relevant. n8n's webhook node exposes all of this for the rest of the workflow to use.

The extraction step parses indicators out of the alert. A Function or Set node pulls the source IP, destination IP, any domains, file hashes and the username into clean variables, and decides which lookups are relevant. There is no point doing a file-hash lookup on a failed-login alert that has no hash, so the workflow branches based on what indicators are actually present.

The enrichment fan-out runs lookups in parallel rather than in sequence, because the sources are independent and waiting for each in turn would make the workflow needlessly slow. n8n runs the GeoIP lookup, the reputation checks, the VirusTotal query and the MISP correlation concurrently, then a Merge node recombines their outputs into a single enriched object. Finally, the workflow writes that object back, to the Wazuh alert as added fields, to a TheHive case, to a Slack notification, or all three.

The Core Enrichment Sources and What Each Adds

Each enrichment source answers a different question, and the combination is what turns a bare indicator into an actionable picture. GeoIP and ASN lookup answers where and whose: the country and city an IP geolocates to, and the autonomous system and organisation that owns it. A login from an unexpected country, or traffic to an IP owned by a bulletproof hosting provider, is an instant signal that a raw alert would never surface on its own.

IP and domain reputation feeds answer whether this indicator is already known bad. Services such as AbuseIPDB, threat-intel reputation lists and passive DNS sources return a score and a history: how many times the IP has been reported, for what kind of abuse, and how recently. Querying several feeds and combining their verdicts is far more reliable than trusting any single source, because reputation data is noisy and feeds disagree.

File-hash reputation, typically via the VirusTotal API, answers whether an observed file is known malware. Submit the hash from a file integrity monitoring or process-execution alert and VirusTotal returns how many engines flag it, the malware family, and first-seen dates. A clean known-good hash lets you down-rank an alert immediately; a hash flagged by dozens of engines escalates it instantly.

MISP correlation answers whether this indicator matches your own and your community's threat intelligence. Where public reputation tells you what the world knows, MISP tells you what your organisation and your sharing partners have specifically seen and attributed, which is often more relevant to a targeted attack. Finally, asset context from your CMDB or inventory answers so what: is the affected host a developer's test laptop or the production payments database. The same alert means very different things on those two assets, and only asset context tells you which.

Caching, Rate Limits and Cost Control

Threat-intelligence APIs are metered, and a naive enrichment workflow will burn through quotas and money fast. A single noisy scanning IP can generate hundreds of alerts an hour, and querying VirusTotal and your reputation feeds afresh on every one of them is wasteful, slow and will get you rate-limited or billed. Caching is not an optimisation here, it is a requirement.

Cache enrichment results keyed by the indicator, with a time-to-live appropriate to how fast that data changes. IP and domain reputation can be cached for hours because it moves slowly; GeoIP and ASN data changes rarely and can be cached for much longer; file-hash verdicts are effectively permanent for a given hash. n8n can use a small datastore, a Redis node, or even a static-data store for caching, so the workflow checks the cache first and only calls the external API on a miss.

Respect each provider's rate limits explicitly. The free VirusTotal tier, for example, permits only a handful of requests per minute, so a workflow must queue and throttle rather than fire in bursts. n8n's batching and wait nodes let you pace requests within the allowed rate. Where you have paid tiers, caching still matters because it keeps you on a smaller, cheaper plan and leaves headroom for genuine spikes during an incident.

Design for graceful degradation. If a feed is down, rate-limited or slow, the workflow should time out that single lookup and continue with whatever other context it gathered, rather than failing the whole enrichment. A partially enriched alert is still vastly better than a raw one, and an enrichment pipeline that blocks the entire SOC because one API had a bad day is an availability problem you created yourself.

Writing Enrichment Back and Scoring Severity

Enrichment is only useful if it lands where analysts look. The most common destinations are the alert itself, the case management system and the notification channel. Writing enriched fields back onto the Wazuh alert or into the index means your dashboards and searches can filter and pivot on reputation, geography and asset criticality, not just raw indicators.

When an alert is significant enough to become a case, the workflow creates a TheHive case pre-populated with all enrichment: the indicators as observables, the reputation verdicts, the GeoIP picture, the VirusTotal result and the asset context, all attached before a human opens it. The analyst starts from a complete picture instead of an empty case and a single IP, which is the difference between minutes and seconds to an informed triage decision.

Enrichment naturally feeds severity scoring. With reputation scores, asset criticality and threat-intel matches available as structured data, the workflow can compute a composite priority: a high-reputation-confidence malicious indicator against a critical asset is automatically escalated, while a single low-confidence hit on a non-critical host is down-ranked or auto-closed. This dynamic scoring is far more accurate than the static rule level alone, because it incorporates context the detection rule could not know.

Keep the analyst in the loop on what enrichment concluded and why. A good enrichment workflow does not just attach raw API responses, it summarises them into a short, readable verdict, three of four feeds flag this IP, hash is known malware family X, target is a production database, alongside the underlying data for anyone who wants to verify. That summary is what turns automated enrichment from a data dump into a genuine force multiplier for the SOC.

Building Your First Enrichment Workflow

Start narrow and prove value before expanding. A strong first workflow enriches a single high-signal alert type, say external authentication failures or outbound connections to unusual destinations, with just GeoIP and one reputation feed. That alone visibly improves triage and gives the team a working template to extend.

Build and test in n8n's test mode against sample alert payloads before connecting it to live Wazuh traffic. Feed in a known-bad IP and confirm the workflow geolocates it, scores it and writes the result correctly; feed in a known-good IP and confirm it is handled cleanly. This catches extraction bugs and API-format surprises before they touch production alert flow.

Add sources incrementally as you see which ones pay off. Layer in VirusTotal once you are enriching hash-bearing alerts, add MISP once you have internal intelligence worth correlating against, and wire in asset context once your inventory is reliable enough to trust. Each addition should be justified by an analyst saying it saved them a manual step, not added for completeness.

Codesecure builds enrichment as the foundation of every n8n SOAR engagement, then layers triage and response workflows on top once the team trusts the platform. The enrichment layer is reusable: the same parallel-lookup, cache and write-back pattern underpins phishing triage, host isolation decisions and incident-response automation. Get enrichment right and the rest of your SOAR programme stands on solid ground.