Pivoting: From One IOC to Many

Why One IOC Is Never Enough

A Wazuh alert fires: outbound connection to 185.220.101.42 on port 443. You have an IP address. What do you actually know?

Almost nothing.

That IP could be a dedicated C2 server operated by an APT group. It could be a compromised legitimate web server hosting a malware staging directory alongside a perfectly innocent WordPress blog. It could be a Cloudflare or AWS IP shared by ten thousand unrelated customers. It could be a Tor exit node that rotated away from the threat actor six hours ago. Without context, an IP address is just four octets — and four octets do not constitute actionable intelligence.

This is where most junior analysts make a critical mistake. They see the IP, check it against one blocklist, confirm it is "malicious," and move on. They block the IP, close the ticket, and call it done. They have completed roughly 10% of the job.

The other 90% is pivoting — systematically using one known indicator to discover related indicators, building outward from a single data point until you have a complete threat picture. Pivoting is the technique that separates a ticket-closer from an analyst. It transforms a single alert into an intelligence product that protects your entire organization.

Think of it this way: a single IOC is a dot. Pivoting connects the dots. And only connected dots reveal the shape of the threat.

Here is what pivoting can produce from that single IP:

• Related infrastructure: domains, subdomains, sibling IPs on the same hosting
• Malware artifacts: hashes, filenames, behavioral signatures
• Campaign context: threat actor attribution, target sectors, historical activity
• Scope of exposure: which internal assets communicated with the infrastructure
• Defensive actions: specific IPs, domains, and hashes to block across every control

Without pivoting, you block one IP and the attacker shifts to the next domain on their infrastructure. With pivoting, you block the entire campaign.

The Pivot Chain

Pivoting is not random — it follows a chain. Each pivot takes an output from the previous step and feeds it into a new lookup, expanding your knowledge with every iteration. A well-executed pivot chain can turn a single IP into a complete campaign profile in under thirty minutes.

Click to enlarge

Let us walk through a complete example, start to finish.

Starting Point: Wazuh Alert

Your SIEM fires an alert: host WIN-SERVER-01 made an outbound HTTPS connection to 185.220.101.42:443. The alert rule is a custom watchlist match — this IP appeared in a threat feed two days ago tagged as "suspicious infrastructure." You have one IOC:

IOC Type:  IP Address
Value:     185.220.101.42
Source:    Wazuh alert (rule 100210)
Context:   Outbound HTTPS from WIN-SERVER-01

Pivot 1 — Passive DNS: IP → Domain

Your first move is passive DNS. Unlike active DNS (which queries live nameservers), passive DNS databases record historical DNS resolutions observed by sensors deployed across the internet. Services like SecurityTrails, CIRCL Passive DNS, Farsight DNSDB, and VirusTotal maintain massive archives of which domains resolved to which IPs and when.

You query 185.220.101.42 and find:

185.220.101.42 → evil-update.example.com  (first seen: 2026-02-18, last seen: 2026-02-23)
185.220.101.42 → ns2.legit-hosting.example.net  (first seen: 2025-06-01, last seen: 2025-12-15)

The second record is old — that IP previously hosted a nameserver for a legitimate hosting company. The first record is current and interesting: evil-update.example.com has been resolving to this IP for only five days. The name itself mimics a software update service — a classic social engineering pattern for C2 domains.

New IOC discovered: evil-update.example.com

Pivot 2 — WHOIS: Domain → Registration Data

Next, you check WHOIS for evil-update.example.com:

Domain:       evil-update.example.com
Registrar:    Namecheap
Registered:   2026-02-15
Updated:      2026-02-15
Expires:      2027-02-15
Registrant:   attacker@proton.me
Name Servers: ns1.suspicious-dns.example.com, ns2.suspicious-dns.example.com

Two red flags jump out immediately. First, the domain was registered only eight days ago. Newly registered domains (NRDs) — especially those less than 30 days old — are disproportionately associated with malicious activity. Legitimate organizations register domains weeks or months before deploying them; attackers register infrastructure just-in-time. Second, the registrant email uses ProtonMail, a privacy-focused provider commonly seen in attacker registrations (though also used legitimately — this is context, not proof).

New IOCs discovered: registrant email attacker@proton.me, nameservers suspicious-dns.example.com

Pivot 3 — Reverse WHOIS: Registrant → Related Domains

Now the pivot chain accelerates. You take the registrant email attacker@proton.me and perform a reverse WHOIS lookup — searching for all domains registered with that same email address. Services like DomainTools, WhoisXML API, and SecurityTrails support this query type.

