Attacker infrastructure as a threat intelligence object
Without a communication channel between the implant and the control server, the attack freezes at the post-exploitation stage: the operator cannot give commands, unload data, navigate the network. MITRE ATT&CK will classify the preparation of such infrastructure as Resource Development - T1584.001 (Domains): The attacker purchases or compromises domains for use in the operation. For business, the final impact is a data leak, host encryption, simple. For an analyst, C2 infrastructure is not an abstract “control server”, but a graph of related resources that can be excavated.
[Applicable to: threat intelligence, foreign intelligence, SOC L3. Not applicable to internal pentest - it's pure TI-discipline.]
Each graph element - domains, IP addresses, TLS certificates, Whois records, ASN - contains metadata that the attacker does not always control. Passive DNS stores the historical binding of the domain to the IP, the Certificate Transparency logs every issued certificate, and Whois history sometimes shows the email registrant before it enabled privacy. The task of deanonymizing the C2 of the infrastructure is to collect these metadata and through a series of piers to restore the full picture of the operation.
Russian-language materials on C2-hunting describe server detection tools (Shodan, Censys, VirusTotal) and search patterns (HTTP headers, favicons, certificates). A good base, but it does not answer the question: who is behind the infrastructure and how to connect disparate servers into a single operation. It is this gap that closes the methodology of infrastructure piercing - from the detection of the dangling CNAME to the construction of the operator's graph.
Dangling CNAME and subdomain gainover: C2 reconnaissance point
Mexhanic dangling DNS and types of vulnerable entries
Dangling DNS - DNS record, which continues to point to a resource that no longer exists. The term “dangling” accurately describes the essence: there is a record, and behind it is emptiness.
According to OWASP Subdomain Ticket Prevention Cheat SheetThe most vulnerable four types of records are:
CNAME is the most common vector. If the canonical name indicates a service that can be re-registered (Heroku, GitHub Pages, AWS S3), the capture of the subdomain becomes trivial. A-records indicating the released IP addresses - in the elastic IP cloud environments are returned to the pool of the provider, and it can be received by another client. NS records that delegate a subdomain to a third-party DNS provider - if the account is closed to the provider, any new user can claim the rights to the delegated zone and control all records under this subdomain. MX records indicating deactivated mail services - according to OWASP, you can intercept mail and pass an email-based domain validation certificate from the Authority, having received a legitimate TLS certificate for a subdomain.
The root reason why dangling records accumulate is the gap between the life cycle of cloud resources and DNS management. The team that created the resource may not have access to the DNS. The command that controls the DNS may not know that the resource is removed. Shadow IT, forgotten PoC stands, DNS zones inherited during mergers of companies - all this generates hanging records that no one controls.
As AWS CIRT notes, services with globally unique namespaces are most susceptible to capture: Amazon S3 (buckets-names are globally unique, can declare any account), Elastic Beanstalk (similar). CloudFront is less vulnerable - DNS name d111111abcdef8.cloudfront.net AWS is assigned automatically. Since March 2026, S3-bakeries created with regional namespaces are tied to an account and are not subject to this problem (according to the AWS Security blog).
For automated detection of dangling records, there are open-source tools: dnsReaper (scanner with support for more than 40 service fingerprints), nuclei with a set of templates for subdomain takeover, community-project can-i-take-over-xyz - Handbook on Vulnerable and Invulnerable Services (according to OWASP data). Microsoft has published a PowerShell-script Get-DanglingDnsRecords.ps1 to check Azure resources.
Subdomain takeover C2: from capture to observation
For threat intelligence analytics, subdomain takeover is interesting in two scenarios, and both are directly related to the deanonymization of the C2 infrastructure.
Scenario 1: The attacker captures the victim’s subdomain to host C2. Direct application T1584.001 - the operator finds dangling CNAME on .target.com, declares the rights to the resource and receives a C2 server on a trusted domain. Traffic to such a subdomain does not cause suspicion in network filters because the parent domain is legitimate. According to OWASP, the attacker can intercept cookies copied to .example.com, circumvent the CSP rules with wildcard-trust to subdomains and even receive valid TLS certificates through automatic DNS-validation. According to Censys, HTTPS with padlock in the browser does not protect against subdomain gainover - an attacker can get a legitimate certificate through a platform that is indicated by the captured resource.
Scenario 2: Danzling CNAME in the infrastructure of the attacker. C2 operators also use CDN, cloud hosting and third-party services for masking. When the campaign is over, they deactivate resources, but they don’t always clean the DNS. These “tails” are visible in passive DNS and allow you to connect the domains that the operator considered unrelated.
In both cases, the vangle CNAME is not an vulnerability to operation, but an indicator for piercing. After finding such a record, the analyst receives a historical domain binding to IP via passive DNS, and this IP becomes the next point of piercing.
Passive DNS to deanonymize C2 infrastructure
Sources and tools of passive DNS intelligence
Passive DNS is a database that records historical DNS resolutions: which domain has indicated which IP, at what time period. In contrast to the active dig- Request, passive DNS shows what was the months and years ago - even after deleting or changing records.
The main sources for the analyst:
• SecurityTrails - keeps the history of A/AAAAA/MX/NS/CNAME records. Through the API or web interface, you can request all historical IPs for the domain and vice versa - all domains that have ever been pointed to a particular IP.
• DNSDB (Farsight Security) is one of the largest passive DNS bases. Supports reverse requests: to get all related domains for a given period.
• PassiveTotal (RiskIQ, now part of Microsoft) - brings together passive DNS with Whois data, certificates and trackers. Convenient for building connections between the elements of the infrastructure in a single interface.
For the initial collection of subdomains before checking on the vangle recordings are used subfinder and amass - they aggregate data from the Certificate Transparency of the Laws, DNS-discovery and passive DNS.
Practical workflow passive DNS
Typical chain in the C2 investigation:
1. Take a domain from an IOC fed or from the results of sample analysis - let's say, update-cdn.example[.]com.
2. Request a history in SecurityTrails: current digshow IP or NXDOMAIN, and SecurityTrails will show all the IPs that this domain has been pointed out in recent years.
3. We make a reverse request for each historical IP. If IP 185.X.X.XServer update-cdn.example[.]comfrom January to March - we ask: what other domains indicated this IP in the same period?
4. Filter results. Shared hosting gives hundreds of domains on one IP - this is noise. Dedicated servers (VPS) with 1-5 domains on IP signal. If the same IP was at the same time delivery-api.example2[.]comand report-portal.example3[.]com- these are candidates for belonging to the same operator.
5. Recursively repeat for each domain found. This is IP bewing - the extension of the graph through iterative requests.
Check the current status of CNAME and fix the dangling-recording can be standard dig:
Bash:
dig staging.target.com CNAME +short
# old-app.herokuapp.com
dig old-app.herokuapp.com A +short
# ;; status: NXDOMAIN
If CNAME is reclaimed to the NXDOMAIN on the provider’s side, and the record is still present in the DNS organization, it is a confirmed vangle CNAME, ready for further analysis via passive DNS.
IP-beuting and attribution of operator C2
Historical correlation through Whois and ASN
IP-beuting - the transition from IP address to other elements of the infrastructure through metadata. Whois records, even when using privacy services, leave artifacts: email renesset, organization, registration date, NS servers.
C2 operators regularly allow OPSEC errors, and this is the attribution:
• Register multiple domains through one account with a registrar with one email
• Use the same NS servers (characteristic for specific bulletproof-hostings)
• Place servers in one standalone system (ASN)
IP bewing methodology for attribution of operator C2:
1. Whois for each domain from passive DNS. If the email of the registrar is not privacy-protected - we do reverse Whois: look for all domains registered on this email. SecurityTrails and DomainTools support such requests.
2. Historical Whois. Registrants did not always include privacy protection from day one. SecurityTrails stores historical Whois images - it can be seen that the domain of the first months was registered on a specific email, and then privacy was included. This email is a strong axis for pirated.
3. ASN-clasterization. Determine AS for each IP in the graph. If four of the five servers are in an AS controlled by one bulletproof host, it’s a pattern. It does not prove attribution by itself, but confirms the connection between the nodes and narrows the circle.
[Applicable: threat intelligence, foreign intelligence. Limitation: The technique does not work when analyzing commodity-malvarium on shared hosting - too much noise on one IP. The dedicated infrastructure of the operator is required.]
Building a graph through Maltego and SpiderFoot
Maltego is the main tool for visualizing infrastructure links in deanonymizing C2 infrastructure. Workflow: Download the initial domain or IP as a root essence, apply Transforms (passive DNS lookup, Whois lookup, reverse DNS, lookup) and watch as the graph expands at every beer. The connections between entities are visible visually: domain → IP → other domains → certificate → SAN → Still domains.
SpiderFoot is an alternative to automated infrastructure intelligence. Unlike Maltego, it works in CLI/web mode and automatically runs dozens of modules (passive DNS, Shodan, Censys, Transferment) on one starting indicator. The results are less convenient for visual analysis, but cover more sources in one launch.
In practice, the optimal bundle: SpiderFoot for the initial wide collection, then Maltego for manual analysis of connections and the final attribution graph. SpiderFoot finds that the analyst could miss; Maltego allows you to trace each connection and cut off false coincidences.
Certificates and TLS-fingerprinting for OSINT C2 attribution
Certificate Transparency and SAN-bewenting
Certificate Transparency (CT) is a public log of all issued TLS certificates. Every time a C2 operator receives a certificate (even a free Let's Encrypt), the record is included in the CT blog and becomes available for search.
Why CT is critical for attribution:
Subject Alternative Names (SAN) One certificate can cover several domains. If the operator has issued a certificate for cdn-update[.]com with SAN, including report-api[.]net and static-files[.]org These three domains are related. Even if they are placed on different IPs and in different ASNs.
Temporary correlation. A series of certificates released from one Let’s Encrypt account within a short window (a few hours) often indicates an automated C2 infrastructure deployment.
Issuer fingerprint. Self-signed certificates or certificates from niche CA are an additional feature for clustering. Operators using non-standard values in issuer and subject fields leave a reproducible trace. It happens that the Subject CN explicitly indicates the name of the framework - according to C2-hunting studies, such blunders are more common than the attackers would like.
Search by CT-logs is available through crt.sh (free, query of the type crt.sh/?q=%.example.com), Censys (API) and SecurityTrails.
JARM and JA3S: fingerprinting C2-frameworks
In addition to the certificate attributes, the TLS connection itself leaves a unique imprint.
JA3/JA3S - passive fingerprinting method of client (JA3) and server (JA3S) part of the TLS-help. Collects settings from Client Hello and Server Hello packages, generates MD5-hash. C2-frameworks (Cobalt Strike, Mythic, Havoc) generate characteristic JA3S hashes, by which they can be identified in the scan results and in network traffic.
JARM - active fingerprint TLS-server. Sends ten specially formed TLS Client Hello with different parameters and hass answers. The JARM fingerprint is stable for a specific server configuration. If five servers on different IPs give the same JARM hash, it is a high probability of one framework with one configuration deployed by one operator.
An example of a search in Shodan by the characteristic Mythic C2 HTTP headers:
Code:
port:80 "Cache-Control: max-age=0, no-cache" "Server: NetDNA-cache/2.2"
"Content-Type: application/javascript" ASN:AS14061
This query searches for servers with a set of headers characteristic of the default configuration of the Mythic C2 profile. IP-stakes found are candidates for further pirated through passive DNS and Whois. Cobalt Strike is characterized by another marker: default HTTP-responsible 404 Not Found c Content-Type: text/plain and Content-Length: 0 without custom profile malleable C2. (Yes, in 2025, people still unfold the CS with a default profile. I am amazed every time.)
Limitation: JARM and Shodan queries are active scanning. They only work with live servers. If C2 is already deactivated, it remains to rely on passive DNS and CT logs.
Practical chain of deanonymization: from IOC to operator
Adjustments to the environment:
• OS: Linux (Kali, Ubuntu 22.04+) or macOS
• RAM: at least 8 GB (Maltego CE consumes 2-4 GB when working with large graphs)
• Network: online (requires access to API SecurityTrails, Shodan, Censys, crt.sh)
• API keys: SecurityTrails (free tier - 50 queries/months), Shodan (free tier), Censys (free tier for Search)
• Tools: dig, curl, jq, subfinder(ProjectDiscovery), Maltego CE (free)
• Additionally: JARM scanner (GitHub:force sales/jam) for active fingerprinting and live servers
Step 1. We get a starting indicator: a domain from sample analysis or TI-Fida. Let's do this update-service.example[.]com.
Step 2. Check the current state of DNS through dig update-service.example[.]com A and dig update-service.example[.]com CNAME. If CNAME points to a non-existent resource - fixed by dangling CNAME. If the A-record returns the IP, we write.
Step 3. We ask for a passive DNS story in SecurityTrails. See all historical IPs for this domain. Each IP is a potential pitting point.
Step 4. Reverse DNS for every historical IP. Through SecurityTrails or DNSDB, we get a list of all domains that have ever pointed to each IP. Filter: VPS with 1-5 domains on IP priority. Shared hosting (100+ domains) - discard.
Step 5. Whois and Reverse Whois for each new domain from step 4. Historic Whois is mandatory: even if it is now privacy, before email could be open. The coincidence of the email of the registrant for several domains is a strong attribution signal.
Step 6. Certificate Transparency: We request crt.sh/?q=%.example[.]com for each linked domain. Analyze SAN - alternative names in certificates disclose additional domains of the operator.
Step 7. TLS-fingerprinting (for live servers only): check JARM hash through the utility jarm or through the Shodan, where JARM is indexed automatically. The JARM match in several IP confirms a single configuration.
Step 8. Visualization in Maltego. We import all collected entities (domains, IP, email renessers, certificates) and lay communications. The graph clearly shows clusters and nodes-hubs - points of intersection of the maximum number of connections.
Result: from one starting domain - an infrastructure graph with dozens of components, united by IP-intersections, common Whois data, SAN-certificates and TLS prints.
Restrictions of deanonymization techniques C2
None of the described techniques work at all. Understanding the boundaries of applicability is as valuable as mastering the techniques themselves.
Shared hosting and CDN. If the C2 domain is behind Cloudflare or Akamai, the reverse passive DNS request for IP will return thousands of domains. IP-beyoting here is useless - you need to switch to other axes: certificates, Whois, JARM.
Operators with high-quality OPSEC. Advanced groups use different registrars, different emails, different AS for each domain. Whois-correlation will not work. Behavioral indicators remain: domain name patterns (DGA-style vs human-readable), characteristic TTL values, temporary registration windows. It is closer to art than to the algorithm.
Ephemeral infrastructure. Servers that live watches. Passive DNS may not have time to index the record. DNSDB and SecurityTrails are updated with a delay of minutes to hours - if the C2 was deployed and rolled in four hours, the records may not be at all.
Domain fronting and redirectors. The operator uses the legitimate CDN domain (Azure, Cloudflare Workers) as a front for C2 traffic. The real backend server is not visible through the DNS at all. Deanonymizing the C2 of infrastructure in this case requires network traffic analysis (NetFlow, TLS inspection), and not DNS-exploration.
Without a communication channel between the implant and the control server, the attack freezes at the post-exploitation stage: the operator cannot give commands, unload data, navigate the network. MITRE ATT&CK will classify the preparation of such infrastructure as Resource Development - T1584.001 (Domains): The attacker purchases or compromises domains for use in the operation. For business, the final impact is a data leak, host encryption, simple. For an analyst, C2 infrastructure is not an abstract “control server”, but a graph of related resources that can be excavated.
[Applicable to: threat intelligence, foreign intelligence, SOC L3. Not applicable to internal pentest - it's pure TI-discipline.]
Each graph element - domains, IP addresses, TLS certificates, Whois records, ASN - contains metadata that the attacker does not always control. Passive DNS stores the historical binding of the domain to the IP, the Certificate Transparency logs every issued certificate, and Whois history sometimes shows the email registrant before it enabled privacy. The task of deanonymizing the C2 of the infrastructure is to collect these metadata and through a series of piers to restore the full picture of the operation.
Russian-language materials on C2-hunting describe server detection tools (Shodan, Censys, VirusTotal) and search patterns (HTTP headers, favicons, certificates). A good base, but it does not answer the question: who is behind the infrastructure and how to connect disparate servers into a single operation. It is this gap that closes the methodology of infrastructure piercing - from the detection of the dangling CNAME to the construction of the operator's graph.
Dangling CNAME and subdomain gainover: C2 reconnaissance point
Mexhanic dangling DNS and types of vulnerable entries
Dangling DNS - DNS record, which continues to point to a resource that no longer exists. The term “dangling” accurately describes the essence: there is a record, and behind it is emptiness.
According to OWASP Subdomain Ticket Prevention Cheat SheetThe most vulnerable four types of records are:
CNAME is the most common vector. If the canonical name indicates a service that can be re-registered (Heroku, GitHub Pages, AWS S3), the capture of the subdomain becomes trivial. A-records indicating the released IP addresses - in the elastic IP cloud environments are returned to the pool of the provider, and it can be received by another client. NS records that delegate a subdomain to a third-party DNS provider - if the account is closed to the provider, any new user can claim the rights to the delegated zone and control all records under this subdomain. MX records indicating deactivated mail services - according to OWASP, you can intercept mail and pass an email-based domain validation certificate from the Authority, having received a legitimate TLS certificate for a subdomain.
The root reason why dangling records accumulate is the gap between the life cycle of cloud resources and DNS management. The team that created the resource may not have access to the DNS. The command that controls the DNS may not know that the resource is removed. Shadow IT, forgotten PoC stands, DNS zones inherited during mergers of companies - all this generates hanging records that no one controls.
As AWS CIRT notes, services with globally unique namespaces are most susceptible to capture: Amazon S3 (buckets-names are globally unique, can declare any account), Elastic Beanstalk (similar). CloudFront is less vulnerable - DNS name d111111abcdef8.cloudfront.net AWS is assigned automatically. Since March 2026, S3-bakeries created with regional namespaces are tied to an account and are not subject to this problem (according to the AWS Security blog).
For automated detection of dangling records, there are open-source tools: dnsReaper (scanner with support for more than 40 service fingerprints), nuclei with a set of templates for subdomain takeover, community-project can-i-take-over-xyz - Handbook on Vulnerable and Invulnerable Services (according to OWASP data). Microsoft has published a PowerShell-script Get-DanglingDnsRecords.ps1 to check Azure resources.
Subdomain takeover C2: from capture to observation
For threat intelligence analytics, subdomain takeover is interesting in two scenarios, and both are directly related to the deanonymization of the C2 infrastructure.
Scenario 1: The attacker captures the victim’s subdomain to host C2. Direct application T1584.001 - the operator finds dangling CNAME on .target.com, declares the rights to the resource and receives a C2 server on a trusted domain. Traffic to such a subdomain does not cause suspicion in network filters because the parent domain is legitimate. According to OWASP, the attacker can intercept cookies copied to .example.com, circumvent the CSP rules with wildcard-trust to subdomains and even receive valid TLS certificates through automatic DNS-validation. According to Censys, HTTPS with padlock in the browser does not protect against subdomain gainover - an attacker can get a legitimate certificate through a platform that is indicated by the captured resource.
Scenario 2: Danzling CNAME in the infrastructure of the attacker. C2 operators also use CDN, cloud hosting and third-party services for masking. When the campaign is over, they deactivate resources, but they don’t always clean the DNS. These “tails” are visible in passive DNS and allow you to connect the domains that the operator considered unrelated.
In both cases, the vangle CNAME is not an vulnerability to operation, but an indicator for piercing. After finding such a record, the analyst receives a historical domain binding to IP via passive DNS, and this IP becomes the next point of piercing.
Passive DNS to deanonymize C2 infrastructure
Sources and tools of passive DNS intelligence
Passive DNS is a database that records historical DNS resolutions: which domain has indicated which IP, at what time period. In contrast to the active dig- Request, passive DNS shows what was the months and years ago - even after deleting or changing records.
The main sources for the analyst:
• SecurityTrails - keeps the history of A/AAAAA/MX/NS/CNAME records. Through the API or web interface, you can request all historical IPs for the domain and vice versa - all domains that have ever been pointed to a particular IP.
• DNSDB (Farsight Security) is one of the largest passive DNS bases. Supports reverse requests: to get all related domains for a given period.
• PassiveTotal (RiskIQ, now part of Microsoft) - brings together passive DNS with Whois data, certificates and trackers. Convenient for building connections between the elements of the infrastructure in a single interface.
For the initial collection of subdomains before checking on the vangle recordings are used subfinder and amass - they aggregate data from the Certificate Transparency of the Laws, DNS-discovery and passive DNS.
Practical workflow passive DNS
Typical chain in the C2 investigation:
1. Take a domain from an IOC fed or from the results of sample analysis - let's say, update-cdn.example[.]com.
2. Request a history in SecurityTrails: current digshow IP or NXDOMAIN, and SecurityTrails will show all the IPs that this domain has been pointed out in recent years.
3. We make a reverse request for each historical IP. If IP 185.X.X.XServer update-cdn.example[.]comfrom January to March - we ask: what other domains indicated this IP in the same period?
4. Filter results. Shared hosting gives hundreds of domains on one IP - this is noise. Dedicated servers (VPS) with 1-5 domains on IP signal. If the same IP was at the same time delivery-api.example2[.]comand report-portal.example3[.]com- these are candidates for belonging to the same operator.
5. Recursively repeat for each domain found. This is IP bewing - the extension of the graph through iterative requests.
Check the current status of CNAME and fix the dangling-recording can be standard dig:
Bash:
dig staging.target.com CNAME +short
# old-app.herokuapp.com
dig old-app.herokuapp.com A +short
# ;; status: NXDOMAIN
If CNAME is reclaimed to the NXDOMAIN on the provider’s side, and the record is still present in the DNS organization, it is a confirmed vangle CNAME, ready for further analysis via passive DNS.
IP-beuting and attribution of operator C2
Historical correlation through Whois and ASN
IP-beuting - the transition from IP address to other elements of the infrastructure through metadata. Whois records, even when using privacy services, leave artifacts: email renesset, organization, registration date, NS servers.
C2 operators regularly allow OPSEC errors, and this is the attribution:
• Register multiple domains through one account with a registrar with one email
• Use the same NS servers (characteristic for specific bulletproof-hostings)
• Place servers in one standalone system (ASN)
IP bewing methodology for attribution of operator C2:
1. Whois for each domain from passive DNS. If the email of the registrar is not privacy-protected - we do reverse Whois: look for all domains registered on this email. SecurityTrails and DomainTools support such requests.
2. Historical Whois. Registrants did not always include privacy protection from day one. SecurityTrails stores historical Whois images - it can be seen that the domain of the first months was registered on a specific email, and then privacy was included. This email is a strong axis for pirated.
3. ASN-clasterization. Determine AS for each IP in the graph. If four of the five servers are in an AS controlled by one bulletproof host, it’s a pattern. It does not prove attribution by itself, but confirms the connection between the nodes and narrows the circle.
[Applicable: threat intelligence, foreign intelligence. Limitation: The technique does not work when analyzing commodity-malvarium on shared hosting - too much noise on one IP. The dedicated infrastructure of the operator is required.]
Building a graph through Maltego and SpiderFoot
Maltego is the main tool for visualizing infrastructure links in deanonymizing C2 infrastructure. Workflow: Download the initial domain or IP as a root essence, apply Transforms (passive DNS lookup, Whois lookup, reverse DNS, lookup) and watch as the graph expands at every beer. The connections between entities are visible visually: domain → IP → other domains → certificate → SAN → Still domains.
SpiderFoot is an alternative to automated infrastructure intelligence. Unlike Maltego, it works in CLI/web mode and automatically runs dozens of modules (passive DNS, Shodan, Censys, Transferment) on one starting indicator. The results are less convenient for visual analysis, but cover more sources in one launch.
In practice, the optimal bundle: SpiderFoot for the initial wide collection, then Maltego for manual analysis of connections and the final attribution graph. SpiderFoot finds that the analyst could miss; Maltego allows you to trace each connection and cut off false coincidences.
Certificates and TLS-fingerprinting for OSINT C2 attribution
Certificate Transparency and SAN-bewenting
Certificate Transparency (CT) is a public log of all issued TLS certificates. Every time a C2 operator receives a certificate (even a free Let's Encrypt), the record is included in the CT blog and becomes available for search.
Why CT is critical for attribution:
Subject Alternative Names (SAN) One certificate can cover several domains. If the operator has issued a certificate for cdn-update[.]com with SAN, including report-api[.]net and static-files[.]org These three domains are related. Even if they are placed on different IPs and in different ASNs.
Temporary correlation. A series of certificates released from one Let’s Encrypt account within a short window (a few hours) often indicates an automated C2 infrastructure deployment.
Issuer fingerprint. Self-signed certificates or certificates from niche CA are an additional feature for clustering. Operators using non-standard values in issuer and subject fields leave a reproducible trace. It happens that the Subject CN explicitly indicates the name of the framework - according to C2-hunting studies, such blunders are more common than the attackers would like.
Search by CT-logs is available through crt.sh (free, query of the type crt.sh/?q=%.example.com), Censys (API) and SecurityTrails.
JARM and JA3S: fingerprinting C2-frameworks
In addition to the certificate attributes, the TLS connection itself leaves a unique imprint.
JA3/JA3S - passive fingerprinting method of client (JA3) and server (JA3S) part of the TLS-help. Collects settings from Client Hello and Server Hello packages, generates MD5-hash. C2-frameworks (Cobalt Strike, Mythic, Havoc) generate characteristic JA3S hashes, by which they can be identified in the scan results and in network traffic.
JARM - active fingerprint TLS-server. Sends ten specially formed TLS Client Hello with different parameters and hass answers. The JARM fingerprint is stable for a specific server configuration. If five servers on different IPs give the same JARM hash, it is a high probability of one framework with one configuration deployed by one operator.
An example of a search in Shodan by the characteristic Mythic C2 HTTP headers:
Code:
port:80 "Cache-Control: max-age=0, no-cache" "Server: NetDNA-cache/2.2"
"Content-Type: application/javascript" ASN:AS14061
This query searches for servers with a set of headers characteristic of the default configuration of the Mythic C2 profile. IP-stakes found are candidates for further pirated through passive DNS and Whois. Cobalt Strike is characterized by another marker: default HTTP-responsible 404 Not Found c Content-Type: text/plain and Content-Length: 0 without custom profile malleable C2. (Yes, in 2025, people still unfold the CS with a default profile. I am amazed every time.)
Limitation: JARM and Shodan queries are active scanning. They only work with live servers. If C2 is already deactivated, it remains to rely on passive DNS and CT logs.
Practical chain of deanonymization: from IOC to operator
Adjustments to the environment:
• OS: Linux (Kali, Ubuntu 22.04+) or macOS
• RAM: at least 8 GB (Maltego CE consumes 2-4 GB when working with large graphs)
• Network: online (requires access to API SecurityTrails, Shodan, Censys, crt.sh)
• API keys: SecurityTrails (free tier - 50 queries/months), Shodan (free tier), Censys (free tier for Search)
• Tools: dig, curl, jq, subfinder(ProjectDiscovery), Maltego CE (free)
• Additionally: JARM scanner (GitHub:force sales/jam) for active fingerprinting and live servers
Step 1. We get a starting indicator: a domain from sample analysis or TI-Fida. Let's do this update-service.example[.]com.
Step 2. Check the current state of DNS through dig update-service.example[.]com A and dig update-service.example[.]com CNAME. If CNAME points to a non-existent resource - fixed by dangling CNAME. If the A-record returns the IP, we write.
Step 3. We ask for a passive DNS story in SecurityTrails. See all historical IPs for this domain. Each IP is a potential pitting point.
Step 4. Reverse DNS for every historical IP. Through SecurityTrails or DNSDB, we get a list of all domains that have ever pointed to each IP. Filter: VPS with 1-5 domains on IP priority. Shared hosting (100+ domains) - discard.
Step 5. Whois and Reverse Whois for each new domain from step 4. Historic Whois is mandatory: even if it is now privacy, before email could be open. The coincidence of the email of the registrant for several domains is a strong attribution signal.
Step 6. Certificate Transparency: We request crt.sh/?q=%.example[.]com for each linked domain. Analyze SAN - alternative names in certificates disclose additional domains of the operator.
Step 7. TLS-fingerprinting (for live servers only): check JARM hash through the utility jarm or through the Shodan, where JARM is indexed automatically. The JARM match in several IP confirms a single configuration.
Step 8. Visualization in Maltego. We import all collected entities (domains, IP, email renessers, certificates) and lay communications. The graph clearly shows clusters and nodes-hubs - points of intersection of the maximum number of connections.
Result: from one starting domain - an infrastructure graph with dozens of components, united by IP-intersections, common Whois data, SAN-certificates and TLS prints.
Restrictions of deanonymization techniques C2
None of the described techniques work at all. Understanding the boundaries of applicability is as valuable as mastering the techniques themselves.
Shared hosting and CDN. If the C2 domain is behind Cloudflare or Akamai, the reverse passive DNS request for IP will return thousands of domains. IP-beyoting here is useless - you need to switch to other axes: certificates, Whois, JARM.
Operators with high-quality OPSEC. Advanced groups use different registrars, different emails, different AS for each domain. Whois-correlation will not work. Behavioral indicators remain: domain name patterns (DGA-style vs human-readable), characteristic TTL values, temporary registration windows. It is closer to art than to the algorithm.
Ephemeral infrastructure. Servers that live watches. Passive DNS may not have time to index the record. DNSDB and SecurityTrails are updated with a delay of minutes to hours - if the C2 was deployed and rolled in four hours, the records may not be at all.
Domain fronting and redirectors. The operator uses the legitimate CDN domain (Azure, Cloudflare Workers) as a front for C2 traffic. The real backend server is not visible through the DNS at all. Deanonymizing the C2 of infrastructure in this case requires network traffic analysis (NetFlow, TLS inspection), and not DNS-exploration.
