{ "id": "49a1ba27-cc16-4587-9bb5-7e8eebcf3019", "created_at": "2026-04-06T00:19:50.157033Z", "updated_at": "2026-04-10T03:37:32.475279Z", "deleted_at": null, "sha1_hash": "ec18bcac3caa1c3c0b007229755edf0e4031b2fb", "title": "Cobalt Strike | Defining Cobalt Strike Components \u0026 BEACON", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 2013099, "plain_text": "Cobalt Strike | Defining Cobalt Strike Components \u0026 BEACON\r\nBy Mandiant\r\nPublished: 2021-12-10 · Archived: 2026-04-05 13:13:36 UTC\r\nWritten by: Alyssa Rahman\r\nCobalt Strike is a commercial adversary simulation software that is marketed to red teams but is also stolen and\r\nactively used by a wide range of threat actors from ransomware operators to espionage-focused Advanced\r\nPersistent Threats (APTs). Many network defenders have seen Cobalt Strike payloads used in intrusions, but for\r\nthose who have not had the opportunity to use Cobalt Strike as an operator, it can be challenging to understand the\r\nmany components and features included in this framework.\r\nIn this blog post, we will walk through important definitions and concepts to help defenders understand Cobalt\r\nStrike and, hopefully, identify new ways to hunt for, respond to, and attribute malicious actors using this tool.\r\nThis content is informed by a combination of official documentation, public research, and Mandiant’s own\r\nexperience with both performing red team assessments and responding to intrusions where threat actors are using\r\nCobalt Strike. Because Cobalt Strike is used for both legitimate testing and for intrusions, in this post we will refer\r\nto all Cobalt Strike users, regardless of motivation, as \"operators\" for simplicity.\r\nWhile this blog post is focused on explaining Cobalt Strike and BEACON artifacts to aid defenders’ analysis, we\r\nhave also included references to several resources to learn more about Cobalt Strike and how to detect common\r\nBEACON activity at various stages of the attack lifecycle.\r\nImportant Components\r\nCobalt Strike, BEACON, Team Server. Oh My!\r\nYou may hear the names Cobalt Strike, BEACON, and even team server used interchangeably, but there are some\r\nimportant distinctions between all of them.\r\nCobalt Strike is the command and control (C2) application itself. This has two primary components: the team\r\nserver and the client. These are both contained in the same Java executable (JAR file) and the only difference is\r\nwhat arguments an operator uses to execute it.\r\nTeam server is the C2 server portion of Cobalt Strike. It can accept client connections, BEACON\r\ncallbacks, and general web requests.\r\nBy default, it accepts client connections on TCP port 50050.\r\nTeam server only supports being run on Linux systems.\r\nClient is how operators connect to a team server.\r\nClients can run on the same system as a Team server or connect remotely.\r\nhttps://www.mandiant.com/resources/defining-cobalt-strike-components\r\nPage 1 of 16\n\nClient can be run on Windows, macOS or Linux systems.\r\nBEACON is the name for Cobalt Strike’s default malware payload used to create a connection to the team server.\r\nActive callback sessions from a target are also called \"beacons\". (This is where the malware family got its name.)\r\nThere are two types of BEACON:\r\nThe Stager is an optional BEACON payload. Operators can \"stage\" their malware by sending an initial\r\nsmall BEACON shellcode payload that only does some basic checks and then queries the configured C2\r\nfor the fully featured backdoor.\r\nThe Full backdoor can either be executed through a BEACON stager, by a “loader” malware family, or by\r\ndirectly executing the default DLL export “ReflectiveLoader”. This backdoor runs in memory and can\r\nestablish a connection to the team server through several methods.\r\nLoaders are not BEACON. BEACON is the backdoor itself and is typically executed with some other loader,\r\nwhether it is the staged or full backdoor. Cobalt Strike does come with default loaders, but operators can also\r\ncreate their own using PowerShell, .NET, C++, GoLang, or really anything capable of running shellcode.\r\nIt’s All Connected\r\nListeners are the Cobalt Strike component that payloads, such as BEACON, use to connect to a team server.\r\nCobalt Strike supports several protocols and supports a wide range of modifications within each listener type.\r\nSome changes to a listener require a \"listener restart\" and generating a new payload. Some changes require a full\r\nteam server restart.\r\nHTTP/HTTPS is by far the most common listener type.\r\nWhile Cobalt Strike includes a default TLS certificate, this is well known to defenders and blocked\r\nby many enterprise products (“signatured”). Usually operators will generate valid certificates, such\r\nas with LetsEncrypt, for their C2 domains to blend in.\r\nThanks to Malleable Profiles (discussed later in the post), operators can heavily configure how the\r\nBEACON network traffic will look and can masquerade as legitimate HTTP connections.\r\nOperators can provide a list of domains/IPs when configuring a listener, and the team server will\r\naccept BEACON connections from all of them (see \"Redirectors\"). Operators can also specify Host\r\nheader values (see \"Domain Fronting\").\r\nDNS listeners establish sessions to their team server using DNS requests for domains the team server is\r\nauthoritative for. DNS listeners support two modes:\r\nHybrid (DNS+HTTP) is the default and uses DNS for a beacon channel and HTTP for a data\r\nchannel.\r\nPure DNS can also be enabled to use DNS for both beacon and data channels. This leverages\r\nregular A record requests to avoid using HTTPS and provide a stealthier, though slower method of\r\ncommunication.\r\nSMB is a bind style listener and is most often used for chaining beacons. Bind listeners open a local port\r\non a targeted system and wait for an incoming connection from an operator. See \"Important Concepts \u003e\r\nChaining Beacons\" for more information.\r\nhttps://www.mandiant.com/resources/defining-cobalt-strike-components\r\nPage 2 of 16\n\nRaw TCP is a (newer) bind style listener and can also be used for chaining beacons. See \"Important\r\nConcepts \u003e Chaining Beacons\" for more information.\r\nThe final two listeners are less common, but they provide compatibility with other payload types.\r\nForeign listeners allow connections from Metasploit’s Meterpreter backdoor to simplify passing sessions\r\nbetween the Metasploit framework and the Cobalt Strike framework.\r\nExternal C2 listeners provide a specification that operators can use to connect to a team server with a\r\nreverse TCP listener. Reverse listeners connect back and establish an external connection to an operator,\r\ninstead of waiting for an incoming connection such as with “bind” listeners.\r\nIt’s (Almost) All Customizable\r\nArsenal Kits are available for download, with a valid license, and for use with licensed (or cracked) installations\r\nonly. Arsenal kits are sometimes distributed with cracked copies of Cobalt Strike. The full list of kits (as of\r\nOctober 2021) is:\r\nApplet/PowerApplet Kit allows operators to modify Cobalt Strike’s built-in Java Applet payloads. This\r\nkit was the first to be added to Arsenal and is no longer widely used.\r\nArtifact Kit allows operators to modify the templates for all Cobalt Strike executables, DLLs, and\r\nshellcode. This kit was added in January 2014 and is still used.\r\nElevate Kit allows operators to integrate their privilege escalation exploits as Cobalt Strike commands.\r\nThis kit was released in December 2016. Unlike other kits, this is public, and it is essentially just an\r\nAggressor Script to streamline loading your own PowerShell scripts, binaries, etc. into a BEACON session\r\n(see “Aggressor Scripts”).\r\nMimikatz Kit allows operators to update their version of Mimikatz without waiting for a Cobalt Strike\r\nsoftware update. This kit was added in July 2021.\r\nResource Kit allows operators to modify the script templates Cobalt Strike uses (mostly as loaders). This\r\nkit was added in May 2017 and is still used.\r\nSleep Mask Kit allows operators to modify the in-memory obfuscation that BEACON uses to avoid\r\ndetection methods such as these. This kit was added in August 2021. For a walkthrough on how this kit can\r\nbe used to affect in-memory BEACON detection check out this blog post.\r\nUser Defined Reflective Loaders Kit allows operators to customize the reflective loader functionality\r\nused by BEACON. This kit was added in August 2021.\r\nMalleable Profile is the final part of Arsenal Kit, and it allows operators to extensively modify how their Cobalt\r\nStrike installation works. It is the most common way operators customize Cobalt Strike and has thus been heavily\r\ndocumented.\r\nChanges to a Malleable Profile require a team server restart and, depending on the change, may require re-generating payloads and re-spawning beacon sessions.\r\nThere are several robust open-source projects that generate randomized profiles which can make detection\r\nchallenging. Still, operators will often reuse profiles (or only slightly modify them) allowing for easier\r\ndetection and potentially attribution clustering.\r\nWhen analyzing samples, check GitHub and other public sources to see if the profile is open source.\r\nhttps://www.mandiant.com/resources/defining-cobalt-strike-components\r\nPage 3 of 16\n\nAggressor Scripts are macros that operators can write and load in their client to streamline their workflow. These\r\nare loaded and executed within the client context and don't create new BEACON functionality, so much as\r\nautomate existing commands. They are written in a Perl-based language called \"Sleep\" which Raphael Mudge (the\r\ncreator of Cobalt Strike) wrote. For an example, check out the \"An Operator's View\" section.\r\nAggressor scripts are only loaded into an operator's local Client. They are not loaded into other operators’ clients,\r\nthe team server, or BEACON sessions (victim hosts). The primary detection opportunity for these scripts is\r\nreviewing them for static defaults that can be used in detection or hunting rules.\r\nExecute-Assembly is a BEACON command that allows operators to run a .NET executable in memory on a\r\ntargeted host. BEACON runs these executables by spawning a temporary process and injecting the assembly into\r\nit. In contrast to Aggressor Scripts, execute-assembly does allow operators to extend BEACON functionality.\r\nAssemblies run in this way will still be scanned by Microsoft’s AMSI if it is enabled.\r\nBeacon Object Files (BOFs) are a fairly recent Cobalt Strike feature that allows operators to extend BEACON\r\npost-exploitation functionality. BOFs are compiled C programs that are executed in memory on a targeted host. In\r\ncontrast to Aggressor Scripts, BOFs are loaded within a BEACON session and can create new BEACON\r\ncapabilities. Additionally, compared to other BEACON post-exploitation commands like execute-assembly, BOFs\r\nare relatively stealthy as they run within a BEACON session and do not require a process creation or injection.\r\nAn Operator’s View\r\nFour of the aforementioned components—the Client, Aggressor Scripts, Beacon Object Files, and Malleable\r\nProfiles—are the primary ways operators interact with and customize their team server. An example of each is\r\nincluded here to show these components from an operator’s perspective.\r\nAn operator accessing a team server through the Cobalt Strike client would see a view like the following. The top\r\npane shows a list of active beacon sessions with basic metadata including the current user, process ID, internal and\r\nexternal IP addresses, and the last time the host checked in with the team server. The bottom pane includes a tab\r\nfor each session where operators can send commands to the victim hosts and see a log of past commands and\r\noutput. The client interface also allows operators to build payloads, execute plugins, and generate reports.\r\nhttps://www.mandiant.com/resources/defining-cobalt-strike-components\r\nPage 4 of 16\n\nFigure 1: Cobalt Strike 3.10 client view (source)\r\nWithin the client, operators can import Aggressor Scripts to customize their commands, menu options, and\r\ninterface. Aggressor Scripts vary in complexity, from adding a new menu shortcut to chaining multiple attack\r\nsteps. The following is an excerpt from credpocalypse.cna, an Aggressor Script that checks active beacon sessions\r\non a schedule and runs Mimikatz, an open-source credential dumper, if a new user logs in.\r\nNote that this is not adding functionality to Cobalt Strike. In this case, the script uses built-in BEACON\r\nfunctionality to list processes and execute Mimikatz, and it uses Cobalt Strike APIs to run on a schedule. That\r\nmeans existing detections for BEACON’s Mimikatz module will also detect this.\r\nhttps://www.mandiant.com/resources/defining-cobalt-strike-components\r\nPage 5 of 16\n\nBeacon Object Files are single file C programs that are run within a BEACON session. BOFs are expected to be\r\nsmall and run for a short time. Since BEACON sessions are single threaded, BOFs will block any other BEACON\r\ncommands while they are executing. The following is an example from the Cobalt Strike documentation that uses\r\nDynamic Function Resolution to look up the current domain.\r\nhttps://www.mandiant.com/resources/defining-cobalt-strike-components\r\nPage 6 of 16\n\nFinally, Malleable Profiles allow operators to customize a wide range of settings when they first launch their\r\nteam server. The snippet that follows from a public profile is an example of how an operator could make\r\nBEACON traffic look like it's related to Amazon. The portions in blue (the set uri line and the client block), define\r\nhow a BEACON payload behaves. Some of these values can be extracted from a BEACON sample. See\r\n“Interpreting Artifacts \u003e GET and POST Requests” for more information.\r\nImportant Concepts\r\nhttps://www.mandiant.com/resources/defining-cobalt-strike-components\r\nPage 7 of 16\n\nStagers\r\nEarlier, I mentioned there are \"two types of BEACON\", one of them being a stager. Operators can have stagers for\r\nmultiple listener types (e.g. a DNS stager, an SMB stager, an HTTPS stager). In those cases, when the stager\r\nshellcode is executed, it will pull the final BEACON payload over the relevant protocol and execute it,\r\nestablishing a connection using the defined listener method.\r\nAn important note for defenders is that, by default, defenders can download a Cobalt Strike HTTP/S stager\r\npayload from a team server even if the operator is not using staged payloads in their operations. This will allow\r\ndefenders to 1. confirm something is hosting a team server with a listener on that port and 2. extract additional\r\nconfiguration artifacts from the payload.\r\nThis works because Cobalt Strike was designed to be compatible with Metasploit's Meterpreter payload.\r\nMetasploit (and thus Cobalt Strike) will serve an HTTPS stager when a valid URL request is received. A valid\r\nURL is any 4-character alphanumeric value with a valid 8 bit checksum calculated by adding the ASCII values of\r\nthe 4 characters.\r\nOperators can prevent defenders from retrieving stagers by setting the host_stage Malleable Profile value to\r\n\"false\". More commonly, they may use reverse proxies to filter out unwanted traffic like stager requests. As a\r\nprotection feature, Cobalt Strike will ignore web requests with blacklisted User-Agents, such as curl or wget.\r\nStarting in Cobalt Strike 4.4, operators can also whitelist user agents with the .http-config.allow_useragents\r\nMalleable Profile option. These caveats are important to remember, since a team server may not always function\r\nas expected by scanners that automate stager requests.\r\nAs an operational security note, operators can also detect any web request to a team server, as it will be visible to\r\nthe operator in their logs. They will also be able to see in the \"Web Log\" view if a stager has been pulled, along\r\nwith all HTTP request details like source IP.\r\nTrial vs Licensed vs Cracked\r\nCobalt Strike is not legitimately freely available. Copies of the team server/client cannot be downloaded as a trial\r\nor licensed copy from Help Systems—the company that owns Cobalt Strike—unless the operator applies and has\r\nbeen approved. Unfortunately, trials and cracked copies (including most, if not all, licensed features) have been\r\nand continue to be leaked and distributed publicly for nearly all recent versions.\r\nTrial versions of Cobalt Strike are heavily signatured and include lots of obvious defaults intended to be\r\ncaught in a production environment. (For example, it embeds the EICAR string in all payloads.) This is to\r\nensure that the operator is really using it as a trial and will eventually pay if using it for professional\r\npurposes.\r\nLicensed versions of Cobalt Strike include more features (e.g. Arsenal Kits) and fewer embedded artifacts\r\n(no more EICAR!). A watermark related to the associated Cobalt Strike license is still embedded in\r\npayloads and can be extracted using most BEACON configuration parsers. There are a lot of caveats with\r\nthat value, so please see \"Interpreting Artifacts \u003e Watermarks\" later in the post.\r\nLicenses can be stolen, however if a license is revoked operators will no longer be able to use it to\r\nupdate an installation. If operators keep the \"authorization file\" (See \"Interpreting Artifacts \u003e\r\nhttps://www.mandiant.com/resources/defining-cobalt-strike-components\r\nPage 8 of 16\n\nWatermarks\"), the existing installation will still work until expiration.\r\nCracked versions of Cobalt Strike are distributed in various forums. Typically, these are the result of\r\nsomeone modifying a trial JAR file to bypass the license check and rebuilding the JAR, or by crafting an\r\nauthorization file with a fake license ID and distributing that with the JAR.\r\nDifferentiating cracked versions of Cobalt Strike from legitimately licensed versions can be difficult. If the\r\nwatermark was statically defined as part of the cracking process, it may be possible to tie that to a\r\nshared/distributed copy. Some cracked copies of Cobalt Strike also contain backdoors to provide third-party\r\naccess to a team server. In these cases, malware analysts may be able to identify illegitimate copies through static\r\nanalysis.\r\nRedirectors\r\nInstead of having beacons connect directly to a team server, operators will sometimes use a redirector (or several)\r\nthat accepts connections and forwards them to the team server. This has several advantages for operators,\r\nincluding being able to:\r\nCycle through multiple domains for a single BEACON connection\r\nReplace detected/blocked redirectors without having to replace the underlying team server\r\nUse high(er) reputation domains that help BEACON traffic blend in and avoid detection\r\nOperators can also use redirectors to filter out \"suspicious\" traffic, like scanners or hunting tools, to protect their\r\nteam server, however there are typically still easy wins to track down team servers and redirectors. See the\r\n\"Hunting for Team Servers\" section for more details.\r\nWhat About Domain Fronting?\r\nSometimes \"redirectors\" are as simple as a cloud instance with an nginx proxy, but another highly effective\r\nredirector method is \"domain fronting\". Domain fronting is a technique by which an operator may hide the true\r\ndestination of a network connection by redirecting it through the infrastructure of a Content Delivery Network\r\n(CDN). The technique was first documented as a means of bypassing internet censorship and has also been used\r\nby threat actors, such as APT 29, to disguise C2 traffic.\r\nWhen an HTTPS request is fronted, the connection is established directly with a reputable domain hosted by the\r\nCDN. This is the “fronted” domain. The encrypted request will contain a unique identifier, often contained in the\r\nHTTP “Host” header, that the CDN uses to route the request to an operator-controlled server. Because domain\r\nfronted traffic is initially sent to the CDN, it will use the legitimate SSL/TLS certificate of the CDN when\r\nobserved by a defender.\r\nhttps://www.mandiant.com/resources/defining-cobalt-strike-components\r\nPage 9 of 16\n\nFigure 2: Domain fronted C2 connection (source)\r\nIn this situation, to block traffic to the operator’s domain, a defender would need to decrypt the traffic to discover\r\nthe true destination within an HTTPS connection, but this is not always practical. In addition to being resource\r\nintensive, decrypting the traffic for some CDNs may not be possible. For example, some CDNs enforce certificate\r\npinning on their SSL/TLS certificates, to prevent interception and decryption of the traffic using an organization-provided trusted root certificate.\r\nDomain Fronting vs Masquerading\r\nMasqueraded traffic is designed to look like a legitimate service but is actually a direct connection to an\r\noperator’s server, while fronted traffic is sent to a legitimate service (CDN) and forwarded from there to the\r\noperator.\r\nIf the Host header value and destination domain are the same, this is just a normal, direct HTTP connection.\r\nIf the Host header and destination domain are different and the Host header is\r\nA legitimate domain (e.g. in the Alexa Top 1M), then it is likely domain masquerading\r\nA domain used for CDN endpoints (e.g. *.azureedge.net), then it may be domain fronting.\r\nThere are multiple public guides to test if a domain is frontable. This repo also includes a pre-compiled list of\r\nfrontable domains by CDN provider. Please note, public lists may be out of date and manual validation will likely\r\nstill be necessary.\r\nChaining Beacons\r\nAnother way operators can establish connections is by chaining beacons. Once an operator has a single\r\ncompromised system, for example beaconing back to an HTTPS listener, they can pivot internally to other\r\nhttps://www.mandiant.com/resources/defining-cobalt-strike-components\r\nPage 10 of 16\n\nsystems.\r\nThe most common reason an operator will chain beacons is to bypass network segmentation and restrictions. If\r\nthey target a server that doesn't have outbound internet access, they can proxy their connection through another\r\nbeacon with network connectivity to the targeted system and receive the callback on their team server. If the\r\noperator loses access to the parent system, they will also lose access to chained beacons.\r\nSMB listeners and SMB staged beacons were the original method for chaining. Cobalt Strike now also supports a\r\nraw TCP listener. In environments where the SMB stager is detected (increasingly common for Endpoint\r\nDetection and Response products), an operator can use a raw TCP chain over port 445. This will allow them to\r\nstill leverage the fact that SMB is rarely blocked between internal hosts but avoid using the more heavily\r\nsignatured SMB listener.\r\nIn the screenshot from the \"An Operator's View\" section, the first session’s external IP matches the internal IP for\r\nsession 2. This indicates it is being chained through the second session. A double infinity/chain icon next to the IP\r\nalso shows that it is chained. If the system loses connection to its parent host, that chain icon will be disconnected.\r\nThe following screenshot shows the “Pivot Graph” view from a Cobalt Strike client. In this graphic, each\r\nBEACON is represented by a computer icon. Chained sessions are identified by arrows to their child sessions, and\r\nthe firewall icon represents an external connection to the operator’s C2.\r\nFigure 3: Client \"graph view\" of chained BEACONs (source)\r\nIf responding to an intrusion with SMB or TCP staged BEACON payloads, look for other compromised hosts\r\nstarting with the IP addresses configured as the “C2” for the staged payloads.\r\nHunting for Team Servers\r\nMandiant’s Advanced Practices team regularly scans the internet for C2s, including Cobalt Strike team servers. If\r\nan operator does not properly protect their team server, analysts can identify malicious infrastructure without prior\r\nhttps://www.mandiant.com/resources/defining-cobalt-strike-components\r\nPage 11 of 16\n\nknowledge of if or where it is being used and provide advanced warning and coverage for customers. For more\r\ndetails on how we identify C2s like Cobalt Strike, check out our blog post, “SCANdalous! (External Detection\r\nUsing Network Scan Data and Automation).”\r\nInterpreting Artifacts\r\nTeam Server and Client Logs\r\nCobalt Strike logs are invaluable for understanding the activities conducted using a team server. Defenders may\r\nnot frequently have access to this log data, but in the event that logs are available, it is useful to understand what\r\ndata can be extracted from them.\r\nCobalt Strike stores logs in two primary formats: full, plaintext beacon logs and Java serialized bins. These are\r\nstored in the team server working directory and duplicated in client working directories when a client is connected\r\nto a team server. They are also updated when items change, such as new credentials being captured.\r\nThe cobaltstrike/logs/ directory includes a directory structure of the format [date]/[internal ip of beaconed\r\nhost]/[beacon id].log. Each file is a plaintext log of every beacon command and the associated output. This\r\nmirrors what an operator would see in the Cobalt Strike beacon console.\r\nThe cobaltstrike/screenshots/ and cobaltstrike/downloads/ folders each respectively contain all screenshots or\r\nfiles an operator has downloaded from beacons.\r\nAn individual operator/client working directory will only contain downloads which that operator\r\nsynchronized to their local system, and these could be from multiple team server connections.\r\nA team server working directory, will contain screenshots/downloads from any operator on that team\r\nserver. \r\nUnder each cobaltstrike/logs/[date] directory, there is also an events.log and a web.log file.\r\nEvents.log is a mirror of the \"events\" console for the team server which, at a minimum, will include the\r\ndate/time of each operator connecting to the server and each initial beacon callback.\r\nWeb.log will show a log of every web request to the team server, including requests for staged payloads or\r\nteam server-hosted files.\r\nFiles hosted on a team server and served through the Web feature of Cobalt Strike are saved in\r\nthe cobaltstrike/uploads/ directory. An individual operator/client working directory, will only contain files which\r\nthat operator uploaded.\r\nThe cobaltstrike/data directory includes several .bin files which are serialized Java objects of different data\r\nmodels used by Cobalt Strike to track its state. The data from Cobalt Strike serialized .bin logs can be extracted as\r\nCSVs using this script.\r\nFor most analysts, sessions.bin, listeners.bin, and credentials.bin will be of the highest interest. The .bin logs\r\ncontain the most concentrated and simple to parse data for identifying which systems and users were\r\ncompromised using a given team server.\r\nhttps://www.mandiant.com/resources/defining-cobalt-strike-components\r\nPage 12 of 16\n\nSessions.bin lists all active and historical beacon sessions from the given team server along with some\r\nbasic metadata (e.g. user, internal and external IP, hostname, architecture). \r\nListeners.bin details all active listeners for the given team server.\r\nCredentials.bin includes any credentials (cleartext, hashed, etc.) that were either automatically dumped\r\nwith a built-in credential module (such as Mimikatz) or manually added (such as after cracking a password\r\noffline). \r\nWatermarks\r\nCobalt Strike watermarks are a unique value generated from and tied to a given \"CobaltStrike.auth\" file. This\r\nvalue is embedded as the last 4 bytes for all BEACON stagers and in the embedded configuration for full\r\nbackdoor BEACON samples.\r\nThe CobaltStrike.auth file is a config file used by Cobalt Strike to determine license ID and expiration. When\r\nlaunched, Cobalt Strike will check that the license is valid and unexpired. The CobaltStrike.auth file is required to\r\nlaunch modern versions of Cobalt Strike, and it is updated when updating Cobalt Strike and when entering a\r\nlicense (whether for the first time or as a re-entry).\r\nThe CobaltStrike.auth file is a config file used by Cobalt Strike to determine license ID and expiration. When\r\nlaunched, Cobalt Strike will check that the license is valid and unexpired. The CobaltStrike.auth file is required to\r\nlaunch modern versions of Cobalt Strike, and it is updated when updating Cobalt Strike and when entering a\r\nlicense (whether for the first time or as a re-entry).\r\nA matching watermark means that two payloads came from a team server(s) using the same CobaltStrike.auth\r\nfile. This does not necessarily mean it came from the same operator. Someone can copy the whole Cobalt Strike\r\ndirectory, including the auth file, and install it on another server which would then have the same watermark until\r\nthe license expired.\r\nPublic Keys\r\nCobalt Strike uses 4 different types of keystores:\r\nListeners can have custom keystores specified in Malleable Profiles.\r\nCode signing can be configured with custom keystores specified in Malleable Profiles.\r\nClient Connections use the cobaltstrike.store file to encrypt client communications.\r\nBeacon Connections use a team server generated keystore to encrypt BEACON data and handle other\r\nsecurity features.\r\nThe BEACON keys and other security features are discussed in the Raphael Mudge’s training “Advanced Threat\r\nTactics: Infrastructure”. These keys are only used in the full BEACON backdoor, not stagers. As identified by\r\nNCCGroup, these keys are stored in a serialized file called “.cobaltstrike.beacon_keys” in the team server working\r\ndirectory.\r\nA matching public key means that two payloads came from a team server(s) using the same\r\n.cobaltstrike.beacon_keys keystore. This does NOT NECESSARILY mean it came from the same team server.\r\nhttps://www.mandiant.com/resources/defining-cobalt-strike-components\r\nPage 13 of 16\n\nAgain, someone could copy the whole Cobalt Strike directory, including the keystore, as is sometimes done with\r\ndistributed or cracked copies.\r\nC2 IPs and URLs\r\nBEACON parsers will also typically extract C2 IPs, domains, and URLs from samples. Some of these may be\r\nlegitimate domains, for example if the operator is using domain fronting or masquerading.\r\nThere are some gotchas to be aware of when attempting to cluster BEACON activity for attribution purposes. For\r\nexample, the following cases do not necessarily mean you're looking at different team servers.\r\nTwo samples connect to different IPs - This could be the result of changing redirectors or multiple\r\ndomains/hosts being defined in a listener. \r\nTwo samples refer to different URL paths - Operators can specify multiple URL paths when defining\r\nMalleable Profiles. Each time an operator generates BEACON shellcode, Cobalt Strike will select a\r\nrandom value from this list. If two samples have different URLs, it's possible they are still referring to the\r\nsame server. \r\nGET and POST Requests\r\nBEACON configurations may include custom HTTP headers, Cookies, etc. for HTTP GET and POST requests.\r\nThose fields are representations of how an operator has configured their team server (using Malleable Profile or\r\ndefault values) to construct and disguise the BEACON network traffic. This is not a direct 1-to-1 for what will be\r\nin a payload. Malleable Profiles accept multiple values for several fields, and only one of them may appear in a\r\ngiven payload. If the GET or POST requests don't match exactly, that is not necessarily an indication that it's from\r\na different server.\r\nSpawn To\r\nEach BEACON payload will be configured with two “spawn to” processes, one for 32-bit tasks and one for 64-bit\r\ntasks. These values are what BEACON will spawn as temporary processes for various post-exploitation\r\ncommands. BEACON launches the process, injects into it (with whatever technique the operator has specified),\r\nexecutes the post-exploitation task, and terminates the process. As an example of what commands this may affect,\r\ncheck out this older guide: Opsec Considerations for Beacon Commands. The default spawn to process is\r\nrundll32.exe, but this can be modified in two ways. \r\nMalleable Profile allows operators to modify the default spawn_to processes (if using a licensed or\r\ncracked version). Changing these values will require restarting the team server and regenerating new\r\nBEACON payloads to use the new values. \r\nClient allows operators to interactively modify the spawn_to processes once a BEACON session is\r\nestablished. These can be changed as many times as desired and don't require a restart, although it will only\r\naffect the current BEACON session. \r\nNamed Pipes\r\nhttps://www.mandiant.com/resources/defining-cobalt-strike-components\r\nPage 14 of 16\n\nNamed pipes are a Windows feature used for interprocess communication (IPC). Cobalt Strike uses named pipes\r\nin several ways:\r\nPayloads - Used to load the backdoor into memory and are modifiable via Malleable profile and/or Artifact\r\nKit. \r\nPost-exploitation Jobs - Used for a variety of Cobalt Strike commands that need to spawn and inject into a\r\nprocess. \r\nStaging - Used for SSH/SMB BEACON staging and chaining\r\nRaphael Mudge's post, “Learn Pipe Fitting for all of your Offense Projects,“ has some helpful additional details on\r\nthis feature. \r\nSleep Time\r\nThe \"sleeptime\" value in a BEACON configuration is the base time used for callback intervals. BEACON will\r\nrandomize callbacks within a range determined by the \"jitter\" percentage. For example, a sleeptime of 10 seconds\r\nand a jitter of 50%, will produce callbacks every 5 to 15 seconds. This value is not constant to make network\r\ndetection more challenging.\r\nIn Malleable Profile, operators can specify a sleeptime in milliseconds. After a session is created, operators can\r\ninteractively change the sleeptime and jitter values, but both must be integers and sleeptime must be defined\r\nin seconds. \r\nKill Date\r\nThe “killdate” value in a BEACON sample dictates whether it should connect to a team server after a given date.\r\nThis is used by red team operators to ensure payloads are not accidentally executed after an engagement is\r\ncomplete. It can also be used by threat actors to limit successful sandbox execution and frustrate retroactive\r\nanalysis efforts.\r\nThis value is defined by a command line argument when the team server is started, and it is not modifiable\r\nthrough Malleable Profile or interactive BEACON commands. By default, no killdate is specified.\r\nConclusion\r\nCobalt Strike continues to be the C2 framework of choice for both legitimate security testers and threat actors\r\nalike. Our hope is that with a more thorough understanding of the framework’s capabilities and common usage,\r\ndefenders will be more equipped to find new ways to hunt, respond to, and attribute malicious actors using this\r\ntool.\r\nReferences\r\nDetection Guides\r\nCobalt Strike, a Defender’s Guide (DFIR Report)\r\nFull-Spectrum Cobalt Strike Detection (Recorded Future)\r\nhttps://www.mandiant.com/resources/defining-cobalt-strike-components\r\nPage 15 of 16\n\nDetecting Cobalt Strike with memory signatures (Elastic)\r\nAnalysis Resources\r\nOpen-source Cobalt Strike Parser (Sentinel One)\r\nStrike Back at Retired Cobalt Strike (NCCGroup)\r\nUnderstanding Cobalt Strike Profiles (ZeroSec)\r\nDeep Dive into Malleable C2 (Specter Ops)\r\nWalkthroughs and Examples\r\nThe creator of Cobalt Strike, Raphael Mudge, created a nine-part YouTube course, Red Team Ops with Cobalt\r\nStrike, showing how to use Cobalt Strike. This is worth watching to see what the product looks like and how to\r\nuse the various features discussed in this blog post (+ some).\r\nCobalt Strike Documentation (Raphael Mudge + Help Systems)\r\nMalleable Profile Examples (Raphael Mudge)\r\nCommunity Kit (Assorted) – A “central repository of extensions … to extend … Cobalt Strike”\r\nSleeping with a Mask On (Adam Svoboda)\r\nDomain Fronting Lists (Vincent Yiu)\r\nAcknowledgements\r\nSpecial thanks to Tyler Dean, Jae Young Kim, Matthew Dunwoody, and Chris King for their technical expertise\r\nand review.\r\nPosted in\r\nThreat Intelligence\r\nSource: https://www.mandiant.com/resources/defining-cobalt-strike-components\r\nhttps://www.mandiant.com/resources/defining-cobalt-strike-components\r\nPage 16 of 16", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://www.mandiant.com/resources/defining-cobalt-strike-components" ], "report_names": [ "defining-cobalt-strike-components" ], "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 }, { "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": 1775434790, "ts_updated_at": 1775792252, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/ec18bcac3caa1c3c0b007229755edf0e4031b2fb.pdf", "text": "https://archive.orkl.eu/ec18bcac3caa1c3c0b007229755edf0e4031b2fb.txt", "img": "https://archive.orkl.eu/ec18bcac3caa1c3c0b007229755edf0e4031b2fb.jpg" } }