{
	"id": "db5f369c-9cfa-4a44-b74b-ae9a62304dc2",
	"created_at": "2026-04-06T00:21:09.994165Z",
	"updated_at": "2026-04-10T03:24:24.638357Z",
	"deleted_at": null,
	"sha1_hash": "06b68c70fac490a7473249ef7783a595177782db",
	"title": "Cobalt Strike Analysis and Tutorial: Identifying Beacon Team Servers in the Wild",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 8337879,
	"plain_text": "Cobalt Strike Analysis and Tutorial: Identifying Beacon Team\r\nServers in the Wild\r\nBy Durgesh Sangvikar, Chris Navarrete, Matthew Tennis, Yanhui Jia, Yu Fu, Siddhart Shibiraj\r\nPublished: 2022-11-03 · Archived: 2026-04-05 18:48:49 UTC\r\nExecutive Summary\r\nAs Cobalt Strike remains a premier post-exploitation tool for malicious actors trying to evade threat detection,\r\nnew techniques are needed to identify its Team Servers. To this end, we present new techniques that leverage\r\nactive probing and network fingerprint technology. This is a fundamental change from previous passive traffic\r\ndetection approaches.\r\nOver the course of our Unit 42 blog series covering the adversary framework tool Cobalt Strike, we document the\r\nencoding and encryption techniques of its HTTP transactions. Specifically, we analyzed the advanced, flexible\r\ntraffic profiles used by Cobalt Strike’s Beacon command-and-control (C2) communication to evade detection by\r\ndefenders.\r\nBeacon implants communicate to an attacker-controlled application called Team Server. Team Server and the\r\nBeacon’s C2 traffic allow adversaries to easily and effectively cloak malicious traffic as normal, benign traffic.\r\nThis is made possible by a modular, extensible domain-specific language called Malleable C2.\r\nSanctioned adversaries (such as Red/Blue team members, pentesters and ethical hackers) as well as malicious\r\nactors can use premade or custom Malleable C2 profiles. These profiles can be exceedingly difficult to continually\r\ndevelop traditional defenses against, such as conventional firewall threat prevention.\r\nIn previous approaches, Team Server detections could only be made after a Beacon binary was implanted on a\r\nvictim’s system and attempted to “phone home” to an attacker-controlled server. Our new techniques can\r\nproactively detect Team Servers in the wild before an active C2 connection from a victim’s system has been\r\ninitialized.\r\nWe will also demonstrate the following:\r\nHow Team Servers behave when they receive specially-crafted HTTP requests\r\nWhat kind of network fingerprint can be inferred and with what confidence\r\nDetails of some real-life malicious C2 between Beacon and Team Server in the wild\r\nPalo Alto Networks customers receive protections from and mitigations for Cobalt Strike Beacon and Team Server\r\nC2 communication in the following ways:\r\nNext-Generation Firewalls with a Threat Prevention subscription can identify and block Cobalt Strike\r\nHTTP C2 requests as well as responses that are masked with the base64 encoding settings of the default\r\nprofile (signatures 86445 and 86446).\r\nhttps://unit42.paloaltonetworks.com/cobalt-strike-team-server/\r\nPage 1 of 10\n\nNext-Generation Firewalls with an Advanced Threat Prevention subscription can identify and block Cobalt\r\nStrike HTTP C2 requests generated by custom profiles.\r\nWildFire and Cortex XDR can identify and block Cobalt Strike Beacon binaries.\r\nCortex XSOAR response pack and playbook can automate the mitigation process.\r\nCortex XDR will report related exploitation attempts.\r\nMalicious URLs and IPs have been added to Advanced URL Filtering.\r\nIf you think you may have been compromised or have an urgent matter, the Unit 42 Incident Response\r\nteam can provide personalized assistance.\r\nProbing and Fingerprint Identification Technology\r\nThe Cobalt Strike Team Server, also known as CS Team Server, is the centralized C2 application for a Beacon and\r\nits operator(s). It accepts client connections, orchestrates remote commands to Beacon implants, provides UI\r\nmanagement, and various other functions.\r\nDuring our research and development of Advanced Threat Prevention’s inline deep learning detection for Cobalt\r\nStrike traffic, we began experimenting with forging C2 requests to suspected malicious Team Servers on the\r\nInternet. Through our analysis of attacker-controlled server responses, we developed a variety of techniques to\r\nclassify previously undetected Cobalt Strike Team Servers before an attack can occur.\r\nIn the following sections, we share our findings on the following identification techniques:\r\nActive Probing Over HTTP\r\nActive Probing Over DNS\r\nActive Probing Over HTTP HTTP/S OPTIONS Request and Response Fingerprint\r\nThe Team Server is a Linux program running an HTTP server configured to respond to a variety of HTTP\r\nrequests. When the server receives requests with the HTTP OPTIONS method, the server will return HTTP status\r\ncode 200 and Content-Length: 0.\r\nFigure 1 shows an HTTP request and response to a Team Server. The URI provided in an HTTP OPTIONS request\r\nis disregarded as the same response is returned regardless of URI.\r\nFigure 1. HTTP OPTIONS request with HTTP 200 response.\r\nHTTP/HTTPs GET Request and Response Fingerprint\r\nhttps://unit42.paloaltonetworks.com/cobalt-strike-team-server/\r\nPage 2 of 10\n\nWhen a Team Server starts, the HTTP server exposes certain URIs. Figure 2 shows the list of URIs.\r\nThe URLs stager and stager64 are masked if the profile has the set host_stage \"false\"; option set. The HTTP server\r\nwill return HTTP status code 404 if the URI begins with a forward slash (/).\r\nFigure 2. List of the URIs from the Team Server.\r\nRequest to Stager URI\r\nWhen a user sends the following HTTP request to a Team Server, the server will return the 32-bit Beacon binary\r\nto the client. Figure 3 shows the HTTP request and response. Note the lack of a forward slash (/) at the beginning\r\nof the URI path.\r\nFigure 3. HTTP GET request and response for a 32-bit Beacon payload.\r\nRequest to Stager64 URI\r\nTo receive a 64-bit Beacon payload, a user must send an HTTP GET request to the URI stager64. Figure 4 shows\r\nthe HTTP request and response for a 64-bit Beacon payload.\r\nhttps://unit42.paloaltonetworks.com/cobalt-strike-team-server/\r\nPage 3 of 10\n\nFigure 4. HTTP GET request and response for a 64-bit Beacon payload.\r\nRequest to Beacon.http-get URI\r\nCertain preset URI paths can be configured in the Malleable C2 profile to serve static data. If a user sends a GET\r\nrequest to the URI beacon.http-get, the Team Server responds with the data that has been specified in its profile.\r\nSpecifically, it sends the output section within the server tag of the http-get configuration.\r\nIf the output section only contains the command print;, the server responds with HTTP status code 200 and\r\nContent-Length: 0. Figure 5 shows the HTTP request and response with the default profile.\r\nFigure 5. HTTP request and response with default profile.\r\nIf Team Server initializes with the Malleable C2 Gmail profile, the server responds with static data presented as\r\ndescribed above. In this profile, GET requests to beacon.http-get result in a response containing a JavaScript\r\npayload.\r\nFigure 6 shows the HTTP request and response generated by a Beacon session preset with the Gmail Malleable C2\r\nprofile.\r\nhttps://unit42.paloaltonetworks.com/cobalt-strike-team-server/\r\nPage 4 of 10\n\nFigure 6. HTTP request and response configured with the Gmail Malleable C2 Gmail profile.\r\nRequest to Beacon.http-post URI\r\nTeam Server’s behavior is the same for a GET request to the URI beacon.http-post as it is for the URI beacon.http-get. Figure 7 shows the HTTP request and response for a Team Server instance that initializes with the default\r\nMalleable C2 profile.\r\nFigure 7. HTTP request and response configured with the default Malleable C2 profile.\r\nFigure 8 shows an HTTP transaction when a GET request for beacon.http-post is sent to a Team Server instance\r\nthat has initialized with the Gmail Malleable C2 profile.\r\nFigure 8. HTTP request and response configured with the Malleable C2 Gmail profile.\r\nURI Checksum\r\nhttps://unit42.paloaltonetworks.com/cobalt-strike-team-server/\r\nPage 5 of 10\n\nTeam Server utilizes a custom one-byte checksum of the request URI as a condition to serve the 32-bit or 64-bit\r\nversion of the Beacon binary. A simple checksum algorithm implemented in Java named checksum8 is used to\r\ncalculate the checksum of the request URI.\r\nAs shown in Figure 9, for 32-bit payloads, the code compares the URI checksum result to the literal integer 92L\r\n(where the L suffix is Java syntax for integer type long). For 64-bit payload requests, the algorithm compares the\r\nchecksum to 93L.\r\nFigure 9. Code to check the URI checksum.\r\nWhen a user sends a GET request to a Team Server, the URI is passed to checksum8 and is compared to both\r\ninteger values 92L and 93L. If the checksum satisfies one of the conditions, the server will respond with the raw\r\nbytes of the appropriate Beacon binary.\r\nFigure 10 details an example of a URI that computes to a value that satisfies the checksum8 condition, as well as\r\nthe Team Server’s response with the Beacon binary payload. This information was extracted from Beacon\r\nconfiguration scripts, which continue to provide threat intelligence that is useful for preventing Cobalt Strike\r\nconnections.\r\nFigure 10. HTTP GET request and response with a URI that satisfies checksum8.\r\nRandom URI\r\nhttps://unit42.paloaltonetworks.com/cobalt-strike-team-server/\r\nPage 6 of 10\n\nIf a user sends a randomized URI path, the Team Server will respond with HTTP status code 404 with Content-Length: 0. Figure 11 shows the HTTP response from a Team Server when a user sends a GET request with the\r\nURI randomURI.\r\nFigure 11. HTTP GET request and response for a randomURI path.\r\nActive Probing Over DNS\r\nCobalt Strike’s DNS listener enables Beacon implants to covertly utilize the DNS protocol to communicate with\r\nthe Team Server. The DNS-based Beacon uses the DNS TXT, AAAA, and A records for task monitoring and other\r\nrelated functions. The configuration is set by data channel mode in the Malleable C2 profile.\r\nFigure 12 shows a DNS request originating from a Beacon querying the TXT record for the domain aaa.stage[.]xx.\r\nFigure 12. Beacon DNS request for TXT record.\r\nOnce the request is received, the Team Server responds with the base64-encoded Beacon binary in the\r\nTXT\r\nrecord response, as shown in Figure 13 below:\r\nhttps://unit42.paloaltonetworks.com/cobalt-strike-team-server/\r\nPage 7 of 10\n\nFigure 13. Beacon DNS Listener response (base64-encoded data).\r\nTeam Server Found in the wild\r\nBased on the fingerprints and signals discovered, we utilized open source threat intelligence feeds including\r\nZoomEye, Shodan and Censys to scour the internet in search of undetected Cobalt Strike Team Servers in the\r\nwild.\r\nThe following table details IP/port and URI indicators of compromise (IoCs) related to live Team Server instances\r\nwe discovered in the wild in September 2022. We utilized Shodan’s feed service to collect IP addresses of\r\npotential Team Servers before sending 32-bit stager probes to test the daemon for positive indicators. Once a\r\ncandidate returns the expected Cobalt Strike response, we initialize a TCP connection with netcat to test, verify\r\nand extract the served stager bytes as shown in Figure 14.\r\nFigure 14. Successful HTTP/S probing for Team Server via stager check.\r\nIP Address:Port Payload Type GET-URI POST-URI\r\n43[.]129[.]7[.]189:8080 windows-beacon_http-reverse_http /updates /aircanada/dark.php\r\n117[.]50[.]37[.]182:80 windows-beacon_http-reverse_http /api/x /api/y\r\n42[.]192[.]206[.]174:80 windows-beacon_http-reverse_http /dpixel /submit.php\r\n194[.]37[.]97[.]160:80 windows-beacon_http-reverse_http /cx /submit.php\r\n92[.]222[.]172[.]39:80 windows-beacon_http-reverse_http /ptj /submit.php\r\n79[.]141[.]169[.]220:443 windows-beacon_http-reverse_http /pixel.gif /submit.php\r\nhttps://unit42.paloaltonetworks.com/cobalt-strike-team-server/\r\nPage 8 of 10\n\nTable 1. IP/port and URI IoCs related to live Team Server instances.\r\nConclusion\r\nCobalt Strike is a potent post-exploitation adversary emulator that continues to evade conventional next-generation solutions, including signature-based network detection. However, Advanced Threat Prevention’s inline\r\ndeep-learning models and heuristic techniques provide defenses against Cobalt Strike Beacon and Team Server C2\r\ncommunication before they occur.\r\nThe probing and fingerprint technology detailed in this publication is very efficient and reliable in identifying\r\nCobalt Strike instances in the wild with a very high degree of certainty. A single modern network security\r\nappliance is not sufficient to provide comprehensive coverage against complex malicious tools such as Cobalt\r\nStrike. Only a combination of security solutions including firewalls, sandboxes, endpoint agents and cloud-based\r\nmachine learning can integrate the required data to prevent advanced adversaries from mounting successful\r\ncyberattacks from end to end.\r\nPalo Alto Networks customers receive protection from this kind of attack by the following:\r\nNext-Generation Firewalls (NGFWs) with Threat Prevention signatures 86445 and 86446 can identify\r\nHTTP C2 requests with the base64 metadata encoding in default profiles.\r\nNext-Generation Firewalls with Advanced Threat Prevention subscription can identify and block the\r\nCobalt Strike HTTP C2 request in non default profiles.\r\nWildFire, an NGFW security subscription, and Cortex XDR identify and block Cobalt Strike Beacon.\r\nCortex XSOAR response pack and playbook can automate the mitigation process.\r\nCortex XDR will report related exploitation attempts.\r\nMalicious URLs and IPs have been added to Advanced URL Filtering.\r\nIf you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident\r\nResponse team or call:\r\nNorth America Toll-Free: 866.486.4842 (866.4.UNIT42)\r\nEMEA: +31.20.299.3130\r\nAPAC: +65.6983.8730\r\nJapan: +81.50.1790.0200\r\nIndicators of Compromise\r\nCS Samples\r\n50ea11254f184450a7351d407fbb53c54686ce1e62e99c0a41ee7ee3e505d60c\r\nCS Beacon Samples\r\n/lNj8\r\nSHA256 hash:\r\ne712d670382ad6f837feeb5a66adb2d0f133481b5db854de0dd4636d7e906a8e\r\nhttps://unit42.paloaltonetworks.com/cobalt-strike-team-server/\r\nPage 9 of 10\n\nCS Teamserver IP addresses\r\n92[.]255[.]85[.]93\r\n43[.]129[.]7[.]189\r\n117[.]50[.]37[.]182\r\n42[.]192[.]206[.]174\r\n194[.]37[.]97[.]160\r\n92[.]222[.]172[.]39\r\n79[.]141[.]169[.]220\r\nSource: https://unit42.paloaltonetworks.com/cobalt-strike-team-server/\r\nhttps://unit42.paloaltonetworks.com/cobalt-strike-team-server/\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://unit42.paloaltonetworks.com/cobalt-strike-team-server/"
	],
	"report_names": [
		"cobalt-strike-team-server"
	],
	"threat_actors": [
		{
			"id": "610a7295-3139-4f34-8cec-b3da40add480",
			"created_at": "2023-01-06T13:46:38.608142Z",
			"updated_at": "2026-04-10T02:00:03.03764Z",
			"deleted_at": null,
			"main_name": "Cobalt",
			"aliases": [
				"Cobalt Group",
				"Cobalt Gang",
				"GOLD KINGSWOOD",
				"COBALT SPIDER",
				"G0080",
				"Mule Libra"
			],
			"source_name": "MISPGALAXY:Cobalt",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434869,
	"ts_updated_at": 1775791464,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/06b68c70fac490a7473249ef7783a595177782db.pdf",
		"text": "https://archive.orkl.eu/06b68c70fac490a7473249ef7783a595177782db.txt",
		"img": "https://archive.orkl.eu/06b68c70fac490a7473249ef7783a595177782db.jpg"
	}
}