Forem: Nmosi Chinecherem

# Supercharging My SOC Pipeline With VirusTotal Enrichment — Know Your Attacker Before You Block Them

Nmosi Chinecherem — Mon, 27 Apr 2026 09:50:47 +0000

In my last article I built a SOC pipeline that caught real hackers in 3 minutes. This time I'm adding automated threat intelligence enrichment — so every alert now tells me exactly who the attacker is before a human even looks at it.

The Problem With Raw Alerts

After my first article, my pipeline was working well. Real attackers were hitting the honeypot, Wazuh was firing level 15 alerts, Shuffle was processing them, and TheHive was creating cases.

But there was a gap.

Every case in TheHive looked like this:

Alert: SSH Brute Force on Honeypot
Attacker IP: 110.35.80.116
Agent: honeypot
Level: 15

That's useful. But it's not enough. An IP address alone doesn't tell you:

Is this a known malicious actor?
Is this a botnet, a VPN, or a targeted attacker?
Has this IP been reported attacking other people?
What country is it from?
How dangerous is it — 1 engine flagged it or 80?

Without that context, every alert looks the same. You can't prioritise. You can't make intelligent decisions about how to respond.

The solution is threat intelligence enrichment — automatically looking up every attacker IP the moment an alert fires, and adding that intelligence to the case before an analyst even opens it.

What Is VirusTotal?

VirusTotal is a free threat intelligence platform owned by Google. It aggregates data from over 90 security vendors and lets you look up IPs, domains, URLs, and file hashes to check their reputation.

When you query an IP address, VirusTotal returns:

Malicious votes — how many of 90+ engines flagged it as malicious
Country and ISP — where the attacker is connecting from
Tags — scanner, brute-force, malware, botnet
Last seen — when this IP was last reported doing something malicious
Reputation score — a number from -100 (very malicious) to +100 (trusted)

The free API gives you 500 lookups per day — more than enough for a personal SOC pipeline.

The Enriched Pipeline

Before enrichment:

Honeypot → Wazuh → Shuffle → TheHive

After enrichment:

Honeypot → Wazuh → Shuffle → VirusTotal lookup → TheHive

The difference in the TheHive case:

Before:

Attacker IP: 110.35.80.116

After:

Attacker IP: 110.35.80.116
VT Malicious: 12/90 engines
Country: China
ISP: Alibaba Cloud Computing
Tags: scanner, brute-force
Reputation: -25
Last reported: 2026-04-24

Now every case arrives pre-enriched with actionable intelligence. An analyst can immediately see whether this is a low-level scanner they can deprioritise or a high-confidence malicious actor that needs immediate attention.

Step 1 — Get a Free VirusTotal API Key

Go to https://www.virustotal.com
Click Sign In → Join us today
Create a free account
Go to your profile (top right) → API Key
Copy your API key — it looks like a long string of letters and numbers

The free tier gives you:

500 lookups per day
4 lookups per minute
Full API access

Step 2 — Update the Shuffle Workflow

Open your Shuffle instance and go to your Wazuh-TheHive workflow.

We need to add a new step between the Webhook trigger and the HTTP node that creates the TheHive alert.

Add a new HTTP node and connect it between Webhook 1 and Http 1:

Webhook 1 → VT Lookup (new) → Http 1 (TheHive)

Configure the VT Lookup node:

Method: GET
URL:

https://www.virustotal.com/api/v3/ip_addresses/$exec.body.data.srcip

Headers:

x-apikey: YOUR_VIRUSTOTAL_API_KEY

This sends the attacker's source IP from the Wazuh alert to VirusTotal and returns the full reputation report.

Step 3 — Update the TheHive Case With Enriched Data

Now update your Http 1 (TheHive) node body to include the VirusTotal data:

{
  "title": "[Wazuh] $exec.body.rule.description",
  "description": "## Alert Details\n\nRule ID: $exec.body.rule.id\nAgent: $exec.body.agent.name\nLevel: $exec.body.rule.level\nTimestamp: $exec.body.timestamp\n\n## Attacker Intelligence\n\nIP: $exec.body.data.srcip\nVT Malicious Votes: $VT_Lookup.body.data.attributes.last_analysis_stats.malicious\nVT Harmless Votes: $VT_Lookup.body.data.attributes.last_analysis_stats.harmless\nCountry: $VT_Lookup.body.data.attributes.country\nReputation: $VT_Lookup.body.data.attributes.reputation\nASN: $VT_Lookup.body.data.attributes.asn\n\n## Raw Alert\n$exec.body",
  "type": "wazuh",
  "source": "wazuh",
  "sourceRef": "$exec.body.id",
  "severity": 3,
  "tags": ["wazuh", "honeypot", "enriched"]
}

