Skip to content

IP Address

Overview

  • Definition

    An Internet Protocol address is a numerical label assigned to a device connected to a computer network, which can function as either a client, a server, or both.

  • Usecase

    Threat actors purchase or hijack IP addresses and assign them to clients or servers, which they deploy to host various parts of their infrastructure, such as phishing websites, crawlers, malware storage, C&C, exfiltrated data storage, and proxies for routing malicious traffic. Similarly, infected clients also have IP addresses.

  • Example

    134.209.127[.]249 was in use by an unknown threat actor for the triple purpose of hosting servers for running commands against cloud environments, sending phishing SMS messages to targets, and hosting phishing websites.1

  • Pivot Map
    flowchart LR
        classDef primary stroke-width: 2px
        classDef secondary stroke-dasharray: 5 5
    
        %% define nodes
        IP_ADDRESS(IP Address):::primary
        IP_ADDRESS_(IP Address):::secondary
        DOMAIN(Domain)
        SERVER([Server / Client])
        SERVER_([Server]):::secondary
        SAMPLE(Sample)
        USER_AGENT(User Agent)
        TLS_CERT(TLS Certificate)
    
        %% define edges
        SERVER -- identifies as ---> USER_AGENT
        IP_ADDRESS <-- ASN --> IP_ADDRESS_
        IP_ADDRESS <-- traffic --> IP_ADDRESS_
        IP_ADDRESS <-- WHOIS details ---> IP_ADDRESS_
        IP_ADDRESS <-- WHOIS history ---> IP_ADDRESS_
        IP_ADDRESS <-- ports --> IP_ADDRESS_
        IP_ADDRESS -. hosts ..-> SERVER
        TLS_CERT -- served by ---> SERVER
        SERVER <-- fingerprint ---> SERVER_
        SERVER <-- banner ---> SERVER_
        SERVER <-- favicon ---> SERVER_
        SERVER <-- content ---> SERVER_
        SERVER <-- URL path ---> SERVER_
        SERVER -- stores ---> SAMPLE
        SAMPLE -- connects --> SERVER
        SAMPLE -- references --> IP_ADDRESS
        DOMAIN -- forward DNS --> IP_ADDRESS
        DOMAIN <-- DNS history --> IP_ADDRESS
        IP_ADDRESS -- reverse DNS ---> DOMAIN
    
        %% define links
        click IP_ADDRESS_ "#ip-addresses"
        click DOMAIN "#domains"
        click SERVER "#servers"
        click SAMPLE "#samples"
        click USER_AGENT "#user-agents"
        click TLS_CERT "#tls-certificates"
    

Static vs. dynamic addresses

IP addresses can be either static or dynamic, with the first type remaining under the control of the same user for prolonged periods of time, and the second type often changing hands. Therefore, dynamic IP addresses are much less useful for pivoting than their static counterparts, since any pivots could lead to entirely unrelated activity, depending on the timeframe of our query.

Clients vs. servers

IP addresses can be assigned by threat actors to either clients or servers, which affects how they appear in logs and therefore how one should pivot on them. For example, clients can be observed scanning victims' networks or connecting to compromised target machines, whereas servers are applications that recieve connections from compromised devices or attacker-controlled clients.

In some cases, the same IP address can operate as both as server and a client. For example, threat actors may use the same IP address for both crawling and C&C. Similarly, threat actors may establish networks of ORBs composed of compromised devices - these would function as proxies, connecting both to and from other devices.

Pivots

Domains

Domains resolving to it

An IP address might be resolved by one or more domains or subdomains operated by the same threat actor. In some cases, an IP address might be used for multiple purposes at once (e.g., malware C2, serving phishing pages, proxying traffic, etc.), with every server fronted by a different domain or subdomain.

Since most normal network traffic initiates in DNS queries and uses host headers for communicating between clients and servers, actors often configure their malware to communicate with domains rather than directly connecting to an IP address. This affords their activity a measure of stealth, with the added benefit of greater operational flexibility.

While querying a domain for its resolving IP address is called forward DNS (fDNS for short), the opposite query is known as reverse DNS (or rDNS).

Try it out
https://dnschecker.org/reverse-dns.php?query={IP_ADDRESS}
$ curl -s -H 'Authorization: Bearer {API_TOKEN}' \
'https://api.driftnet.io/v1/domain/rdns?ip={IP_ADDRESS}' \
| jq . \
| less -S

Domains that previously resolved to it

Pivoting to past DNS records is especially useful when investigating a long-term campaign or cases in which a threat actor has already shut down their operations.

