{
	"id": "330c72b6-a428-4d67-8dbc-2825459edbea",
	"created_at": "2026-04-06T00:06:13.620817Z",
	"updated_at": "2026-04-10T13:12:27.988646Z",
	"deleted_at": null,
	"sha1_hash": "56a1c4f26464cd35679bfed01d11b3dd39bbf402",
	"title": "Cobalt Strike, a Defender’s Guide - Part 2",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 6024927,
	"plain_text": "Cobalt Strike, a Defender’s Guide - Part 2\r\nBy editor\r\nPublished: 2022-01-24 · Archived: 2026-04-05 17:39:03 UTC\r\nOur previous report on Cobalt Strike focused on the most frequently used capabilities that we had observed. In\r\nthis report, we will focus on the network traffic it produced, and provide some easy wins defenders can be on the\r\nlook out for to detect beaconing activity. We cover topics such as domain fronting, SOCKS proxy, C2 traffic,\r\nSigma rules, JARM, JA3/S, RITA \u0026 more.\r\nAs with our previous article, we will highlight the common ways we see threat actors using Cobalt Strike.\r\nBig shout-out to @Kostastsale for helping put this Part 2 together! Also thanks to @svch0st, @pigerlin, and\r\n@0xtornado for reviewing this report.\r\nThe DFIR Report Services\r\nPrivate Threat Briefs: Over 20 private DFIR reports annually.\r\nThreat Feed: Focuses on tracking Command and Control frameworks like Cobalt Strike, Metasploit, Sliver,\r\netc.\r\nAll Intel: Includes everything from Private Threat Briefs and Threat Feed, plus private events, opendir\r\nreports, long-term tracking, data clustering, and other curated intel.\r\nPrivate Sigma Ruleset: Features 100+ Sigma rules derived from 40+ cases, mapped to ATT\u0026CK with test\r\nexamples.\r\nDFIR Labs: Offers cloud-based, hands-on learning experiences, using real data, from real intrusions.\r\nInteractive labs are available with different difficulty levels and can be accessed on-demand,\r\nhttps://thedfirreport.com/2022/01/24/cobalt-strike-a-defenders-guide-part-2/\r\nPage 1 of 25\n\naccommodating various learning speeds.\r\nContact us today for pricing or a demo!\r\nEven though network monitoring and detection capabilities do not come easy for many organizations, they can\r\ngenerally offer a high return on investment if implemented correctly. Malware has to contact its C2 server if it is\r\nto receive further instructions. This article will demonstrate how to detect this communication before threat actors\r\naccomplish their objectives. There are a couple of factors that we can utilize to fingerprint any suspicious traffic\r\nand subsequent infrastructure. Before we get into that part, we should first discuss what makes Cobalt Strike so\r\nversatile.\r\nCobalt Strike’s versatility comes from the ability to change the indicators with each payload. This is made possible\r\nthanks to Malleable C2 profiles. Our other post touched on Malleable C2 profiles and how threat actors use them;\r\nhowever, that was just some of their many applications. Below you can find information related to some of the\r\nmost important fields that could throw off an analyst while investigating a Cobalt Strike network communication:\r\nThe reference profile below is taken from Raphael Mudge’s GitHub .\r\n###Global Options###\r\nset sample_name \"whatever.profile\";\r\nset sleeptime \"0\"; \u003c================ # Decimal number to indicate the time the beacon will sleep for\r\nset jitter \"25\"; \u003c================ # A number that indicates the percentage of a random sleep time\r\nset useragent \"\u003cstring\u003e\"; \u003c================ # Custom user agent of your choice\r\nset data_jitter \"35\"; \u003c================ # Represents the value bytes variable that would instruct Cob\r\nset headers_remove \"\u003cheader to remove\u003e\"; \u003c================ # Specifying headers to be removed in a co\r\n####### Not much explanation is needed here, you can change the certificate information to your heart\r\nhttps-certificate {\r\n set C \"US\";\r\n set CN \"whatever.com\";\r\n set L \"California\";\r\n set O \"whatever LLC.\";\r\n set OU \"local.org\";\r\n set ST \"CA\";\r\n set validity \"365\";\r\n}\r\n###HTTP-Config Block###\r\nhttp-config {\r\n set headers \"\u003cheaders to include\u003e\"; \u003c================ # Specifying the headers that you want to i\r\n header \"\u003cname of the header(s)\u003e\"; \u003c================ # Specifying the name of the header that wil\r\n set trust_x_forwarded_for \"\u003ctrue OR false\u003e\"; \u003c================ # If the C2 server is behind a re\r\n set block_useragents \"\u003cuser agents\u003e\"; \u003c================ # User agents that C2 server will block\r\n set allow_useragents \"\u003cuser agents\u003e\" \u003c================ # Opposite of the above\r\n}\r\n###HTTP-GET Block. This function and all of its fields could also exist and be customized for the HTT\r\nhttp-get {\r\nhttps://thedfirreport.com/2022/01/24/cobalt-strike-a-defenders-guide-part-2/\r\nPage 2 of 25\n\nset uri \"/\u003cURI string\u003e\"; \u003c================ # Specifying the URI to reference in bidirectional co\r\n set verb \"POST\"; \u003c================ # Setting the verb when requesting available tasks from the C\r\n client {\r\n header \"Host\" \"whatever.com\"; \u003c================ # Setting the header specific to client comm\r\n header \"Connection\" \"close\";\r\n### Metadata corresponds to the information that the beacon is sending to the C2 server about itself\r\n metadata {\r\n #base64; \u003c================ # Base64 encoded string\r\n base64url; \u003c================ # URL safe Base64 encoded string\r\n #mask; \u003c================ # Encrypting and encoding the data with XOR mask and random key\r\n #netbios; \u003c================ # Encoding data as netbios in lower case\r\n #netbiosu; \u003c================ # Another variation of netbios encoding\r\n #prepend \"TEST123\"; \u003c================ # Choosing a string to prepend to the transmitted data\r\n append \".php\"; \u003c================ # Choosing a string to append\r\n ### Termination statements: This statement tells Beacon and its server wherein the transaction t\r\n parameter \"file\"; \u003c================ # Adding a parameter to the URI.\r\n #header \"Cookie\"; \u003c================ # Adding a specific string within a specific header.\r\n #uri-append; \u003c================ # Adding a specific string in the URI.\r\n #print;\r\n }\r\n parameter \"test1\" \"t\r\nWe added comments to the profile above to explain the numerous fields operators can change to customize the\r\nprofile to their needs. All these different fields provide control and flexibility over the indicators of the C2\r\nchannel. Many free, open-source randomizer scripts exist to create a unique profile such as Random C2 Profile\r\nGenerator by @joevest, Malleable-C2-Randomizer by @bluscreenofjeff, and C2concealer by @FortyNorthSec.\r\nBelow are some of the Cobalt Strike C2 servers that we observed during intrusions. On the right column, we show\r\nthe URLs that the Cobalt Strike payloads were configured to query. A trained eye could spot some of the\r\nMalleable profiles that exist on freely available resources such as Raphael Mudge’s list on his GitHub page.\r\nAnother example is the “jquery-3.3.1.min.js” which is associated with this malleable C2 profile as we observed in\r\nfour intrusions.\r\n+----------------------+-----------------------+\r\n| C2 Server | URI queried |\r\n+----------------------+-----------------------+\r\n| gawocag.com | /nd |\r\n| 190.114.254.116 | /push |\r\n| 190.114.254.116 | /__utm.gif |\r\n| kaslose.com | /jquery-3.3.1.min.js |\r\n| yawero.com | /skin.js |\r\n| sazoya.com | /skin.js |\r\n| 192.198.86.130 | /skin.js |\r\n| 162.244.83.216 | /jquery-3.3.1.min.js |\r\n| sammitng.com | /jquery-3.3.1.min.js |\r\n| 23.19.227.147 | /styles.html |\r\nhttps://thedfirreport.com/2022/01/24/cobalt-strike-a-defenders-guide-part-2/\r\nPage 3 of 25\n\n| securityupdateav.com | /tab_shop_active.html |\r\n| 108.62.118.247 | /as |\r\n| windowsupdatesc.com | /as |\r\n| 212.114.52.180 | /copyright.css |\r\n| defenderupdateav.com | /default.css |\r\n| onlineworkercz[.]com | /kj |\r\n| checkauj.com | /jquery-3.3.1.min.js |\r\n+----------------------+-----------------------+\r\nA deep dive into all available fields can be found on this post from @ZephrFish. He also includes other fields\r\nrelated to post-exploitation beacon configuration along with network communication-related fields. Another great\r\nresource is this article released by SpecterOps.\r\nDomain Fronting\r\nThe main purpose of domain fronting is to connect to a restricted host while pretending to communicate with an\r\nallowed host. It essentially masks your traffic to a certain website by masquerading it as a different domain.\r\nThis technique is possible thanks to Content Delivery Networks (CDNs). Domain fronting was mostly used by\r\nweb services to bypass censorship in several countries that restricted traffic (e.g., China). In recent years, attackers\r\nhave started using this technique to hide their malicious infrastructure behind legitimate domains. Because domain\r\nfronting is a complicated topic to grasp, below we have included an image from the official Cobalt Strike page\r\nthat discusses this technique.\r\nCobalt Strike made domain fronting possible by allowing the operators to configure related settings via the\r\nmalleable C2 profiles. The following prerequisites must be met in order for domain fronting to be possible:\r\nhttps://thedfirreport.com/2022/01/24/cobalt-strike-a-defenders-guide-part-2/\r\nPage 4 of 25\n\n1. Own a domain. (e.g., infosecppl.store)\r\n2. Pick one of the many web services that provide CDN capabilities. (e.g., cloudfront.net).\r\n3. Setup the CDN service to create a new CDN endpoint and redirect traffic to your domain. (e.g.,\r\nl33th4x0r.cloudfront.net).\r\n4. Setup a profile to facilitate domain fronting.\r\n5. Identify a domain that uses the same CDN to ensure that the traffic will be forwarded to the correct\r\nresource.\r\nStep five is where things get interesting. Attackers can use legitimate domains that are registered under the same\r\nCDN provider. As demonstrated in the screenshot above, all they have to do is include their CDN endpoint\r\ndomain (created in step three) in the host header of the request. In that way, the legitimate website will forward the\r\ntraffic through the CDN to the original destination according to the host header.\r\nIn the screenshots below, you can see how the malleable C2 profiles are configured to allow domain fronting\r\nusing the Fastly and AzureEdge CDNs:\r\nhttps://thedfirreport.com/2022/01/24/cobalt-strike-a-defenders-guide-part-2/\r\nPage 5 of 25\n\nThis research paper released by academics from the University of California, Berkeley, is a great introduction to\r\ndomain fronting. This paper inspired many researchers to expand the possibilities of this unique way of hiding the\r\nfinal destination server on web traffic. One of those researchers is Vincent who wrote a great article on domain\r\nfronting. He explains in simple terms how it works. He also published a Python script to identify possible domains\r\nthat can be leveraged for domain fronting.\r\nLooking into our reporting, we don’t see many instances of domain fronting. This is most likely due to the\r\ncomplex process of setting up the necessary infrastructure. Although, based on the data we have collected\r\nregarding malicious infrastructure, domain fronting appears to be used by threat actors. According to our data\r\nfrom early 2021 up to now, Amazon Cloudfront takes the lead on preferable CDN used by threat actors, by a large\r\nmargin.\r\nThe data above is available via our services. More information on this service and others can be found here.\r\nReverse Proxy using Cobalt Strike Beacon\r\nA technique that we come across often is a reverse proxy. We see instances where threat actors use their beacon\r\nsessions to establish RDP access through a reverse proxy. Cobalt Strike has the ability to run a SOCKS proxy\r\nserver on the team server. This enables the operators to setup a listening port and leverage it to relay traffic to and\r\nfrom the open beacon session. The screenshot below demonstrates this implementation.\r\nhttps://thedfirreport.com/2022/01/24/cobalt-strike-a-defenders-guide-part-2/\r\nPage 6 of 25\n\nImage credit: cobaltstrike.com\r\nSome of the cases we have observed threat actors using reverse proxy are:\r\nDiavol Ransomware\r\nBazarLoader and the Conti Leaks\r\nSnatch Ransomware\r\nIn most, of the above cases, the aim of the attackers was to establish a Remote Desktop session. There are\r\nnumerous advantages to establishing a RDP session, including the ability to navigate using a graphical\r\nenvironment and easily move laterally once the necessary access has been granted.\r\nBelow, we demonstrate how attackers take advantage of this technique using proxychains from the attackers’ kali\r\nLinux host. In the first image, the attackers open a socks listening port, in this case port 8888, on the Cobalt Strike\r\nhttps://thedfirreport.com/2022/01/24/cobalt-strike-a-defenders-guide-part-2/\r\nPage 7 of 25\n\nteam server.\r\nCreating the listening port (TCP port 8888)\r\nIn this second image, we employ proxychains from the attacker’s Kali Linux host to RDP into our target’s\r\nenvironment via the SOCKS server. We essentially add the team server’s IP address into the proxychains\r\nconfiguration and connect with xfreerdp.\r\nRDP into the target host using reverse proxy\r\nLooking into the generated artifacts, we can see that a 4624 typ 3 event is created on the target host. One\r\ninteresting aspect that we have also mentioned in similar cases from our reporting is that the victim’s hostname is\r\ncaptured in this logon event as well as the source address being 127.0.0.1.\r\nhttps://thedfirreport.com/2022/01/24/cobalt-strike-a-defenders-guide-part-2/\r\nPage 8 of 25\n\nSecurity Event ID 4624 Type 3 shows the attacker’s hostname\r\nOnce again, the running Cobalt Strike beacon acts as the intermediary to facilitate the Remote Desktop session via\r\nreverse proxy.\r\nInside Cobalt Strike’s C2 Traffic\r\nThis section will attempt to illustrate how the different malleable C2 profiles can affect network communication.\r\nIn some of the examples below, we simulated the malicious C2 channel to show how different malleable profile\r\nconfigurations can change the observed traffic. After that, we’ll examine network data associated with lateral\r\nmovement and the various methods employed by Cobalt Strike operators based on our observations.\r\nHTTP/HTTPS C2 traffic\r\nWe will use a slightly modified version of the jquery profile to illustrate how the configuration defines the various\r\nfields that make up the C2 connection. Our previous article presented this jquery profile as one of the most\r\ncommonly used profiles by threat actors in the intrusions we reported.\r\nhttps://thedfirreport.com/2022/01/24/cobalt-strike-a-defenders-guide-part-2/\r\nPage 9 of 25\n\nA portion of the malleable C2 profile configuration is shown at the bottom half of the screenshot. At the top half\r\nof the screenshot, we show the HTTP communication between the Beacon and the Cobalt Strike server.\r\nThe malleable profile determines the content of all parameters used in GET and POST requests. Because of how\r\nsimple it is to change these parameters, creating network signatures for proactive defense can be difficult.\r\nDNS C2 traffic\r\nCobalt Strike is capable of using DNS as the C2 method. Operators can choose to configure their server to\r\nrespond to beacon requests in A, AAAA or TXT records. This strategy is useful for more covert operations, as the\r\ndestination host could be a benign DNS server. Defenders will have to inspect the traffic data and look for\r\nsuspicious DNS records.\r\nThe screenshot below is from the official Cobalt Strike documentation page and shows how DNS communication\r\nworks between the compromised host and the C2 server.\r\nhttps://thedfirreport.com/2022/01/24/cobalt-strike-a-defenders-guide-part-2/\r\nPage 10 of 25\n\nIn the below example, we emulated this technique and configured the Beacon to communicate over DNS and\r\nrequest new tasks using A records. In the same way, we can configure the Beacon to use TXT or AAAA records\r\nfor requesting tasks or sending information to the server. It is worth noting that the default method is the DNS\r\nTXT record data channel. Below is the infrastructure that we used for demonstration purposes:\r\nTarget Host: 192.168.88.179\r\nInternal DNS server: 192.168.88.2\r\nCobalt Strike C2 domain: infosecppl.store\r\nWe instructed the Beacon to execute the command systeminfo on the compromised host. As you can see from the\r\nscreenshot below, it took 148 packets containing DNS requests and responses to finish the task and send back the\r\ndata to the Cobalt Strike Server. The activity took 5 seconds to complete.\r\nAs with HTTP/HTTPS traffic, DNS traffic can be randomized using malleable C2 profiles. Some of the options\r\nthat are available to threat actors are as follows:\r\nhttps://thedfirreport.com/2022/01/24/cobalt-strike-a-defenders-guide-part-2/\r\nPage 11 of 25\n\nThe above table was taken from Cobalt Strike’s official documentation\r\nSMB Beacons\r\nAnother option for threat actors is to employ SMB beacons, once they have gained access to the network. SMB\r\nbeacons open a local port on the target host and listen for incoming communication from a parent beacon. The\r\ncommunication between the two beacons is possible thanks to named pipes.\r\nThe operators can configure the pipename on the client; however, the default pipename starts with “msagent_#”\r\nfor SMB beacons. For a list of default pipe names for other services including some custom profiles check out\r\n@svch0st’s post here.\r\nhttps://thedfirreport.com/2022/01/24/cobalt-strike-a-defenders-guide-part-2/\r\nPage 12 of 25\n\nSMB beacons are mostly used to make network detection harder and to get access to isolated systems where\r\ncommunication to the internet is prohibited. Additionally, due to SMB protocol being accessible in most internal\r\nnetworks, it makes for a reliable C2 method. Operators can also chain beacons and move laterally inside the\r\nnetwork.\r\nAccording to our records, SMB beacons are not frequently used. However, they’re still a powerful weapon in the\r\nhands of skilled operators. As we do not see SMB beacons used often in our intrusion cases, we took an example\r\ncase from our lab to demonstrate the effectiveness of this method.\r\nWe ran a PowerShell loader on the target host, which loaded a stageless SMB beacon in memory. In our case, the\r\nSMB Beacon is communicating over the network with a parent Beacon using named pipes. For this example, we\r\nchose the named pipe “my_pipes”.\r\nhttps://thedfirreport.com/2022/01/24/cobalt-strike-a-defenders-guide-part-2/\r\nPage 13 of 25\n\nAs you can see from the screenshots below, windows event 4688 contains the execution of the PowerShell\r\ncommand.\r\nAs explained in our previous Cobalt Strike article, Sysmon events 17 and 18 can log named pipes. However,\r\nSysmon should be explicitly configured to log named pipes. A good public Sysmon config that includes named\r\npipes and much more is Olaf‘s Sysmon Moduler.\r\nBelow, you can see the named pipe created that we specified on the Cobalt Strike interface when we created the\r\nSMB listener.\r\nhttps://thedfirreport.com/2022/01/24/cobalt-strike-a-defenders-guide-part-2/\r\nPage 14 of 25\n\nFurthermore, the SMB Beacon will communicate over port 445 to the main beacon as we described above, which\r\nwill then send the results to the C2 server. This is known as chaining beacons. The below screenshot illustrates the\r\nSMB communication between the beacon on the beachhead host and the chained beacon(s). Another way to\r\ndescribe the communication is a parent/child relationship.\r\nThe network traffic shows the target host communicating over SMB with the other compromised host running the\r\nparent HTTP Beacon. Named Pipes are used to facilitate the transition of data.\r\nhttps://thedfirreport.com/2022/01/24/cobalt-strike-a-defenders-guide-part-2/\r\nPage 15 of 25\n\n192.168.38.102 = SMB Beacon\r\n192.168.38.104 = HTTP Parent Beacon\r\nDetecting and Analyzing C2 Traffic\r\nThanks to free, open-source tooling, investigating network traffic has become more accessible. There are specific\r\ntools that we use to analyze suspicious network traffic in our intrusion cases. We believe that no single tool can\r\nprovide complete detection coverage, but we can get close by combining them. In the following section, we will\r\nlook at these tools that could accelerate analysis for defenders.\r\nSigma\r\nWe’ll go through a few Sigma rules that can help us detect Cobalt Strike’s network activity.\r\nCobalt Strike DNS Beaconing is a rule created by Florian Roth which looks at DNS logs to detect the default DNS\r\nC2 behavior based on the dns_stager_subhost, put_output and dns_stager_subhost as seen above.\r\nhttps://thedfirreport.com/2022/01/24/cobalt-strike-a-defenders-guide-part-2/\r\nPage 16 of 25\n\nBelow is a more generic rule created by @bareiss_patrick which is a good example of detecting suspicious DNS\r\ntraffic based on a high amount of queries for a single domain.\r\nhttps://thedfirreport.com/2022/01/24/cobalt-strike-a-defenders-guide-part-2/\r\nPage 17 of 25\n\nAnother more generic rule created by Daniil Yugoslavskiy uses dns logs to look for 50 or more TXT records from\r\na single source in one minute:\r\nDefault Cobalt Strike Certificate is a rule written by Bhabesh Raj that uses Zeek logs to detect the default Cobalt\r\nStrike certificate.\r\nhttps://thedfirreport.com/2022/01/24/cobalt-strike-a-defenders-guide-part-2/\r\nPage 18 of 25\n\nRDP over Reverse SSH Tunnel WFP by Samir Bousseaden is a rule that can look for suspicious RDP activity\r\nusing reverse tunneling.\r\nhttps://thedfirreport.com/2022/01/24/cobalt-strike-a-defenders-guide-part-2/\r\nPage 19 of 25\n\nCobaltStrike Malleable Amazon Browsing Traffic Profile by Markus Neis which looks at proxy logs for the\r\nAmazon Malleable profile.\r\nOther malleable profile rules include CobaltStrike Malformed UAs in Malleable Profiles, CobaltStrike Malleable\r\n(OCSP) Profile, and CobaltStrike Malleable OneDrive Browsing Traffic Profile.\r\nAll Sigma rules here are documented towards the bottom of Part 1.\r\nRita\r\nRita stands for Real Intelligence Threat Analytics (RITA), developed by Active Countermeasures. Rita is a\r\nframework for detecting command and control communication. It takes Zeek logs data and can, in our experience,\r\naccurately detect beaconing activity.\r\nOne of the great features of Rita is its ease of use and detailed output information in various forms, including CSV\r\nand HTML. One simply can point Rita to the Zeek logs and wait for the results. The more available data, the more\r\nprecise the results will be. Zeek logs can be generated from the PCAP(s).\r\nThe screenshot samples below show the results created by Rita based on the traffic we used in the previous\r\nsections to demonstrate the jquery malleable C2 profile.\r\nhttps://thedfirreport.com/2022/01/24/cobalt-strike-a-defenders-guide-part-2/\r\nPage 20 of 25\n\nWe left the Beacon running for an hour to simulate an actual infection while several other network-unrelated\r\nprocesses ran in the background. During this hour, we tasked the Beacon with carrying out several commands.\r\nRita determined that one hour of network data was adequate for identifying the beacon link and assigning it the\r\nhighest score. Although, the more data you have, the more accurate the results will be.\r\nBelow, we can see the results from one of our recent cases, BazarLoader and the Conti Leaks. The first three IP\r\naddresses relate to the CS servers with which the Beacon communicated.\r\nRita accurately identified beaconing activity related to Cobalt Strike C2 communication. Using Rita, we can\r\nidentify malicious C2 traffic based on multiple variables, including communication frequency, average bytes\r\nsent/received, number of connections etc. As a result, we can detect Cobalt Strike beaconing regardless of the\r\nmalleable C2 profile utilized or any additional jitter present.\r\nJA3/JA3S\r\nJA3 is an open-source project created by John Althouse, Jeff Atkinson and Josh Atkins. JA3/JA3S can create SSL\r\nfingerprints for communication between clients and servers. The unique signatures can represent several values\r\ncollected from fields in the Client Hello packet:\r\n- SSL Version\r\n- Accepted Ciphers\r\n- List of Extensions\r\n- Elliptic Curves\r\n- Elliptic Curve Formats\r\nFor more information on how JA3 works, you can visit the official GitHub repository here:\r\nhttps://github.com/salesforce/ja3.\r\nThe JA3 tool is used to generate a signature for the client-side beacon connection with the server. JA3S, on the\r\nother hand, is able to generate a server fingerprint. The combination of the two can produce the most accurate\r\nresult. JA3S can capture the full cryptographic communication and combine the JA3 findings to generate the\r\nsignature.\r\nThe downside of this method is that it can produce inaccurate results if the Cobalt Strike is behind redirectors.\r\nWe can find many reports that contain the JA3 value that corresponds to the Cobalt Strike fingerprint. When it\r\ncomes to Cobalt Strike infrastructure, the known JA3 and JA3s signatures that we are looking for are:\r\nhttps://thedfirreport.com/2022/01/24/cobalt-strike-a-defenders-guide-part-2/\r\nPage 21 of 25\n\nJA3\r\n72a589da586844d7f0818ce684948eea\r\na0e9f5d64349fb13191bc781f81f42e1\r\nJA3s\r\nb742b407517bac9536a77a7b0fee28e9\r\nae4edc6faf64d08308082ad26be60767\r\nBy using JA3/S signatures, we can discover various malware C2 servers and not just Cobalt Strike. Salesforce\r\nprovides a thorough collection of signatures that belong to many different applications here. Some other example\r\nsignatures with well known JA3 fingerprints are:\r\nTrickbot: 6734f37431670b3ab4292b8f60f29984\r\nfc54e0d16d9764783542f0146a98b300\r\nDridex: 51c64c77e60f3980eea90869b68c58a8\r\nJA3 of Python usually hosting Empire or PoshC2: db42e3017c8b6d160751ef3a04f695e7\r\nTOR client: e7d705a3286e19ea42f587b344ee6865\r\nAnother very good website to test the JA3 signature against a large database is ja3er.\r\nJARM\r\nSimilar to JA3/JA3S, JARM has the ability to fingerprint the TLS values of the remote server. It does this by\r\ninteracting with the target server sending 10 TLS Client Hello packets and recording the specific attributes from\r\nthe replies. It will then hash the result values and create the final JARM fingerprint.\r\nUnlike JA3/S, JARM is an active way of fingerprinting remote server applications. John Althouse has created a\r\nmedium post that accurately conveys the differences between JA3/S and JARM:\r\n“JARM actively scans the server and builds a fingerprint of the server application. Whereas JA3/S is passive, just\r\nlistening, not reaching out, JARM is active, actively probing the target. And is able to build a fingerprint of the\r\nserver application where JA3S could not.”\r\nAccording to research and further changes on the JAVA TLS version as mentioned below, the JARM fingerprint\r\nthat corresponds to a default configuration of the Cobalt Strike is:\r\n07d14d16d21d21d00042d41d00041de5fb3038104f457d92ba02e9311512c2\r\nCobalt Strike is dependent on Java to run both the client graphical user interface (GUI) and the team server. When\r\nwe scan a Cobalt Strike server using JARM, the results we get back are dependent on the Java version that is used.\r\nAccording to Cobalt Strike’s documentation, OpenJDK 11 is the preferred version that needs to be installed by the\r\noperators. This makes it easier to identify a potential Cobalt Strike server, however, defenders should be aware\r\nthat this outcome alone is prone to false positives. This is because many other legitimate servers on the internet\r\nuse this version of Java to operate their web applications.\r\nhttps://thedfirreport.com/2022/01/24/cobalt-strike-a-defenders-guide-part-2/\r\nPage 22 of 25\n\nOn , 2021 Java Disabled TLS 1.0 and TLS 1.1 in favor of TLS 1.2 or above. Following this change, the JARM\r\nfingerprint for Cobalt Strike servers changed:\r\nFrom: 07d14d16d21d21d07c42d41d00041d24a458a375eef0c576d23a7bab9a9fb1\r\nTo: 07d14d16d21d21d00042d41d00041de5fb3038104f457d92ba02e9311512c2\r\nThis change was highlighted by @bodziurity and @WLesicki in a collaborative effort:\r\nhttps://thedfirreport.com/2022/01/24/cobalt-strike-a-defenders-guide-part-2/\r\nPage 23 of 25\n\nCobalt Strike has a post dedicated to JARM that goes into detail on how JARM works and how the specific hash\r\nvalue is created based on the Java version.\r\nLooking into our reporting for this hash value will return four of our cases. All these cases involve Cobalt Strike\r\nas the post-exploitation method.\r\nTo generate a JARM fingerprint against a server, you can run the JARM python tool:\r\npython3 jarm.py [target] -p [port]\r\nWhile JARM’s offer another tool to help reveal adversary infrastructure they are not an indicator that can be used\r\nin isolation. JARM signatures can be masked, Dagmawi Mulugeta presented at HiTB Amsterdam in 2021 a tool\r\nthat enables red teams or adversaries to mask the JARM signatures of their infrastructure. Called JARM\r\nRandomizer the tool can be configured as a proxy in front of the Cobalt Strike server to serve up false data to\r\npotential internet scanners.\r\nOther JARMs can be found at: https://github.com/cedowens/C2-JARM.\r\nhttps://thedfirreport.com/2022/01/24/cobalt-strike-a-defenders-guide-part-2/\r\nPage 24 of 25\n\nAll for now\r\nThat wraps up Cobalt Strike, a Defender’s Guide Part 2. Would you like to see something specific in Part 3?\r\nContact us here or on Twitter with suggestions. Thanks for reading and hope this helps!\r\nPlease see the bottom of our first report for more detections \u0026 rules.\r\nSource: https://thedfirreport.com/2022/01/24/cobalt-strike-a-defenders-guide-part-2/\r\nhttps://thedfirreport.com/2022/01/24/cobalt-strike-a-defenders-guide-part-2/\r\nPage 25 of 25",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://thedfirreport.com/2022/01/24/cobalt-strike-a-defenders-guide-part-2/"
	],
	"report_names": [
		"cobalt-strike-a-defenders-guide-part-2"
	],
	"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": 1775433973,
	"ts_updated_at": 1775826747,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/56a1c4f26464cd35679bfed01d11b3dd39bbf402.pdf",
		"text": "https://archive.orkl.eu/56a1c4f26464cd35679bfed01d11b3dd39bbf402.txt",
		"img": "https://archive.orkl.eu/56a1c4f26464cd35679bfed01d11b3dd39bbf402.jpg"
	}
}