Step 4 — Add Conditional Severity

One of the most powerful things you can do with VirusTotal data is automatically adjust the severity of the TheHive case based on the malicious vote count.

In Shuffle, add a Condition node between VT Lookup and TheHive:

If VT malicious votes > 20:
    severity = 3 (High)
Else if VT malicious votes > 5:
    severity = 2 (Medium)  
Else:
    severity = 1 (Low)

Now TheHive cases are automatically prioritised. A known malicious IP with 60 vendor detections creates a High severity case. An unknown scanner with 0 detections creates a Low severity case. Analysts can triage instantly.

Real Example: What the Enriched Cases Look Like

Here are three real attackers that hit my honeypot, enriched with VirusTotal data:

Attacker 1 — High Severity

IP: 110.35.80.116
VT Malicious: 23/90
Country: China
ISP: Alibaba Cloud
Tags: scanner, brute-force
Severity: HIGH → Immediate investigation

Attacker 2 — Medium Severity

IP: 165.22.54.16
VT Malicious: 8/90
Country: Netherlands  
ISP: DigitalOcean
Tags: scanner
Severity: MEDIUM → Monitor and log

Attacker 3 — Low Severity

IP: 193.32.162.145
VT Malicious: 1/90
Country: Russia
ISP: Unknown hosting
Tags: none
Severity: LOW → Auto-close after logging

Without enrichment, all three look identical. With enrichment, you know exactly how to respond to each one.

Taking It Further — Automatic IP Blocking

Once you have VirusTotal enrichment, you can add an automatic blocking step:

If VT malicious votes > 15:
    → Add to Wazuh block list
    → Run: ufw deny from $ATTACKER_IP
    → Create HIGH severity TheHive case

Known bad actors get blocked automatically. Unknown scanners get logged and monitored. The whole process takes milliseconds and requires no human intervention.

What This Adds to Your SOC

Capability	Before	After
Alert context	IP only	IP + reputation + country + ISP
Case prioritisation	Manual	Automatic based on VT score
Analyst workload	Every alert equal	High confidence threats flagged
Response speed	Human triage required	Auto-block for known bad actors

The Bigger Picture

Threat intelligence enrichment is what separates a basic monitoring setup from a professional SOC pipeline. Raw alerts are noise. Enriched alerts are intelligence.

By adding VirusTotal to the pipeline, every alert that reaches an analyst already contains the context they need to make a decision. No manual lookups. No context switching. Just actionable intelligence, automatically delivered.

The full updated pipeline — with VirusTotal enrichment — is available on GitHub:

github.com/agunna99/soc-honeypot-pipeline

What's Next

In the next article I'll cover:

Adding AbuseIPDB as a second enrichment source
Automatic IP blocking using Wazuh active response
Email/Slack notifications for high severity cases
Protecting a real web application with the same pipeline

Favour Nmosi is a cybersecurity engineer building open-source security automation tools.
GitHub: github.com/agunna99 | Medium: medium.com/@chrisnmosi

Tags: #cybersecurity #virustotal #threatintelligence #soc #wazuh #shuffle #thehive #infosec #blueteam #securityautomation

I Built a Production SOC Pipeline That Caught Real Hackers in 3 Minutes

Nmosi Chinecherem — Fri, 24 Apr 2026 09:53:25 +0000

How I went from zero to a full threat detection and response system using OpenCanary, Wazuh, Shuffle, and TheHive — and what happened when I turned it on.

The Problem I Was Trying to Solve
I've been studying cybersecurity for years, reading about SOC pipelines, SIEM platforms, and incident response workflows. But there's a massive gap between reading about something and actually building it.
I wanted to build a real Security Operations Centre pipeline — not a lab with simulated attacks, but something that would face the actual internet and catch real threats. Something I could point to and say: "I built this, it works, and here's the proof."
So I built one.

What I Built
A complete, end-to-end SOC pipeline consisting of four components working together:
Internet → OpenCanary Honeypot → Wazuh SIEM → Shuffle SOAR → TheHive IR
OpenCanary — A honeypot that pretends to be a vulnerable server, running fake SSH, FTP, HTTP, and Telnet services. Attackers think they've found a real target.
Wazuh — A SIEM that collects logs from the honeypot, applies custom detection rules, and fires high-priority alerts when attackers interact with the honeypot.
Shuffle — A SOAR platform that receives Wazuh alerts via webhook and automatically routes them to TheHive for case management.
TheHive — An incident response platform that creates structured cases from every alert, ready for analyst investigation.

