{
	"id": "6ac27925-5a73-4e61-8962-f7890178b9a4",
	"created_at": "2026-04-06T00:09:58.645294Z",
	"updated_at": "2026-04-10T03:20:02.686345Z",
	"deleted_at": null,
	"sha1_hash": "4f46521324b534fc3dafb1fcbc6e9c7d7da076ef",
	"title": "A Beginner's Guide to Tracking Malware Infrastructure - Censys",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 4236727,
	"plain_text": "A Beginner's Guide to Tracking Malware Infrastructure - Censys\r\nBy Ivonne Francia\r\nPublished: 2024-02-09 · Archived: 2026-04-05 14:59:24 UTC\r\nBuilding queries for malware infrastructure can be a valuable step in the security lifecycle. Sadly, there are few\r\nresources for how to get started and which indicators can be used to build queries from. Today we aim to fill this\r\ngap by demonstrating approachable and high value methods that can be used to hunt for malware infrastructure.\r\nWhat Is Query Building For Malware Infrastructure?\r\nQuery building is the process of observing suspicious or known malicious infrastructure and creating queries to\r\nidentify the configuration pattern that the creator of the infrastructure has used. Since threat actors often re-use the\r\nsame or similar configuration across multiple deployed servers, there is often a pattern that can be used to identify\r\nmultiple servers from a single initial indicator.\r\nA well built query allows an analyst to identify additional servers related to the actor’s infrastructure. The analyst\r\ncan then proactively block, investigate or perform any additional actions needed to limit compromise and gather\r\nintelligence.\r\nWhy Build Queries On Malware Infrastructure?\r\nBuilding queries on Malware Infrastructure  can be a highly efficient means of obtaining IOC’s for blocking and\r\nhunting.\r\nTraditional means of listing malware infrastructure involves obtaining a large set of unique malware samples and\r\nextracting individual IOC’s from each file.\r\nThis can be a highly tedious and technical process requiring a dedicated reverse engineer to deconstruct a sample,\r\ndevelop and test a Yara hunting rule, acquire new samples, and then develop and apply a configuration extractor to\r\nobtain individual IOCs.\r\nThis reverse engineering capability  involves a significant amount of technical know-how which most teams\r\noutsource to threat intelligence feeds. Outsourcing to threat intelligence feeds can be effective and there are good\r\npaid feeds available, but they are often expensive and can vary significantly in quality and timeliness.\r\nBenefits of Building Infrastructure Queries\r\nBy developing your own infrastructure queries for the purposes of hunting, you can establish a far greater list of\r\nmalware IOCs with a significantly smaller set of malware samples, technical expertise, and overall cost. You can\r\nalso leverage queries to expand on alerting from your own environment, allowing you to establish a list of IOCs\r\nrelated to known malware impacting your organisation.\r\nhttps://censys.com/a-beginners-guide-to-tracking-malware-infrastructure/\r\nPage 1 of 23\n\nUsing the techniques shown in this post, you can potentially identify dozens of current malware IOCs and\r\ninfrastructure with only a single available sample or alert.\r\nWhat Are The Indicators That We Can Use?\r\nA single malicious IP address contains a great deal of information that can be used to identify additional servers.\r\nThis is due to unique patterns related to the software and configuration deployed by an actor.\r\nSince threat actors often re-use the same software and configurations across multiple instances of malicious\r\ninfrastructure, a single pattern can be used to identify other servers.\r\nSome of the most common indicators that threat actors will re-use are:\r\nCertificate Information – Fields inside of TLS and SSL certificates. Hardcoded values are often re-used.\r\nServer Headers – Actors deploying custom software may forget to change default headers that contain\r\nindicators.\r\nData in HTTP Responses – Custom software containing unique values in HTTP responses\r\nLocation, ASN and Hosting Providers – Actors re-using hosting providers for infrastructure. Similar\r\nservers may be hosted at the same ASN.\r\nJA3 Hashes – Actors deploying uncommon software configurations can be fingerprinted by JA3\r\nsignatures.\r\nPort Configurations – Actors will often leave the same ports open across infrastructure.\r\nRegular Expressions – Actors may deploy unique values with highly similar structure that can be captured\r\nwith Regular Expressions.\r\nNow that we’ve covered the key concepts, let’s dive in with some examples.\r\nHunting Infrastructure with TLS Certificates\r\nThreat actors and malware developers utilise TLS certificates to encrypt communications and establish\r\nconnections between a target host and malicious infrastructure.\r\nFor many reasons, actors rarely deploy unique certificates for each deployed sample. This results in values within\r\na single TLS certificate being present on numerous other servers, which introduces simple patterns that can be\r\nsignatured and queried.\r\nExample 1: Hunting AsyncRAT with TLS Certificates\r\nThe malware family of AsyncRAT contains a hardcoded TLS certificate left by the developer. This certificate\r\ncontains the hardcoded subject common name value of AsyncRAT Server\r\nTake for example an IP Address of 91.109.176[.]4. Querying this IP in Censys Search confirms a subject common\r\nname (CN) value of AsyncRAT Server on port 8808.\r\nhttps://censys.com/a-beginners-guide-to-tracking-malware-infrastructure/\r\nPage 2 of 23\n\nBy expanding the host information and locating the exact field where the AsyncRAT Server value is stored\r\nservices.tls.certificates.leaf_data.subject_dn, we can build a query to locate additional servers.\r\nIn this case, either the subject_dn or issuer_dn field can be used as they both contain the same hardcoded value.\r\nBy searching for AsyncRAT Server in either of these fields, we can locate an additional 110 servers with the\r\nsame certificate value.\r\nhttps://censys.com/a-beginners-guide-to-tracking-malware-infrastructure/\r\nPage 3 of 23\n\nExample 2: Hunting Cobalt Strike with TLS Certificates\r\nThe infamous Cobalt Strike toolkit can also be tracked using TLS Certificate values.\r\nThis is primarily due to a default subject common name of Major Cobalt Strike\r\nTake for example the IP address 23.98.137[.]196 with the following certificate on port 50050.\r\nThere are multiple hardcoded values here that can be utilised, but for the sake of simplicity we will leverage the\r\nissuer common name of Major Cobalt Strike.\r\nWe can expand the detailed host view again to determine the exact field name.\r\nServices.tls.certificates.leaf_data.issuer.common_name.\r\nQuerying this value returns 236 results. The chances of legitimate software containing “Major Cobalt Strike” is\r\nvery low, so these are likely all active Cobalt Strike deployments.\r\nhttps://censys.com/a-beginners-guide-to-tracking-malware-infrastructure/\r\nPage 4 of 23\n\nHunting Infrastructure with HTTP Response Titles\r\nDevelopers of malware control servers often leave unique and identifying strings in web page data.\r\nMost commonly these can be found in the HTML Titles and HTTP Bodies.\r\nIt’s useful to note that these values can be changed, but many actors do not go to this effort and leave the\r\nidentifying strings intact.\r\nExample 1: Mythic C2 Framework\r\nThe Mythic C2 framework is often utilised by threat actors and contains a default HTML Title of Mythic.\r\nLooking at the IP 89.223.66[.]195, we can confirm the Mythic string present in the HTML title.\r\nhttps://censys.com/a-beginners-guide-to-tracking-malware-infrastructure/\r\nPage 5 of 23\n\nQuerying for the Mythic string inside of services.http.response.html_title, we can locate a total of 75 servers.\r\nMany of these servers have already been marked as C2 servers by the Censys platform. (You can locate other C2’s\r\nwith the query labels:C2)\r\nHunting Infrastructure with Service Banners\r\nThreat actors and malware developers often leave identifying strings inside of service banners. These are often left\r\nintentionally by the author to limit misuse of the software.\r\nThese can be identified, queried, and tracked using similar methods to the HTML Titles.\r\nNote that service banners may not be displayed by default, and you may need to open the detailed host view to see\r\nthem.\r\nExample 1: Havoc C2 Framework\r\nTake for example the Havoc C2 framework. Havoc is an open source C2 framework developed by C5pider that\r\nhas been leveraged by threat actors due to its high quality implementation of modern offensive techniques.\r\nWith default settings, the Havoc Team Server contains the X-Havoc string inside of the service banner. This has\r\nbeen left intentionally by the author to limit mis-use of the software.\r\nhttps://censys.com/a-beginners-guide-to-tracking-malware-infrastructure/\r\nPage 6 of 23\n\nSearching for services.banner with the X-Havoc string returns a total of 71 results.\r\nA string like this is specific and unlikely to have false positives. So there is a strong chance that these are all active\r\ndeployments of Havoc.\r\nExample 2: Hunting DarkComet with Service Banners\r\nA second example of hunting with service banners can be seen with DarkComet malware.\r\nLooking a the IP address of 187.135.84[.]89, we can observe a unique looking service banner of\r\nBF7CAB464EFB on port 2000\r\nWe can search services.banner with the value BF7CAB464EFB to identify a total of 25 servers.\r\nhttps://censys.com/a-beginners-guide-to-tracking-malware-infrastructure/\r\nPage 7 of 23\n\nSummary – Hunting Infrastructure with Service Banners\r\nThreat actors often work in a hurry and avoid changing default strings in custom or open source software. When\r\ninvestigating a host, be sure to check all service banners for unique or interesting strings.\r\nThese default strings are great indicators for building queries and you should absolutely use them to your\r\nadvantage.\r\nIf you’d like to see for yourself, here is a prebuilt query for both Havoc and DarkComet.\r\nHunting with Locations and ASN Providers\r\nThreat actors often re-use the same hosting providers when deploying multiple servers for malicious purposes.\r\nOften this is done to avoid takedowns and investigations. Other times it is done because hosting providers in an\r\nactor’s home country are easier to obtain.\r\nRegardless of the reasons, actors often re-use providers and we can use this to our advantage to locate malicious\r\nservers and to fine-tune existing queries on other indicators.\r\nExample 1: Amadey Bot Servers\r\nLet’s look at the IP address of 185.215.113[.]68 . This IP address has a relatively unique HTTP response body of\r\nnone.\r\nhttps://censys.com/a-beginners-guide-to-tracking-malware-infrastructure/\r\nPage 8 of 23\n\nHoning in with the query of services.http.response.body=”none”, we have an initial result of 84 servers. Many\r\nof these servers are located in the United States and do not appear to be malicious in nature.\r\nReturning to the initial results on the host page for 185.215.113[.]68, we can see that the server is hosted in\r\nMoscow with an Autonomous System Number of 51381.\r\nWe can add this number as an additional filter to hone in our query results.\r\nhttps://censys.com/a-beginners-guide-to-tracking-malware-infrastructure/\r\nPage 9 of 23\n\nBy adding autonomous_system.asn=51381 to our search, we have now limited our search to only 4 results.\r\nQuerying these results in Virustotal shows that they are all related to Amadey Bot malware.\r\nSummary – Hunting with Locations and Hosting Providers\r\nThreat actors often utilise the same hosting providers when deploying infrastructure. The hosting provider is not\r\nnecessarily an indicator in itself, but it can be combined with other indicators to produce a highly effective query.\r\nWhen investigating an IOC and finding that you have too many search results. Try adding the physical location of\r\nthe server or the ASN Number to hone in your search.\r\nYou can experiment with the Amadey example using this prebuilt query.\r\nHunting Infrastructure with Open Directories\r\nhttps://censys.com/a-beginners-guide-to-tracking-malware-infrastructure/\r\nPage 10 of 23\n\nThreat actors will often host malware and supporting software on open directories which are exposed to the public\r\ninternet. These directories are generally deployed so that malware can easily retrieve additional files to facilitate\r\nexploitation.\r\nTo locate open directories, we can search for common directory titles like Directory Listing or Index Of.\r\nAlternatively we can search for pre-labelled servers with the open-dir tag provided by Censys.\r\nExample 1: Hunting Open Directories with Common File Names\r\nSearching for open directories alone can return hundreds of thousands of results. Many of which are benign and\r\nnon-malicious.\r\nTo identify malicious cases, we can combine the search with a specific file name related to suspicious software.\r\nTake for example nc.exe which is a common file name for the netcat tool.\r\nhttps://censys.com/a-beginners-guide-to-tracking-malware-infrastructure/\r\nPage 11 of 23\n\nInvestigating one of the first returned addresses of 123.57.56[.]129, we can observe an open directory containing\r\nnc.exe as well as references to Hacktools and a .bat script with foreign characters. This information is enough to\r\nassume that the IP is highly suspicious.\r\nWith these indicators identified we can attempt to retrieve the files to perform additional analysis and confirm\r\nmalicious-ness, or we can use the new file names to refine the query and identify additional servers.\r\nFor example we can leverage the newly identified string of hacktools to create a new query.\r\nWe can do this with labels:open-dir and response bodies containing hacktools.\r\nhttps://censys.com/a-beginners-guide-to-tracking-malware-infrastructure/\r\nPage 12 of 23\n\nIn this case only a single result is returned, but this demonstrates the concept of using initial results to establish\r\nnew queries. This query could easily be re-run at a later date to identify new instances of the suspicious server.\r\nExample 2: Open Directories Containing Procdump.exe\r\nTo demonstrate the concept further, we can search for open directories containing references to the process\r\ndumping tool procdump.exe.\r\nOne of the results is a server hosting procdump.exe, beacon.exe and shell.exe.\r\nhttps://censys.com/a-beginners-guide-to-tracking-malware-infrastructure/\r\nPage 13 of 23\n\nWe can use these results to identify new strings and pivot to open directories containing beacon.exe.\r\nThis identifies a new server with IP 62.204.41[.]104 . This server contains references to `beacon.exe` but not the\r\ninitial netcat or procdump. Highlighting the useful-ness of building new queries based on initial results.\r\nhttps://censys.com/a-beginners-guide-to-tracking-malware-infrastructure/\r\nPage 14 of 23\n\nSummary – Hunting Open Directories\r\nOpen directory hunting can be a useful means to hunt for suspicious servers. This is particularly useful when\r\ndealing with Downloader malware that has called out to a server with an open directory.\r\nWhen building queries, use the pre-built open-dir tag and leverage known file names. Then add new file names\r\nand strings based on your results.\r\nWe’ve included some prebuilt queries here for beacon.exe, procdump.exe and nc.exe.\r\nIncorporating Regular Expressions Into Hunting Queries\r\nAdvanced threat actors will often avoid using hardcoded values across multiple servers.\r\nWhen unique values are deployed, this is often done via scripting and automated programs. This means that even\r\nthough the values are unique, the “structure” of the values is often repeated and can be signatured using regular\r\nexpressions.\r\nLet’s take a look at some examples of unique values that can be signatured with regular expressions. Note that\r\nRegular Expression searching is a paid feature of Censys Search.\r\nExample 1: Catching Qakbot Servers With Regular Expressions\r\nA great example of unique values with the same structure is with Qakbot.\r\nhttps://censys.com/a-beginners-guide-to-tracking-malware-infrastructure/\r\nPage 15 of 23\n\nQakbot uses an automated system to deploy and refresh unique TLS certificate values across servers. But these\r\nvalues have a similar structure which can be queried with regular expressions.\r\nWe can see two such certificates in the below screenshots.\r\nObserving the two certificate values, we can see that they are wildly different in their values. However, they\r\nfollow a similar pattern which can be caught with regular expressions.\r\nWe can verify this by copying out the values and bringing in Cyberchef. This allows us to prototype a regular\r\nexpression and confirm that we can match on both values.\r\nhttps://censys.com/a-beginners-guide-to-tracking-malware-infrastructure/\r\nPage 16 of 23\n\nRepeating this process for both the issuer and subject fields of the TLS certificate, we can develop a query that\r\ncatches a total of 64 servers.\r\nTo verify that the results are matching as intended, we can generate a Censys report on the returned results. This\r\nallows us to list all returned certificate values in an easy-to-read list.\r\nBelow is a short snippet of the results, confirming that the query is working as intended.\r\nhttps://censys.com/a-beginners-guide-to-tracking-malware-infrastructure/\r\nPage 17 of 23\n\nExample 2: Catching BianLian Servers with Regular Expressions\r\nThe BianLian malware is another example of unique TLS certificate values containing identical structure and\r\nformatting.\r\nBelow we can observe two certificates. Both the subject and issuer contain only the “C”, “O” and “OU” fields.\r\n(This contrasts with a “typical” certificate, which would contain also contain the “ST” and “L” fields)\r\nEach value contains exactly 16 characters with no spacing or use of special characters.\r\nBringing the two issuer values to Cyberchef, we can prototype a regular expression that captures the values from\r\nboth certificates.\r\nhttps://censys.com/a-beginners-guide-to-tracking-malware-infrastructure/\r\nPage 18 of 23\n\nWe can now search on services.tls.certificate.parsed.issuer_dn with our regular expression. This returns a total\r\nof 24 servers.\r\nWe can go ahead and generate another search report on the services.tls.certificate.parsed.issuer_dn to confirm\r\nthat the results are matching as intended.\r\nhttps://censys.com/a-beginners-guide-to-tracking-malware-infrastructure/\r\nPage 19 of 23\n\nExample 3: Viper Servers with TLS Certificates and Regular Expressions\r\nTo demonstrate one more example, we can take a look at an IP of 139.155.90[.]81 which was marked as Viper\r\nMalware on ThreatFox.\r\nWe can view the TLS certificate information in Censys. Showing subject and issuer fields that are exactly 8\r\ncharacters in length and contain only lowercase letters and numbers.\r\nBringing one of the values into Cyberchef, we can again prototype a regular expression to match on the identified\r\nstructure.\r\nhttps://censys.com/a-beginners-guide-to-tracking-malware-infrastructure/\r\nPage 20 of 23\n\nWe can then search for this regular expression in the services.tls.certificates.leaf_data.issuer_dn field. This\r\nreturns a total of 1593 results.\r\nGenerating another search report verifies that many of these results contain the same TLS structure as the initial\r\nserver.\r\nhttps://censys.com/a-beginners-guide-to-tracking-malware-infrastructure/\r\nPage 21 of 23\n\nSummary – Hunting Infrastructure with Regular Expressions\r\nThere will be cases where hardcoded values won’t be enough to hunt infrastructure.\r\nMany of these situations can be handled by identifying the structure of seemingly unique values and incorporating\r\nregular expressions into your queries.\r\nIf you’re unfamiliar with regular expressions, there is a great free resource over at regexone that will help you get\r\nstarted.\r\nHow Can I Get Started?\r\nAll of the queries (excluding regular expressions) can be performed with a Censys Search Community account.\r\nYou can sign up today and begin threat hunting, gathering intelligence, and building up lists of IOCs.\r\nTo obtain initial IOCs, we recommend using public IOC repositories like ThreatFox and URLHaus and starting\r\nyour hunt from there. We can also recommend leveraging pre-built queries like those shared by drb_ra and\r\nMichael Koczwara.\r\nConclusion\r\nWe’ve now looked at several indicators that can be used to identify malicious infrastructure. You can and should\r\nuse all of these to your advantage when investigating an IP address or performing a threat hunt.\r\nThreat actors vary in quality and sophistication, some will be more difficult to track than others. But in many\r\ncases you can track actors using only the techniques shown here today.\r\nhttps://censys.com/a-beginners-guide-to-tracking-malware-infrastructure/\r\nPage 22 of 23\n\nMatthew\r\nEmbee Research\r\nMatthew (aka @embee_research) is a security researcher based out of Melbourne, Australia. Matthew has a\r\npassion for all things malware, burritos and creating educational cyber content.\r\nSource: https://censys.com/a-beginners-guide-to-tracking-malware-infrastructure/\r\nhttps://censys.com/a-beginners-guide-to-tracking-malware-infrastructure/\r\nPage 23 of 23",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://censys.com/a-beginners-guide-to-tracking-malware-infrastructure/"
	],
	"report_names": [
		"a-beginners-guide-to-tracking-malware-infrastructure"
	],
	"threat_actors": [],
	"ts_created_at": 1775434198,
	"ts_updated_at": 1775791202,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/4f46521324b534fc3dafb1fcbc6e9c7d7da076ef.pdf",
		"text": "https://archive.orkl.eu/4f46521324b534fc3dafb1fcbc6e9c7d7da076ef.txt",
		"img": "https://archive.orkl.eu/4f46521324b534fc3dafb1fcbc6e9c7d7da076ef.jpg"
	}
}