{
	"id": "3026a9b8-dd69-4bb2-a855-69cc4383e847",
	"created_at": "2026-04-06T00:10:13.176009Z",
	"updated_at": "2026-04-10T03:37:33.14113Z",
	"deleted_at": null,
	"sha1_hash": "bec23043f910b07042da964611d7d0770857c907",
	"title": "How to Detect Cobalt Strike",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 9219911,
	"plain_text": "How to Detect Cobalt Strike\r\nBy Ryan Robinson\r\nPublished: 2021-08-18 · Archived: 2026-04-05 19:06:07 UTC\r\nCobalt Strike is a penetration testing tool created by Raphael Mudge in 2012. To this day, it remains extremely\r\npopular both in red team activities and for malicious purposes by threat actors. Cobalt Strike is popular due to its\r\nrange of deployment options, ease of use, ability to avoid detection by security products, and the number of\r\ncapabilities it has.\r\nIt is for these reasons that threat actors also like Cobalt Strike. Since Cobalt Strike is widely used by a range of\r\nactors, this lack of exclusivity makes attribution harder. Companies still struggle to detect Cobalt Strike also due\r\nto the various defensive techniques it has.\r\nThis blog explains Cobalt Strike and practical steps to take if you believe that you are being targeted by Cobalt\r\nStrike or already compromised. We will demonstrate some real world examples of Cobalt Strike delivery and steps\r\nto detect each.\r\nWhat is Cobalt Strike?\r\nCobalt Strike is marketed as “Software for Adversary Simulations and Red Team Operations.”\r\nIt is a popular platform that allows users to emulate advanced threats, perform reconnaissance, hide\r\ncommunications, escalate privileges, move laterally across the network, and deploy additional payloads. The main\r\npayload of Cobalt Strike is called “Beacon.” The Beacon payload is used to model advanced APT malware, and\r\ncan do the following:\r\nReceive commands (either passively or from an interactive console)\r\nEgress communications over HTTP, HTTPS, and DNS\r\nLaunch PowerShell\r\nExecute binaries\r\nModify and query the Windows registry\r\nInject malicious code into legitimate processes\r\nLog keystrokes\r\nTake screenshots\r\nSet up proxies\r\nEscalate privileges\r\nBypass UAC\r\nDump password hashes\r\nScan ports among other abilities\r\nThis tool is mainly used in red team operations for government agencies and private enterprises, but it’s also a\r\npopular tool leveraged by cybercrime and APT groups in cracked versions. It is evident why Cobalt Strike is used\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 1 of 67\n\nby organizations and threat actors alike because of the extensive suite of capabilities it possesses, and also due to\r\nits ability to bypass defenses. It also comes with the feature to generate reporting in which the attacking team or\r\nthreat actor can continuously study and improve their campaigns.\r\nWhy is it difficult to detect Cobalt Strike?\r\nCobalt Strike is difficult to detect because of its several defense techniques. Cobalt Strike payloads are usually\r\nshellcode encrypted with a rolling XOR key. This makes static analysis difficult to conduct. This, combined with\r\nthe ability to configure many parts of the payload, makes hash-based detection almost impossible. Cobalt Strike\r\nstagers are designed to be loaded and executed only in-memory. This opens up a ton of possibilities for how this\r\nshellcode is shipped, making signature-based detection on the delivery method a cat and mouse game. Depending\r\non how the code is delivered, the code can be injected into other legitimate running processes, bypassing defenses\r\nthat do not scan legitimate processes or code in-memory.\r\nHow has Cobalt Strike been deployed?\r\nCobalt Strike has many different ways for deployment. This flexibility has helped attackers find many\r\nunconventional and creative ways to infect victims with a payload. For an in-depth technical analysis of Cobalt\r\nStrike’s deployment options and how they differ, check out Avast’s blog or this Cisco Talos white paper. Let’s take\r\na look at some real world examples of how Cobalt Strike is being used in the wild. We will cover the following:\r\nMacro-Laden Microsoft Office files\r\nSupply Chain Attack\r\nLiving off the Land (LotL)\r\nExecutables (EXE) files\r\nMacro-Laden Microsoft Office Files Detection\r\nAn example of a Cobalt Strike payload being delivered to victims via Microsoft Excel spreadsheets demonstrates\r\nthat this tool is also used in mass phishing campaigns, not just targeted APT attacks. The attack starts by sending\r\npotential victims a Microsoft OneDrive link from which an Excel (.xls) file is downloaded.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 2 of 67\n\nThe “IoCs” tab in Intezer Analyze shows indicators that can help you pivot and search in your environment during\r\ninvestigations to map out the scope of an attack. IoCs provide you with file hashes and network indicators such as\r\nURLs, and IP addresses being contacted through irregular ports.\r\nIoCs tab showing file and network indicators\r\nThe “Behavior” tab shows a more in-depth analysis of the file’s behavior, where you can see the process tree,\r\nnetwork activity, screenshots and file/registry activity.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 3 of 67\n\nBehavior tab showing observed behavior during sandbox execution\r\nThe Only Abused Pen Testing Tool?\r\nCobalt Strike is not the only penetration testing or legitimate tool that has been co-opted and abused by threat\r\nactors. In the past, tools such as Pafish (Paranoid Fish) have been used by Iranian actors in their tooling for virtual\r\nmachine (VM) detection. The “Sysinternals” suite has been used extensively by threat actors. Most notably,\r\nPsExec has been used in high-profile attacks such as the 2017 NotPetya global ransomware outbreak.\r\nMore recently, legitimate and penetration testing tools for the cloud have been used by threat actors. The threat\r\nactor TeamTNT has used Weave Scope, a trusted tool which gives the user full access to their cloud environment,\r\nand is integrated with Docker, Kubernetes, the Distributed Cloud Operating System (DC/OS), and AWS Elastic\r\nCompute Cloud (EC2). The attacker installs this tool in order to map the cloud environment of their victim and\r\nexecute system commands without needing to deploy malicious code on the server. The same group has also been\r\ndocumented using the penetration testing tool Break Out The Box (BOTB) for cloud and containerized\r\nenvironments.\r\nGet Started for Free\r\nWith Intezer Analyze, you can analyze any suspicious files that you encounter, including non-executable files such\r\nas Microsoft Office documents, scripts, archives, and more. Stay on top of analyzing and classifying Cobalt Strike\r\nand other threats. Get started for free and start with 50 file uploads per month.\r\nThe document drops and executes Cobalt Strike in the memory space of “rundll32.exe.” Signatures are leveraged\r\nto show capabilities and file characteristics. Under the “TTPs” tab the user can see the techniques/capabilities\r\nemployed by the malicious document.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 4 of 67\n\nTTPs section showing capabilities detected during execution\r\nThe document displays interesting techniques such as macros with auto-execution, network activity with a unique\r\nuser agent, office process starting martian subprocess, and process injection. You can also dive deeper into\r\ncapabilities specific to the injected Cobalt Strike process.\r\nThe “IoCs” tab in Intezer Analyze shows indicators that can help you pivot and search in your environment during\r\ninvestigations to map out the scope of an attack. IoCs provide you with file hashes and network indicators such as\r\nURLs, and IP addresses being contacted through irregular ports.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 5 of 67\n\nIoCs tab showing file and network indicators\r\nThe “Behavior” tab shows a more in-depth analysis of the file’s behavior, where you can see the process tree,\r\nnetwork activity, screenshots and file/registry activity.\r\nBehavior tab showing observed behavior during sandbox execution\r\nThe Only Abused Pen Testing Tool?\r\nCobalt Strike is not the only penetration testing or legitimate tool that has been co-opted and abused by threat\r\nactors. In the past, tools such as Pafish (Paranoid Fish) have been used by Iranian actors in their tooling for virtual\r\nmachine (VM) detection. The “Sysinternals” suite has been used extensively by threat actors. Most notably,\r\nPsExec has been used in high-profile attacks such as the 2017 NotPetya global ransomware outbreak.\r\nMore recently, legitimate and penetration testing tools for the cloud have been used by threat actors. The threat\r\nactor TeamTNT has used Weave Scope, a trusted tool which gives the user full access to their cloud environment,\r\nand is integrated with Docker, Kubernetes, the Distributed Cloud Operating System (DC/OS), and AWS Elastic\r\nCompute Cloud (EC2). The attacker installs this tool in order to map the cloud environment of their victim and\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 6 of 67\n\nexecute system commands without needing to deploy malicious code on the server. The same group has also been\r\ndocumented using the penetration testing tool Break Out The Box (BOTB) for cloud and containerized\r\nenvironments.\r\nGet Started for Free\r\nWith Intezer Analyze, you can analyze any suspicious files that you encounter, including non-executable files such\r\nas Microsoft Office documents, scripts, archives, and more. Stay on top of analyzing and classifying Cobalt Strike\r\nand other threats. Get started for free and start with 50 file uploads per month.\r\nAPI Hashing algorithms employed by Cobalt Strike hide imports from static analysis techniques. Signature-based\r\ndetection is great for detecting malware, but due to the versatility of Cobalt Strike’s deployment using multiple\r\nstages and encrypted/obfuscated payloads, an analyst may only be able to detect that a file is going to load and\r\nexecute a payload in-memory. Without dynamic analysis, they won’t be able to detect exactly what that payload\r\nwill be.\r\nDynamic Analysis\r\nDynamic analysis is the process of executing the suspect file in order to analyze its behavior and how it affects the\r\nenvironment it runs in. Dynamic analysis can open up new areas to explore as one can follow the malware through\r\neach stage of its deployment and functionality. Dynamic analysis can get the malware to unpack, decode, or\r\ndownload additional stages. These new stages are then subject to further dynamic analysis as well as the\r\npreviously mentioned static analysis techniques.\r\nDynamic analysis does not have many limitations, although some malware includes functionality to detect if it is\r\nbeing observed or running inside a sandboxed environment. There is also the possibility that during dynamic\r\nanalysis, areas of malicious code may not be intentionally executed, and thus not detected in the behavior. The\r\nbest way to detect malicious code is via genetic code analysis which is done automatically for you in Intezer\r\nAnalyze.\r\nCombination of Several Techniques\r\nThe best way to detect Cobalt Strike code is through a combination of dynamic, static, and genetic analysis. Let’s\r\ntake a suspicious looking document from an unknown entity as an example. Before opening the document, we\r\nsubmit it to Intezer Analyze and get the verdict, as shown below.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 7 of 67\n\nIntezer Analyze result showing in-memory Cobalt Strike code\r\nThe document drops and executes Cobalt Strike in the memory space of “rundll32.exe.” Signatures are leveraged\r\nto show capabilities and file characteristics. Under the “TTPs” tab the user can see the techniques/capabilities\r\nemployed by the malicious document.\r\nTTPs section showing capabilities detected during execution\r\nThe document displays interesting techniques such as macros with auto-execution, network activity with a unique\r\nuser agent, office process starting martian subprocess, and process injection. You can also dive deeper into\r\ncapabilities specific to the injected Cobalt Strike process.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 8 of 67\n\nThe “IoCs” tab in Intezer Analyze shows indicators that can help you pivot and search in your environment during\r\ninvestigations to map out the scope of an attack. IoCs provide you with file hashes and network indicators such as\r\nURLs, and IP addresses being contacted through irregular ports.\r\nIoCs tab showing file and network indicators\r\nThe “Behavior” tab shows a more in-depth analysis of the file’s behavior, where you can see the process tree,\r\nnetwork activity, screenshots and file/registry activity.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 9 of 67\n\nBehavior tab showing observed behavior during sandbox execution\r\nThe Only Abused Pen Testing Tool?\r\nCobalt Strike is not the only penetration testing or legitimate tool that has been co-opted and abused by threat\r\nactors. In the past, tools such as Pafish (Paranoid Fish) have been used by Iranian actors in their tooling for virtual\r\nmachine (VM) detection. The “Sysinternals” suite has been used extensively by threat actors. Most notably,\r\nPsExec has been used in high-profile attacks such as the 2017 NotPetya global ransomware outbreak.\r\nMore recently, legitimate and penetration testing tools for the cloud have been used by threat actors. The threat\r\nactor TeamTNT has used Weave Scope, a trusted tool which gives the user full access to their cloud environment,\r\nand is integrated with Docker, Kubernetes, the Distributed Cloud Operating System (DC/OS), and AWS Elastic\r\nCompute Cloud (EC2). The attacker installs this tool in order to map the cloud environment of their victim and\r\nexecute system commands without needing to deploy malicious code on the server. The same group has also been\r\ndocumented using the penetration testing tool Break Out The Box (BOTB) for cloud and containerized\r\nenvironments.\r\nGet Started for Free\r\nWith Intezer Analyze, you can analyze any suspicious files that you encounter, including non-executable files such\r\nas Microsoft Office documents, scripts, archives, and more. Stay on top of analyzing and classifying Cobalt Strike\r\nand other threats. Get started for free and start with 50 file uploads per month.\r\nIntezer Analyze endpoint scan of a Cobalt Strike-infected system via LotL technique\r\nHow to Detect Executables (EXE) Files\r\nThere is an acronym in the United States Armed Forces called “KISS.” KISS stands for “Keep it simple, stupid!”\r\nSometimes simple is better, and another way for Cobalt Strike to be deployed is in a simple Windows EXE form.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 10 of 67\n\nThis requires either social engineering tactics to get the target to execute the malware or another program/script to\r\nexecute the file. This process involves creation of a thread that sets up a named pipe for privilege escalation. Once\r\nthe shellcode is written to the named pipe, it is decrypted and executed in a separate thread.\r\nAn example of one of these payloads is shown in the analysis below. Notice how the Cobalt Strike code is only\r\nshown when it is executed and found in-memory.\r\nCobalt Strike found via memory analysis\r\nHow can Cobalt Strike be detected and remediated?\r\nDue to the many ways Cobalt Strike is deployed, detection can be hard. The use of shellcode, encoding,\r\ncompression, obfuscated strings, process injection, hashing algorithms, domain fronting, different communication\r\nchannels, and dynamically loaded libraries all give malware and network defenses a run for their money.\r\nStatic Analysis\r\nStatic analysis involves examining the file using various techniques without actually having to execute the file\r\nitself. Static analysis can involve hashing the file and finding intel on it, taking a look at the strings to see if there\r\nare functionality or network indicators, or checking imports and running signatures such as YARA for the file.\r\nAlthough useful, static analysis on its own is probably not sufficient to detect Cobalt Strike.\r\nUsing hash-based identification of Cobalt Strike is insufficient, since each payload will be encrypted with\r\ndifferent keys and each configuration will uniquely change the hash value. It is trivial to generate a new payload\r\nfor each new target.\r\nChecking strings may be insufficient also. Strings for pipe names are dynamically generated and incorporate\r\nrandom numbers, meaning they can change every time the malware is executed. Encrypted payloads will also\r\nobfuscate useful strings from static analysis.\r\nAPI Hashing algorithms employed by Cobalt Strike hide imports from static analysis techniques. Signature-based\r\ndetection is great for detecting malware, but due to the versatility of Cobalt Strike’s deployment using multiple\r\nstages and encrypted/obfuscated payloads, an analyst may only be able to detect that a file is going to load and\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 11 of 67\n\nexecute a payload in-memory. Without dynamic analysis, they won’t be able to detect exactly what that payload\r\nwill be.\r\nDynamic Analysis\r\nDynamic analysis is the process of executing the suspect file in order to analyze its behavior and how it affects the\r\nenvironment it runs in. Dynamic analysis can open up new areas to explore as one can follow the malware through\r\neach stage of its deployment and functionality. Dynamic analysis can get the malware to unpack, decode, or\r\ndownload additional stages. These new stages are then subject to further dynamic analysis as well as the\r\npreviously mentioned static analysis techniques.\r\nDynamic analysis does not have many limitations, although some malware includes functionality to detect if it is\r\nbeing observed or running inside a sandboxed environment. There is also the possibility that during dynamic\r\nanalysis, areas of malicious code may not be intentionally executed, and thus not detected in the behavior. The\r\nbest way to detect malicious code is via genetic code analysis which is done automatically for you in Intezer\r\nAnalyze.\r\nCombination of Several Techniques\r\nThe best way to detect Cobalt Strike code is through a combination of dynamic, static, and genetic analysis. Let’s\r\ntake a suspicious looking document from an unknown entity as an example. Before opening the document, we\r\nsubmit it to Intezer Analyze and get the verdict, as shown below.\r\nIntezer Analyze result showing in-memory Cobalt Strike code\r\nThe document drops and executes Cobalt Strike in the memory space of “rundll32.exe.” Signatures are leveraged\r\nto show capabilities and file characteristics. Under the “TTPs” tab the user can see the techniques/capabilities\r\nemployed by the malicious document.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 12 of 67\n\nTTPs section showing capabilities detected during execution\r\nThe document displays interesting techniques such as macros with auto-execution, network activity with a unique\r\nuser agent, office process starting martian subprocess, and process injection. You can also dive deeper into\r\ncapabilities specific to the injected Cobalt Strike process.\r\nThe “IoCs” tab in Intezer Analyze shows indicators that can help you pivot and search in your environment during\r\ninvestigations to map out the scope of an attack. IoCs provide you with file hashes and network indicators such as\r\nURLs, and IP addresses being contacted through irregular ports.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 13 of 67\n\nIoCs tab showing file and network indicators\r\nThe “Behavior” tab shows a more in-depth analysis of the file’s behavior, where you can see the process tree,\r\nnetwork activity, screenshots and file/registry activity.\r\nBehavior tab showing observed behavior during sandbox execution\r\nThe Only Abused Pen Testing Tool?\r\nCobalt Strike is not the only penetration testing or legitimate tool that has been co-opted and abused by threat\r\nactors. In the past, tools such as Pafish (Paranoid Fish) have been used by Iranian actors in their tooling for virtual\r\nmachine (VM) detection. The “Sysinternals” suite has been used extensively by threat actors. Most notably,\r\nPsExec has been used in high-profile attacks such as the 2017 NotPetya global ransomware outbreak.\r\nMore recently, legitimate and penetration testing tools for the cloud have been used by threat actors. The threat\r\nactor TeamTNT has used Weave Scope, a trusted tool which gives the user full access to their cloud environment,\r\nand is integrated with Docker, Kubernetes, the Distributed Cloud Operating System (DC/OS), and AWS Elastic\r\nCompute Cloud (EC2). The attacker installs this tool in order to map the cloud environment of their victim and\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 14 of 67\n\nexecute system commands without needing to deploy malicious code on the server. The same group has also been\r\ndocumented using the penetration testing tool Break Out The Box (BOTB) for cloud and containerized\r\nenvironments.\r\nGet Started for Free\r\nWith Intezer Analyze, you can analyze any suspicious files that you encounter, including non-executable files such\r\nas Microsoft Office documents, scripts, archives, and more. Stay on top of analyzing and classifying Cobalt Strike\r\nand other threats. Get started for free and start with 50 file uploads per month.\r\nAs shown above, the project file has an encoded and compressed payload. This payload is decrypted,\r\ndecompressed, and then copied into memory. The shellcode is then executed in a new thread.\r\nHow to Detect?\r\nAn endpoint with a system injected with Cobalt Strike via MSBuild is shown below. Note the process tree at the\r\nbottom indicating the “fileless code.”\r\nIntezer Analyze endpoint scan of a Cobalt Strike-infected system via LotL technique\r\nHow to Detect Executables (EXE) Files\r\nThere is an acronym in the United States Armed Forces called “KISS.” KISS stands for “Keep it simple, stupid!”\r\nSometimes simple is better, and another way for Cobalt Strike to be deployed is in a simple Windows EXE form.\r\nThis requires either social engineering tactics to get the target to execute the malware or another program/script to\r\nexecute the file. This process involves creation of a thread that sets up a named pipe for privilege escalation. Once\r\nthe shellcode is written to the named pipe, it is decrypted and executed in a separate thread.\r\nAn example of one of these payloads is shown in the analysis below. Notice how the Cobalt Strike code is only\r\nshown when it is executed and found in-memory.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 15 of 67\n\nCobalt Strike found via memory analysis\r\nHow can Cobalt Strike be detected and remediated?\r\nDue to the many ways Cobalt Strike is deployed, detection can be hard. The use of shellcode, encoding,\r\ncompression, obfuscated strings, process injection, hashing algorithms, domain fronting, different communication\r\nchannels, and dynamically loaded libraries all give malware and network defenses a run for their money.\r\nStatic Analysis\r\nStatic analysis involves examining the file using various techniques without actually having to execute the file\r\nitself. Static analysis can involve hashing the file and finding intel on it, taking a look at the strings to see if there\r\nare functionality or network indicators, or checking imports and running signatures such as YARA for the file.\r\nAlthough useful, static analysis on its own is probably not sufficient to detect Cobalt Strike.\r\nUsing hash-based identification of Cobalt Strike is insufficient, since each payload will be encrypted with\r\ndifferent keys and each configuration will uniquely change the hash value. It is trivial to generate a new payload\r\nfor each new target.\r\nChecking strings may be insufficient also. Strings for pipe names are dynamically generated and incorporate\r\nrandom numbers, meaning they can change every time the malware is executed. Encrypted payloads will also\r\nobfuscate useful strings from static analysis.\r\nAPI Hashing algorithms employed by Cobalt Strike hide imports from static analysis techniques. Signature-based\r\ndetection is great for detecting malware, but due to the versatility of Cobalt Strike’s deployment using multiple\r\nstages and encrypted/obfuscated payloads, an analyst may only be able to detect that a file is going to load and\r\nexecute a payload in-memory. Without dynamic analysis, they won’t be able to detect exactly what that payload\r\nwill be.\r\nDynamic Analysis\r\nDynamic analysis is the process of executing the suspect file in order to analyze its behavior and how it affects the\r\nenvironment it runs in. Dynamic analysis can open up new areas to explore as one can follow the malware through\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 16 of 67\n\neach stage of its deployment and functionality. Dynamic analysis can get the malware to unpack, decode, or\r\ndownload additional stages. These new stages are then subject to further dynamic analysis as well as the\r\npreviously mentioned static analysis techniques.\r\nDynamic analysis does not have many limitations, although some malware includes functionality to detect if it is\r\nbeing observed or running inside a sandboxed environment. There is also the possibility that during dynamic\r\nanalysis, areas of malicious code may not be intentionally executed, and thus not detected in the behavior. The\r\nbest way to detect malicious code is via genetic code analysis which is done automatically for you in Intezer\r\nAnalyze.\r\nCombination of Several Techniques\r\nThe best way to detect Cobalt Strike code is through a combination of dynamic, static, and genetic analysis. Let’s\r\ntake a suspicious looking document from an unknown entity as an example. Before opening the document, we\r\nsubmit it to Intezer Analyze and get the verdict, as shown below.\r\nIntezer Analyze result showing in-memory Cobalt Strike code\r\nThe document drops and executes Cobalt Strike in the memory space of “rundll32.exe.” Signatures are leveraged\r\nto show capabilities and file characteristics. Under the “TTPs” tab the user can see the techniques/capabilities\r\nemployed by the malicious document.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 17 of 67\n\nTTPs section showing capabilities detected during execution\r\nThe document displays interesting techniques such as macros with auto-execution, network activity with a unique\r\nuser agent, office process starting martian subprocess, and process injection. You can also dive deeper into\r\ncapabilities specific to the injected Cobalt Strike process.\r\nThe “IoCs” tab in Intezer Analyze shows indicators that can help you pivot and search in your environment during\r\ninvestigations to map out the scope of an attack. IoCs provide you with file hashes and network indicators such as\r\nURLs, and IP addresses being contacted through irregular ports.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 18 of 67\n\nIoCs tab showing file and network indicators\r\nThe “Behavior” tab shows a more in-depth analysis of the file’s behavior, where you can see the process tree,\r\nnetwork activity, screenshots and file/registry activity.\r\nBehavior tab showing observed behavior during sandbox execution\r\nThe Only Abused Pen Testing Tool?\r\nCobalt Strike is not the only penetration testing or legitimate tool that has been co-opted and abused by threat\r\nactors. In the past, tools such as Pafish (Paranoid Fish) have been used by Iranian actors in their tooling for virtual\r\nmachine (VM) detection. The “Sysinternals” suite has been used extensively by threat actors. Most notably,\r\nPsExec has been used in high-profile attacks such as the 2017 NotPetya global ransomware outbreak.\r\nMore recently, legitimate and penetration testing tools for the cloud have been used by threat actors. The threat\r\nactor TeamTNT has used Weave Scope, a trusted tool which gives the user full access to their cloud environment,\r\nand is integrated with Docker, Kubernetes, the Distributed Cloud Operating System (DC/OS), and AWS Elastic\r\nCompute Cloud (EC2). The attacker installs this tool in order to map the cloud environment of their victim and\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 19 of 67\n\nexecute system commands without needing to deploy malicious code on the server. The same group has also been\r\ndocumented using the penetration testing tool Break Out The Box (BOTB) for cloud and containerized\r\nenvironments.\r\nGet Started for Free\r\nWith Intezer Analyze, you can analyze any suspicious files that you encounter, including non-executable files such\r\nas Microsoft Office documents, scripts, archives, and more. Stay on top of analyzing and classifying Cobalt Strike\r\nand other threats. Get started for free and start with 50 file uploads per month.\r\nIntezer Analyze endpoint scan result for Raindrop loading and executing a fileless Cobalt Strike payload\r\nLiving off the Land (LotL) Detection\r\nLiving off the Land (LotL) is the attack process of using legitimate and signed tools, usually provided within the\r\noperating system, to execute malware. This is a powerful tactic as it can result in unauthorized code being\r\nexecuted within the memory space of a trusted process, evading malware defenses by flying under the radar. This\r\ntype of tactic also makes incident response difficult, since analysts can’t just filter out known legitimate processes\r\nduring triage. All processes must be inspected in order to find that one needle in the haystack.\r\nOne popular tool used for LotL operations is the Microsoft.NET framework utility called MSBuild. MSBuild is\r\nthe build platform used for Microsoft and Visual Studio. Visual Studio relies on MSBuild to build projects for\r\ntesting and releases. Attackers are able to pass MSBuild.exe, a project (.proj) file, to build and execute. The\r\npayload, usually shellcode, is injected into another process. This attack is effective for attackers as\r\nmany sandboxing solutions are not able to handle project files and struggle with fileless malware. This technique\r\nwas observed by Cisco Talos researchers in 2020 to deploy Cobalt Strike.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 20 of 67\n\nProject file code\r\nAs shown above, the project file has an encoded and compressed payload. This payload is decrypted,\r\ndecompressed, and then copied into memory. The shellcode is then executed in a new thread.\r\nHow to Detect?\r\nAn endpoint with a system injected with Cobalt Strike via MSBuild is shown below. Note the process tree at the\r\nbottom indicating the “fileless code.”\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 21 of 67\n\nIntezer Analyze endpoint scan of a Cobalt Strike-infected system via LotL technique\r\nHow to Detect Executables (EXE) Files\r\nThere is an acronym in the United States Armed Forces called “KISS.” KISS stands for “Keep it simple, stupid!”\r\nSometimes simple is better, and another way for Cobalt Strike to be deployed is in a simple Windows EXE form.\r\nThis requires either social engineering tactics to get the target to execute the malware or another program/script to\r\nexecute the file. This process involves creation of a thread that sets up a named pipe for privilege escalation. Once\r\nthe shellcode is written to the named pipe, it is decrypted and executed in a separate thread.\r\nAn example of one of these payloads is shown in the analysis below. Notice how the Cobalt Strike code is only\r\nshown when it is executed and found in-memory.\r\nCobalt Strike found via memory analysis\r\nHow can Cobalt Strike be detected and remediated?\r\nDue to the many ways Cobalt Strike is deployed, detection can be hard. The use of shellcode, encoding,\r\ncompression, obfuscated strings, process injection, hashing algorithms, domain fronting, different communication\r\nchannels, and dynamically loaded libraries all give malware and network defenses a run for their money.\r\nStatic Analysis\r\nStatic analysis involves examining the file using various techniques without actually having to execute the file\r\nitself. Static analysis can involve hashing the file and finding intel on it, taking a look at the strings to see if there\r\nare functionality or network indicators, or checking imports and running signatures such as YARA for the file.\r\nAlthough useful, static analysis on its own is probably not sufficient to detect Cobalt Strike.\r\nUsing hash-based identification of Cobalt Strike is insufficient, since each payload will be encrypted with\r\ndifferent keys and each configuration will uniquely change the hash value. It is trivial to generate a new payload\r\nfor each new target.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 22 of 67\n\nChecking strings may be insufficient also. Strings for pipe names are dynamically generated and incorporate\r\nrandom numbers, meaning they can change every time the malware is executed. Encrypted payloads will also\r\nobfuscate useful strings from static analysis.\r\nAPI Hashing algorithms employed by Cobalt Strike hide imports from static analysis techniques. Signature-based\r\ndetection is great for detecting malware, but due to the versatility of Cobalt Strike’s deployment using multiple\r\nstages and encrypted/obfuscated payloads, an analyst may only be able to detect that a file is going to load and\r\nexecute a payload in-memory. Without dynamic analysis, they won’t be able to detect exactly what that payload\r\nwill be.\r\nDynamic Analysis\r\nDynamic analysis is the process of executing the suspect file in order to analyze its behavior and how it affects the\r\nenvironment it runs in. Dynamic analysis can open up new areas to explore as one can follow the malware through\r\neach stage of its deployment and functionality. Dynamic analysis can get the malware to unpack, decode, or\r\ndownload additional stages. These new stages are then subject to further dynamic analysis as well as the\r\npreviously mentioned static analysis techniques.\r\nDynamic analysis does not have many limitations, although some malware includes functionality to detect if it is\r\nbeing observed or running inside a sandboxed environment. There is also the possibility that during dynamic\r\nanalysis, areas of malicious code may not be intentionally executed, and thus not detected in the behavior. The\r\nbest way to detect malicious code is via genetic code analysis which is done automatically for you in Intezer\r\nAnalyze.\r\nCombination of Several Techniques\r\nThe best way to detect Cobalt Strike code is through a combination of dynamic, static, and genetic analysis. Let’s\r\ntake a suspicious looking document from an unknown entity as an example. Before opening the document, we\r\nsubmit it to Intezer Analyze and get the verdict, as shown below.\r\nIntezer Analyze result showing in-memory Cobalt Strike code\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 23 of 67\n\nThe document drops and executes Cobalt Strike in the memory space of “rundll32.exe.” Signatures are leveraged\r\nto show capabilities and file characteristics. Under the “TTPs” tab the user can see the techniques/capabilities\r\nemployed by the malicious document.\r\nTTPs section showing capabilities detected during execution\r\nThe document displays interesting techniques such as macros with auto-execution, network activity with a unique\r\nuser agent, office process starting martian subprocess, and process injection. You can also dive deeper into\r\ncapabilities specific to the injected Cobalt Strike process.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 24 of 67\n\nThe “IoCs” tab in Intezer Analyze shows indicators that can help you pivot and search in your environment during\r\ninvestigations to map out the scope of an attack. IoCs provide you with file hashes and network indicators such as\r\nURLs, and IP addresses being contacted through irregular ports.\r\nIoCs tab showing file and network indicators\r\nThe “Behavior” tab shows a more in-depth analysis of the file’s behavior, where you can see the process tree,\r\nnetwork activity, screenshots and file/registry activity.\r\nBehavior tab showing observed behavior during sandbox execution\r\nThe Only Abused Pen Testing Tool?\r\nCobalt Strike is not the only penetration testing or legitimate tool that has been co-opted and abused by threat\r\nactors. In the past, tools such as Pafish (Paranoid Fish) have been used by Iranian actors in their tooling for virtual\r\nmachine (VM) detection. The “Sysinternals” suite has been used extensively by threat actors. Most notably,\r\nPsExec has been used in high-profile attacks such as the 2017 NotPetya global ransomware outbreak.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 25 of 67\n\nMore recently, legitimate and penetration testing tools for the cloud have been used by threat actors. The threat\r\nactor TeamTNT has used Weave Scope, a trusted tool which gives the user full access to their cloud environment,\r\nand is integrated with Docker, Kubernetes, the Distributed Cloud Operating System (DC/OS), and AWS Elastic\r\nCompute Cloud (EC2). The attacker installs this tool in order to map the cloud environment of their victim and\r\nexecute system commands without needing to deploy malicious code on the server. The same group has also been\r\ndocumented using the penetration testing tool Break Out The Box (BOTB) for cloud and containerized\r\nenvironments.\r\nGet Started for Free\r\nWith Intezer Analyze, you can analyze any suspicious files that you encounter, including non-executable files such\r\nas Microsoft Office documents, scripts, archives, and more. Stay on top of analyzing and classifying Cobalt Strike\r\nand other threats. Get started for free and start with 50 file uploads per month.\r\nThe Raindrop variant is built from a modified version of 7-ZIP source code. It uses a different custom packer than\r\nTEARDROP, also leveraging steganography to locate the start of the encoded payload. Once the encoded payload\r\nhas been located, it extracts, decrypts, and decompresses the data to be executed as shellcode.\r\nIt can often be difficult to detect if your organization has been the victim of a supply chain attack. It can be\r\nespecially hard to collect forensic evidence for an attack when it could be mixed in with the code of legitimate and\r\nlarge files. Due to the nature of supply chain attacks, there are often a large number of machines in an organization\r\ninfected at one time. An action you can take is to run Intezer’s live endpoint scanner across all machines in the\r\norganization. This will give you immediate visibility over all running code and quickly identify infected machines\r\nby detecting any traces of malicious code found in-memory. An example of a machine with Raindrop loading\r\nCobalt Strike is shown in the endpoint scan below.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 26 of 67\n\nIntezer Analyze endpoint scan result for Raindrop loading and executing a fileless Cobalt Strike payload\r\nLiving off the Land (LotL) Detection\r\nLiving off the Land (LotL) is the attack process of using legitimate and signed tools, usually provided within the\r\noperating system, to execute malware. This is a powerful tactic as it can result in unauthorized code being\r\nexecuted within the memory space of a trusted process, evading malware defenses by flying under the radar. This\r\ntype of tactic also makes incident response difficult, since analysts can’t just filter out known legitimate processes\r\nduring triage. All processes must be inspected in order to find that one needle in the haystack.\r\nOne popular tool used for LotL operations is the Microsoft.NET framework utility called MSBuild. MSBuild is\r\nthe build platform used for Microsoft and Visual Studio. Visual Studio relies on MSBuild to build projects for\r\ntesting and releases. Attackers are able to pass MSBuild.exe, a project (.proj) file, to build and execute. The\r\npayload, usually shellcode, is injected into another process. This attack is effective for attackers as\r\nmany sandboxing solutions are not able to handle project files and struggle with fileless malware. This technique\r\nwas observed by Cisco Talos researchers in 2020 to deploy Cobalt Strike.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 27 of 67\n\nProject file code\r\nAs shown above, the project file has an encoded and compressed payload. This payload is decrypted,\r\ndecompressed, and then copied into memory. The shellcode is then executed in a new thread.\r\nHow to Detect?\r\nAn endpoint with a system injected with Cobalt Strike via MSBuild is shown below. Note the process tree at the\r\nbottom indicating the “fileless code.”\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 28 of 67\n\nIntezer Analyze endpoint scan of a Cobalt Strike-infected system via LotL technique\r\nHow to Detect Executables (EXE) Files\r\nThere is an acronym in the United States Armed Forces called “KISS.” KISS stands for “Keep it simple, stupid!”\r\nSometimes simple is better, and another way for Cobalt Strike to be deployed is in a simple Windows EXE form.\r\nThis requires either social engineering tactics to get the target to execute the malware or another program/script to\r\nexecute the file. This process involves creation of a thread that sets up a named pipe for privilege escalation. Once\r\nthe shellcode is written to the named pipe, it is decrypted and executed in a separate thread.\r\nAn example of one of these payloads is shown in the analysis below. Notice how the Cobalt Strike code is only\r\nshown when it is executed and found in-memory.\r\nCobalt Strike found via memory analysis\r\nHow can Cobalt Strike be detected and remediated?\r\nDue to the many ways Cobalt Strike is deployed, detection can be hard. The use of shellcode, encoding,\r\ncompression, obfuscated strings, process injection, hashing algorithms, domain fronting, different communication\r\nchannels, and dynamically loaded libraries all give malware and network defenses a run for their money.\r\nStatic Analysis\r\nStatic analysis involves examining the file using various techniques without actually having to execute the file\r\nitself. Static analysis can involve hashing the file and finding intel on it, taking a look at the strings to see if there\r\nare functionality or network indicators, or checking imports and running signatures such as YARA for the file.\r\nAlthough useful, static analysis on its own is probably not sufficient to detect Cobalt Strike.\r\nUsing hash-based identification of Cobalt Strike is insufficient, since each payload will be encrypted with\r\ndifferent keys and each configuration will uniquely change the hash value. It is trivial to generate a new payload\r\nfor each new target.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 29 of 67\n\nChecking strings may be insufficient also. Strings for pipe names are dynamically generated and incorporate\r\nrandom numbers, meaning they can change every time the malware is executed. Encrypted payloads will also\r\nobfuscate useful strings from static analysis.\r\nAPI Hashing algorithms employed by Cobalt Strike hide imports from static analysis techniques. Signature-based\r\ndetection is great for detecting malware, but due to the versatility of Cobalt Strike’s deployment using multiple\r\nstages and encrypted/obfuscated payloads, an analyst may only be able to detect that a file is going to load and\r\nexecute a payload in-memory. Without dynamic analysis, they won’t be able to detect exactly what that payload\r\nwill be.\r\nDynamic Analysis\r\nDynamic analysis is the process of executing the suspect file in order to analyze its behavior and how it affects the\r\nenvironment it runs in. Dynamic analysis can open up new areas to explore as one can follow the malware through\r\neach stage of its deployment and functionality. Dynamic analysis can get the malware to unpack, decode, or\r\ndownload additional stages. These new stages are then subject to further dynamic analysis as well as the\r\npreviously mentioned static analysis techniques.\r\nDynamic analysis does not have many limitations, although some malware includes functionality to detect if it is\r\nbeing observed or running inside a sandboxed environment. There is also the possibility that during dynamic\r\nanalysis, areas of malicious code may not be intentionally executed, and thus not detected in the behavior. The\r\nbest way to detect malicious code is via genetic code analysis which is done automatically for you in Intezer\r\nAnalyze.\r\nCombination of Several Techniques\r\nThe best way to detect Cobalt Strike code is through a combination of dynamic, static, and genetic analysis. Let’s\r\ntake a suspicious looking document from an unknown entity as an example. Before opening the document, we\r\nsubmit it to Intezer Analyze and get the verdict, as shown below.\r\nIntezer Analyze result showing in-memory Cobalt Strike code\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 30 of 67\n\nThe document drops and executes Cobalt Strike in the memory space of “rundll32.exe.” Signatures are leveraged\r\nto show capabilities and file characteristics. Under the “TTPs” tab the user can see the techniques/capabilities\r\nemployed by the malicious document.\r\nTTPs section showing capabilities detected during execution\r\nThe document displays interesting techniques such as macros with auto-execution, network activity with a unique\r\nuser agent, office process starting martian subprocess, and process injection. You can also dive deeper into\r\ncapabilities specific to the injected Cobalt Strike process.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 31 of 67\n\nThe “IoCs” tab in Intezer Analyze shows indicators that can help you pivot and search in your environment during\r\ninvestigations to map out the scope of an attack. IoCs provide you with file hashes and network indicators such as\r\nURLs, and IP addresses being contacted through irregular ports.\r\nIoCs tab showing file and network indicators\r\nThe “Behavior” tab shows a more in-depth analysis of the file’s behavior, where you can see the process tree,\r\nnetwork activity, screenshots and file/registry activity.\r\nBehavior tab showing observed behavior during sandbox execution\r\nThe Only Abused Pen Testing Tool?\r\nCobalt Strike is not the only penetration testing or legitimate tool that has been co-opted and abused by threat\r\nactors. In the past, tools such as Pafish (Paranoid Fish) have been used by Iranian actors in their tooling for virtual\r\nmachine (VM) detection. The “Sysinternals” suite has been used extensively by threat actors. Most notably,\r\nPsExec has been used in high-profile attacks such as the 2017 NotPetya global ransomware outbreak.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 32 of 67\n\nMore recently, legitimate and penetration testing tools for the cloud have been used by threat actors. The threat\r\nactor TeamTNT has used Weave Scope, a trusted tool which gives the user full access to their cloud environment,\r\nand is integrated with Docker, Kubernetes, the Distributed Cloud Operating System (DC/OS), and AWS Elastic\r\nCompute Cloud (EC2). The attacker installs this tool in order to map the cloud environment of their victim and\r\nexecute system commands without needing to deploy malicious code on the server. The same group has also been\r\ndocumented using the penetration testing tool Break Out The Box (BOTB) for cloud and containerized\r\nenvironments.\r\nGet Started for Free\r\nWith Intezer Analyze, you can analyze any suspicious files that you encounter, including non-executable files such\r\nas Microsoft Office documents, scripts, archives, and more. Stay on top of analyzing and classifying Cobalt Strike\r\nand other threats. Get started for free and start with 50 file uploads per month.\r\nSpreadsheet lure masquerading as an Apple Store receipt\r\nUpon enablement of macros, the spreadsheet will fetch and execute the payload in-memory.\r\nThis can be difficult to detect, as there are multiple degrees of separation before the Cobalt Strike payload is\r\nexecuted. Detection first requires dynamic analysis in order to reach the Cobalt Strike stage. When this stage is\r\nreached, the best ways to detect the running Cobalt Strike code are through static signatures or genetic code\r\nanalysis.\r\nWhen it comes to static signatures, it can be difficult to isolate the exact area in-memory that you should run the\r\nsignatures over. One way this can be achieved is running the file through debugging tools and manually dumping\r\nmemory to perform signature analysis. This can be extremely time consuming and requires a high degree of\r\ntechnical knowledge. Another possible way is to use a sandbox and download memory dumps from a finished\r\nanalysis in order to run static analysis tools. This requires slightly less technical knowledge but it still can be time\r\nconsuming. We suggest taking the suspicious document and uploading it to Intezer Analyze to find out if Cobalt\r\nStrike is hidden in-memory.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 33 of 67\n\nIntezer Analyze result for Cobalt Strike payload\r\nHow to Detect Supply Chain Attacks\r\nOne of the biggest cybersecurity stories of 2020 was the SolarWinds supply chain attack that compromised high-profile entities around the world. This attack was done by an APT group known as NOBELIUM (UNC2452)\r\nleveraging the “Orion” business software to distribute malware to private and public organizations. Among the\r\ndeployed malware was a Cobalt Strike loader dubbed TEARDROP by FireEye. The variant was named Raindrop\r\nby Symantec. The TEARDROP dropper is a memory-only DLL that runs as a service spawning a thread that pulls\r\nthe Cobalt Strike payload from a fake JPG file.\r\nThe Raindrop variant is built from a modified version of 7-ZIP source code. It uses a different custom packer than\r\nTEARDROP, also leveraging steganography to locate the start of the encoded payload. Once the encoded payload\r\nhas been located, it extracts, decrypts, and decompresses the data to be executed as shellcode.\r\nIt can often be difficult to detect if your organization has been the victim of a supply chain attack. It can be\r\nespecially hard to collect forensic evidence for an attack when it could be mixed in with the code of legitimate and\r\nlarge files. Due to the nature of supply chain attacks, there are often a large number of machines in an organization\r\ninfected at one time. An action you can take is to run Intezer’s live endpoint scanner across all machines in the\r\norganization. This will give you immediate visibility over all running code and quickly identify infected machines\r\nby detecting any traces of malicious code found in-memory. An example of a machine with Raindrop loading\r\nCobalt Strike is shown in the endpoint scan below.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 34 of 67\n\nIntezer Analyze endpoint scan result for Raindrop loading and executing a fileless Cobalt Strike payload\r\nLiving off the Land (LotL) Detection\r\nLiving off the Land (LotL) is the attack process of using legitimate and signed tools, usually provided within the\r\noperating system, to execute malware. This is a powerful tactic as it can result in unauthorized code being\r\nexecuted within the memory space of a trusted process, evading malware defenses by flying under the radar. This\r\ntype of tactic also makes incident response difficult, since analysts can’t just filter out known legitimate processes\r\nduring triage. All processes must be inspected in order to find that one needle in the haystack.\r\nOne popular tool used for LotL operations is the Microsoft.NET framework utility called MSBuild. MSBuild is\r\nthe build platform used for Microsoft and Visual Studio. Visual Studio relies on MSBuild to build projects for\r\ntesting and releases. Attackers are able to pass MSBuild.exe, a project (.proj) file, to build and execute. The\r\npayload, usually shellcode, is injected into another process. This attack is effective for attackers as\r\nmany sandboxing solutions are not able to handle project files and struggle with fileless malware. This technique\r\nwas observed by Cisco Talos researchers in 2020 to deploy Cobalt Strike.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 35 of 67\n\nProject file code\r\nAs shown above, the project file has an encoded and compressed payload. This payload is decrypted,\r\ndecompressed, and then copied into memory. The shellcode is then executed in a new thread.\r\nHow to Detect?\r\nAn endpoint with a system injected with Cobalt Strike via MSBuild is shown below. Note the process tree at the\r\nbottom indicating the “fileless code.”\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 36 of 67\n\nIntezer Analyze endpoint scan of a Cobalt Strike-infected system via LotL technique\r\nHow to Detect Executables (EXE) Files\r\nThere is an acronym in the United States Armed Forces called “KISS.” KISS stands for “Keep it simple, stupid!”\r\nSometimes simple is better, and another way for Cobalt Strike to be deployed is in a simple Windows EXE form.\r\nThis requires either social engineering tactics to get the target to execute the malware or another program/script to\r\nexecute the file. This process involves creation of a thread that sets up a named pipe for privilege escalation. Once\r\nthe shellcode is written to the named pipe, it is decrypted and executed in a separate thread.\r\nAn example of one of these payloads is shown in the analysis below. Notice how the Cobalt Strike code is only\r\nshown when it is executed and found in-memory.\r\nCobalt Strike found via memory analysis\r\nHow can Cobalt Strike be detected and remediated?\r\nDue to the many ways Cobalt Strike is deployed, detection can be hard. The use of shellcode, encoding,\r\ncompression, obfuscated strings, process injection, hashing algorithms, domain fronting, different communication\r\nchannels, and dynamically loaded libraries all give malware and network defenses a run for their money.\r\nStatic Analysis\r\nStatic analysis involves examining the file using various techniques without actually having to execute the file\r\nitself. Static analysis can involve hashing the file and finding intel on it, taking a look at the strings to see if there\r\nare functionality or network indicators, or checking imports and running signatures such as YARA for the file.\r\nAlthough useful, static analysis on its own is probably not sufficient to detect Cobalt Strike.\r\nUsing hash-based identification of Cobalt Strike is insufficient, since each payload will be encrypted with\r\ndifferent keys and each configuration will uniquely change the hash value. It is trivial to generate a new payload\r\nfor each new target.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 37 of 67\n\nChecking strings may be insufficient also. Strings for pipe names are dynamically generated and incorporate\r\nrandom numbers, meaning they can change every time the malware is executed. Encrypted payloads will also\r\nobfuscate useful strings from static analysis.\r\nAPI Hashing algorithms employed by Cobalt Strike hide imports from static analysis techniques. Signature-based\r\ndetection is great for detecting malware, but due to the versatility of Cobalt Strike’s deployment using multiple\r\nstages and encrypted/obfuscated payloads, an analyst may only be able to detect that a file is going to load and\r\nexecute a payload in-memory. Without dynamic analysis, they won’t be able to detect exactly what that payload\r\nwill be.\r\nDynamic Analysis\r\nDynamic analysis is the process of executing the suspect file in order to analyze its behavior and how it affects the\r\nenvironment it runs in. Dynamic analysis can open up new areas to explore as one can follow the malware through\r\neach stage of its deployment and functionality. Dynamic analysis can get the malware to unpack, decode, or\r\ndownload additional stages. These new stages are then subject to further dynamic analysis as well as the\r\npreviously mentioned static analysis techniques.\r\nDynamic analysis does not have many limitations, although some malware includes functionality to detect if it is\r\nbeing observed or running inside a sandboxed environment. There is also the possibility that during dynamic\r\nanalysis, areas of malicious code may not be intentionally executed, and thus not detected in the behavior. The\r\nbest way to detect malicious code is via genetic code analysis which is done automatically for you in Intezer\r\nAnalyze.\r\nCombination of Several Techniques\r\nThe best way to detect Cobalt Strike code is through a combination of dynamic, static, and genetic analysis. Let’s\r\ntake a suspicious looking document from an unknown entity as an example. Before opening the document, we\r\nsubmit it to Intezer Analyze and get the verdict, as shown below.\r\nIntezer Analyze result showing in-memory Cobalt Strike code\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 38 of 67\n\nThe document drops and executes Cobalt Strike in the memory space of “rundll32.exe.” Signatures are leveraged\r\nto show capabilities and file characteristics. Under the “TTPs” tab the user can see the techniques/capabilities\r\nemployed by the malicious document.\r\nTTPs section showing capabilities detected during execution\r\nThe document displays interesting techniques such as macros with auto-execution, network activity with a unique\r\nuser agent, office process starting martian subprocess, and process injection. You can also dive deeper into\r\ncapabilities specific to the injected Cobalt Strike process.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 39 of 67\n\nThe “IoCs” tab in Intezer Analyze shows indicators that can help you pivot and search in your environment during\r\ninvestigations to map out the scope of an attack. IoCs provide you with file hashes and network indicators such as\r\nURLs, and IP addresses being contacted through irregular ports.\r\nIoCs tab showing file and network indicators\r\nThe “Behavior” tab shows a more in-depth analysis of the file’s behavior, where you can see the process tree,\r\nnetwork activity, screenshots and file/registry activity.\r\nBehavior tab showing observed behavior during sandbox execution\r\nThe Only Abused Pen Testing Tool?\r\nCobalt Strike is not the only penetration testing or legitimate tool that has been co-opted and abused by threat\r\nactors. In the past, tools such as Pafish (Paranoid Fish) have been used by Iranian actors in their tooling for virtual\r\nmachine (VM) detection. The “Sysinternals” suite has been used extensively by threat actors. Most notably,\r\nPsExec has been used in high-profile attacks such as the 2017 NotPetya global ransomware outbreak.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 40 of 67\n\nMore recently, legitimate and penetration testing tools for the cloud have been used by threat actors. The threat\r\nactor TeamTNT has used Weave Scope, a trusted tool which gives the user full access to their cloud environment,\r\nand is integrated with Docker, Kubernetes, the Distributed Cloud Operating System (DC/OS), and AWS Elastic\r\nCompute Cloud (EC2). The attacker installs this tool in order to map the cloud environment of their victim and\r\nexecute system commands without needing to deploy malicious code on the server. The same group has also been\r\ndocumented using the penetration testing tool Break Out The Box (BOTB) for cloud and containerized\r\nenvironments.\r\nGet Started for Free\r\nWith Intezer Analyze, you can analyze any suspicious files that you encounter, including non-executable files such\r\nas Microsoft Office documents, scripts, archives, and more. Stay on top of analyzing and classifying Cobalt Strike\r\nand other threats. Get started for free and start with 50 file uploads per month.\r\nSpreadsheet lure masquerading as an Apple Store receipt\r\nUpon enablement of macros, the spreadsheet will fetch and execute the payload in-memory.\r\nThis can be difficult to detect, as there are multiple degrees of separation before the Cobalt Strike payload is\r\nexecuted. Detection first requires dynamic analysis in order to reach the Cobalt Strike stage. When this stage is\r\nreached, the best ways to detect the running Cobalt Strike code are through static signatures or genetic code\r\nanalysis.\r\nWhen it comes to static signatures, it can be difficult to isolate the exact area in-memory that you should run the\r\nsignatures over. One way this can be achieved is running the file through debugging tools and manually dumping\r\nmemory to perform signature analysis. This can be extremely time consuming and requires a high degree of\r\ntechnical knowledge. Another possible way is to use a sandbox and download memory dumps from a finished\r\nanalysis in order to run static analysis tools. This requires slightly less technical knowledge but it still can be time\r\nconsuming. We suggest taking the suspicious document and uploading it to Intezer Analyze to find out if Cobalt\r\nStrike is hidden in-memory.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 41 of 67\n\nIntezer Analyze result for Cobalt Strike payload\r\nHow to Detect Supply Chain Attacks\r\nOne of the biggest cybersecurity stories of 2020 was the SolarWinds supply chain attack that compromised high-profile entities around the world. This attack was done by an APT group known as NOBELIUM (UNC2452)\r\nleveraging the “Orion” business software to distribute malware to private and public organizations. Among the\r\ndeployed malware was a Cobalt Strike loader dubbed TEARDROP by FireEye. The variant was named Raindrop\r\nby Symantec. The TEARDROP dropper is a memory-only DLL that runs as a service spawning a thread that pulls\r\nthe Cobalt Strike payload from a fake JPG file.\r\nThe Raindrop variant is built from a modified version of 7-ZIP source code. It uses a different custom packer than\r\nTEARDROP, also leveraging steganography to locate the start of the encoded payload. Once the encoded payload\r\nhas been located, it extracts, decrypts, and decompresses the data to be executed as shellcode.\r\nIt can often be difficult to detect if your organization has been the victim of a supply chain attack. It can be\r\nespecially hard to collect forensic evidence for an attack when it could be mixed in with the code of legitimate and\r\nlarge files. Due to the nature of supply chain attacks, there are often a large number of machines in an organization\r\ninfected at one time. An action you can take is to run Intezer’s live endpoint scanner across all machines in the\r\norganization. This will give you immediate visibility over all running code and quickly identify infected machines\r\nby detecting any traces of malicious code found in-memory. An example of a machine with Raindrop loading\r\nCobalt Strike is shown in the endpoint scan below.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 42 of 67\n\nIntezer Analyze endpoint scan result for Raindrop loading and executing a fileless Cobalt Strike payload\r\nLiving off the Land (LotL) Detection\r\nLiving off the Land (LotL) is the attack process of using legitimate and signed tools, usually provided within the\r\noperating system, to execute malware. This is a powerful tactic as it can result in unauthorized code being\r\nexecuted within the memory space of a trusted process, evading malware defenses by flying under the radar. This\r\ntype of tactic also makes incident response difficult, since analysts can’t just filter out known legitimate processes\r\nduring triage. All processes must be inspected in order to find that one needle in the haystack.\r\nOne popular tool used for LotL operations is the Microsoft.NET framework utility called MSBuild. MSBuild is\r\nthe build platform used for Microsoft and Visual Studio. Visual Studio relies on MSBuild to build projects for\r\ntesting and releases. Attackers are able to pass MSBuild.exe, a project (.proj) file, to build and execute. The\r\npayload, usually shellcode, is injected into another process. This attack is effective for attackers as\r\nmany sandboxing solutions are not able to handle project files and struggle with fileless malware. This technique\r\nwas observed by Cisco Talos researchers in 2020 to deploy Cobalt Strike.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 43 of 67\n\nProject file code\r\nAs shown above, the project file has an encoded and compressed payload. This payload is decrypted,\r\ndecompressed, and then copied into memory. The shellcode is then executed in a new thread.\r\nHow to Detect?\r\nAn endpoint with a system injected with Cobalt Strike via MSBuild is shown below. Note the process tree at the\r\nbottom indicating the “fileless code.”\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 44 of 67\n\nIntezer Analyze endpoint scan of a Cobalt Strike-infected system via LotL technique\r\nHow to Detect Executables (EXE) Files\r\nThere is an acronym in the United States Armed Forces called “KISS.” KISS stands for “Keep it simple, stupid!”\r\nSometimes simple is better, and another way for Cobalt Strike to be deployed is in a simple Windows EXE form.\r\nThis requires either social engineering tactics to get the target to execute the malware or another program/script to\r\nexecute the file. This process involves creation of a thread that sets up a named pipe for privilege escalation. Once\r\nthe shellcode is written to the named pipe, it is decrypted and executed in a separate thread.\r\nAn example of one of these payloads is shown in the analysis below. Notice how the Cobalt Strike code is only\r\nshown when it is executed and found in-memory.\r\nCobalt Strike found via memory analysis\r\nHow can Cobalt Strike be detected and remediated?\r\nDue to the many ways Cobalt Strike is deployed, detection can be hard. The use of shellcode, encoding,\r\ncompression, obfuscated strings, process injection, hashing algorithms, domain fronting, different communication\r\nchannels, and dynamically loaded libraries all give malware and network defenses a run for their money.\r\nStatic Analysis\r\nStatic analysis involves examining the file using various techniques without actually having to execute the file\r\nitself. Static analysis can involve hashing the file and finding intel on it, taking a look at the strings to see if there\r\nare functionality or network indicators, or checking imports and running signatures such as YARA for the file.\r\nAlthough useful, static analysis on its own is probably not sufficient to detect Cobalt Strike.\r\nUsing hash-based identification of Cobalt Strike is insufficient, since each payload will be encrypted with\r\ndifferent keys and each configuration will uniquely change the hash value. It is trivial to generate a new payload\r\nfor each new target.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 45 of 67\n\nChecking strings may be insufficient also. Strings for pipe names are dynamically generated and incorporate\r\nrandom numbers, meaning they can change every time the malware is executed. Encrypted payloads will also\r\nobfuscate useful strings from static analysis.\r\nAPI Hashing algorithms employed by Cobalt Strike hide imports from static analysis techniques. Signature-based\r\ndetection is great for detecting malware, but due to the versatility of Cobalt Strike’s deployment using multiple\r\nstages and encrypted/obfuscated payloads, an analyst may only be able to detect that a file is going to load and\r\nexecute a payload in-memory. Without dynamic analysis, they won’t be able to detect exactly what that payload\r\nwill be.\r\nDynamic Analysis\r\nDynamic analysis is the process of executing the suspect file in order to analyze its behavior and how it affects the\r\nenvironment it runs in. Dynamic analysis can open up new areas to explore as one can follow the malware through\r\neach stage of its deployment and functionality. Dynamic analysis can get the malware to unpack, decode, or\r\ndownload additional stages. These new stages are then subject to further dynamic analysis as well as the\r\npreviously mentioned static analysis techniques.\r\nDynamic analysis does not have many limitations, although some malware includes functionality to detect if it is\r\nbeing observed or running inside a sandboxed environment. There is also the possibility that during dynamic\r\nanalysis, areas of malicious code may not be intentionally executed, and thus not detected in the behavior. The\r\nbest way to detect malicious code is via genetic code analysis which is done automatically for you in Intezer\r\nAnalyze.\r\nCombination of Several Techniques\r\nThe best way to detect Cobalt Strike code is through a combination of dynamic, static, and genetic analysis. Let’s\r\ntake a suspicious looking document from an unknown entity as an example. Before opening the document, we\r\nsubmit it to Intezer Analyze and get the verdict, as shown below.\r\nIntezer Analyze result showing in-memory Cobalt Strike code\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 46 of 67\n\nThe document drops and executes Cobalt Strike in the memory space of “rundll32.exe.” Signatures are leveraged\r\nto show capabilities and file characteristics. Under the “TTPs” tab the user can see the techniques/capabilities\r\nemployed by the malicious document.\r\nTTPs section showing capabilities detected during execution\r\nThe document displays interesting techniques such as macros with auto-execution, network activity with a unique\r\nuser agent, office process starting martian subprocess, and process injection. You can also dive deeper into\r\ncapabilities specific to the injected Cobalt Strike process.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 47 of 67\n\nThe “IoCs” tab in Intezer Analyze shows indicators that can help you pivot and search in your environment during\r\ninvestigations to map out the scope of an attack. IoCs provide you with file hashes and network indicators such as\r\nURLs, and IP addresses being contacted through irregular ports.\r\nIoCs tab showing file and network indicators\r\nThe “Behavior” tab shows a more in-depth analysis of the file’s behavior, where you can see the process tree,\r\nnetwork activity, screenshots and file/registry activity.\r\nBehavior tab showing observed behavior during sandbox execution\r\nThe Only Abused Pen Testing Tool?\r\nCobalt Strike is not the only penetration testing or legitimate tool that has been co-opted and abused by threat\r\nactors. In the past, tools such as Pafish (Paranoid Fish) have been used by Iranian actors in their tooling for virtual\r\nmachine (VM) detection. The “Sysinternals” suite has been used extensively by threat actors. Most notably,\r\nPsExec has been used in high-profile attacks such as the 2017 NotPetya global ransomware outbreak.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 48 of 67\n\nMore recently, legitimate and penetration testing tools for the cloud have been used by threat actors. The threat\r\nactor TeamTNT has used Weave Scope, a trusted tool which gives the user full access to their cloud environment,\r\nand is integrated with Docker, Kubernetes, the Distributed Cloud Operating System (DC/OS), and AWS Elastic\r\nCompute Cloud (EC2). The attacker installs this tool in order to map the cloud environment of their victim and\r\nexecute system commands without needing to deploy malicious code on the server. The same group has also been\r\ndocumented using the penetration testing tool Break Out The Box (BOTB) for cloud and containerized\r\nenvironments.\r\nGet Started for Free\r\nWith Intezer Analyze, you can analyze any suspicious files that you encounter, including non-executable files such\r\nas Microsoft Office documents, scripts, archives, and more. Stay on top of analyzing and classifying Cobalt Strike\r\nand other threats. Get started for free and start with 50 file uploads per month.\r\nOneDrive URLs sent to victims\r\nUsing cloud storage links to deliver malicious files is a well-known strategy. It leverages the good reputation of\r\ncloud provider domains such as Microsoft, Amazon, and Google to bypass domain reputation-based security\r\ncontrols. This link delivers an Excel file pretending to be an Apple Store invoice requesting the target “enable\r\ncontent to view receipt.”\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 49 of 67\n\nSpreadsheet lure masquerading as an Apple Store receipt\r\nUpon enablement of macros, the spreadsheet will fetch and execute the payload in-memory.\r\nThis can be difficult to detect, as there are multiple degrees of separation before the Cobalt Strike payload is\r\nexecuted. Detection first requires dynamic analysis in order to reach the Cobalt Strike stage. When this stage is\r\nreached, the best ways to detect the running Cobalt Strike code are through static signatures or genetic code\r\nanalysis.\r\nWhen it comes to static signatures, it can be difficult to isolate the exact area in-memory that you should run the\r\nsignatures over. One way this can be achieved is running the file through debugging tools and manually dumping\r\nmemory to perform signature analysis. This can be extremely time consuming and requires a high degree of\r\ntechnical knowledge. Another possible way is to use a sandbox and download memory dumps from a finished\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 50 of 67\n\nanalysis in order to run static analysis tools. This requires slightly less technical knowledge but it still can be time\r\nconsuming. We suggest taking the suspicious document and uploading it to Intezer Analyze to find out if Cobalt\r\nStrike is hidden in-memory.\r\nIntezer Analyze result for Cobalt Strike payload\r\nHow to Detect Supply Chain Attacks\r\nOne of the biggest cybersecurity stories of 2020 was the SolarWinds supply chain attack that compromised high-profile entities around the world. This attack was done by an APT group known as NOBELIUM (UNC2452)\r\nleveraging the “Orion” business software to distribute malware to private and public organizations. Among the\r\ndeployed malware was a Cobalt Strike loader dubbed TEARDROP by FireEye. The variant was named Raindrop\r\nby Symantec. The TEARDROP dropper is a memory-only DLL that runs as a service spawning a thread that pulls\r\nthe Cobalt Strike payload from a fake JPG file.\r\nThe Raindrop variant is built from a modified version of 7-ZIP source code. It uses a different custom packer than\r\nTEARDROP, also leveraging steganography to locate the start of the encoded payload. Once the encoded payload\r\nhas been located, it extracts, decrypts, and decompresses the data to be executed as shellcode.\r\nIt can often be difficult to detect if your organization has been the victim of a supply chain attack. It can be\r\nespecially hard to collect forensic evidence for an attack when it could be mixed in with the code of legitimate and\r\nlarge files. Due to the nature of supply chain attacks, there are often a large number of machines in an organization\r\ninfected at one time. An action you can take is to run Intezer’s live endpoint scanner across all machines in the\r\norganization. This will give you immediate visibility over all running code and quickly identify infected machines\r\nby detecting any traces of malicious code found in-memory. An example of a machine with Raindrop loading\r\nCobalt Strike is shown in the endpoint scan below.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 51 of 67\n\nIntezer Analyze endpoint scan result for Raindrop loading and executing a fileless Cobalt Strike payload\r\nLiving off the Land (LotL) Detection\r\nLiving off the Land (LotL) is the attack process of using legitimate and signed tools, usually provided within the\r\noperating system, to execute malware. This is a powerful tactic as it can result in unauthorized code being\r\nexecuted within the memory space of a trusted process, evading malware defenses by flying under the radar. This\r\ntype of tactic also makes incident response difficult, since analysts can’t just filter out known legitimate processes\r\nduring triage. All processes must be inspected in order to find that one needle in the haystack.\r\nOne popular tool used for LotL operations is the Microsoft.NET framework utility called MSBuild. MSBuild is\r\nthe build platform used for Microsoft and Visual Studio. Visual Studio relies on MSBuild to build projects for\r\ntesting and releases. Attackers are able to pass MSBuild.exe, a project (.proj) file, to build and execute. The\r\npayload, usually shellcode, is injected into another process. This attack is effective for attackers as\r\nmany sandboxing solutions are not able to handle project files and struggle with fileless malware. This technique\r\nwas observed by Cisco Talos researchers in 2020 to deploy Cobalt Strike.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 52 of 67\n\nProject file code\r\nAs shown above, the project file has an encoded and compressed payload. This payload is decrypted,\r\ndecompressed, and then copied into memory. The shellcode is then executed in a new thread.\r\nHow to Detect?\r\nAn endpoint with a system injected with Cobalt Strike via MSBuild is shown below. Note the process tree at the\r\nbottom indicating the “fileless code.”\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 53 of 67\n\nIntezer Analyze endpoint scan of a Cobalt Strike-infected system via LotL technique\r\nHow to Detect Executables (EXE) Files\r\nThere is an acronym in the United States Armed Forces called “KISS.” KISS stands for “Keep it simple, stupid!”\r\nSometimes simple is better, and another way for Cobalt Strike to be deployed is in a simple Windows EXE form.\r\nThis requires either social engineering tactics to get the target to execute the malware or another program/script to\r\nexecute the file. This process involves creation of a thread that sets up a named pipe for privilege escalation. Once\r\nthe shellcode is written to the named pipe, it is decrypted and executed in a separate thread.\r\nAn example of one of these payloads is shown in the analysis below. Notice how the Cobalt Strike code is only\r\nshown when it is executed and found in-memory.\r\nCobalt Strike found via memory analysis\r\nHow can Cobalt Strike be detected and remediated?\r\nDue to the many ways Cobalt Strike is deployed, detection can be hard. The use of shellcode, encoding,\r\ncompression, obfuscated strings, process injection, hashing algorithms, domain fronting, different communication\r\nchannels, and dynamically loaded libraries all give malware and network defenses a run for their money.\r\nStatic Analysis\r\nStatic analysis involves examining the file using various techniques without actually having to execute the file\r\nitself. Static analysis can involve hashing the file and finding intel on it, taking a look at the strings to see if there\r\nare functionality or network indicators, or checking imports and running signatures such as YARA for the file.\r\nAlthough useful, static analysis on its own is probably not sufficient to detect Cobalt Strike.\r\nUsing hash-based identification of Cobalt Strike is insufficient, since each payload will be encrypted with\r\ndifferent keys and each configuration will uniquely change the hash value. It is trivial to generate a new payload\r\nfor each new target.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 54 of 67\n\nChecking strings may be insufficient also. Strings for pipe names are dynamically generated and incorporate\r\nrandom numbers, meaning they can change every time the malware is executed. Encrypted payloads will also\r\nobfuscate useful strings from static analysis.\r\nAPI Hashing algorithms employed by Cobalt Strike hide imports from static analysis techniques. Signature-based\r\ndetection is great for detecting malware, but due to the versatility of Cobalt Strike’s deployment using multiple\r\nstages and encrypted/obfuscated payloads, an analyst may only be able to detect that a file is going to load and\r\nexecute a payload in-memory. Without dynamic analysis, they won’t be able to detect exactly what that payload\r\nwill be.\r\nDynamic Analysis\r\nDynamic analysis is the process of executing the suspect file in order to analyze its behavior and how it affects the\r\nenvironment it runs in. Dynamic analysis can open up new areas to explore as one can follow the malware through\r\neach stage of its deployment and functionality. Dynamic analysis can get the malware to unpack, decode, or\r\ndownload additional stages. These new stages are then subject to further dynamic analysis as well as the\r\npreviously mentioned static analysis techniques.\r\nDynamic analysis does not have many limitations, although some malware includes functionality to detect if it is\r\nbeing observed or running inside a sandboxed environment. There is also the possibility that during dynamic\r\nanalysis, areas of malicious code may not be intentionally executed, and thus not detected in the behavior. The\r\nbest way to detect malicious code is via genetic code analysis which is done automatically for you in Intezer\r\nAnalyze.\r\nCombination of Several Techniques\r\nThe best way to detect Cobalt Strike code is through a combination of dynamic, static, and genetic analysis. Let’s\r\ntake a suspicious looking document from an unknown entity as an example. Before opening the document, we\r\nsubmit it to Intezer Analyze and get the verdict, as shown below.\r\nIntezer Analyze result showing in-memory Cobalt Strike code\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 55 of 67\n\nThe document drops and executes Cobalt Strike in the memory space of “rundll32.exe.” Signatures are leveraged\r\nto show capabilities and file characteristics. Under the “TTPs” tab the user can see the techniques/capabilities\r\nemployed by the malicious document.\r\nTTPs section showing capabilities detected during execution\r\nThe document displays interesting techniques such as macros with auto-execution, network activity with a unique\r\nuser agent, office process starting martian subprocess, and process injection. You can also dive deeper into\r\ncapabilities specific to the injected Cobalt Strike process.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 56 of 67\n\nThe “IoCs” tab in Intezer Analyze shows indicators that can help you pivot and search in your environment during\r\ninvestigations to map out the scope of an attack. IoCs provide you with file hashes and network indicators such as\r\nURLs, and IP addresses being contacted through irregular ports.\r\nIoCs tab showing file and network indicators\r\nThe “Behavior” tab shows a more in-depth analysis of the file’s behavior, where you can see the process tree,\r\nnetwork activity, screenshots and file/registry activity.\r\nBehavior tab showing observed behavior during sandbox execution\r\nThe Only Abused Pen Testing Tool?\r\nCobalt Strike is not the only penetration testing or legitimate tool that has been co-opted and abused by threat\r\nactors. In the past, tools such as Pafish (Paranoid Fish) have been used by Iranian actors in their tooling for virtual\r\nmachine (VM) detection. The “Sysinternals” suite has been used extensively by threat actors. Most notably,\r\nPsExec has been used in high-profile attacks such as the 2017 NotPetya global ransomware outbreak.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 57 of 67\n\nMore recently, legitimate and penetration testing tools for the cloud have been used by threat actors. The threat\r\nactor TeamTNT has used Weave Scope, a trusted tool which gives the user full access to their cloud environment,\r\nand is integrated with Docker, Kubernetes, the Distributed Cloud Operating System (DC/OS), and AWS Elastic\r\nCompute Cloud (EC2). The attacker installs this tool in order to map the cloud environment of their victim and\r\nexecute system commands without needing to deploy malicious code on the server. The same group has also been\r\ndocumented using the penetration testing tool Break Out The Box (BOTB) for cloud and containerized\r\nenvironments.\r\nGet Started for Free\r\nWith Intezer Analyze, you can analyze any suspicious files that you encounter, including non-executable files such\r\nas Microsoft Office documents, scripts, archives, and more. Stay on top of analyzing and classifying Cobalt Strike\r\nand other threats. Get started for free and start with 50 file uploads per month.\r\nOneDrive URLs sent to victims\r\nUsing cloud storage links to deliver malicious files is a well-known strategy. It leverages the good reputation of\r\ncloud provider domains such as Microsoft, Amazon, and Google to bypass domain reputation-based security\r\ncontrols. This link delivers an Excel file pretending to be an Apple Store invoice requesting the target “enable\r\ncontent to view receipt.”\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 58 of 67\n\nSpreadsheet lure masquerading as an Apple Store receipt\r\nUpon enablement of macros, the spreadsheet will fetch and execute the payload in-memory.\r\nThis can be difficult to detect, as there are multiple degrees of separation before the Cobalt Strike payload is\r\nexecuted. Detection first requires dynamic analysis in order to reach the Cobalt Strike stage. When this stage is\r\nreached, the best ways to detect the running Cobalt Strike code are through static signatures or genetic code\r\nanalysis.\r\nWhen it comes to static signatures, it can be difficult to isolate the exact area in-memory that you should run the\r\nsignatures over. One way this can be achieved is running the file through debugging tools and manually dumping\r\nmemory to perform signature analysis. This can be extremely time consuming and requires a high degree of\r\ntechnical knowledge. Another possible way is to use a sandbox and download memory dumps from a finished\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 59 of 67\n\nanalysis in order to run static analysis tools. This requires slightly less technical knowledge but it still can be time\r\nconsuming. We suggest taking the suspicious document and uploading it to Intezer Analyze to find out if Cobalt\r\nStrike is hidden in-memory.\r\nIntezer Analyze result for Cobalt Strike payload\r\nHow to Detect Supply Chain Attacks\r\nOne of the biggest cybersecurity stories of 2020 was the SolarWinds supply chain attack that compromised high-profile entities around the world. This attack was done by an APT group known as NOBELIUM (UNC2452)\r\nleveraging the “Orion” business software to distribute malware to private and public organizations. Among the\r\ndeployed malware was a Cobalt Strike loader dubbed TEARDROP by FireEye. The variant was named Raindrop\r\nby Symantec. The TEARDROP dropper is a memory-only DLL that runs as a service spawning a thread that pulls\r\nthe Cobalt Strike payload from a fake JPG file.\r\nThe Raindrop variant is built from a modified version of 7-ZIP source code. It uses a different custom packer than\r\nTEARDROP, also leveraging steganography to locate the start of the encoded payload. Once the encoded payload\r\nhas been located, it extracts, decrypts, and decompresses the data to be executed as shellcode.\r\nIt can often be difficult to detect if your organization has been the victim of a supply chain attack. It can be\r\nespecially hard to collect forensic evidence for an attack when it could be mixed in with the code of legitimate and\r\nlarge files. Due to the nature of supply chain attacks, there are often a large number of machines in an organization\r\ninfected at one time. An action you can take is to run Intezer’s live endpoint scanner across all machines in the\r\norganization. This will give you immediate visibility over all running code and quickly identify infected machines\r\nby detecting any traces of malicious code found in-memory. An example of a machine with Raindrop loading\r\nCobalt Strike is shown in the endpoint scan below.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 60 of 67\n\nIntezer Analyze endpoint scan result for Raindrop loading and executing a fileless Cobalt Strike payload\r\nLiving off the Land (LotL) Detection\r\nLiving off the Land (LotL) is the attack process of using legitimate and signed tools, usually provided within the\r\noperating system, to execute malware. This is a powerful tactic as it can result in unauthorized code being\r\nexecuted within the memory space of a trusted process, evading malware defenses by flying under the radar. This\r\ntype of tactic also makes incident response difficult, since analysts can’t just filter out known legitimate processes\r\nduring triage. All processes must be inspected in order to find that one needle in the haystack.\r\nOne popular tool used for LotL operations is the Microsoft.NET framework utility called MSBuild. MSBuild is\r\nthe build platform used for Microsoft and Visual Studio. Visual Studio relies on MSBuild to build projects for\r\ntesting and releases. Attackers are able to pass MSBuild.exe, a project (.proj) file, to build and execute. The\r\npayload, usually shellcode, is injected into another process. This attack is effective for attackers as\r\nmany sandboxing solutions are not able to handle project files and struggle with fileless malware. This technique\r\nwas observed by Cisco Talos researchers in 2020 to deploy Cobalt Strike.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 61 of 67\n\nProject file code\r\nAs shown above, the project file has an encoded and compressed payload. This payload is decrypted,\r\ndecompressed, and then copied into memory. The shellcode is then executed in a new thread.\r\nHow to Detect?\r\nAn endpoint with a system injected with Cobalt Strike via MSBuild is shown below. Note the process tree at the\r\nbottom indicating the “fileless code.”\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 62 of 67\n\nIntezer Analyze endpoint scan of a Cobalt Strike-infected system via LotL technique\r\nHow to Detect Executables (EXE) Files\r\nThere is an acronym in the United States Armed Forces called “KISS.” KISS stands for “Keep it simple, stupid!”\r\nSometimes simple is better, and another way for Cobalt Strike to be deployed is in a simple Windows EXE form.\r\nThis requires either social engineering tactics to get the target to execute the malware or another program/script to\r\nexecute the file. This process involves creation of a thread that sets up a named pipe for privilege escalation. Once\r\nthe shellcode is written to the named pipe, it is decrypted and executed in a separate thread.\r\nAn example of one of these payloads is shown in the analysis below. Notice how the Cobalt Strike code is only\r\nshown when it is executed and found in-memory.\r\nCobalt Strike found via memory analysis\r\nHow can Cobalt Strike be detected and remediated?\r\nDue to the many ways Cobalt Strike is deployed, detection can be hard. The use of shellcode, encoding,\r\ncompression, obfuscated strings, process injection, hashing algorithms, domain fronting, different communication\r\nchannels, and dynamically loaded libraries all give malware and network defenses a run for their money.\r\nStatic Analysis\r\nStatic analysis involves examining the file using various techniques without actually having to execute the file\r\nitself. Static analysis can involve hashing the file and finding intel on it, taking a look at the strings to see if there\r\nare functionality or network indicators, or checking imports and running signatures such as YARA for the file.\r\nAlthough useful, static analysis on its own is probably not sufficient to detect Cobalt Strike.\r\nUsing hash-based identification of Cobalt Strike is insufficient, since each payload will be encrypted with\r\ndifferent keys and each configuration will uniquely change the hash value. It is trivial to generate a new payload\r\nfor each new target.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 63 of 67\n\nChecking strings may be insufficient also. Strings for pipe names are dynamically generated and incorporate\r\nrandom numbers, meaning they can change every time the malware is executed. Encrypted payloads will also\r\nobfuscate useful strings from static analysis.\r\nAPI Hashing algorithms employed by Cobalt Strike hide imports from static analysis techniques. Signature-based\r\ndetection is great for detecting malware, but due to the versatility of Cobalt Strike’s deployment using multiple\r\nstages and encrypted/obfuscated payloads, an analyst may only be able to detect that a file is going to load and\r\nexecute a payload in-memory. Without dynamic analysis, they won’t be able to detect exactly what that payload\r\nwill be.\r\nDynamic Analysis\r\nDynamic analysis is the process of executing the suspect file in order to analyze its behavior and how it affects the\r\nenvironment it runs in. Dynamic analysis can open up new areas to explore as one can follow the malware through\r\neach stage of its deployment and functionality. Dynamic analysis can get the malware to unpack, decode, or\r\ndownload additional stages. These new stages are then subject to further dynamic analysis as well as the\r\npreviously mentioned static analysis techniques.\r\nDynamic analysis does not have many limitations, although some malware includes functionality to detect if it is\r\nbeing observed or running inside a sandboxed environment. There is also the possibility that during dynamic\r\nanalysis, areas of malicious code may not be intentionally executed, and thus not detected in the behavior. The\r\nbest way to detect malicious code is via genetic code analysis which is done automatically for you in Intezer\r\nAnalyze.\r\nCombination of Several Techniques\r\nThe best way to detect Cobalt Strike code is through a combination of dynamic, static, and genetic analysis. Let’s\r\ntake a suspicious looking document from an unknown entity as an example. Before opening the document, we\r\nsubmit it to Intezer Analyze and get the verdict, as shown below.\r\nIntezer Analyze result showing in-memory Cobalt Strike code\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 64 of 67\n\nThe document drops and executes Cobalt Strike in the memory space of “rundll32.exe.” Signatures are leveraged\r\nto show capabilities and file characteristics. Under the “TTPs” tab the user can see the techniques/capabilities\r\nemployed by the malicious document.\r\nTTPs section showing capabilities detected during execution\r\nThe document displays interesting techniques such as macros with auto-execution, network activity with a unique\r\nuser agent, office process starting martian subprocess, and process injection. You can also dive deeper into\r\ncapabilities specific to the injected Cobalt Strike process.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 65 of 67\n\nThe “IoCs” tab in Intezer Analyze shows indicators that can help you pivot and search in your environment during\r\ninvestigations to map out the scope of an attack. IoCs provide you with file hashes and network indicators such as\r\nURLs, and IP addresses being contacted through irregular ports.\r\nIoCs tab showing file and network indicators\r\nThe “Behavior” tab shows a more in-depth analysis of the file’s behavior, where you can see the process tree,\r\nnetwork activity, screenshots and file/registry activity.\r\nBehavior tab showing observed behavior during sandbox execution\r\nThe Only Abused Pen Testing Tool?\r\nCobalt Strike is not the only penetration testing or legitimate tool that has been co-opted and abused by threat\r\nactors. In the past, tools such as Pafish (Paranoid Fish) have been used by Iranian actors in their tooling for virtual\r\nmachine (VM) detection. The “Sysinternals” suite has been used extensively by threat actors. Most notably,\r\nPsExec has been used in high-profile attacks such as the 2017 NotPetya global ransomware outbreak.\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 66 of 67\n\nMore recently, legitimate and penetration testing tools for the cloud have been used by threat actors. The threat\r\nactor TeamTNT has used Weave Scope, a trusted tool which gives the user full access to their cloud environment,\r\nand is integrated with Docker, Kubernetes, the Distributed Cloud Operating System (DC/OS), and AWS Elastic\r\nCompute Cloud (EC2). The attacker installs this tool in order to map the cloud environment of their victim and\r\nexecute system commands without needing to deploy malicious code on the server. The same group has also been\r\ndocumented using the penetration testing tool Break Out The Box (BOTB) for cloud and containerized\r\nenvironments.\r\nGet Started for Free\r\nWith Intezer Analyze, you can analyze any suspicious files that you encounter, including non-executable files such\r\nas Microsoft Office documents, scripts, archives, and more. Stay on top of analyzing and classifying Cobalt Strike\r\nand other threats. Get started for free and start with 50 file uploads per month.\r\nSource: https://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nhttps://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/\r\nPage 67 of 67",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"references": [
		"https://www.intezer.com/blog/malware-analysis/cobalt-strike-detect-this-persistent-threat/"
	],
	"report_names": [
		"cobalt-strike-detect-this-persistent-threat"
	],
	"threat_actors": [
		{
			"id": "b43e5ea9-d8c8-4efa-b5bf-f1efb37174ba",
			"created_at": "2022-10-25T16:07:24.36191Z",
			"updated_at": "2026-04-10T02:00:04.954902Z",
			"deleted_at": null,
			"main_name": "UNC2452",
			"aliases": [
				"Dark Halo",
				"Nobelium",
				"SolarStorm",
				"StellarParticle",
				"UNC2452"
			],
			"source_name": "ETDA:UNC2452",
			"tools": [],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"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": "1d3f9dec-b033-48a5-8b1e-f67a29429e89",
			"created_at": "2022-10-25T15:50:23.739197Z",
			"updated_at": "2026-04-10T02:00:05.275809Z",
			"deleted_at": null,
			"main_name": "UNC2452",
			"aliases": [
				"UNC2452",
				"NOBELIUM",
				"StellarParticle",
				"Dark Halo"
			],
			"source_name": "MITRE:UNC2452",
			"tools": [
				"Sibot",
				"Mimikatz",
				"Cobalt Strike",
				"AdFind",
				"GoldMax"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "f809bfcb-b200-4988-80a8-be78ef6a52ef",
			"created_at": "2023-01-06T13:46:39.186988Z",
			"updated_at": "2026-04-10T02:00:03.240002Z",
			"deleted_at": null,
			"main_name": "TeamTNT",
			"aliases": [
				"Adept Libra"
			],
			"source_name": "MISPGALAXY:TeamTNT",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "c3ca592f-0669-49bd-ab5c-310007ab2fb4",
			"created_at": "2022-10-25T15:50:23.334495Z",
			"updated_at": "2026-04-10T02:00:05.264841Z",
			"deleted_at": null,
			"main_name": "TeamTNT",
			"aliases": [
				"TeamTNT"
			],
			"source_name": "MITRE:TeamTNT",
			"tools": [
				"Peirates",
				"MimiPenguin",
				"LaZagne",
				"Hildegard"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"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": "70872c3a-e788-4b55-a7d6-b2df52001ad0",
			"created_at": "2023-01-06T13:46:39.18401Z",
			"updated_at": "2026-04-10T02:00:03.239111Z",
			"deleted_at": null,
			"main_name": "UNC2452",
			"aliases": [
				"DarkHalo",
				"StellarParticle",
				"NOBELIUM",
				"Solar Phoenix",
				"Midnight Blizzard"
			],
			"source_name": "MISPGALAXY:UNC2452",
			"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": 1775434213,
	"ts_updated_at": 1775792253,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/bec23043f910b07042da964611d7d0770857c907.pdf",
		"text": "https://archive.orkl.eu/bec23043f910b07042da964611d7d0770857c907.txt",
		"img": "https://archive.orkl.eu/bec23043f910b07042da964611d7d0770857c907.jpg"
	}
}