The Architecture
Each component runs on its own server:
ComponentRoleOpenCanary 0.9.7HoneypotWazuh 4.9.2SIEM + DetectionShuffleSOAR AutomationTheHive 5.5.14Incident Response
The data flow is fully automated. When an attacker hits the honeypot, within seconds a structured incident case is created in TheHive — no human intervention required.

What Happened When I Turned It On
This is the part that surprised me.
Within 3 minutes of deploying the honeypot, a real attacker from IP 105.127.14.91 connected to the fake SSH service and attempted to log in with:
json{
"USERNAME": "root",
"PASSWORD": "ella1Mootie",
"src_host": "105.127.14.91",
"logtype": 4002
}
Within hours, dozens of attackers from across the world were hitting the honeypot. I captured credentials like 888888, 87654321, wsx33, and Abc123... — real passwords people use in brute force attacks.
The Wazuh rule I wrote fired at level 15 (the highest priority) for every SSH brute force attempt, and Shuffle automatically processed each alert.
This wasn't a simulation. These were real attackers, real credentials, real threat intelligence.

How I Built It
Step 1: The Honeypot (OpenCanary)
OpenCanary is lightweight, runs on Python, and supports over a dozen fake services. I installed it on Ubuntu 22.04 and configured it to listen on ports 22 (SSH), 21 (FTP), 80 (HTTP), and 23 (Telnet).
The key insight: move the real SSH service to port 2222, and put the honeypot on port 22. Any attacker scanning the internet will hit the honeypot first.
json{
"ssh.enabled": true,
"ssh.port": 22,
"ftp.enabled": true,
"http.enabled": true,
"telnet.enabled": true,
"logger": {
"class": "PyLogger",
"kwargs": {
"handlers": {
"file": {
"class": "logging.FileHandler",
"filename": "/var/log/opencanary/opencanary.log"
}
}
}
}
}
Step 2: Custom Wazuh Detection Rules
I wrote four custom rules to detect and classify honeypot interactions:
xml

json
opencanary
OpenCanary: Honeypot interaction detected

100200
^4002$
OpenCanary: SSH brute force login attempt on honeypot

Rule 100201 fires at level 15 — the maximum — because any login attempt on a honeypot is by definition malicious. There are no false positives.
Step 3: Automated Alert Routing with Shuffle
I configured Wazuh to send all level 7+ alerts to a Shuffle webhook. Shuffle then processes each alert and forwards it to TheHive's API as a structured alert.
The Wazuh integration block:
xml
shuffle
http://YOUR_SHUFFLE_IP:3001/api/v1/hooks/YOUR_WEBHOOK_ID
7
json

Step 4: TheHive for Incident Response
TheHive receives structured alerts with full context — attacker IP, username attempted, password used, timestamp, and the originating agent. Each alert becomes a case that analysts can investigate, assign, and close.

What I Learned

The internet is hostile by default. Within minutes of exposing any service to the internet, automated scanners find it. The speed and scale of internet-wide scanning is remarkable.
Honeypots generate high-fidelity intelligence. Unlike SIEM alerts that often have false positives, honeypot alerts are almost always genuine. Nobody has a legitimate reason to connect to a honeypot.
Automation is not optional in a modern SOC. When you're receiving hundreds of alerts per day, manual triage is impossible. The Wazuh → Shuffle → TheHive pipeline processes every alert automatically, ensuring nothing is missed.
Building is better than reading. I learned more about SOC architecture in the process of building this pipeline than I did in months of studying. There is no substitute for hands-on experience.

The Full Stack
All configuration files, custom rules, and integration scripts are available on GitHub:
github.com/agunna99/soc-honeypot-pipeline
The repository includes:

OpenCanary configuration
Custom Wazuh detection rules
TheHive integration script
Shuffle workflow setup guide

What's Next

Adding IP enrichment using threat intelligence feeds (VirusTotal, AbuseIPDB)
Implementing automated IP blocking when attackers are detected
Adding email/Slack notifications for critical alerts
Publishing threat intelligence reports from captured attack data

Final Thoughts
Building a production SOC pipeline from scratch taught me that security is not just about tools — it's about architecture, data flow, and automation. Every component in this pipeline serves a specific purpose, and together they create something more powerful than any individual tool.
If you're learning cybersecurity, build things. Deploy them. See what happens. The internet will teach you things no course or textbook can.
The code is open source. Use it, improve it, and share what you build.

Favour Nmosi is a cybersecurity engineer building open-source security tools.
GitHub: github.com/agunna99

Tags: #cybersecurity #soc #honeypot #wazuh #thehive #shuffle #siem #soar #opencanary #infosec #security