$ oraclehacker@root:~

~/posts/hunting-adversary-infrastructure

Hunting Adversary Infrastructure.

Hello Readers,

This post walks through practical, intelligence-driven techniques used by threat researchers/threat intelligence analysts to detect malicious infrastructure used by the threat actors.

Introduction Modern cyber operations don’t begin and end with malware — they rely on infrastructure.

Behind every phishing kit, remote access trojan, or command-and-control (C2) framework lies attacker-controlled infrastructure: VPS servers, redirectors, staging domains, TLS certificates, and cloud instances.

Hunting adversary infrastructure means identifying attacker-controlled systems (C2 servers, redirectors, phishing hosts, malware distribution servers, staging servers, etc.) before or during campaigns.

So, Starting with What Is Adversary Infrastructure?

Adversary infrastructure refers to systems controlled or abused by attackers, including C2 Servers, Reverse tunnels, Malware download servers, Phishing domains, Redirectors, Bulletproof hosting providers, HTTP response structures etc.

For example, attackers leverage Frameworks such as Cobalt Strike or tunneling tools like Reverse SSH to establish Persistent Access to the compromised host.

And I will demonstrate how to hunt for Tunnelling tool Reverse SSH at the end of this blog post.

Why Infrastructure hunting matters?

Malware can change rapidly but infrastructure cannot be changed that easily as it takes lot of efforts for attackers to build infra bottom up from scratch so they frequently reuse TLS certificates, HTML templates, hosting providers, redirector patterns, domain registration emails.

By focussing on the fingerprints available, rather than the IP addresses researchers can uncover campaings, infrastructure etc.

Another example: Threat Actors Reuse self-signed certificates, Use identical Common Names (CN), Deploy certificates with similar validity periods by pivoting on SHA256 certificate fingerprints, Subject Common Name Issuer, Serial number we can identify cluster of related servers/services hosted on these nodes.

Ways to Uncover Threat Actor Infrastructure.

Internet-Wide Scanning & Search Engines : Search exposed services using Shodan, Censys, FOFA, Pivot on favicon hashes, Search by specific HTTP headers, Hunt exposed admin panels or login portals etc TLS & Certificate Analysis: Pivot on certificate SHA256 fingerprint, Search by Subject Common Name (CN), Pivot on Issuer patterns (e.g., bulk Let’s Encrypt issuance), Analyze JARM or JA3 TLS fingerprints etc DNS & Domain Intelligence: Passive DNS pivoting, Hunt newly registered domains, Look for domain registration pattern reuse (email, registrar, naming structure) etc Web Application Fingerprinting: Analyze HTML templates, Search for default framework strings, Identify reused login panels etc. Hosting & ASN Analysis: Pivot on hosting ASN, Identify clusters in same IP range, Hunt infrastructure in common VPS providers like, DigitalOcean, Linode, Amazon Web Services etc Malware & Tooling Analysis: Extract hardcoded C2 domains/IPs, Identify default configuration artifacts, Extract embedded TLS certificates, Identify hardcoded HTTP paths, Look for reused campaign infrastructure across samples Although there are many other ways to uncover the infrastructure, I have highlighted most important ones, perhaps the commonly used techniques in infra hunting.

Why Pivoting Plays a Critical Role in Infrastructure Hunting:

Pivoting is the process of taking one known artifact (IP, domain, certificate, string, hash, ASN, etc.) and using it to discover related infrastructure.

Without pivoting, you find one server. With pivoting, you uncover an entire campaign.

Pivoting allows analysts to group infrastructure by shared characteristics.

For example: Same certificate + same ASN, Same favicon hash + same HTML template, Same hosting provider + same domain naming pattern

Real time example, APT 43/Kimusky uses Hosting provider Vultr and uses .cloud, .store.info in their newly created domains.

So, lets start with Hunting for ReverseSSH Tunnels deployed.

We have github repository dedicated to point the reverse SSH https://github.com/NHAS/reverse_ssh/tree/main(found by Michael Koczwara Intel Ops)

First step is to understand how this tools works,

It’s a tool written in Go that lets you establish reverse SSH connections between a server and remote clients — essentially enabling remote shell access back to a central controller.

Why this is important to hunt for:

Post-exploitation frameworks (since a reverse connection bypasses firewall inbound restrictions).

Lets start by reviewing its source code.

The response header has standard 404 Not Found, also contains

w.Header().Set(“content-type”, “text/html”) w.Header().Set(“server”, “nginx”) w.Header().Set(“Connection”, “keep-alive”)

Hardcoded Strings include:

CommonName: AutoTLSCommonName, Country: []string{“US”}, Organization: []string{“Cloudflare, Inc”},

This will give us large pool of results, to narrow down we need more artifacts which will get it by fingerprinting the server to grab the HTTP headers.

Here I have hosted the reverse SSH server on port 3232 on EC2 to which I will have reverse shell using my own kali machine

Note: EC2 has already been deleted.

Now we will grab the headers to get the exact headers.

The important artifacts include Content length, Content Type Server etc.

Combining these artifacts with the headers we got we will be able to identify the threat actors infra.

For that we will use Shodan, Hunt IO, FOFA, Virus Total

We will start with Shodan, query built is

HTTP/1.1 404 Not Found country:”US” org:”Cloudflare Inc.” Content-Length: 138 which gave us the 2 results.

Now these results might not be the exact output that we want, but stay tuned to uncover the magic of Pivoting.

Checking the reputation on Virus Total to check if any malicious activity is seen recently.

Ohh nothing suspicious found, but wait observed something unusual, yes

We have our awesome community contributing everyday to keep us updated.

Yes we have successfully identified our first node of reverse SSH C2

Now its time to check these nodes on FOFA and Hunt IO, to check whether we will find any additional artifacts which will help us hunt to Infra.

Fofa provides valuable information regarding Certificate but not much useful information so that we can pivot.

But, it matches the country, organization & Common name in the github we found earlier which confirms the node as Reverse SSH instance.

Now, lets check in hunt io,

Here we have very useful information of JARM fingerprint which we can use to pivot to the actual infra.

So head back to the shodan again to build the query, now not limiting our search to country or organization.

Shodan Query looks like : ssl.jarm:3fd3fd20d3fd3fd00043d3fd3fd43d5ecfbe778b06e32b538bd51f24eb7398 HTTP/1.1 404 Not Found Content-Length: 138

Ohh, Yes we have our results, these 10 nodes uses the same HTTP response in their header and also uses same JARM fingerprint.

Lets check the reputation for any malicious activity.

Not flagged as malcious , but wait thanks to our community, we have our community note waiting for review.

Now, its your turn to check for other nodes, check the community notes, communicating files, referrer files, DNS replications and identify new domains, IP’s etc.

Here’s a small recap,

We have grabbed the header from the actual Reverse SSH C2 server Using the hard coded artifacts in the source code, idenfied first node Checking for more valuable information on other platforms and identifying usable artifacts to pivot Pivoting using the additional artifacts to hunt for actual hosted infra. Cross examining those infra on intel platforms to check their recent activity and confirming the nodes. Thanks for reading, Hope you liked the blog post!!!! Will continue to post on hunting addtional Malwares, C2 Frameworks, uncovering addtional threat actor infra.

Happy Hunting!!!!!!

$ cd ../blog