Results:

attacker@proton.me owns:
  1. evil-update.example.com     (registered 2026-02-15)
  2. safe-patch.example.com      (registered 2026-02-14)
  3. win-update.example.com      (registered 2026-02-14)
  4. app-store.example.com       (registered 2026-02-16)

All four domains were registered within a 48-hour window. All four use naming patterns that mimic legitimate software update or distribution services. This is a coordinated infrastructure setup — the attacker registered a batch of C2 domains in preparation for a campaign.

From one IP address, you now have four domains to block. Without the reverse WHOIS pivot, three of those domains would remain unknown — sitting in your network, waiting for the attacker to rotate to them when you block the first one.

Pivot 4 — MISP Correlation: Domains → Threat Events

You search all four domains plus the original IP in your MISP instance. One hit: evil-update.example.com appears in an event titled "Cobalt Strike Infrastructure — February 2026" contributed by a sector ISAC three days ago. The MISP event contains:

Event:    Cobalt Strike Infrastructure — February 2026
Tags:     tlp:amber, cobalt-strike, apt
Attributes:
  - Domain:  evil-update.example.com
  - IP:      185.220.101.42
  - SHA256:  a1b2c3d4e5f6...7890abcdef1234567890abcdef1234567890abcdef12345678
  - URL:     https://evil-update.example.com/update.exe
  - Comment: "Beacon payload, HTTPS C2, profile mimics Windows Update traffic"

New IOC discovered: SHA256 hash of the Cobalt Strike beacon payload, plus a delivery URL.

Pivot 5 — Sandbox / VirusTotal: Hash → Malware Behavior

You submit the SHA256 hash to VirusTotal:

SHA256:         a1b2c3d4e5f6...7890abcdef1234567890
Detection:      45/70 vendors flagged as malicious
Family:         Cobalt Strike Beacon
First seen:     2026-02-16
File size:      287 KB
File type:      PE32 executable (GUI) Intel 80386

Behavioral analysis:
  - Creates scheduled task "WindowsUpdate" (runs every 4 hours)
  - Spawns powershell.exe with encoded command
  - Connects to evil-update.example.com:443
  - Writes to C:\ProgramData\update\svchost.exe
  - Modifies registry: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

The sandbox tells you exactly what the malware does: it creates persistence via scheduled task and registry run key, uses PowerShell for execution, and communicates over HTTPS to the C2 domain you already identified. Every one of these behaviors maps to a specific detection opportunity.

New IOCs discovered: file path C:\ProgramData\update\svchost.exe, scheduled task name WindowsUpdate, registry key modification.

Pivot 6 — ATT&CK Mapping: Behaviors → Techniques

The behavioral data maps cleanly to ATT&CK techniques:

This TTP profile — HTTPS beacon + PowerShell + dual persistence mechanisms + process name masquerading — is consistent with Cobalt Strike operations by multiple threat groups including APT29 and FIN7.

The Result

From one IP address, you now have:

• 4 domains to block at DNS/proxy
• 1 malware hash for EDR detection rules
• 1 delivery URL to block at web gateway
• 1 file path + 1 scheduled task for endpoint detection
• 1 registry key for persistence monitoring
• 5 ATT&CK techniques for detection coverage mapping
• Campaign attribution linking to Cobalt Strike infrastructure
• Scope assessment: WIN-SERVER-01 confirmed affected, need to hunt for the hash and domains across all endpoints

That is the power of pivoting. Six steps. One IP became an entire defensive playbook.

Pivot Techniques Reference

Each pivot technique connects different IOC types. Knowing which technique to reach for — and in what order — is what makes pivoting efficient rather than random.

[14:32] Pivot 1: IP 185.220.101.42 → pDNS → evil-update.example.com (SecurityTrails)
[14:35] Pivot 2: evil-update.example.com → WHOIS → attacker@proton.me, registered 2026-02-15
[14:38] Pivot 3: attacker@proton.me → reverse WHOIS → 3 additional domains
...

Cross-Tool Pivoting

The techniques above describe how to pivot between indicator types (IP → domain → registrant → more domains). But the real force multiplier in a SOC is pivoting between tools — using the output of one platform as the input for another.

Click to enlarge

SIEM → Threat Intel (Wazuh → MISP)

This is the most common starting point. A Wazuh alert fires with an IP, domain, or hash. You take that IOC and search MISP.