Historic DNS resolutions can be based on either passive DNS collection (pDNS), which involves continuously recording DNS queries from various sources and aggregating their results into a queryable database, or active forward DNS collection (fDNS), which involves regularly querying for known domains and storing their resolutions.

Try it out
https://app.validin.com/detail?type=ip&find={IP_ADDRESS}#tab=resolutions

IP Addresses

Addresses in same ASN

Some Autonomous System Numbers (ASN) are known to be operated by malicious actors2, and in some cases an address's ASN may contain additional addresses in use by the same actor.

Given an ASN, analysts can use DNS tools such as MXToolBox to identify the IP ranges associated with it.

Addresses with similar registration details

When actors purchase an IP address, they must supply registrant information, which is made publicly available through the WHOIS protocol. Unlike domain registration, leasing an IP address does not allow for registrant privacy; the registrant must supply their personal or business details. While stealthy actors will often provide fake registration details, these can sometimes still be useful for pivoting if they are rare enough and the actor uses the same details more than once. Note that if a threat actor leases a (static or dynamic) IP address from a cloud provider, a WHOIS query will only return information about the provider.

  • Features

    Some of the registrant details of 140.82.112.3, which resolves github.com as of 17/06/24:

    OrgName:        GitHub, Inc.
    OrgId:          GITHU
    Address:        88 Colin P Kelly Jr Street
    City:           San Francisco
    StateProv:      CA
    PostalCode:     94107
    Country:        US
    RegDate:        2012-10-22
    Updated:        2021-05-20
    OrgNOCHandle:   GITHU-ARIN
    OrgNOCPhone:    +1-415-735-4488
    OrgNOCEmail:    hostmaster@github.com
    OrgNOCRef:      https://rdap.arin.net/registry/entity/GITHU-ARIN
    

Addresses with historically similar registrant details

As mentioned above, threat actors may lease different IP addresses at different times but reuse certain registration details (which might be real or fake). By reviewing WHOIS history platforms, analysts can reveal past similarities which may no longer exist in the current record.

Addresses with same open ports

If an IP address hosting a C&C server has a relatively unique set of open ports (e.g., 80, 443, 5432, and 6379), analysts can leverage this to query host scanning services such as Shodan and Censys for other IP addresses with the exact same set of open ports, some of which might be hosting servers operated by the same threat actor or running the same malicious applications.

Example

Cobalt Strike team server is configured to listen on port 50050 by default, and threat actors don't always bother to change the default configuration prior to deployment.4


Clients

Clients connecting to it

If you have access to traffic aggregation data, you can check for other IP addresses that may have been observed in communication with this IP address. This can reveal victim devices communicating with malicious infrastructure, or other components of a threat actor's operation (such as proxy servers).

Example

Proofpoint and Team Cymru analyzed Netflow data to surface a common server observed in communication with multiple C2 servers used by Latrodectus malware operators.3

Clients connecting from it

Besides their use for hosting traditional servers, threat actors can also use IP addresses to connect as clients to victim infrastructure. Threat actors can do so using IP addresses they own or via proxy or VPN servers. Client behavior (whether automated or "hands-on-keyboard") can be observed during brute-force attacks, password spray attacks, as well as remote connection sessions such as logging into a target database.

Clients with same fingerprint

Infected or attacker-controlled clients running the same tools often have overlapping techstacks (meaning that they run the same set of software components). Moreover, these clients might be configured in the exact same way. This can result in a subset of such clients that can be uniquely identified by their fingerprint (or a set of fingerprint types), such as one of the JA4+ fingerprints.


User Agents

User agents identifying it

Various components of malicious activity involve clients identifying as certain user agents. In some cases, client behavior can be pivoted upon between different IP addresses based on shared user agents. However, this is usually considered a relatively weak correlation, since the same user agent could have legitimate uses as well, unless it's unique.

Given the IP address of a device infected with malware, or a machine running an attacker-side tool (such as a toolkit, crawler or scanner), analysts can review network activity logs to determine which user agents identify the IP address.

Example

Permiso identified a threat actor using S3 Browser and identifying as the user agent S3 Browser 9.5.5 <https://s3browser.com>. While this tool and user agent can be used legitimately, in this case it was never used by employees in the target environment, and was therefore unique to this actor's activity in that specific context.5


Servers

Servers hosted by it

An IP address can host one or more servers on various ports. Scanning different ports can reveal new information about how a threat actor is using a given IP address.

Host scanning services such as Shodan and Censys regularly scan the entire IPv4 space and report their findings in queryable databases.

