Internal vs External IP Analysis in Threat Hunting

Two Addresses, Two Investigations

Your SIEM fires a high-severity alert at 3 AM. A workstation on the finance VLAN just made an outbound connection to an IP address flagged in three threat intelligence feeds. That external address matters. But the internal address — the workstation itself — matters just as much. IP analysis in threat hunting is the discipline of working both ends of a connection simultaneously, and getting the sequence wrong can cost you hours during an active incident.

Most SOC analysts start with the external indicator. It is the flashy one, the address tied to a known command-and-control server or a bulletproof hosting provider. But limiting your investigation to the external side leaves a dangerous blind spot. The internal IP tells you which asset is compromised, what it has access to, and whether the adversary has already moved laterally.

External IP Analysis: Mapping the Adversary’s Infrastructure

External IP analysis focuses on the destination side of suspicious connections. When you identify a potentially malicious external address, the goal is to answer three questions. Is this IP genuinely malicious? How many internal systems have contacted it? How long has this communication been occurring?

Start with your firewall connection logs. These provide the source and destination IP addresses along with the protocols used for every connection between your internal network and the outside world. Look beyond allowed connections. Denied connections are equally telling. Adversaries routinely probe well-known ports to map what is accessible from the outside. A pattern of denied connections from a single external IP targeting ports 445, 3389, and 22 in sequence is a textbook network scan, mapping directly to MITRE ATT&CK Active Scanning under the Reconnaissance tactic (T1595).

Proxy logs are your next stop. They reveal whether internal systems connected to specific URLs hosted on that external IP. DNS logs add another layer — they show whether any system on the internal network attempted to resolve domains associated with the suspicious address. The combination of proxy, DNS, and firewall logs gives you a timeline that no single data source can provide alone.

Enrichment Changes Everything

Raw IP addresses are just numbers. Enrichment turns them into intelligence. Run the external IP through threat intelligence platforms like MISP, VirusTotal, or AbuseIPDB. Check the ASN, the hosting provider, the geolocation, and any associated domains. A connection to a residential IP in a country where you have no business operations at 2 AM local time is far more suspicious than a connection to a well-known CDN during business hours.

We ran into exactly this pattern during a threat hunting engagement for a financial services client. A server in their environment was communicating with an external IP during off-peak hours — roughly between 1 AM and 4 AM over a two-week period. The regular traffic pattern for that server showed zero outbound connections after midnight. The external IP was registered to a hosting provider with no ties to any of the client’s vendors. That off-hours cadence is a hallmark of C2 beaconing, and the SIEM correlation confirmed it. Identifying patient zero — that first compromised server — let us scope the incident down from the entire network to three affected systems within two hours.

Internal IP Analysis: Following the Adversary Inside Your Network

External analysis tells you where the threat originates. Internal analysis tells you how far it has spread. This is the harder half of the investigation, and it is where most threat hunts either succeed or stall.

Once you have identified a compromised internal host, the next step is determining whether the adversary used that foothold to move laterally. Pull the connection logs for that internal IP and look for east-west traffic that deviates from baseline. A workstation in accounting that suddenly initiates SMB connections to a domain controller is not normal behavior.

The key indicators to watch for during internal IP analysis include:

• Unusual outbound network traffic volume or destinations from the host
• Anomalies in privileged user account activity originating from that IP
• Excessive login failures against other internal systems
• Port-application mismatches — SSH traffic on port 443, for instance
• DNS request anomalies such as high-frequency queries or requests to newly registered domains
• Suspicious registry or system file changes on the endpoint

Each of these maps to specific MITRE ATT&CK tactics. Excessive login failures point to Credential Access via Brute Force (T1110). Port-application mismatches suggest Defense Evasion through protocol tunneling. DNS anomalies could indicate either C2 communication or data exfiltration via DNS tunneling, which falls under Exfiltration (T1048).

Internal IP Blocking Is Not Just for External Threats

Here is my position on this: too many SOC teams treat internal IP blocking as a last resort. It should not be. If an internal host is confirmed compromised and is actively spreading an attack laterally, network isolation of that host is a containment action that buys you time. The same applies to rogue endpoints — devices plugged into the local network by a threat actor, or virtual interfaces configured as tunnels back to adversary infrastructure. Waiting to isolate these systems while you gather more evidence is a luxury that shrinks with every minute of lateral movement.

That said, isolating an internal IP in a production environment can cause service disruptions if that host runs critical applications. This is why your Active Directory audit policies need to be configured before an incident occurs. You need the log data to make fast, informed containment decisions without guessing which systems depend on the compromised host. Pre-incident preparation is not optional — it is the difference between a controlled response and a fire drill.

