According to CrowdStrike Global Threat Report 2025, the average time of the email movement after initial access is 62 minutes. The record is 51 seconds. In a team of five analysts where I built a TI process, the processing cycle of the new IOC from the appearance in the feed to the triggering of the rule in SIEM took six hours - manually. For this gap, we paid missed incidents: while the hash hit the block list, the C2 server is already folded, payload is repackaged. In six months, the window was reduced to fifteen minutes - without a budget for commercial platforms, the Python script on the cron and the free MISP. Below is a summary of what worked with the code, Sigma rules and a checklist for two weeks.
Collection of threat intelligence: sources and tools without a commercial budget
Two questions define the entire TI process in the small SOC. The first is obvious: which fides to connect with a zero budget? The second is asked less often, but it is more important: how quickly do these fides burn the attacker’s infrastructure – and what does it mean for your detection window?
Free cyber threat intelligence tools and fides
The minimum set covering 80% of the needs of threat intelligence for SOC number 3-8 people:
• CIRCL MISP OSINT feed - aggregates events from CERT of Luxembourg. From fresh - phishing campaign against the hotel sector (June 2026) and the IDS-Overalling series with tags kill-chain:Reconnaissance. Format MISP events, one-click connection via Server Settings -> Feeds
• Abuse.ch (URLhaus, MalwareBazaar, ThreatFox) - hasheish, URL, C2-domains. Updates every 5 minutes, without download limits. IOC source infostealers and ransomware
• AlienVault OTX - user pulses with IOCs tied to specific campaigns. Quality floats: take pulses only from verified authors with history, the rest is noise
• AbuseIPDB is an IP crowdssourcing reputation. Free rate: 1000 requests/day via /api/v2/check. Confidence score from 0 to 100, threshold 75+ - for automatic lock
That’s enough for the first quarter. Commercial fides (Recorded Future, Mandiant Advantage) add context to APT-groups and operational exploration, but the basic detect is built without them.
How Attackers See Your TI Fides
Here, threat intelligence for SOC becomes interesting not only for analysts, but also pentesters. Attackers do not work blindly: Thread Intel Vendors technology (T1597.001, Reconnaissance) describes targeted monitoring of TI platforms for verification whether the infrastructure has fallen into fides. The C2 operator checks its domain through VirusTotal and AbuseIPDB before starting the campaign and in the process is a standard, not paranoia.
This leads to both sides:
• SOC analyst: IOC from the moment of getting into the public feed has a limited TTL - the attacker will change the infrastructure in a watch. Food is useful only if it is processed faster than the attacker rotates C2
• Red Team: shared hosting on VPS with a “dirty” reputation ANS (bulletproof providers like Stark Industries) reduces TTL infrastructure to watches. Dedicated-hosting on a clean IP range goes unnoticed weeks - but it costs a multiple of more. For an external pentest, this is critical; for the internal - less relevant if C2 goes through a legitimate channel
According to the IBM X-Force Threat Intelligence Index 2025, infostestalers (32% of all incidents) is the most common type of malware in 2024. Their C2 infrastructure is rotated aggressively: according to our experience of feed processing, the C2 style domain lives from several hours to 2-3 days. If the TI-pipeline SOC processes the IOC once a day - for 60-80% of the styles you are already late. The bands of ransomware Play and Nova (active according to ransomware.live, June 2026, 3 and 15 victims, respectively) rotate C2 at least aggressively - judging by the dynamics of DLS publications, the infrastructure changes between the waves of attacks.
Configuring MISP and OpenCTI: TI platform for small commands SOC
Both platforms are free, both solve the problem of collecting and processing threat intelligence, but architecturally these are different animals with different trade-offs.
For small SOC - start with MISP. In 3-6 months, when there is a need to analyze the links between campaigns and groupings, add OpenCTI with a connector to the already working MISP. Both projects are actively supported (MISP - the last release of June 2026, OpenCTI - a stable release cycle every 2-3 weeks).
Restrictions and when both platforms will not help. Neither MISP nor OpenCTI solve the insider threat problem. TI platforms work with external indicators: C2 domains, malicious hashes, IP addresses of attackers. A compromised legitimate host inside the perimeter is a blind zone for the fed model. UEBA and baseline deviations (DE.AE-01 by NIST CSF 2.0: establishment of baseline network operations and expected data flows). I saw an SOC that was illuminated by feds like a New Year’s tree, but I missed the lateral movement through the RDP between the two servers in one VLAN – because both IPs were “their own.”
Environment requirements for MISP
• OS: Ubuntu 22.04/24.04 LTS or RHEL 8+
• RAM: at least 4 GB, recommended 8 GB when connecting 5+ feds
• Disc: 50 GB SSD (increase ~5 GB/year with a standard set of feds)
• Network: outgoing HTTPS to endpoints of feds; incoming - only from the internal network of SOC
• Mode: online (for feed update); web interface works locally
Processing of IOC commethrative indicators and enrichment
Cheese IOCs without context - noise. The IP address in the feed has no operating value, as yet it is known: it is C2 ransomware bands, the Tor node output or CDN Cloudflare. I was burned on this in the first month - blocked the IP from the feed, and it turned out to be a Cloudflare address for half of the client services. There were more teats than from the attacks themselves.
AbuseIPDB enrichment is the first level of contextualization for threat intelligence in SOC. Service gives abuseConfidenceScore from 0 to 100, calculated on the basis of the frequency of reports, the variety of sources and the age. Automation threshold: locking at a score > 75, manual checking at 50–75, ignition at < 50.
The white list before blocking is mandatory. Without it, you will sooner or later block something important:
• Tor exit nodes: list on torproject.org/exit-addresses. High confidence on AbuseIPDB is the norm for Tor. Blocking = loss of legitimate users
• CDN ASN: Cloudflare (AS13335), Fastly (AS54113), Akamai - blocking IP from these ranges will put half the Internet
• CGNAT outputs: providers with Carrier-Grade NAT generate false positives. One IP divides thousands of users
For a penesster, this logic works in a mirror: if the C2 server is deployed to an ASN with a high concentration of Malicious IPs, AbuseIPDB-scoping will work before the start of the campaign. According to Verizon DBIR 2025, 38% of leaks are related to the theft of accounts, and often first-stage C2 for the style is detected precisely through IP reputation, rather than through signature analysis. Checking IP via AbuseIPDB before using a Red Team operation is not paranoia, but a basic OPSEC: score > 0 before the start of the campaign means that IP is already in several feds. With an external pentest, this is critical; in internal - depends on whether the SOC monitors outgoing traffic through TI-lookup (spoiler: after reading this article - will monitor).
Automation threat intelligence: pipaline MISP -> AbuseIPDB -> Wazuh
Three levels of TI automation maturity for SOC:
1. Manual (week 1): An analyst unloads the CSV from MISP, checks IP in AbuseIPDB manually, puts into the CDB-list Wazuh via a text editor. Cycle time: 4-6 hours. Humiliating, but works like a starting point
2. Script (week 2-3): Python script on cron takes the IOC from MISP, enriches through AbuseIPDB, records in the CDB-list. Cycle time: 15 minutes
3. Orchestrated (month 2+): SOAR platform (Shuffle, n8n) manages the conveyor, adds notifications and retrospective search by historical logs
A place in kill chain: this pypeline closes the detection phase – from the moment when the IOC appeared in public space, until your SIEM begins to respond to it. To the pyplay - collection (feeds). After - response (blocking, host insulation, escalation).
Adjacent requirements for pypeline
• Python: 3.10+
• Libraries: pymisp(pip install pymisp) requests
• API Keys: MISP (Settings -> Auth Keys), AbuseIPDB (free rate - 1000 queries / days; cache results in SQLite/Redis for 24-72 hours, otherwise the limit will end at >10 unique IPs for start)
• Wazuh: access to the record in /var/ossec/etc/lists/the Wazuh Manager Server
• Cron: recommended interval - every 15 minutes
IOC Forwarding Script for Threat Intelligence in SOC
Block 1 - receiving IP-indigators from MISP in the last 15 minutes:
Python:
from pymisp import PyMISP
import requests, os
MISP_URL = os.environ["MISP_URL"]
MISP_KEY = os.environ["MISP_KEY"]
ABUSE_KEY = os.environ["ABUSEIPDB_KEY"]
CDB_PATH = "/var/ossec/etc/lists/threat_intel"
misp = PyMISP(MISP_URL, MISP_KEY, ssl=False)
attributes = misp.search(controller="attributes", type_attribute="ip-dst", last="15m", pythonify=True)
ips = {a.value for a in attributes}
Block 2 - enrichment through AbuseIPDB and recording in CDB-list Wazuh:
Python:
enriched = {}
for ip in ips:
try:
r = requests.get("https://api.abuseipdb.com/api/v2/check",
headers={"Key": ABUSE_KEY, "Accept": "application/json"},
params={"ipAddress": ip, "maxAgeInDays": 90})
r.raise_for_status()
score = r.json()["data"]["abuseConfidenceScore"]
except (requests.RequestException, KeyError):
continue
if score >= 75:
enriched[ip] = f"score:{score}"
with open(CDB_PATH, "a") as f:
for ip, meta in enriched.items():
f.write(f"{ip}:{meta}\n")
After recording in CDB-list, Wazuh uses it in the rules automatically. V local_rules.xml Added rule c <list field="srcip" lookup="address_match_key">etc/lists/threat_intel</list> - it works when the source of IP coincides with the entries from our list, level 12 (high). Restarting of Wauh Manager (systemctl restart wazuh-manager) apply changes and compiles CDB-list (in Wazuh 4.x this occurs automatically at restart; in earlier versions, manual start may be required /var/ossec/bin/ossec-makelists)
In real operation, add deduplication (checking if IP is already in the CDB-list) and the rotation of records older than 30 days. Without this, the list grows and slows down lookup - we have accumulated 40 thousand records in three months, of which 90% were already dead.
Application TI in monitoring: from IOC to detection rule
Threat intelligence for SOC is useful exactly as much as integrated into the detection container. IOC in MISP, not connected to SIEM - directory, not protection.
Sigma-rules based on TI-Feders
Sigma - universal format detection rules, convertible into requests for Splunk (through sigmac), Elastic (through sigmahq backend) and Wazuh. Example of a rule for DNS query for domains from the feed:
YAML:
title: DNS query to TI-flagged domain
logsource:
category: dns
detection:
selection:
query|endswith:
- ".malwaredomain.example"
- ".phishkit.example"
condition: selection
level: high
The static list is replaced by a lookup table. In Elastic Security (8.x+) it threat_intel ECS fields with auto-newsing through Filebeat TI module; in Splunk Enterprise 9.x inputlookup with a CDB file that updates the same Python script; in Wzuh 4.x - CDB-list from the previous section. Sigma allows you to once describe the logic of the detection and convert to your specific stack.
What TI-monitoring means for Red Team and pentesters
Understanding the TI Conveyor SOC is an operational necessity for the offensive side. If you are breaking an organization and you don’t know which fides are connected to their SIEM, you work blindly:
• TTL domain on engagement: if the target SOC is connected to CIRCL OSINT or Abuse.ch, the newly registered domain will get into the feed within 2-48 hours after the first report. This sets the maximum window for initial access. Vulnerability Scanning (T1595.002) and IP Addresses (T1590.005) in the Reconnaissance phase leave the footprints that TI-Fida pick up. With an external pentest, this is your main timer; with internal - less critical if the initial access is already received through physical access or VPN
• IP-reputation before the campaign: check the IP via AbuseIPDB before the start. Score > 0 - signal to change the provider. I saw a Red Team operation burnt out in the first hour because of the IP with confidence 45 - SOC got an alternator before the beacon got in touch
• C2 rotation as a forced measure: according to Mandiant M-Trends 2025, the median detection time is 11 days (historic minimum). But SOC with a working TI-pipeline detects infostealer infrastructure per clock. 57% of organizations learn about the incident from the outside - and most often the reason is that the TI data were available, but did not reach the detection rule in time
For Red Team, this is a practical knowledge: if SOC features SOC with MISP and Elastic, the assumption "IOC burns in 24 hours" - not the owner-case, but baseline. Plan C2 rotate every 12-18 hours. The full chain looks like: initial through access phishing -> loader with a one-time domain -> handoff on a C2 agent with domain fronting -> rotation of the C2 domain to get into the feed -> post-exploitation through legitimate tools (LOLBins), which fides do not catch.
Collection of threat intelligence: sources and tools without a commercial budget
Two questions define the entire TI process in the small SOC. The first is obvious: which fides to connect with a zero budget? The second is asked less often, but it is more important: how quickly do these fides burn the attacker’s infrastructure – and what does it mean for your detection window?
Free cyber threat intelligence tools and fides
The minimum set covering 80% of the needs of threat intelligence for SOC number 3-8 people:
• CIRCL MISP OSINT feed - aggregates events from CERT of Luxembourg. From fresh - phishing campaign against the hotel sector (June 2026) and the IDS-Overalling series with tags kill-chain:Reconnaissance. Format MISP events, one-click connection via Server Settings -> Feeds
• Abuse.ch (URLhaus, MalwareBazaar, ThreatFox) - hasheish, URL, C2-domains. Updates every 5 minutes, without download limits. IOC source infostealers and ransomware
• AlienVault OTX - user pulses with IOCs tied to specific campaigns. Quality floats: take pulses only from verified authors with history, the rest is noise
• AbuseIPDB is an IP crowdssourcing reputation. Free rate: 1000 requests/day via /api/v2/check. Confidence score from 0 to 100, threshold 75+ - for automatic lock
That’s enough for the first quarter. Commercial fides (Recorded Future, Mandiant Advantage) add context to APT-groups and operational exploration, but the basic detect is built without them.
How Attackers See Your TI Fides
Here, threat intelligence for SOC becomes interesting not only for analysts, but also pentesters. Attackers do not work blindly: Thread Intel Vendors technology (T1597.001, Reconnaissance) describes targeted monitoring of TI platforms for verification whether the infrastructure has fallen into fides. The C2 operator checks its domain through VirusTotal and AbuseIPDB before starting the campaign and in the process is a standard, not paranoia.
This leads to both sides:
• SOC analyst: IOC from the moment of getting into the public feed has a limited TTL - the attacker will change the infrastructure in a watch. Food is useful only if it is processed faster than the attacker rotates C2
• Red Team: shared hosting on VPS with a “dirty” reputation ANS (bulletproof providers like Stark Industries) reduces TTL infrastructure to watches. Dedicated-hosting on a clean IP range goes unnoticed weeks - but it costs a multiple of more. For an external pentest, this is critical; for the internal - less relevant if C2 goes through a legitimate channel
According to the IBM X-Force Threat Intelligence Index 2025, infostestalers (32% of all incidents) is the most common type of malware in 2024. Their C2 infrastructure is rotated aggressively: according to our experience of feed processing, the C2 style domain lives from several hours to 2-3 days. If the TI-pipeline SOC processes the IOC once a day - for 60-80% of the styles you are already late. The bands of ransomware Play and Nova (active according to ransomware.live, June 2026, 3 and 15 victims, respectively) rotate C2 at least aggressively - judging by the dynamics of DLS publications, the infrastructure changes between the waves of attacks.
Configuring MISP and OpenCTI: TI platform for small commands SOC
Both platforms are free, both solve the problem of collecting and processing threat intelligence, but architecturally these are different animals with different trade-offs.
For small SOC - start with MISP. In 3-6 months, when there is a need to analyze the links between campaigns and groupings, add OpenCTI with a connector to the already working MISP. Both projects are actively supported (MISP - the last release of June 2026, OpenCTI - a stable release cycle every 2-3 weeks).
Restrictions and when both platforms will not help. Neither MISP nor OpenCTI solve the insider threat problem. TI platforms work with external indicators: C2 domains, malicious hashes, IP addresses of attackers. A compromised legitimate host inside the perimeter is a blind zone for the fed model. UEBA and baseline deviations (DE.AE-01 by NIST CSF 2.0: establishment of baseline network operations and expected data flows). I saw an SOC that was illuminated by feds like a New Year’s tree, but I missed the lateral movement through the RDP between the two servers in one VLAN – because both IPs were “their own.”
Environment requirements for MISP
• OS: Ubuntu 22.04/24.04 LTS or RHEL 8+
• RAM: at least 4 GB, recommended 8 GB when connecting 5+ feds
• Disc: 50 GB SSD (increase ~5 GB/year with a standard set of feds)
• Network: outgoing HTTPS to endpoints of feds; incoming - only from the internal network of SOC
• Mode: online (for feed update); web interface works locally
Processing of IOC commethrative indicators and enrichment
Cheese IOCs without context - noise. The IP address in the feed has no operating value, as yet it is known: it is C2 ransomware bands, the Tor node output or CDN Cloudflare. I was burned on this in the first month - blocked the IP from the feed, and it turned out to be a Cloudflare address for half of the client services. There were more teats than from the attacks themselves.
AbuseIPDB enrichment is the first level of contextualization for threat intelligence in SOC. Service gives abuseConfidenceScore from 0 to 100, calculated on the basis of the frequency of reports, the variety of sources and the age. Automation threshold: locking at a score > 75, manual checking at 50–75, ignition at < 50.
The white list before blocking is mandatory. Without it, you will sooner or later block something important:
• Tor exit nodes: list on torproject.org/exit-addresses. High confidence on AbuseIPDB is the norm for Tor. Blocking = loss of legitimate users
• CDN ASN: Cloudflare (AS13335), Fastly (AS54113), Akamai - blocking IP from these ranges will put half the Internet
• CGNAT outputs: providers with Carrier-Grade NAT generate false positives. One IP divides thousands of users
For a penesster, this logic works in a mirror: if the C2 server is deployed to an ASN with a high concentration of Malicious IPs, AbuseIPDB-scoping will work before the start of the campaign. According to Verizon DBIR 2025, 38% of leaks are related to the theft of accounts, and often first-stage C2 for the style is detected precisely through IP reputation, rather than through signature analysis. Checking IP via AbuseIPDB before using a Red Team operation is not paranoia, but a basic OPSEC: score > 0 before the start of the campaign means that IP is already in several feds. With an external pentest, this is critical; in internal - depends on whether the SOC monitors outgoing traffic through TI-lookup (spoiler: after reading this article - will monitor).
Automation threat intelligence: pipaline MISP -> AbuseIPDB -> Wazuh
Three levels of TI automation maturity for SOC:
1. Manual (week 1): An analyst unloads the CSV from MISP, checks IP in AbuseIPDB manually, puts into the CDB-list Wazuh via a text editor. Cycle time: 4-6 hours. Humiliating, but works like a starting point
2. Script (week 2-3): Python script on cron takes the IOC from MISP, enriches through AbuseIPDB, records in the CDB-list. Cycle time: 15 minutes
3. Orchestrated (month 2+): SOAR platform (Shuffle, n8n) manages the conveyor, adds notifications and retrospective search by historical logs
A place in kill chain: this pypeline closes the detection phase – from the moment when the IOC appeared in public space, until your SIEM begins to respond to it. To the pyplay - collection (feeds). After - response (blocking, host insulation, escalation).
Adjacent requirements for pypeline
• Python: 3.10+
• Libraries: pymisp(pip install pymisp) requests
• API Keys: MISP (Settings -> Auth Keys), AbuseIPDB (free rate - 1000 queries / days; cache results in SQLite/Redis for 24-72 hours, otherwise the limit will end at >10 unique IPs for start)
• Wazuh: access to the record in /var/ossec/etc/lists/the Wazuh Manager Server
• Cron: recommended interval - every 15 minutes
IOC Forwarding Script for Threat Intelligence in SOC
Block 1 - receiving IP-indigators from MISP in the last 15 minutes:
Python:
from pymisp import PyMISP
import requests, os
MISP_URL = os.environ["MISP_URL"]
MISP_KEY = os.environ["MISP_KEY"]
ABUSE_KEY = os.environ["ABUSEIPDB_KEY"]
CDB_PATH = "/var/ossec/etc/lists/threat_intel"
misp = PyMISP(MISP_URL, MISP_KEY, ssl=False)
attributes = misp.search(controller="attributes", type_attribute="ip-dst", last="15m", pythonify=True)
ips = {a.value for a in attributes}
Block 2 - enrichment through AbuseIPDB and recording in CDB-list Wazuh:
Python:
enriched = {}
for ip in ips:
try:
r = requests.get("https://api.abuseipdb.com/api/v2/check",
headers={"Key": ABUSE_KEY, "Accept": "application/json"},
params={"ipAddress": ip, "maxAgeInDays": 90})
r.raise_for_status()
score = r.json()["data"]["abuseConfidenceScore"]
except (requests.RequestException, KeyError):
continue
if score >= 75:
enriched[ip] = f"score:{score}"
with open(CDB_PATH, "a") as f:
for ip, meta in enriched.items():
f.write(f"{ip}:{meta}\n")
After recording in CDB-list, Wazuh uses it in the rules automatically. V local_rules.xml Added rule c <list field="srcip" lookup="address_match_key">etc/lists/threat_intel</list> - it works when the source of IP coincides with the entries from our list, level 12 (high). Restarting of Wauh Manager (systemctl restart wazuh-manager) apply changes and compiles CDB-list (in Wazuh 4.x this occurs automatically at restart; in earlier versions, manual start may be required /var/ossec/bin/ossec-makelists)
In real operation, add deduplication (checking if IP is already in the CDB-list) and the rotation of records older than 30 days. Without this, the list grows and slows down lookup - we have accumulated 40 thousand records in three months, of which 90% were already dead.
Application TI in monitoring: from IOC to detection rule
Threat intelligence for SOC is useful exactly as much as integrated into the detection container. IOC in MISP, not connected to SIEM - directory, not protection.
Sigma-rules based on TI-Feders
Sigma - universal format detection rules, convertible into requests for Splunk (through sigmac), Elastic (through sigmahq backend) and Wazuh. Example of a rule for DNS query for domains from the feed:
YAML:
title: DNS query to TI-flagged domain
logsource:
category: dns
detection:
selection:
query|endswith:
- ".malwaredomain.example"
- ".phishkit.example"
condition: selection
level: high
The static list is replaced by a lookup table. In Elastic Security (8.x+) it threat_intel ECS fields with auto-newsing through Filebeat TI module; in Splunk Enterprise 9.x inputlookup with a CDB file that updates the same Python script; in Wzuh 4.x - CDB-list from the previous section. Sigma allows you to once describe the logic of the detection and convert to your specific stack.
What TI-monitoring means for Red Team and pentesters
Understanding the TI Conveyor SOC is an operational necessity for the offensive side. If you are breaking an organization and you don’t know which fides are connected to their SIEM, you work blindly:
• TTL domain on engagement: if the target SOC is connected to CIRCL OSINT or Abuse.ch, the newly registered domain will get into the feed within 2-48 hours after the first report. This sets the maximum window for initial access. Vulnerability Scanning (T1595.002) and IP Addresses (T1590.005) in the Reconnaissance phase leave the footprints that TI-Fida pick up. With an external pentest, this is your main timer; with internal - less critical if the initial access is already received through physical access or VPN
• IP-reputation before the campaign: check the IP via AbuseIPDB before the start. Score > 0 - signal to change the provider. I saw a Red Team operation burnt out in the first hour because of the IP with confidence 45 - SOC got an alternator before the beacon got in touch
• C2 rotation as a forced measure: according to Mandiant M-Trends 2025, the median detection time is 11 days (historic minimum). But SOC with a working TI-pipeline detects infostealer infrastructure per clock. 57% of organizations learn about the incident from the outside - and most often the reason is that the TI data were available, but did not reach the detection rule in time
For Red Team, this is a practical knowledge: if SOC features SOC with MISP and Elastic, the assumption "IOC burns in 24 hours" - not the owner-case, but baseline. Plan C2 rotate every 12-18 hours. The full chain looks like: initial through access phishing -> loader with a one-time domain -> handoff on a C2 agent with domain fronting -> rotation of the C2 domain to get into the feed -> post-exploitation through legitimate tools (LOLBins), which fides do not catch.