Try it out
https://www.shodan.io/host/{IP_ADDRESS}
$ curl -X GET "https://api.shodan.io/shodan/host/{IP_ADDRESS}?key={YOUR_API_KEY}"

Servers with same fingerprint

Attacker-controlled servers operated by the same threat actor or that are part of the same campaign often have overlapping techstacks (meaning that they run the same set of software components). Moreover, these servers might be configured in the exact same way. This can result in a subset of malicious servers that can be uniquely identified by their fingerprint (or a set of fingerprint types), such as JARM, HHHash, or one of the JA4+ fingerprints.

Servers with same banner or headers

Depending on the protocols in use, servers normally respond to clients with a specific canned response. HTTP/S servers return response headers, whereas non-HTTP servers return banners. Analysts can leverage this to perform a type of scan called banner grabbing to identify what applications are running on the server.

Given an IP address, analysts can query host scanning platforms such as Censys to see the results of past scans of any servers it hosts.

Example

Until January 2019, Cobalt Strike team servers contained an “extraneous space” in their default HTTP response headers (after the word OK in HTTP/1.1 200 OK). At the time, this mistake could be leveraged for unique identification of such servers.6

Servers with same favicon

Favicons are icons displayed in browser windows or tabs when viewing a given webpage, and they are usually associated with a specific company or software component. When threat actors reuse software between different servers, this sometimes leads to these servers also sharing the same favicon, which can be leveraged for pivoting by querying host scanning services such as Shodan (see this blogpost from Shodan for more information).

Servers with similar content

When threat actors set up landing pages for a phishing campaign, they may reuse certain assets across multiple sites. Similarly, threat actors might inject the same malicious JavaScript or JavaScript tags into hijacked websites. This can be leveraged by analysts to pivot from one landing page or compromised website to others through host scanning platforms such as Censys or URL scanning platforms such as URLScan, by searching for these particular elements.

In other cases, phishing websites operated by the same threat actor may only share their general visual appearance, which can occasionally be leveraged for pivoting as well, albeit as a much weaker signal, and only if content-based scanning fails to surface actual code overlap.

Example

Sucuri tracked a website hijacking campaign in which the threat actor compromised the hosting server and then injected malicious code into JavaScript files. This code consistently began with a unique string (/*trackmyposs*/eval). By querying PublicWWW for the indicative string, Sucuri were able to effectively identify many such compromised websites.7

Servers with same URL path

Threat actors may set up various API endpoints on their servers to facilitate the required functionality for their malicious infrastructure. Each of these endpoints may be available on a different URL path (e.g., malware may connect to an /upload/ endpoint to exfiltrate data). Similarly, threat actors may hijack legitimate servers and deploy a file containing malicious code, which may be located on a consistent URL path across multiple compromised servers.

Therefore, given a server with an indicative URL path, analysts can run a wide scan to identify related servers with the same URL path that may be available on other IP addresses. Alternatively, analysts can query the databases of URL scanning services such as URLScan for a given URL path in order to surface domains resolving to potentially related servers.

Try it out
https://urlscan.io/search/#page.url%3A%22{PATH}%22

TLS Certificates

Certificates served by it

Threat actors use TLS certificates to enable encrypted TLS communication between attacker-controlled servers, as well as between infected clients and attacker-controlled servers (such as for encrypting communication between malware and its C&C server). If a threat actor deploys multiple servers as part of the same campaign, they might use the same certificate across a subset of their fleet, or use several certificates with partially overlapping details.

Example

The default configuration of Cobalt Strike servers is to use a specific self-signed TLS certificate (SHA-1 6ECE5ECE4192683D2D84E25B0BA7E04F9CB7EB7C). Some threat actors make the mistake of using this default certificate, which can be leveraged for identification.8


Samples

Samples that reference it in their code

By statically scanning a malware sample or reverse engineering it, analysts can identify server IP addresses that may be included in its source code, depending on how well the sample is obfuscated.

Given an IP address, analysts can use "malware zoo" platforms such as VirusTotal to query for any such previously encountered samples.

Samples that communicate with it at runtime

By executing a malware sample in a sandboxed environment, or by observing the behavior of malware that has infected a honeypot, one can determine if the infected machine communicates with any IP addresses of C&C or data exfiltration servers.

Given an IP address, analysts can use "malware zoo" platforms such as VirusTotal to query for any such previously encountered samples.

Samples it stores

Attacker-controlled servers hosted on an IP address may store malware for victim devices to download. Gaining access to such servers may therefore afford access to samples of aforementioned malware. Similarly, samples may be retrieved from infected clients by performing forensics, or through security product telemetry.