A Practical Guide to Uncovering Malicious Infrastructure With Hunt.io

Tracking malicious infrastructure is critical to threat hunting and cyber threat intelligence. While traditional hunts focus on detecting compromises within an organization's environment, infrastructure hunting shifts the defender's focus outward-mapping attacker operations before they reach the network.

Threat actors rarely operate from a single server. Instead, they use clusters of domains, IP addresses, and network resources to stage malware, manage command-and-control (C2) and evade detection.

In this post, we'll walk through how to hunt malicious infrastructure using the Hunt app. We'll start with a single IP and use scan data to reveal connections leading to a group of servers likely linked to malware delivery. By following these indicators, defenders can take a proactive approach, turning isolated data points into a clearer picture of adversary C2 activity.

Step 1: Finding a Starting Point

Every hunt begins somewhere. Sometimes, it starts with a clear lead-an IP address found in a threat feed like IOC Hunter, a domain listed as an indicator of compromise (IoC) in a security report, or an alert in a security incident and event monitoring (SIEM) system. It can also begin with a hunch-an unusual connection in a firewall log or a pattern in network traffic that stands out.

Websites like MalwareBazaar and ThreatFox regularly publish indicators linked to malware infrastructure, making them valuable investigative sources. Discussions on X can also surface real-time threat activity, offering additional context on C2 tactics.

Our investigation starts with 168.100.9[.]71, an IP recently identified in Hunt's internet scans. While we know it's associated with suspicious activity, the focus here isn't on attribution-it's on analyzing the IP and uncovering related infrastructure.

Open a text editor or grab a notebook, and follow along as we walk through each step.

Step 2: Querying the IP in Hunt

We'll start by entering the IP into Hunt's search bar. In addition to IP addresses, users can also conduct lookups of domains, ASNs, and even threat actor names. If you haven't checked out our post on the new features in Hunt 2.0, please do.

By default, we are dropped into the Info tab (Figure 1).

Breaking Down the Overview Page

The Overview page immediately shows where this IP is hosted, what ports are open, and whether DNS records are associated. The Info tab is a starting point, providing key details like the hosting provider, ASN, and software. While this alone won't confirm malicious activity, it helps researchers and defenders decide whether an IP warrants further analysis.

Several other tabs will assist in our hunt going forward:

• Domains - Displays any domain names that have resolved to the IP.

• Associations - Quickly identifies connections to additional infrastructure through shared SSH keys, TLS certificates, and IOCs.

• SSL History - Logs past TLS certificates used by the IP, making it an essential tool for tracking infrastructure reuse.

These tabs will assist us as we continue investigating, offering immediate pivot points that help us map out the surrounding infrastructure.

Step 3: Analyzing ASN & Domain Data

Staying within the overview page in Figure 1, we can see the IP address in question is hosted by BL Networks. Also referred to as BitLaunch and BLNWX, the company offers anonymous virtual private servers (VPS), allowing customers to pay with digital currencies-an attractive option for cybercriminals.

In February, @BushidoToken wrote an in-depth blog post about BLNWX, highlighting some of the malware families operating within its IP space.

A closer look at the Domain tab reveals a single domain- btc-winnings-made[.]com-resolving to our IP (Figure 2). The naming scheme suggests ties to cryptocurrency-related fraud, scams, and other criminal activity.

This lone domain linked to the server is a strong hunting indicator that we are dealing with a VPS. More importantly, this aligns with our earlier observations about BL Networks: this is a dedicated VPS, not shared hosting.

Shared servers typically host hundreds or thousands of domains on the same IP, making attribution difficult. Many threat actors exploit this to blend into legitimate traffic, hoping researchers will focus elsewhere.

At this stage, we've established:

• An IP linked to a cryptocurrency-related domain with potential fraud ties.

• A VPS provider known to host malicious infrastructure.

Starting your hunt by analyzing domain names provides insight into how a server is likely being used, offering an early look at the threat actor's intent before examining the ports and services.

Step 4: Ports, Services, and Server Responses

Network ports tell the story of a server's purpose on the internet-whether for malware delivery, phishing, or command-and-control. The ports that are exposed, the protocols in use, and how services respond can reveal unique patterns that can be used to track malicious activity.

Our suspect IP has ports 22 (SSH), 80 (HTTP), and 443 (HTTPS) open, and Nginx is detected as the software for web-facing services. Port 8080 was briefly observed on March 17th; however, we were unable to identify the protocol.

Examining HTTP Responses

HTTP headers, response codes, and server banners often reveal patterns linked to attacker-controlled infrastructure. Threat actors may modify error pages, alter default headers, or run outdated software-leaving behind identifiable fingerprints that can be used to track related servers.

The web ports share the same software, response codes, and HTML body. Clicking the magnifying glass next to port 443 displays the captured response data.

Near the bottom of the image in Figure 3, we see that the server returned a generic 404 Not Found. Additionally, we can see some standard HTTP headers that you'll become more familiar with as you continue your threat hunting journey.

Sending an unexpected request to some Cobalt Strike servers results in the below response headers :

HTTP/1.1  404 Not Found
Content-Type: text/plain
Date: Varies
Content-Length: 0

You may quickly notice the stark difference in header fields between port 443 in the screenshot and the Cobalt Strike example.

