{
	"id": "eabeae3c-e6ed-40fe-a970-418c9e0b45e4",
	"created_at": "2026-04-06T00:21:20.22476Z",
	"updated_at": "2026-04-10T13:11:46.356137Z",
	"deleted_at": null,
	"sha1_hash": "20e7e00b9a4692c748f80ec12cdaf5aeefbcd285",
	"title": "Advanced Persistent Infrastructure Tracking - Censys",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 298170,
	"plain_text": "Advanced Persistent Infrastructure Tracking - Censys\r\nBy jaime\r\nPublished: 2020-12-07 · Archived: 2026-04-05 15:34:30 UTC\r\nUsing OSINT services for tracking malicious infrastructure\r\nIntroduction\r\nMost cyber activity by malicious actors requires infrastructure like servers on the internet. The larger the\r\ncampaign, the more servers are needed. Some APT groups used several thousand Command and Control (C2)\r\nservers over the years. For Threat Intelligence this offers unique opportunities for tracking such activities, because\r\noften the C2 servers need to be configured in a specific way and many actors have developed their idiosyncratic\r\nhabits of setting up servers. An essential advantage over purely forensic investigations of incidents is that\r\nanalyzing the infrastructure can sometimes identify C2 servers even before they were used in an attack. Internet\r\nsearch engines like Censys are crucial in this type of analysis. They collect information about hosts on the internet\r\nand their configurations, thereby saving researchers the effort of scanning large address spaces themselves.\r\nThis article explains why infrastructure tracking is possible, what attributes can be important to take a look on,\r\nshows two recent examples as well as an example process and gives some hints for starting out with infrastructure\r\nanalysis. Keep in mind that this article only discusses passive methods for finding and clustering malicious\r\ninfrastructure. Active methods, such as scanning for hosts yourself, introduces further possibilities such as\r\nmimicking a malware‘s handshake in order to identify C2 servers or victims with high confidence. Also, this\r\narticle covers only HTTP(S) based infrastructure.\r\nBackground\r\nThere are multiple reasons why malicious infrastructure can be found via Censys and similar services, and most of\r\nthem are due to mistakes in operations security (OPSEC). While the following paragraph is surely not exhaustive,\r\nit mentions a few key points why such mistakes happen. Some actors might not be aware of their mistakes, but\r\nothers might even be aware of the impact on OPSEC. Yet, since they need to trade-off OPSEC for efficiency, they\r\nsometimes seem to decide to take the risk.\r\n1. The pace of cyber attacks greatly increased While cyber attacks were the exception some years ago, today\r\nthey are business as usual. Due to the growing number of targets, the demand of infrastructure also increased. In\r\norder to save valuable time, some kind of infrastructure automation is used to set up and configure servers. Some\r\nactors chose the easiest way by deploying prepared images, while others seem to set up C2 servers via some\r\nscripts.\r\n2. Different teams are responsible for operating campaigns and setting up infrastructure While some\r\nexperienced operators (who conduct the actual attacks) might know about OPSEC pitfalls, in some groups the\r\ninfrastructure is set up by another team which is not aware of the technical possibilities to identify their servers.\r\nhttps://censys.com/advanced-persistent-infrastructure-tracking/\r\nPage 1 of 7\n\n3. Specific terms need to be used in order to appear legitimate to potential victims Often it is necessary to\r\ntrick the victims into thinking the used infrastructure is legitimate. This can either be in order to hide in the\r\ngeneral network traffic or because the victim would recognize suspicious addresses in the URL bar, e.g. for\r\nphishing campaigns.\r\n4. No OPSEC-by-design In general, many actors do not seem to follow OPSEC-by-design. Instead of thinking\r\nbeforehand how Threat Intelligence analysts could identify their servers, they seem to live by trial-and-error or at\r\nleast only improve their OPSEC after being outed in a Threat Intelligence report1. Because we don’t want to\r\nprovide OPSEC tips for recent threats, this blog post only covers already known infrastructure that has been\r\nblogged about.\r\nCriteria for clustering hosts\r\nThere are multiple criteria that can be used for finding and clustering infrastructure. Some of them are listed here\r\nincluding the respective attributes which can be used for searching this host – as before, this list is not exhaustive.\r\nIn general, there are three groups of criteria: response header, response content, and certificates. Because some\r\nthreat actors use custom server-side software or specific library versions, responses to HTTP requests often\r\ninclude a characteristic combination of headers. So, hosts can be clustered either by the absence of a header or by\r\nspecific header strings. We will cover an example for clustering hosts by response headers below. With Censys\r\nqueries, headers can be filtered via\r\n\u003cport\u003e.http(s).get.headers.\r\nAlso, the response content can contain characteristic artifacts. Some Command and Control servers try to mimic a\r\nspecific web server and therefore deliver some kind of default page as index or error page. A well-known example\r\nis the use of the Microsoft Internet Information Service (IIS) default web page as an index page for Powershell\r\nEmpire2. Scanning services typically access just the index page or receive an error page as a response if the C2\r\nserver expects a certain path to be accessed. In these cases, often the hash value of the response body can be used\r\nfor clustering hosts.\r\nOther actors sometimes use a default setup, where another website will be completely cloned first and changed\r\nafterwards. In these cases it can be helpful to search for specific resources in the website, such as used favicons,\r\nembedded javascript snippets (and ad network or tracking IDs that might be in there) or included css files. The last\r\ngroup of criteria are certificates. Filtering by serial number, fingerprint or distinguished name (see example 2\r\nbelow) can be a useful way to cluster hosts by their certificates. Actors might tend to use a specific certificate\r\nauthority along quite unique terms in the common name or even reuse self-signed certificates along all their\r\ninfrastructure.\r\nBoth, response content and certificates, sometimes are created in a way that appear legitimate to potential victims\r\nand therefore include specific elements.\r\nExample 1 – Tracking based on HTTP headers\r\nAs a broadly known commercial penetration testing toolkit, Cobalt Strike (CS) is not only used by Red Teams.\r\nOver time, lots of different threat actors used (and probably continue to use) it as a first stage. The typical server\r\nhttps://censys.com/advanced-persistent-infrastructure-tracking/\r\nPage 2 of 7\n\nresponse for Cobalt Strike can be characterized as follows:\r\nHTTP 404 Not Found\r\nContent-Type: text/plain\r\nContent-Length: 0\r\nDate Header\r\nNo Server-Header\r\nWith these criteria, we are able to easily find servers using the following Censys query:\r\n80.http.get.status_line: \"404 Not Found\"\r\nAND 80.http.get.headers.content_type: \"text/plain\"\r\nAND 80.http.get.headers.content_length: 0\r\nNOT _exists_:80.http.get.headers.server\r\nCensys query for Cobalt Strike instances on port 80\r\nBe aware that not all results you see necessarily are Cobalt Strike instances, but it is a good indicator. Also, as you\r\nmight have already guessed, Cobalt Strike is not limited to port 80. Apart from the default TLS certificate used by\r\nthe tool, you can find other instances using TLS by additionally searching for popular certificate authorities or\r\nself-signed certificates.\r\n87f2085c32b6a2cc709b365f55873e207a9caa10bffecf2fd16d3cf9d94d390c\r\nCensys query using the SHA256 hash of the default Cobalt Strike certificate fingerprint\r\nThere is a tremendous amount of Cobalt Strike infrastructure available online, so you most likely need another\r\ntype of data source, such as passive DNS data, in order to properly cluster the instances found.\r\nResults for typical Cobalt Strike headers on port 80:\r\nhttps://censys.com/advanced-persistent-infrastructure-tracking/\r\nPage 3 of 7\n\nCertificate distinguished names\r\nExample 2 – Tracking based on certificate data\r\nIn July 2020, NCSC UK, the national cyber security authority in the UK, published an advisory about APT29\r\ntargeting COVID-19 vaccine research3. The group also known as “The Dukes” or “Cozy Bear” used Citrix and\r\nVPN vulnerabilities to attack various companies connected to vaccine development. In these campaigns, the group\r\nused two custom malware families, WellMess and WellMail. The infrastructure used by the perpetrators included\r\nvery specific self-signed certificates which made them easy to track, as reported by several sources. PwC recently\r\npublished a report about the server side software used by the perpetrators4.\r\nIssuer: C=Tunis, O=IT, CN=* Subject: C=Tunis, O=IT\r\nBy using the certificate distinguished names given in table 1, we can create a query in order to find recent\r\ninfrastructure:\r\n443.https.tls.certificate.parsed.subject_dn: \"C=Tunis, O=IT\" AND 443.https.tls.certificate.parsed.iss\r\nWith the query in table 2, 20 hosts can be found using the certificate details.\r\nhttps://censys.com/advanced-persistent-infrastructure-tracking/\r\nPage 4 of 7\n\nCensys query using certificate distinguished names from WellMess reports\r\nExample Process\r\nWhen I started with infrastructure tracking, I wrote a simple python tool that queried different data sources based\r\non a given rule.\r\nWellMess C2 rule file\r\nThe rule (see figure 3) included the necessary query and the script sent the results to other systems. As those were\r\npurely used as notifications at the start, I called the section “alerts”. After setting up cronjobs to run your scripts,\r\nyou’re good to go – without needing a huge software stack. In case I need the raw response from the queried\r\nhttps://censys.com/advanced-persistent-infrastructure-tracking/\r\nPage 5 of 7\n\nsources, I store all API responses in a JSON file. This way I can create a completely new data structure if needed,\r\nwithout losing data.\r\nTips for starters\r\nWhile you’re going to develop your own procedures for infrastructure tracking, I want to give some advice for\r\npeople starting out, hoping you find the following tips useful.\r\n1. Combine different resources.\r\nIn order to get the most precise picture of the infrastructure used by adversaries, it is very helpful to combine\r\nvarious services that deliver different types of information. In addition to host data (e.g. from Censys or Shodan),\r\npivoting through infrastructure can be enhanced through passive DNS data (e.g. RiskIQ or Domaintools) and\r\ncertificate data (e.g. Censys or crt.sh). If you’re consuming data from different providers, you might want to use a\r\ncommon data model5.\r\n2. Store results in a searchable and flexible way.\r\nAfter you started with infrastructure tracking, you’re eventually going to have a lot of data in your hands and you\r\ndefinitely want to be able to search through that data very fast. Having your data in an elasticsearch cluster or a\r\nsimilar searchable data storage will save you a ton of time. When setting up your toolset, keep in mind that you\r\nmight want to search through your data with regular expressions.\r\n3. Keep older results.\r\nDo not delete results of older search queries. Keeping and updating host information allows the discovery of\r\ninteresting patterns. Also, it is quite useful to have first and last seen dates for C2 servers.\r\n4. Document your queries.\r\nYour ever-growing number of queries need to be documented somehow, otherwise, you’re going to lose the\r\noverview. A good starting point is to create a schema2 that includes metadata such as a description.\r\nConclusion\r\nThreat actors are bound by similar constraints as network defenders – time, money, skills, and laziness. This leads\r\nto mistakes or certain habits when setting up their infrastructure. With some creativity and tooling network\r\ndefenders can exploit those mistakes and habits to track malicious infrastructure. The reward will be IoCs and\r\ninsights into the activities of the attackers. Censys and other tools give analysts a great head-start. The magic then\r\nis in the queries that you write. I hope you found the above techniques and tips helpful. I’ll be happy to hear about\r\nyour experiences, you can reach me via Twitter6 or Keybase7.\r\n1. Compare p. 75 Steffens, Timo (2020). Attribution of Advanced Persistent Threats.\r\nhttps://doi.org/10.1007/978-3-662-61313-9 ↩\r\n2. Compare https://github.com/BCSECURITY/Empire/blob/master/lib/listeners/http.py#L262 ↩\r\nhttps://censys.com/advanced-persistent-infrastructure-tracking/\r\nPage 6 of 7\n\n3. NCSC-UK (2020). APT29 targets COVID-19 vaccine development.\r\nhttps://www.ncsc.gov.uk/files/Advisory-APT29-targets-COVID-19-vaccinedevelopment.pdf (accessed 2020-09-21) ↩\r\n4. PwC UK (2020). WellMess malware: analysis of its Command and Control (C2)\r\nserver. https://www.pwc.co.uk/issues/cyber-security-services/insights/wellmessanalysis-command-control.html (accessed 2020-\r\n09-21) ↩\r\n5. Common OSINT data model for infrastructure analysis:\r\nhttps://github.com/3c7/common-osint-model (accessed 2020-09-21) ↩\r\n6. https://twitter.com/0x3c7 ↩\r\n7. https://keybase.io/nkuhnert↩\r\nSource: https://censys.com/advanced-persistent-infrastructure-tracking/\r\nhttps://censys.com/advanced-persistent-infrastructure-tracking/\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://censys.com/advanced-persistent-infrastructure-tracking/"
	],
	"report_names": [
		"advanced-persistent-infrastructure-tracking"
	],
	"threat_actors": [
		{
			"id": "5b748f86-ac32-4715-be9f-6cf25ae48a4e",
			"created_at": "2024-06-04T02:03:07.956135Z",
			"updated_at": "2026-04-10T02:00:03.689959Z",
			"deleted_at": null,
			"main_name": "IRON HEMLOCK",
			"aliases": [
				"APT29 ",
				"ATK7 ",
				"Blue Kitsune ",
				"Cozy Bear ",
				"The Dukes",
				"UNC2452 ",
				"YTTRIUM "
			],
			"source_name": "Secureworks:IRON HEMLOCK",
			"tools": [
				"CosmicDuke",
				"CozyCar",
				"CozyDuke",
				"DiefenDuke",
				"FatDuke",
				"HAMMERTOSS",
				"LiteDuke",
				"MiniDuke",
				"OnionDuke",
				"PolyglotDuke",
				"RegDuke",
				"RegDuke Loader",
				"SeaDuke",
				"Sliver"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "a241a1ca-2bc9-450b-a07b-aae747ee2710",
			"created_at": "2024-06-19T02:03:08.150052Z",
			"updated_at": "2026-04-10T02:00:03.737173Z",
			"deleted_at": null,
			"main_name": "IRON RITUAL",
			"aliases": [
				"APT29",
				"Blue Dev 5 ",
				"BlueBravo ",
				"Cloaked Ursa ",
				"CozyLarch ",
				"Dark Halo ",
				"Midnight Blizzard ",
				"NOBELIUM ",
				"StellarParticle ",
				"UNC2452 "
			],
			"source_name": "Secureworks:IRON RITUAL",
			"tools": [
				"Brute Ratel C4",
				"Cobalt Strike",
				"EnvyScout",
				"GoldFinder",
				"GoldMax",
				"NativeZone",
				"RAINDROP",
				"SUNBURST",
				"Sibot",
				"TEARDROP",
				"VaporRage"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "46b3c0fc-fa0c-4d63-a38a-b33a524561fb",
			"created_at": "2023-01-06T13:46:38.393409Z",
			"updated_at": "2026-04-10T02:00:02.955738Z",
			"deleted_at": null,
			"main_name": "APT29",
			"aliases": [
				"Cloaked Ursa",
				"TA421",
				"Blue Kitsune",
				"BlueBravo",
				"IRON HEMLOCK",
				"G0016",
				"Nobelium",
				"Group 100",
				"YTTRIUM",
				"Grizzly Steppe",
				"ATK7",
				"ITG11",
				"COZY BEAR",
				"The Dukes",
				"Minidionis",
				"UAC-0029",
				"SeaDuke"
			],
			"source_name": "MISPGALAXY:APT29",
			"tools": [
				"SNOWYAMBER",
				"HALFRIG",
				"QUARTERRIG"
			],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "20d3a08a-3b97-4b2f-90b8-92a89089a57a",
			"created_at": "2022-10-25T15:50:23.548494Z",
			"updated_at": "2026-04-10T02:00:05.292748Z",
			"deleted_at": null,
			"main_name": "APT29",
			"aliases": [
				"APT29",
				"IRON RITUAL",
				"IRON HEMLOCK",
				"NobleBaron",
				"Dark Halo",
				"NOBELIUM",
				"UNC2452",
				"YTTRIUM",
				"The Dukes",
				"Cozy Bear",
				"CozyDuke",
				"SolarStorm",
				"Blue Kitsune",
				"UNC3524",
				"Midnight Blizzard"
			],
			"source_name": "MITRE:APT29",
			"tools": [
				"PinchDuke",
				"ROADTools",
				"WellMail",
				"CozyCar",
				"Mimikatz",
				"Tasklist",
				"OnionDuke",
				"FatDuke",
				"POSHSPY",
				"EnvyScout",
				"SoreFang",
				"GeminiDuke",
				"reGeorg",
				"GoldMax",
				"FoggyWeb",
				"SDelete",
				"PolyglotDuke",
				"AADInternals",
				"MiniDuke",
				"SeaDuke",
				"Sibot",
				"RegDuke",
				"CloudDuke",
				"GoldFinder",
				"AdFind",
				"PsExec",
				"NativeZone",
				"Systeminfo",
				"ipconfig",
				"Impacket",
				"Cobalt Strike",
				"PowerDuke",
				"QUIETEXIT",
				"HAMMERTOSS",
				"BoomBox",
				"CosmicDuke",
				"WellMess",
				"VaporRage",
				"LiteDuke"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "f27790ff-4ee0-40a5-9c84-2b523a9d3270",
			"created_at": "2022-10-25T16:07:23.341684Z",
			"updated_at": "2026-04-10T02:00:04.549917Z",
			"deleted_at": null,
			"main_name": "APT 29",
			"aliases": [
				"APT 29",
				"ATK 7",
				"Blue Dev 5",
				"BlueBravo",
				"Cloaked Ursa",
				"CloudLook",
				"Cozy Bear",
				"Dark Halo",
				"Earth Koshchei",
				"G0016",
				"Grizzly Steppe",
				"Group 100",
				"ITG11",
				"Iron Hemlock",
				"Iron Ritual",
				"Midnight Blizzard",
				"Minidionis",
				"Nobelium",
				"NobleBaron",
				"Operation Ghost",
				"Operation Office monkeys",
				"Operation StellarParticle",
				"SilverFish",
				"Solar Phoenix",
				"SolarStorm",
				"StellarParticle",
				"TEMP.Monkeys",
				"The Dukes",
				"UNC2452",
				"UNC3524",
				"Yttrium"
			],
			"source_name": "ETDA:APT 29",
			"tools": [
				"7-Zip",
				"ATI-Agent",
				"AdFind",
				"Agentemis",
				"AtNow",
				"BEATDROP",
				"BotgenStudios",
				"CEELOADER",
				"Cloud Duke",
				"CloudDuke",
				"CloudLook",
				"Cobalt Strike",
				"CobaltStrike",
				"CosmicDuke",
				"Cozer",
				"CozyBear",
				"CozyCar",
				"CozyDuke",
				"Danfuan",
				"EnvyScout",
				"EuroAPT",
				"FatDuke",
				"FoggyWeb",
				"GeminiDuke",
				"Geppei",
				"GoldFinder",
				"GoldMax",
				"GraphDrop",
				"GraphicalNeutrino",
				"GraphicalProton",
				"HAMMERTOSS",
				"HammerDuke",
				"LOLBAS",
				"LOLBins",
				"LiteDuke",
				"Living off the Land",
				"MagicWeb",
				"Mimikatz",
				"MiniDionis",
				"MiniDuke",
				"NemesisGemina",
				"NetDuke",
				"OnionDuke",
				"POSHSPY",
				"PinchDuke",
				"PolyglotDuke",
				"PowerDuke",
				"QUIETEXIT",
				"ROOTSAW",
				"RegDuke",
				"Rubeus",
				"SNOWYAMBER",
				"SPICYBEAT",
				"SUNSHUTTLE",
				"SeaDaddy",
				"SeaDask",
				"SeaDesk",
				"SeaDuke",
				"Sharp-SMBExec",
				"SharpView",
				"Sibot",
				"Solorigate",
				"SoreFang",
				"TinyBaron",
				"WINELOADER",
				"WellMail",
				"WellMess",
				"cobeacon",
				"elf.wellmess",
				"reGeorg",
				"tDiscoverer"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434880,
	"ts_updated_at": 1775826706,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/20e7e00b9a4692c748f80ec12cdaf5aeefbcd285.pdf",
		"text": "https://archive.orkl.eu/20e7e00b9a4692c748f80ec12cdaf5aeefbcd285.txt",
		"img": "https://archive.orkl.eu/20e7e00b9a4692c748f80ec12cdaf5aeefbcd285.jpg"
	}
}