What you gain: Campaign context. The MISP event tells you who the threat actor is, what malware family they use, what other infrastructure they operate, and who else has reported this activity. A raw alert becomes a contextualized threat.

Example workflow:

1. Wazuh alert: DNS query for evil-update.example.com from WIN-SERVER-01
2. Copy domain → search in MISP
3. MISP returns: Cobalt Strike event with 12 related IOCs, tagged APT29, TLP:AMBER
4. You now know this is not a random domain — it is part of a known campaign

Threat Intel → SIEM (MISP → Wazuh)

The reverse direction is equally valuable but often overlooked. Instead of starting from an alert, you start from a MISP event — perhaps a new threat report shared by your ISAC — and proactively search your SIEM for hits.

What you gain: Scope of exposure. You discover whether your environment has already been affected by a threat you just learned about, potentially catching compromises that did not trigger alerts.

Example workflow:

1. MISP event published: new Emotet wave, 35 C2 IPs listed
2. Extract all 35 IPs → search Wazuh logs for the past 30 days
3. Three IPs have hits: 10.0.5.22 contacted 198.51.100.77 on Feb 19, 20, and 21
4. You have a confirmed compromise that was not previously escalated

Threat Intel → EDR (MISP → Velociraptor)

MISP gives you file hashes and behavioral indicators. Velociraptor lets you hunt across every endpoint in your fleet.

What you gain: Infected machine identification. You find exactly which endpoints have the malware artifacts present — files on disk, registry keys, scheduled tasks, running processes.

Example workflow:

1. MISP event contains SHA256 hash of Cobalt Strike beacon
2. Create Velociraptor hunt: search all endpoints for that hash in common persistence locations
3. Velociraptor finds the file on 3 machines: WIN-SERVER-01, WIN-WS-14, WIN-WS-27
4. Scope is now defined — 3 machines need containment, not the entire network

EDR → SIEM (Velociraptor → Wazuh)

You find a suspicious process or artifact on an endpoint via Velociraptor. Now pivot to the SIEM to find the network-layer evidence.

What you gain: Full attack timeline. The endpoint tells you what happened on the machine; the SIEM tells you what happened on the network. Together they reconstruct the entire attack chain.

Example workflow:

1. Velociraptor: WIN-SERVER-01 has suspicious svchost.exe in C:\ProgramData\update\ (wrong path for legitimate svchost)
2. Check Wazuh: correlate by hostname + time window
3. Wazuh shows: outbound connections to 185.220.101.42:443 every 4 hours (beacon interval)
4. Wazuh also shows: PowerShell execution event at 2026-02-19T03:14:22Z (initial execution)
5. Full timeline: initial compromise → beacon installation → periodic C2 checkin

The Feedback Loop

Notice how each tool's output feeds another tool's input:

Alert (Wazuh) → IOC lookup (MISP) → Context
    ↑                                    ↓
Timeline                            New IOCs
    ↑                                    ↓
Correlation (Wazuh) ← Endpoint hunt (Velociraptor)

This is not a linear process — it is a loop. You cycle through the tools multiple times as each iteration reveals new information. The first pass gives you breadth (how big is this?). Subsequent passes give you depth (what exactly happened on each affected system?).

Building a Threat Profile

After a thorough pivot chain, you will have accumulated a significant amount of information. A pile of IOCs in your notes is useful to you in the moment, but it is not useful to your team tomorrow, to your incident commander right now, or to the ISAC members who might benefit from your findings. You need to organize your pivot results into a threat profile — a structured document that captures everything you discovered.

A threat profile is the deliverable that justifies the time you spent pivoting. It transforms raw investigation notes into an intelligence product.

============================================================
THREAT PROFILE
============================================================
Campaign:        Cobalt Strike Infrastructure Wave — Feb 2026
Attribution:     Unknown (TTP overlap with APT29)
Confidence:      Medium-High
Date:            2026-02-23
Analyst:         [Your Name]

------------------------------------------------------------
INDICATORS OF COMPROMISE
------------------------------------------------------------
IP Addresses:
  - 185.220.101.42          (C2 server, AS12345)

Domains:
  - evil-update.example.com  (primary C2)
  - safe-patch.example.com   (standby C2)
  - win-update.example.com   (standby C2)
  - app-store.example.com    (standby C2)

File Hashes (SHA256):
  - a1b2c3d4e5f6...78 (Cobalt Strike beacon, 287KB PE32)

URLs:
  - https://evil-update.example.com/update.exe (delivery)

File Paths:
  - C:\ProgramData\update\svchost.exe