HTML response body content is a reliable second to headers regarding fingerprinting servers. This method is often seen in admin panels for stealers, phishing kits, and some security frameworks. The key is to isolate elements attackers must leave in place for the page to function rather than random code that can quickly be deleted.

The HTML body for port 443 included the following string:

"a padding to disable MSIE and Chrome friendly error page."

We can use SQL Search to quickly determine the number of occurrences of the above strings in Hunt's database. A high number of results means the string is prevalent across the internet; this is the opposite of what we seek while hunting.

With over six million results, this string is too common to be helpful. Hunting often requires working through multiple data points before finding something actionable, and in this case, the ports and HTTP response didn't provide any leads.

A check of SSH history also revealed no shared keys or configurations linking this IP to additional infrastructure. We've exhausted almost all pieces of information except for one: the TLS certificate.

Step 5: Analyzing TLS Certificates for Clues

TLS certificates are a valuable tool for tracking adversary infrastructure. Unlike domains and IP addresses, which are easy to change, certificates often persist across multiple systems, exposing connections threat actors might try to obscure. Whether issued by a legitimate Certificate Authority or self-signed, TLS data can reveal patterns that help analysts identify related activity before an operation gains traction.

In Hunt, the SSL History tab provides a timeline of certificates previously used on the server, offering valuable context on how the IP has been configured over time. In this case, we see a recent certificate from March 18th, giving us a fresh lead to explore.

The domain we identified earlier appears as a certificate subject common name dating back to 2022. There is no indication that this domain is linked to malicious activity, so it can be disregarded.

At the top of the list, just a few days old as of this post, we see a certificate on port 443 with the often-used field of 'Internet Widgits Pty Ltd.' This placeholder appears in self-signed certificates by default when OpenSSL fields are not manually configured. The actor likely used 'localhost' to make the certificate appear as part of a local test environment.

The 'Certificate Details' view provides key metadata, including the validity period, SHA-256 fingerprint, and JA4X hash.

Although we determined the domain is likely historical, we still know the IP is hosted on a suspicious ASN and uses a self-signed certificate, requiring us to keep digging.

Before moving forward, we'll record certificate hashes for tracking:

SHA-256 Fingerprint:
D351D5F06EC229AF75442BE05C5C90F76471EF17EDCB1AF92E8532CA1854AF5D

JA4X Hash:
96a6439c8f5c_96a6439c8f5c_795797892f9c

What is JA4X?

JA4X, part of the JA4+ fingerprinting suite, provides a powerful way to track TLS certificates based on how they are generated rather than their specific values. Instead of relying on standard certificate hashes, which change when a cert is reissued, JA4X fingerprints the underlying structure, making it useful for linking malware C2 servers.

Step 6: Let's Build A Query!

Since our last indicator is a self-signed certificate likely generated with OpenSSL, we can construct an SQL query to search Hunt's scan data for similar servers. Our goal is to identify low-prevalence certificates, as high-occurrence values are often unrelated to targeted malware campaigns. This is dependent on the family being tracked-for instance, we monitor over 1,000 Asset Reconnaissance Lighthouse (ARL) servers, which is a much wider-used software.

To build our query, we'll match the JA4X hash and the subject common name ('localhost') to uncover other servers with identical certificate structures.

SELECT ip,  port
FROM certificates
WHERE ja4x.full = '96a6439c8f5c_96a6439c8f5c_795797892f9c' AND subject.common_name = 'localhost'
GROUP BY ip, port

The results of our SQL query:

Returning just six servers across Hunt's dataset confirms that this certificate is not widely used and likely belongs to a small cluster of related systems or is a default setup for a malware family.

Expanding the Investigation

From here, we can pivot further to understand whether these IPs are linked to known malware or benign activity. A VirusTotal search (Figure 8) can provide additional context, including existing detections and historical reputation data.

As of the last analysis, just seven vendors found the IP malicious or suspicious. The community comments (checking this should be part of your hunt workflow) reveal a possible tie to Latrodectus malware.

Our job isn't done just yet. We can scour sandbox reports for the IP and any malware samples, downloaded from or communicating with the server and check VirusTotal results for the remaining IPs.

By combining Hunt's scan data with external intelligence sources, we've identified a small set of servers exhibiting characteristics consistent with malware infrastructure.

Conclusion

Hunting and tracking adversary infrastructure requires persistence, creativity, and a structured approach to analyzing multiple data points. Starting with a single IP, we leveraged Hunt to examine domains, ports, HTTP responses, and TLS certificates, ultimately identifying potential connections that could expand an investigation. While not every lead will result in a direct pivot, refining your methodology and layering intelligence sources will improve the ability to track threat actor operations over time.

Tips for Getting Started

1. Start Small, Expand Methodically - A single IP, domain, or certificate can reveal hidden overlaps, but avoid jumping too quickly between data points-build a foundation first.

2. Look for Patterns, Not Just IOCs - Threat actors reuse hosting providers, SSL configurations, and infrastructure tactics, so focus on behavioral fingerprints rather than isolated indicators.

3. Use Multiple Intelligence Sources - No single dataset is perfect. Correlate findings across Hunt, passive DNS, WHOIS records, and threat intel feeds to validate and expand investigations.

Hunting Guide Network Observables and IOCs