Correlating Both Sides in Your SIEM

The real power of IP analysis in threat hunting emerges when you correlate internal and external data in a single platform. If your SIEM aggregates connection logs from your perimeter firewall, web proxy, and internal network sensors, you can answer the critical scoping question: how many other internal hosts connected to the same suspect external IP? Organizations already using Azure Security Center for unified security management have a head start here, since centralized log ingestion is already in place.

Here is a KQL query for Microsoft Sentinel that identifies internal hosts communicating with a list of suspect external IPs:

// Find internal hosts connecting to suspect external IPs
let SuspectIPs = dynamic(["198.51.100.23", "203.0.113.47"]);
CommonSecurityLog
| where TimeGenerated > ago(14d)
| where DestinationIP in (SuspectIPs)
| summarize
    ConnectionCount = count(),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated),
    PortsUsed = make_set(DestinationPort)
    by SourceIP, DestinationIP
| sort by ConnectionCount desc

This query surfaces every internal source IP that reached out to your suspect addresses over the past 14 days, along with the connection count, time range, and destination ports. The ConnectionCount and time spread tell you whether this was a one-off DNS resolution or sustained C2 communication.

For Splunk environments, the equivalent SPL follows a similar structure:

index=firewall dest_ip IN ("198.51.100.23", "203.0.113.47")
| stats count as ConnectionCount,
        earliest(_time) as FirstSeen,
        latest(_time) as LastSeen,
        values(dest_port) as PortsUsed
        by src_ip, dest_ip
| sort -ConnectionCount

Both queries produce the same operational picture. The key is running them as soon as you have a confirmed external indicator, not after you have finished analyzing the first compromised host. Automating these queries with PowerShell scripts that trigger on specific alert types will cut your mean time to detect from days to hours.

Building a Repeatable IP Triage Playbook

Every threat hunt involving IP analysis should follow a documented sequence. Here is the five-step playbook we use at SSE for client engagements:

1. Identify the trigger. An alert, a threat intel feed match, or a hypothesis. Document the initial indicator — external IP, domain, or hash.
2. Scope externally. Enrich the external IP through threat intel platforms, ASN data, and geolocation. Determine if the IP is associated with known malware families or threat groups.
3. Scope internally. Query firewall, proxy, and DNS logs for any internal host that contacted the external indicator. This defines your blast radius.
4. Analyze internal hosts. For each internal IP identified, pull endpoint telemetry. Look for privilege escalation attempts, lateral movement, and persistence mechanisms.
5. Contain and document. Isolate confirmed compromised hosts. Block the external IP at the perimeter. Update your detection rules to catch variants.

This playbook aligns with the NIST Cybersecurity Framework functions of Detect, Respond, and Recover. It also feeds directly into your detection engineering cycle — every confirmed threat hunt should produce at least one new or refined detection rule.

Where This Approach Breaks Down

IP-based analysis has real limitations that you need to account for.

Adversaries rotate infrastructure constantly. The C2 IP you block today may be abandoned tomorrow, replaced by a fresh address with no threat intelligence coverage. This is why blocking external domains alongside IPs matters — it prevents attackers from simply updating a DNS A record to point their domain at a new server.

Shared infrastructure creates alert fatigue. A flagged IP address belonging to a major cloud provider might host thousands of legitimate services alongside the one malicious domain. Without additional context — the specific domain, URI path, or SNI header — your analysts will drown in false positives investigating connections to AWS or Azure endpoints. Context beyond the raw IP is non-negotiable for accurate triage.

NAT and proxy architectures inside your network can obscure which specific endpoint initiated a connection. When half your workforce connects through a VPN concentrator, the internal IP in your firewall logs is the VPN gateway, not the user’s device. Ensure your log pipeline captures the original client IP before NAT translation. For organizations managing their remote file storage infrastructure, this is critical — file access logs must correlate with actual user endpoints, not intermediary addresses, or your internal analysis will be incomplete.

Tighten Both Ends of the Connection

IP analysis in threat hunting is not a single discipline. It is two parallel investigations — external infrastructure mapping and internal scope assessment — that must converge to produce an accurate picture of the incident. Prioritize getting your log sources into a single SIEM with at least 14 days of retention. Build your KQL or SPL queries before you need them. Document your playbook so any analyst on your team can execute it at 3 AM without improvising.

The mean time to detect for organizations that correlate both internal and external IP data is measurably lower than those that treat each side in isolation. If your team needs help building detection capabilities, tuning SIEM correlation rules, or establishing a threat hunting program for your environment, reach out to our team. Every investigation makes the next one faster, but only if you are working both sides of the connection from the start.