I Found a Loud IP in the Logs, It Turned Out to Be a Live C2 Channel

On January 31, 2026, one line in a CSV export kept catching my eye every time I re-ran the same query a spike in connection frequency to a managed host in our environment, talking to an external address none of our asset owners could explain. It wasn't the only line in the export, but it was the loudest, and loud is usually where you start.

That address was 185.220.101.47. By the end of the investigation, it wasn't just "a suspicious IP" anymore it was the last visible link in a chain that started with a phishing email, moved through command-line execution, and ended in an active Command and Control callback sitting quietly on a compromised endpoint.

Tooling Breakdown

Three tools carried this investigation from a vague anomaly to a confirmed, mapped-out attack chain:

• Splunk: the SIEM used to ingest, query, and correlate the raw log data, and the primary workspace for reconstructing the attack timeline.
• AbuseIPDB: A community-driven threat intelligence platform used to check the reputation and abuse history of the external IP address in question.
• VirusTotal: used to cross-reference the same IP against a broader set of security vendor detections, malware associations, and historical flags.

Most real-world SOC investigations aren't won with obscure tooling; they're won with disciplined use of the tools every analyst already has access to.

Step-by-Step Telemetry Investigation

Step 1: Getting the Data Into Splunk

The investigation started with raw log data delivered as a CSV export. Before any hunting could happen, that file needed to live inside Splunk, where it could actually be queried, filtered, and correlated against timestamps and event codes.

Step 2: Finding the Loudest Connection

With the data indexed, the next move was to identify which connection was making the most noise literally, the highest-frequency or most anomalous communication pattern in the timeframe. In threat hunting, "loud" traffic is often the fastest lead you'll get, because attackers rarely make a single, quiet call home. C2 beaconing tends to repeat, and repetition is exactly what a SIEM query is built to surface.

Query used:

index=main source="PROJ.CSV" | timechart span=1h count by host

Query used:

index=main source="PROJ.CSV" | timechart span=1h count by host

This step pinpointed the window of time the attacker was active the anchor point for everything that followed.

Step 3: Isolating the External IP

Once the timeline was established, the next query filtered specifically for the external IP address responsible for the unusual communication. Tracing this connection flow wasn't just about naming a bad actor it was about understanding how that actor got in and what path the payload likely took to reach the host. This step effectively drew the first rough sketch of the attack chain.

Query used:

| mvexpand extracted_ip | stats count by extracted_ip | sort - count

Query used:

| mvexpand extracted_ip | stats count by extracted_ip | sort - count

Step 4: Cross-Referencing Against Threat Intelligence

With a specific IP address in hand, it was time to find out who or what this actually was. Cross-referencing 185.220.101.47 against AbuseIPDB and VirusTotal turned a bare IP address into a threat profile with history, context, and community-verified abuse reports.

Step 5: Mapping the Attack Chain Through Windows Event IDs

The final step brought the investigation back into the host itself. By reviewing Windows Event IDs tied to the malicious IP, it became possible to reconstruct exactly how the attacker communicated with the machine not just that a connection happened, but the sequence of technical actions that made it possible.

Query used:

index=main source="PROJ.CSV" | stats count by EventCode | sort - count

Query used:

index=main source="PROJ.CSV" | stats count by EventCode | sort - count

Findings

Initial Access & Threat Intelligence

The primary malicious IP address was confirmed as 185.220.101.47. Both AbuseIPDB and VirusTotal returned results consistent with phishing infrastructure, along with historical reports tied to web-based attacks and brute-force activity. Community-sourced abuse reports independently corroborated that this address had previously been leveraged for social engineering, credential harvesting, and initial access operations this wasn't a first offense for this IP.

Telemetry & Attack Chain Flow

1. Sysmon Event ID 1 (Process Creation): A process was spawned via command-line interface tooling, consistent with the payload delivered through the phishing email being executed on the host.
2. Sysmon Event ID 22 (DNS Query): That process immediately resolved a spoofed domain the malicious payload reaching out to find its C2 infrastructure, not a user browsing to it.

The two events sit seconds apart in the timeline, and the process lineage is what ties them together: the same process responsible for execution is the one that triggered the DNS resolution.

Command and Control & Lateral Movement

Following execution, Sysmon Event ID 3 (Network Connection) confirmed outbound communication from the compromised host to 185.220.101.47 the establishment of an active C2 callback channel. Correlating this with the IP's historical threat profile strongly suggests the attacker was using this foothold to attempt credential harvesting, with the likely intent of pivoting toward lateral movement across adjacent accounts.

Phishing got them in the door, a command-line payload gave them execution, and the outbound connection gave them a way to keep talking to the compromised host from the outside.

Mapping the findings to lets this incident get compared against other cases, fed into detection coverage reviews, and understood by anyone downstream without re-reading the raw logs.

Scope

• Affected hosts: 1 confirmed endpoint; no additional hosts showed the same beaconing pattern to 185.220.101.47 at the time of review.
• Data exfiltration: No confirmed evidence of data exfiltration at the time of writing; outbound traffic volume was consistent with beaconing/callback activity rather than bulk transfer, but full outbound byte-count review is recommended as a follow-up.
• Lateral movement: No confirmed lateral movement to adjacent hosts; the historical threat profile of 185.220.101.47 indicates capability for credential harvesting, which is why IAM remediation below is treated as mandatory rather than precautionary.

Actionable Remediation

Immediate Containment & Perimeter Defense

• Isolate the infected host from the network immediately to halt any further lateral movement.
• Block 185.220.101.47 and all associated indicators of compromise at the firewall and across EDR platforms.

Identity & Access Management

• Force credential resets for all impacted and potentially exposed accounts to shut down any credential-harvesting foothold.
• Enforce mandatory multi-factor authentication (MFA) organization-wide not just for flagged accounts.

Endpoint & Detection Engineering

• Confirm Microsoft Defender is active, updated, and properly tuned across all endpoints.
• Build and deploy SIEM detection rules specifically targeted at suspicious process creation and anomalous command-line execution patterns, so the next Event ID 1 doesn't wait for a human to notice it.

Security Awareness & Training

• Run targeted phishing simulation campaigns to measure and improve employee resistance to social engineering, directly addressing the initial access vector used in this incident.

What This Investigation Reinforced

A few things stuck with me after closing this one out.

First, Sysmon is worth every bit of overhead it adds. It runs quietly in the background, hooked into the Windows kernel, capturing the kind of high-fidelity telemetry that standard Windows event logs simply don't record. Without Event IDs 1, 22, and 3 lined up in sequence and without the process lineage tying execution to the DNS query that followed it this would have stayed an unexplained instead of a fully mapped attack chain.

Second, raw log data is only half the story until it's correlated against threat intelligence. An IP address by itself is just a string of numbers. Cross-referenced against AbuseIPDB and VirusTotal, it becomes a known actor with a history and that context is what turns a hunch into a defensible finding.

Most of all, this incident was a reminder that the loudest signal in your logs is often the fastest way in. Attackers don't always hide well. Sometimes they just need someone to be paying attention to the noise.

If found this breakdown useful, follow along for more. I write these investigations as hands-on, from-the-logs walkthroughs the same way they'd actually get worked in a SOC.

Subscribe or follow for the next one, and drop a comment if there's a specific attack chain, tool, or telemetry source you'd want broken down next.