Persistence:
  - Scheduled task: "WindowsUpdate" (4-hour interval)
  - Registry: HKLM\SOFTWARE\Microsoft\...\Run\WindowsUpdate

------------------------------------------------------------
ATT&CK TECHNIQUES
------------------------------------------------------------
  T1071.001  Application Layer Protocol: Web Protocols
  T1059.001  Command and Scripting Interpreter: PowerShell
  T1053.005  Scheduled Task/Job: Scheduled Task
  T1547.001  Boot or Logon Autostart Execution: Registry Run Keys
  T1036.005  Masquerading: Match Legitimate Name

------------------------------------------------------------
AFFECTED ASSETS
------------------------------------------------------------
  - WIN-SERVER-01 (confirmed: outbound C2, beacon on disk)
  - WIN-WS-14     (confirmed: beacon hash found via EDR hunt)
  - WIN-WS-27     (confirmed: beacon hash found via EDR hunt)

------------------------------------------------------------
TIMELINE
------------------------------------------------------------
  2026-02-14  Domains registered (safe-patch, win-update)
  2026-02-15  evil-update.example.com registered
  2026-02-16  app-store.example.com registered; beacon compiled
  2026-02-19  03:14 UTC — Initial compromise on WIN-SERVER-01
  2026-02-19  03:18 UTC — Beacon installed, first C2 callback
  2026-02-19  07:14 UTC — Second C2 callback (4hr beacon)
  2026-02-23  14:30 UTC — Alert triggered, investigation began

------------------------------------------------------------
RECOMMENDED ACTIONS
------------------------------------------------------------
  [ ] Block all 4 domains at DNS sinkhole / web proxy
  [ ] Block IP 185.220.101.42 at firewall (egress)
  [ ] Deploy EDR signature for beacon hash
  [ ] Isolate WIN-SERVER-01, WIN-WS-14, WIN-WS-27
  [ ] Hunt for scheduled task "WindowsUpdate" fleet-wide
  [ ] Hunt for svchost.exe in C:\ProgramData\update\
  [ ] Share IOCs with ISAC (TLP:AMBER)
  [ ] Escalate to IR team for full containment/eradication
============================================================

Every field in this profile exists because of a specific pivot. The domains came from reverse WHOIS. The hash came from MISP. The file paths and scheduled task came from sandbox analysis. The affected assets came from cross-tool pivoting through Velociraptor. The timeline came from correlating SIEM logs with WHOIS registration dates.

This is what pivoting produces: not just a list of things to block, but a complete operational picture that enables decisive action.

When to Stop Pivoting

Pivoting is powerful, but it is not unlimited. Every minute you spend investigating one alert is a minute you are not spending on the next thirty alerts in the queue. Knowing when to stop is as important as knowing how to start.

Stop pivoting when you hit diminishing returns. If your last three pivots produced no new IOCs, no new affected assets, and no new behavioral context, you have likely exhausted the available intelligence. Further pivoting will produce noise, not signal.

Stop when your confidence is high enough for action. You do not need 100% attribution to block four malicious domains and isolate three compromised machines. If your confidence is "medium-high" that this is Cobalt Strike infrastructure — block it. You can refine attribution later while containment is underway.

Stop when time pressure demands action. If a threat is actively exfiltrating data, do not spend two hours mapping the attacker's entire domain portfolio. Block what you know, contain the affected systems, and continue pivoting in parallel with the incident response.

Match pivot depth to alert severity. This is the practical reality of SOC work:

A critical alert — active C2 beaconing, confirmed malware, evidence of lateral movement — deserves a full pivot chain that produces a complete threat profile. A low-severity alert — a single DNS query to a domain flagged by one feed with no other corroboration — deserves a quick VirusTotal check and a decision.

Do not spend four hours building a threat profile for a level-3 alert that turned out to be a false positive. And do not spend five minutes on a level-1 alert that turned out to be an active breach.

Key Takeaways

What's Next

You now know how to start with one IOC and discover dozens of related indicators through systematic pivoting. You can trace infrastructure chains, correlate across tools, and compile findings into threat profiles that drive defensive action.

In Lesson 5.5 — Intel-Driven Triage, we will bring everything from this module together. You will learn how to apply threat intelligence — IOC lookups, enrichment, feed context, and pivoting results — to the actual triage decision. When an alert arrives, how does intelligence change whether you escalate, investigate, or dismiss? How do you weigh feed confidence against alert severity? Intel-driven triage is where all of this becomes operational.